When agentic coding first landed in engineering teams, the early promise was simple: offload the tedious parts and keep the interesting ones. What nobody anticipated was that the tedious parts, left entirely to models, would quietly accumulate into something worse than slow typing — a slow erosion of code quality that compounds across every subsequent model pass.
That erosion now has a name: the slop apocalypse.
What “Slop” Actually Means
Slop, in this context, is not broken code. It is the noise a language model generates when left unchecked: unnecessary inline comments, verbose output that restates what the code already says, chunks that work but were never refactored into the surrounding codebase’s idiom. Individually, none of this crashes a test suite. Collectively, it creates a problem that gets harder to solve the longer it runs.
The reason is subtle. When a model reads code on a later pass — to fix a bug, extend a feature, review a change — it takes in both the code and any comments alongside it. If those comments have drifted out of sync with the actual logic (which they will, because models update code faster than they update prose), the model now has two competing sources of truth fighting for its attention. The result is not immediate failure; it is slower, more expensive iteration that builds up like interest on a debt.
This is a systemic quality problem, not a one-off model quirk. And it is getting more visible as teams push more of their codebase through agentic loops.
The Spec-First Response
One of the cleaner responses to this problem is also one of the older ideas in software practice: write the spec before writing the code.
BMAD (a popular open-source agent workflow framework) was built explicitly around this principle. Its core insight, discovered early in its development, is that breaking a large idea into small, well-defined “intents” — loosely analogous to agile user stories — dramatically improves agent reliability. Even with weaker models, a well-scoped intent produces better output than an open-ended prompt handed to a stronger one.
The philosophy it embodies is sometimes described as “human on the loop, not human in the loop.” The distinction matters. Human-in-the-loop means a person approves each step. Human-on-the-loop means a person defines the problem, sets the direction, and reviews the result — but the agent executes autonomously in between. The human stays in control of the parts that require judgment; the agent handles the parts that require typing.
What this approach guards against is a subtler failure mode than slop: handing ideation and planning to the model. Letting an AI define what should be built, not just how to build it, tends to produce output that looks coherent but lacks the grounding that comes from actually understanding the problem. The spec-first workflow keeps that grounding human.
When Teams Resist
Getting a team to actually adopt agentic coding is harder than it looks, and resistance from experienced engineers is often rational. Engineers who have spent years developing reliable intuitions about their codebase are right to be skeptical of a tool that bypasses those intuitions and generates plausible-looking output at speed.
One approach that has shown real results: remove sprint pressure entirely for two weeks. Give each engineer a single story — something that would previously have taken three or four days — and ask them to have the agent complete and validate it autonomously by the end of the period. Run daily standups focused on sharing techniques, not status. The goal is to let engineers rediscover, on their own terms, what actually works: context engineering, spec-first prompting, careful scoping. Buy-in built this way tends to stick because the engineer earned it.
The Structural Shift
As agentic development matures, the unit of work is shifting upward. Where a competent engineer once owned a story or a ticket, they increasingly own an epic — a full thread of capability from spec through delivery. This compresses team sizes: effective pods are trending toward two to four people rather than five to eight.
What that requires is engineers who are systems thinkers — people who understand the product, the business context, and the architecture, not just the implementation details of their current ticket. The skill being valued is judgment about what to build and how to decompose it, not the raw ability to write code quickly.
Product management is adjusting too. Fewer PMs are needed per team, but the role either goes deeper (embedded in a pod as a technical contributor) or higher (operating at strategic level across multiple pods). The middle ground — a PM who writes tickets and runs standups — has less of a place in this model.
Where This Goes
The slop problem is real, but it is also solvable by the same discipline that has always separated good software from fast software: intentional structure, clear specs, and humans who stay accountable for the outcome. Models will keep changing; the specific parameters that produce clean output today will drift with the next release. What holds up across those changes is the practice: define the problem well, delegate the execution, review the result.
The teams that figure that out will find agentic coding genuinely transformative. The ones that skip the structure will find themselves debugging comments.
Text summarized and optimized using Anthropic’s models and reviewed by a human.