Why

The middle shrinks, the ends get expensive

When AI speeds up the whole middle, analysis through review, the work does not vanish. It moves to the two ends.

• At the front: what is worth building, who it is for, what good would look like.
• At the back: whether what came back is any good, and what production teaches you once it ships.

The middle is the part we spent twenty years optimizing. Frameworks, ceremonies, career ladders, all of it aimed at the stretch that just got cheap. A system has one bottleneck at a time, and only that bottleneck decides how fast finished work comes out. Speed up anything else and work piles up in front of it. Eliyahu Goldratt’s Theory of Constraints named this decades ago. Building was that bottleneck, the slow step everything else waited on. AI sped it up almost overnight, and the constraint jumped to the two ends a cheap middle had hidden: what is worth building, and whether what came back is any good.

You have probably felt this already. An agent hands you a finished feature in minutes. Then you spend an hour working out whether it is the thing you actually wanted. That hour was the work. The typing was never the constraint. We just could not see that while typing was slow.

Agentic engineering is machine learning

The technical half of the argument comes from François Chollet, in a post on X from May 2026. His frame: agentic engineering is a form of machine learning. The engineer defines the goal, the constraints, and the search spaceSearch spaceThe set of possible solutions a task allows. An agent does not translate a spec line by line; it samples from this space, pulled toward one solution by your context, or proposing a few in a planning step. Generating many on purpose and selecting the best is a discipline you opt into.There are many valid ways to implement a story. The agent is choosing among them, not transcribing the one right answer.. An optimization process generates the code. You then treat the result as a blackbox artifactBlackbox artifactSomething you judge by how it behaves, not by reading how it was made.A dependency you trust through its tests and its behavior, not by reading its source. whose behavior and generalizationGeneralizationWhether something keeps working on cases it was not specifically built or tested against.Does the fix hold for the inputs you did not think of, not just the one in the ticket? you check empirically, the way you would with any model.

That quietly reclassifies jobs. Classic spec-driven development treats software as deterministic translation: requirements in, code out, and if the output is wrong, the spec was wrong. Plenty of teams are retreating to that little waterfall right now, pinning their hopes on better specs with agents doing the typing. The reflex even has a Radar entry: ThoughtWorks lists spec-driven development in Assess, caveats attached. The full sorting of where specs help and where they harm lives on Grading. Agentic engineering treats software as an optimization problem instead: a defined search space, a search process, an evaluation functionEvaluation functionThe function that scores how good a candidate solution is, so the search can tell a better result from a worse one and steer toward it. Without one, generating many solutions tells you nothing about which to keep.A test suite or a definition of done, read as a score the search aims for instead of a yes/no check at the very end.. Those are two different professions. Many of us, myself included, come from the deterministic one. Most of those reflexes do not survive the move. The one that does is judgment about whether a result is any good.

That reframing also moves the target you optimize for. The reflex with any productivity tool is to chase output: more pull requests, more green on the dashboard. I find that framing boring, and worse, wrong. If building is a search, throughput is the wrong thing to measure. You would never rate a machine-learning model by how many predictions it emits per second. You rate it on whether the output holds up.

Chase raw productivity and the search just hands you more of everything. That is the exact shape of sprawl and slop.

There is a deeper reflex hiding in that, carried over from deterministic work: variance looks like waste, something to stamp out. But a search runs on variance. It hands you many candidate solutions on purpose, and the skill is to bound that spread and keep the best of it, not to drive it to zero the way a factory drives a part to spec. That distinction comes back when we reach the factory floor on Harness.

The objective worth optimizing is solution quality, and the field evidence backs that. In an experiment at Procter & Gamble, Dell’Acqua, Mollick et al. (2025) ran 776 professionals through real product work. One person with AI matched a team of two without it. And the gain was better solutions, not faster ones. But solution quality only counts if you can measure it, which is the harder problem.

Outcome Grading is the new specification

If the build step is a search process, the leverage moves to whoever can grade what comes out of it. Grade the outcome precisely and you can let machines iterate against that grade, for hours, in parallel, while you do something else. Tests are the primitive form of this: this input, this expected output. The broader forms cover whole classes of behavior: rubricsRubricA written list of what “good” means for a kind of output, so the same standard can be applied to every result.Acceptance criteria, reused as a grading checklist instead of a one-off. and scenarios, the goldenGoldenAn output you have blessed as correct and keep around as the answer key, to compare new output against.The trusted fixture in an integration test: the known-good result everything else is measured against. and counter examples that calibrate them, an LLM judgeLLM judgeA second AI you ask to grade the first one’s output against your criteria. It scales review, but has blind spots of its own.A tireless reviewer who needs a clear checklist, or it will rubber-stamp anything that looks plausible. playing adversary, a human where the call is genuinely a judgment call, and production itself, grading whatever slipped through.

