Engineers Pay the Bill for AI Slop, and PMs Can Prevent It

Brandolini’s Sentence Met Free Production

Alberto Brandolini wrote a sentence in 2013. The energy needed to refute bullshit is an order of magnitude bigger than the energy needed to produce it. Known as Brandolini’s law, it was aimed at arguments on social media. It fits a sprint planning session today just as well.

In May 2024, Simon Willison suggested calling unwanted AI output “slop”, and the word stuck. On a team, slop mostly shows up as specs, PRDs, meeting summaries and user stories. It takes minutes to produce. Reading and refuting it takes a person’s hours, and that person turns out to be the engineer who has to turn the spec into code.

That is why the bottleneck moved from production to decision. Once writing a document costs close to nothing, deciding which documents deserve to be written is the only expensive job left. The product discovery Marty Cagan describes in INSPIRED revolves around exactly this question of what to build and why.

The feeling of speed is not to be trusted either. In July 2025, METR published a controlled experiment: 16 experienced developers working in their own open source repositories, 246 tasks. Tasks where AI tools were allowed took 19 percent longer. Before the study the developers expected a 24 percent speedup, and afterward they still believed they had been 20 percent faster. The sample is small and it is a single study, so it can’t be generalized. Still, the felt speedup and the measurement did not line up, and a team that celebrates “we shipped a lot of documents this week” is making the same mistake.

Slop Starts With a Vague Brief

Put a one-page brief next to a generated PRD. The ten-page document looks complete, the headings are in place and every section is filled. Look closely, though, and each section is the same vague sentence stretched out with different words. The brief is short, and every sentence in it rests on a decision.

This is exactly where slop gets produced. “The user experience should be improved” is a reasonable sentence, but it doesn’t say for whom, on which screen, or measured against what. You can’t refute a sentence like that, because there is no claim to refute. Everyone nods and moves on, and only the delivered output reveals the mistake.

The source is usually not the model’s capability. When the input is blurry, the model turns the blur into fluent paragraphs. An unverified assumption travels the same road. If “users miss notifications” is a PM’s guess and nobody checked it against the logs, the AI builds ten pages on top of that guess. The more pages there are, the truer the assumption looks, because a crowd of text now surrounds it.

One check is enough: for every sentence in the document, ask “if I deleted this, would anyone notice?” If nobody would, the sentence goes. Run the same check on a PRD that lands on your desk, mark the deletable sentences, and see how close what remains comes to the decision in the brief. Often what remains is a single paragraph, and doing justice to that paragraph is the PM’s job.

Four Places Need a Signature

A document with no human name on it belongs to nobody. The person listed on the “prepared by” line under the title should be able to defend every sentence of it in a meeting. If they can’t, they didn’t write the sentence. They only passed it along.

Applying this rule everywhere wears a team out. There is no point asking for a signature on meeting notes. Four of the places where slop gets in do need one:

• Problem statement. Work built on the wrong problem solves the wrong problem, however cleanly it is delivered. A person should write this sentence in their own words.
• Acceptance criteria. A criterion that can’t be tested can’t measure “done”.
• Release notes. They are the only text telling customers what changed, and if they promise something false, the support team pays the bill.
• User-facing text such as error messages, confirmation emails and one-line explanations on screen. Users read these as the voice of the product.

When a senior engineer sees an assumption in one of these places, they should be able to ask “What data is this sentence based on?” In a signed document there is someone to ask and someone to answer. In an unsigned one the question hangs in the air.

“The model wrote it that way” is not an answer. The owner either shows the source of the assumption or deletes it. Both take five minutes. To start, add a field called “Assumptions I rely on” to the brief template and the PR template, with a name under it.

At the team level there are three early signs. PR descriptions get longer without getting more informative, nobody opens the meeting notes, and the same idea is repeated across three different documents. If you see any of these, go back to the sign-off points.

Saying No to an Idea That Has a Demo

Building a prototype has become cheap, so the number of candidates explodes. Three ideas come out of a meeting, and the next morning all three have a working demo on the table. Saying no to an idea with a demo is much harder than saying no to an idea that has only been described.

A relative of technical debt is born here, and I call it AI debt. Features that were built but nobody asked for, screens that are maintained but never opened, and half-finished experiments are its line items. Each one means tests, documentation, and someone reading it one day. The cost of production has fallen to near zero, while the cost of ownership has stayed where it was.

The PM’s real filtering job lands here too. The purpose of prioritization frameworks is to keep ideas that can’t clear the bar at the door and to leave the team’s attention for the ones that can. A no also keeps a record for every item on the list: if the reason it wasn’t built is written down, then when the same idea comes back with a demo three months later, the discussion doesn’t start from zero.

Customer contact can’t be delegated here either. An AI summary does not replace a user interview. Interview recordings, support tickets and raw data should stay in the PM’s hands, and the summary should be only a second reading. To filter, you first have to see with your own eyes what is being filtered.

Set the Bar With the Team’s Own Briefs

As a technical manager, I find that setting a shared bar works better than auditing the PM on AI use. In concrete form it is a short folder: good and bad briefs side by side, with a written note under each explaining why it is good or bad.

A bad example goes like this: “Let users manage their invoices easily, build a smart invoice dashboard.” It isn’t clear who comes with which problem, or when we will count it as done.

A good example goes like this: “The most repeated complaint in support records is users who can’t find their invoice PDF. After login, the user should be able to download their last six invoices in three clicks. We won’t do: bulk download, sending by email.” It is one page with one owner, an engineer or a model can test it, and it states what is out of scope.

These two examples should be picked from your own team’s history, not copied from this post. If the bar is imposed on the PM from outside, the team keeps it up as a rule. If it comes out of their own briefs, they own it as a quality standard.

This week, take your team’s last three briefs, ask of every sentence “if I deleted this, would anyone notice?”, and share what remains in the team channel. Looking at what survived will show you where to put the next rule.