The Code-Review-Simplify Loop

The specification crossed the gate at the end of part 3, and the temptation at this exact moment is enormous: the plan is refined, the intent is encoded, so surely now you just let the agent run. Hand it the breakdown, come back later, collect the code. That is Execution as a single heroic pass, and it is the version of Execution I stopped running early, because a single pass converts every residual weakness in the plan into shipped code with no intermediate moment where anyone could have noticed. Execution in PREVC is not a pass. It is a loop — three steps, Code, Review, Simplify, repeated per work package until an exit condition fires — and this part is about why the loop has exactly those three steps.

Before the mechanics, the ledger note this series owes you every time: the five-phase skeleton I run is adapted from an open-source ancestor, credited in full in part 1, but the Code-Review-Simplify loop inside Execution is my extension to that skeleton. It has honourable roots, which I will credit precisely, but the shape, the emphasis and the faults are mine — this is field practice, not established industry doctrine.

Why one pass loses quietly

The argument for a loop starts with an observation Addy Osmani has documented as the “80% problem” in agentic coding: agents get you most of the way to a correct solution, and the remainder — the subtle misreadings, the structural excess, the requirements half-satisfied — needs human-guided iteration. Osmani's framing is deliberately loose; nobody has measured a clean 80/20 split, and I will not pretend otherwise. But the qualitative claim matches everything I have watched an agent do: the first pass is impressively close and reliably not done.

The question, then, is not whether you iterate — you will, the only alternative is shipping the first pass — but whether the iteration is systematic or ad hoc. Ad hoc iteration is what most people do by instinct: run the agent, skim the output, prod at whatever looks off, repeat until tired. It works, in the sense that poking at things works, but it has no memory, no consistent standard, and no answer to the question "what are we actually checking for this time?". The loop exists to give the iteration a shape: the same three steps, in the same order, every time, so that nothing depends on what I happened to notice while skimming.

Step one — Code, where the harness pays rent

The agent implements the current work package from the refined breakdown. One package, not the whole plan — the granularity matters, because everything downstream of this step (the review, the simplification, the exit decision) happens per package, while the mistakes are still small and local.

This is also the step where investment made long before this cycle pays off. An agent with a well-configured harness — context files carrying the project's conventions, the right tools wired in, hooks enforcing the rules that should never be negotiable — starts every implementation already knowing the architecture, the naming, the constraints. An agent without one reinvents your architecture from scratch every package, and the loop's later steps spend their budget correcting inventions instead of catching real defects.

Take Rosterly, the invented rota service this series has been building since part 2, whose hardest work package — eligibility rules for shift swaps — the human sharpened during Review. The agent picks up package 2.1: the qualification check, defined operationally, with a named read-only data source. It writes the code. So far, so unremarkable.

Step two — Review, with the spec open

The second step examines the output for three things: correctness, hallucinations, and adherence to the specification. The order of those words undersells the third one. The review question inside the loop is never “does it run?” — it is "is this the package the specification describes?", and answering it requires the work package open next to the diff, because agent output has a property that human first drafts rarely have: it looks finished. The naming is clean, the structure is confident, the comments are plausible. Polish is the default surface, and polish is exactly what makes a wrong implementation easy to wave through.

On Rosterly's qualification check, the review pass earns its keep in the second file it reads. The code is tidy, but it evaluates the swap target's skill tags against the current rota — and requirement 2.3, the line the human added at the gate in part 3, says eligibility is evaluated against the rota as it would be after the swap. Nothing in the toolchain would ever have flagged this. It compiles; the obvious tests would pass; it is wrong only relative to a sentence in the spec, which is precisely why the review step reads against the spec and not against its own taste.

What the review step should be hunting for deserves — and gets — a part of its own: the failure patterns that survive the compiler are the subject of part 6. For now the loop-level point stands: the review is a comparison, not an appraisal.

Step three — Simplify, the step that names the enemy

The third step exists because of the most consistent behavioural fact I know about coding agents: they over-engineer by default. Elaborate class hierarchies where a function would do, abstraction layers for flexibility nobody asked for, defensive code guarding against scenarios the system cannot produce, configuration for futures that will never arrive. Osmani puts it exactly: "They'll scaffold 1,000 lines where 100 would suffice, creating elaborate class hierarchies where a function would do." That sentence is the Simplify step's founding charter.

Rosterly obliges with a textbook specimen. Asked for a working-time check that applies the tenant's configured rule set, the agent delivers a RuleEngine interface, an abstract RuleEvaluator, a RuleEvaluatorFactory, and a plugin registration mechanism — for a tenant rule set that contains, in every tenant that exists, between two and five declarative rules. The review pass has nothing to object to: it is correct, it adheres to the spec, every rule evaluates properly. It is also five times the code the problem needs, and every surplus line is a line some future cycle must read, test and preserve.

The Simplify step applies direct pressure, and the pressure is a question: couldn't you just…? Couldn't you just evaluate the rules in a loop? Couldn't the factory be a dictionary? In my experience the question works disproportionately well — agents fold speculative machinery the moment you name it, because the machinery was never load-bearing. The rule engine collapses to a twenty-line evaluator over the tenant's rule list, and the diff gets smaller, which is the only direction a third step should ever push.

Simplify is a separate step, not a flavour of review, because the two hunt opposite failures. Review catches what the code does wrong; Simplify catches what the code does needlessly, and needless code passes every correctness check ever devised. Fold the two together and simplification reliably loses — wrongness feels urgent, excess feels like someone else's problem. Giving the excess its own named step in every iteration is the entire trick.

The roots, credited

None of these three steps is an invention; the arrangement is. The obvious ancestor is Kent Beck's Red-Green-Refactor cycle from Test-Driven Development: By Example (2002): write a failing test, write the minimum code to pass, then refactor. Code-Review-Simplify mirrors it with one adaptation that changes the emphasis entirely — agents do not write the minimum code to pass. They skip straight past minimum to elaborate, which is why the refactoring step, optional-feeling in much human TDD practice, becomes the loop's most consistently necessary move.

The second root is PDCA's Do and Check steps, run as a micro-cycle: implement, then measure against expectation, at work-package granularity rather than project granularity, so that errors are caught before they compound across packages. And the third is ordinary agile instinct — small iterations with feedback beat large single passes — applied one level finer than a sprint ever goes.

Until something says stop

One loop pass on Rosterly's eligibility package caught a spec violation and stripped an unnecessary rule engine. The natural next question is: when do you stop? Review will always have another opinion if you ask for one; Simplify can always find another candidate. The loop repeats until a breakout constraint is met — an explicit, per-package exit condition decided before the loop starts — and those constraints are load-bearing enough to deserve their own part. Next, four ways out of an infinite loop: the iteration cap, the quality threshold, the time budget and the diminishing-returns test.