One caveat I want to plant early, because the whole framework gets dangerous without it: a rubric is not automatically truth. Good outcome graders are engineering artifacts in their own right, calibrated against counterexamplesCounterexampleA plausible-looking but wrong output you keep on file, so the system learns never to produce that kind of thing again.The bug you once shipped and then wrote a regression test for., failure taxonomies, the occasional human read. Skip that calibration and the agent will optimize toward output that sounds plausible to the grader, and the grader will applaud. You will have built a machine for generating confident mediocrity.

Only retained feedback counts

There is now a precise measurement language for this shift. Zhang et al. (2026) propose Effective Feedback Compute, which counts neither raw tokens nor tool calls nor wall time. It counts only feedback that is informative, valid, and actually retained in the agent’s state for later decisions. Feedback that changes nothing downstream is noise, however expensive it was to produce.

That is the empirical version of the backpressureBackpressureThe resistance an agent works against while it builds, well before any review at the end: a failing test or type error on the technical side, an acceptance scenario or rubric on the product side. Some of it reaches the agent automatically as a signal in the loop; some it imposes on itself by following a discipline set at the start, like writing the failing test first and working until it goes green. The more of it you can encode, the longer you can let the loop run.A red build is backpressure; the agent reads it and fixes the code. So are acceptance criteria: write them well and the agent works against your definition of good as it goes, instead of a person catching the miss at the end. thesis. A bad loop burns compute and keeps nothing. A good loop stores the pressure: a changed plan, a sharper rubric, a rejected variant that stays rejected. Which is the whole point:

The unit of agentic progress is retained feedbackRetained feedbackFeedback only counts when it changes a later decision: an updated plan, a sharper test, a rejected option that stays rejected. The rest is noise, however expensive it was to produce.A review comment matters only if it changes the next commit., not generated output.

The setup around the model beats the model

Chollet gives the theory; there are now measurements to go with it. Hold the model fixed and swap only the scaffold around it, and the score swings hard. On SWE-bench Verified Mini, the Holistic Agent Leaderboard (Kapoor et al.) has Claude Sonnet 4.5 at 68% with the SWE-Agent scaffold and 34% with the HAL Generalist scaffold. Same model, and the harnessHarnessThe scaffold that turns a model into an agent, assembled from many parts. Among those: the loop it works in, the tools it can reach, how its context is managed as a run grows long (compression, retrieval), the hooks that fire on what it does, subagents, and guardrails. Backpressure and other resistance attach here, and beyond it.An interactive agent tool like Claude Code, Codex, or Pi is a harness. You have been working inside one all along. alone doubles the score. “Agent scaffolds create drastic differences in cost and accuracy,” the authors write. LangChain ran the same test on Terminal-Bench 2.0 and got +13.7 points, 52.8% to 66.5%: “We only tweaked the harness and kept the model fixed, gpt-5.2-codex.”

The harness dominates the outcome, while the industry keeps arguing about the model. clawbench, the agent benchmark from the OpenClaw ecosystem, takes the design stance to its conclusion: it scores the whole combination you ship, the model together with the loop and configuration around it. That argument earns its own chapter: Harness.

The explosion and the slow collision

Sprawl is the explosion, slopThe statistical middle (slop)Output that converges on the bland average of everything the model has ever read: plausible, smooth, and indistinguishable from anyone else’s.The onboarding text that reads like every onboarding text ever written. is the slow collision. Both are what a search process does with nothing pushing back. The anatomy of each is worth a look.

For sprawl, the pressure-reactor image holds up the more you push on it. Agents generate pressure — output, speed, options — and the harness is the containment wall that makes a productive reaction possible instead of just an explosion to fear. The rest of the assembly maps over too: grading is the sensors that tell you what is happening inside, approval gates are the safety valves, rollback is the emergency shutdown. None of it is interesting on its own. A reactor is the whole assembly, or it is a crater.

Slop needs the front of the loop to explain, which surprised me when I first worked through it. Slop is sampling from the statistical middle of everything the model has ever read, and the agent lands there because it lacks the specific context that would pull it out: your customers, your constraints, the edge cases your domain knows by heart. So context and backpressure pull slop out of the middle in two moves. Context at the front keeps the agent from starting in the middle at all (the grounding step in the formula), and product and domain backpressure at the back pulls whatever comes out the rest of the way toward your product.

And the two depend on each other: backpressure without context is a filter with no signal. Your graders either reject endlessly, which looks exactly like sprawl, or they wave plausible-generic output through because they were calibrated on the middle themselves. You cannot buy your way out of missing context with more gates.

I closed the original talk that gave birth to this book with a line I still believe:

Build things that would not exist otherwise.

Slop gives that line its negative, and honestly its urgency. Slop is precisely what would exist otherwise, the statistical middle arriving on schedule, with or without you. But slop is also the raw material that makes variants and creativity possible at all. So this whole page comes down to one question, easy to ask and expensive to answer:

What, in your loop, would pull the output anywhere else?