Dexter Horthy, who runs a company called HumanLayer that builds tooling for AI agents, spent part of 2025 telling audiences of engineers that large monolithic agents did not work, that the answer was small focused workflows, and that control flow belonged in code rather than in prompts. Then he went back to his own product and wrote a single prompt containing eighty-five instructions. When he eventually worked out why the thing had started behaving unpredictably, he described the discovery with more good humour than most people manage about their own work: "We got on stage and said full-fat agents don't work, build workflows and micro agents, use control flow for control flow. Then we turned around and wrote a giant monolithic eighty-five-instruction prompt. It was time to drink our own Kool-Aid."
The method he had been teaching was called Research-Plan-Implement, and it had three steps: work out what the codebase actually does, write a plan, then build against the plan. It was the first structured workflow for coding agents to spread on its own merits, turning up in repositories and forum threads without anyone marketing it, and by the time Horthy pulled it apart in public it had a substantial following who were about to learn that the version they were using had failure modes nobody had noticed. His replacement runs through questions, research, design, structure, plan, worktree, implement and pull request, with a hard ceiling of forty instructions on each step.1
Something similar happened to compound engineering, the method Kieran Klaassen developed while running the AI email product Cora at Every, and which he has written up in enough detail that other small teams have adopted it wholesale. Its original loop had four steps: brainstorm, work, review, and compound, the last being the point at which you capture whatever the round taught you so the next one starts further along. In May 2026 Klaassen expanded it to eight, explaining that the four-step version "leaves out the two places where I now spend most of my attention: before there is a plan, and after the work technically passes review."
Two practitioners with good reputations and real production experience arrived at the same verdict within a quarter of each other, and both fixed it the same way, by adding steps. What makes the coincidence worth examining is not the churn itself, which is what you would expect from a young practice, but where the new steps went. Both men added them at the front, and the front is not where anyone has been building tools.
I should say plainly that we build governance and agent infrastructure, and that this argument came out of trying to solve the problem for our own engineering rather than from watching the field from a safe distance. Some of what follows describes a design we have not finished, which is a particular kind of interest to declare.
Instruction sixty-seven of eighty-five
Horthy's account of what went wrong is more specific than the usual complaint that a technique failed to scale, and each of the three failures he identifies constrains anything anyone builds in this area.
The first is arithmetic. Frontier models will follow somewhere between a hundred and fifty and two hundred instructions with reasonable consistency, and his planning prompt had reached eighty-five on its own, before anyone counted the system prompt, the tool definitions and the connected servers that arrived alongside it. Together they put the model over budget, and the way that failure presented itself is the reason it survived so long undetected: nothing refused, nothing complained, and nothing came back visibly broken. The instructions that went unheeded were the ones furthest down the prompt, which happened to be the alignment steps, the careful part. No system emits a warning when instruction sixty-seven of eighty-five is quietly skipped, so the work looked like compliance and the debt accumulated underneath it.
The second failure is the one with consequences beyond his own product. Trying to understand why some runs went well and others badly, Horthy narrowed the difference down to a single sentence that somebody had to remember to type, asking the agent to work back and forth with them, starting with its open questions and an outline, before writing any plan. Runs where a person typed it went well. Runs where nobody did went badly, in ways that only became apparent later. He found himself explaining this to enterprise engineers, in his own summary of the situation, as here is the software, but do not forget to say the magic words. His conclusion was that a tool requiring magic words for basic functionality is a broken tool, and the reasoning generalises further than he applies it: any workflow that only holds when an agent chooses to honour an instruction is not really a workflow at all.
The third failure should worry anybody currently writing specifications for agents to follow. Detailed plans felt like progress, read as rigour, and were satisfying to produce, and by the time a human being was reading a thousand-line plan the agent had already made every architectural decision inside it. The document created to keep the work honest had become the thing obscuring what the work was doing, and part of Horthy's remedy is now to push people towards reading the code rather than the plan file.
From all of this he drew a single line that indicts a good deal of what is currently being built: do not use prompts for control flow, use control flow for control flow. An if-statement will outperform any amount of hoping that a model reaches instruction sixty-seven, and that is a claim about where determinism has to live rather than advice about prompt hygiene. It cuts against the prevailing instinct in the field, which is to answer the fragility of prompts by writing better prompts.
We have run this experiment before, slowly
None of this requires an agent to happen, which is the part most worth holding on to, because software has already run the same experiment across twenty years and a much larger population.
In February 2001, seventeen people met at a ski lodge in Utah and produced the Manifesto for Agile Software Development, a document of four values and twelve principles that fits comfortably on a single page. It was written as a corrective to the heavyweight processes of the preceding decade, and the second of its four values addressed documentation directly, declaring a preference for working software over comprehensive documentation. The people who signed it were reacting against exactly the failure this article is about: artefacts produced because a method demanded them, maintained by nobody, describing a system that had moved on.
What happened next is familiar enough that it barely needs describing. The single page acquired ceremonies, then certifications, then scaling frameworks to coordinate the ceremonies, then consultancies to install the scaling frameworks, then certification bodies to accredit the consultancies. A movement founded on the observation that process artefacts decay produced, within about a decade, an industry selling process artefacts.
Its authors noticed. Dave Thomas, one of the original seventeen, declared the word dead in 2014, writing that it "has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products." Andy Hunt, another signatory, followed in May 2015 with an assessment titled The Failure of Agile, observing that fourteen years on "we've lost our way" and that the word had been sloganised into something meaningless at best. Beginners, he argued, were latching onto concrete practices and following them as iron rules, because agile methods ask practitioners to think and it is far more comfortable to follow the rules and claim you are doing it by the book. His sharpest observation was also his shortest: "agile methods themselves have not been agile." Ron Jeffries, a third, eventually advised developers to abandon the named methods entirely while keeping the values underneath them.2
Three of the seventeen authors publicly disowning what the thing had become, spread across four years, is a slower version of what Horthy and Klaassen did to their own methods inside a single quarter. The mechanism is identical. A practice is created to reduce ceremony, the ceremony returns because ceremony is easier to sell and easier to follow than judgement, and eventually the people who created it say so out loud.
The compression is the only genuinely new thing. Agile took the better part of two decades to complete that arc, and the current generation of agent workflows is managing it in months, because the tooling ships faster and the feedback arrives faster. Nobody should expect the third revision of either method to be the last, and anyone building infrastructure underneath these methods should assume the method above will change shape at least once more before it settles.
The second system
Spec-driven development is where the same argument is being had now, and its practitioners are reaching Horthy's third finding from the opposite direction.
The practice now ships in some form with every serious AI coding tool. You write down what the software should do in enough detail that an agent can act on it, and that document becomes the standard the resulting work is measured against. GitHub's Spec Kit, Amazon's Kiro, OpenSpec and Tessl are all careful pieces of engineering by people addressing a genuine problem, and the practice is a clear improvement on describing a feature in a chat window and hoping for the best. Anybody who has watched an agent confidently build the wrong thing understands the appeal immediately.
The failure mode is being documented by its own practitioners rather than its critics. Markus Eisele, writing in July 2026, put it in terms that will be recognisable to anyone who has inherited such a repository: open one after six months of spec-driven agent work and you may find a second system sitting next to the code, comparable in size, describing something the code has since drifted away from. The comparative surveys of this tooling have begun sorting products by whether they resist that drift, separating the ones that actively track a specification against the code from the ones where the two quietly diverge as soon as generation begins, and that distinction only needs drawing because divergence is the expected outcome rather than the surprising one.
Set Eisele's finding beside Horthy's and they describe the same phenomenon. Plans concealed debt; specifications went stale. In both cases an artefact created for the tool's benefit eventually misled the people relying on it, and did so while looking exactly like diligence, which is what makes the failure hard to catch early.
The reason has less to do with engineering discipline than the usual complaints suggest. A specification written so that an agent has something to work against has exactly one constituency, and that constituency cannot notice when the document is wrong. Nobody outside the team reads it, nothing breaks when it drifts, no one files an issue against it, and no contributor turns up to argue with it in a thread. What the team has acquired is a permanent maintenance cost attached to no independent reason for the document to be true, and it competes for attention against every artefact that does have somebody waiting on it. Given a fortnight of delivery pressure, the outcome is not in much doubt.
Between the manifesto and the present sits a smaller experiment worth recalling. Tom Preston-Werner made the case for writing the README before the code in August 2010, arguing that until you have written about your software you have no idea what you will be coding, and he was right about the design benefit. The practice survives in the places it suits, among libraries and small services with a clear public surface, but it never generalised, and the reasons people recorded at the time are the ones being rediscovered now: the artefact costs more to maintain than its authors expect, and it suits projects in rapid change worst of all.
Things that break loudly
None of which is an argument for less rigour, and it is certainly not an argument for trusting the agent. The way out begins with noticing that most projects are already carrying contracts considerably stronger than any specification would be, for the straightforward reason that somebody outside the team enforces them.
Published documentation has to be true, because the people using the software complain when it is not. Executable examples either run or they do not, and no judgement enters the question. Tests fail loudly, in public, in front of colleagues, which is a social mechanism as much as a technical one. Architecture decision records get argued over by contributors who were not in the room when the decision was taken, and that argument is the forcing function. Every one of these artefacts is maintained for reasons that predate anybody's tooling budget, and that independence is precisely what makes them worth measuring work against. It is also, incidentally, what the agile signatories were pointing at when they preferred working software to comprehensive documentation: not that documents are worthless, but that a document nobody depends on will not survive contact with a deadline.
Documentation also happens to be the right size for most changes, a point that tends to get lost in enthusiasm for architectural rigour. A bug fix genuinely does relate to published documentation, in that the behaviour did not match what was written down, whereas asking which architectural decision a bug fix serves is usually unanswerable. Insisting on an answer produces either a stream of meaningless exemptions or invented references that corrupt the record with links carrying no information, and both outcomes are worse than not asking.
So the useful operation is to review work against whatever a project already keeps, taking the strongest artefact that happens to exist rather than demanding a better one. Those artefacts are not equal. Executable examples prove the most, since they run; reference material describing an interface comes next, because it can be checked mechanically; documented scenarios with tests traced to them follow, since a scenario with no test is a finding that requires no model to spot. Decision records are the right anchor for architectural work and can only be checked by judgement. Below them sits the test suite, which is a project's real contract whether or not anyone wrote it down, then prose documentation, where only a reader can tell you the published understanding has come loose from the software, and finally the change's own description and whatever issue it references, which proves very little and which nearly every project has.
Below that there is nothing, and nothing is a perfectly legitimate place to land. A project with none of these artefacts can still be built, tested, linted, audited for licences and dependencies, and checked for changes to its public interface, which is a real floor rather than a polite fiction.
What holds the arrangement together is a piece of bookkeeping that sounds administrative and turns out to be load-bearing: a review has to record which contract it was measured against and how strong that contract was. A check anchored to a runnable example proves something quite different from one anchored to a commit message, and presenting the two as equivalent is how automated quality reporting becomes theatre, producing a green tick that means far less than the person reading it assumes. Recording the strength also changes the character of improvement, because a team can see exactly which artefact would give it stronger checks and decide for itself whether writing that artefact is worth the trouble, which is an invitation rather than a mandate and asks a great deal less than adopting a specification workflow does.
There is a failure lurking in this design that ought to be said out loud rather than discovered in production. If nearly every change in a project ends up anchored to a commit message, then the graded evidence is telling you something true and useless, and the right response is not to start mandating better artefacts. It is to check whether those weakly anchored reviews are finding anything worth having, and to stop running them if they are not.
Two pages instead of two thousand lines
Here is the finding that cuts against most of what is being built in this space, including the first version of what we were building.
Both methods failed at the front, and neither man added alignment phases for symmetry. Horthy added his because reviewing a thousand-line plan, or a thousand lines of code, is the wrong place to catch a misalignment: by the time anyone is reading either document the misalignment has been elaborated, committed to and made expensive to reverse. His remedy front-loads the work into roughly two hundred lines of design and two pages of structure, where being wrong costs an afternoon rather than a milestone. Klaassen described the same discovery in different vocabulary when he identified the place his attention had migrated to as the stretch before there is a plan at all.
Anyone building review machinery should find this uncomfortable, because review happens afterwards by definition. If the leverage genuinely sits upstream, then a great deal of engineering effort across the industry is going into the cheap end of the problem, ours included.
The resolution turns out to be less dramatic than abandoning review. It comes from noticing which artefact on that ladder is strongest and when it exists, because a decision record reviewed before anybody implements against it is not post-hoc review in any meaningful sense. It is alignment work performed on a two-page document at the point where changing your mind is nearly free, and mechanically it is the same operation as reviewing a merge request: read the thing, check it against what the project has already committed to, and say where it contradicts something. The only difference is when it happens, which is the difference Horthy is pointing at.
That suggests the target should be artefacts rather than changes, and the generalisation is small enough to be worth making immediately. If the machinery reviews any artefact that has an anchor, whether that is a draft decision, a design note, a structure outline or a diff, then a team running an eight-phase method gets its design discussion checked by the same apparatus that checks its code, and nobody has to hold an opinion about which phase anyone is currently in. Given the history above, building for anybody's particular step ordering means rebuilding when its author revises it, and its author will revise it.
One boundary is worth drawing while we are here. Klaassen's other addition was polish, the work that technically passes review but does not feel right, and that is taste. It is human, it resists specification, and any tool claiming to cover it is overreaching.
The step nobody automated
Look at what has actually been built over the past two years and a hole opens up in the middle of it.
Planning has been automated enthusiastically. Implementation has been automated enthusiastically. Review has been automated so enthusiastically that its noise is now an occupational hazard, with reported false-positive rates clustering somewhere between five and fifteen per cent depending on which tool you believe.3 The rates matter less than what they do to the people receiving them, because a tenth of comments being wrong is enough that engineers begin scrolling past machine output by default within a few months, and once that reflex sets they apply it to everything appearing in the same place, including the careful comment a colleague left underneath. The wasted attention is the smaller cost; the habit generalising is the larger one, and it is not recoverable by tuning the tool that caused it.
Meanwhile the compounding step, the one that gives compound engineering its name and is supposed to ensure each unit of work leaves the next one easier, is performed everywhere it is practised by a person who noticed a lesson and remembered to write it down. That was true of the four-step loop and it remains true of the eight-step one. Klaassen's expansion added ideation at the front and polish at the end, and left compounding exactly where it had always been, done by hand. Eight steps in, the step the whole method is named after is still the one nobody has automated.
The ratchet
The mechanism that would close that gap is unglamorous, which may be part of why nobody has bothered with it.
When a review finding is confirmed, whoever confirms it also names the check that would have caught it: a lint rule, a specific assertion, a schema constraint. That proposal then goes through review like any other change, and once accepted the problem is caught mechanically from then on, never needs anyone's judgement again, and stops being raised as a comment. Reviewers consequently stop spending attention on problems the team has already solved once, and judgement concentrates on things nobody has seen before, which is the only place it was ever worth much.
The consequence people tend to miss concerns volume. If a finding falls into a category that already has a check, there is no reason to raise it as a comment at all, since the check will either catch it or it will not, so machine commentary falls as the system matures. That inverts the usual trajectory of these tools, where coverage broadens, precision does not, and the experience grows steadily more tiresome until somebody switches it off. An inverted noise curve is, as far as I can tell, the only version of automated review that survives prolonged contact with a team's patience.
It carries a timing problem that has to be respected rather than engineered away. Suppression does nothing at all until a body of checks exists, and that empty early period is exactly when people are deciding whether to trust the thing, which argues for an ordering that feels backwards: judged review should not begin until mechanical coverage is already substantial. The checks needing no model come first, asking whether the document parses, whether the links resolve, whether an identifier has been used twice, whether the build passed. Anything needing judgement waits until there is something for suppression to suppress.
Horthy's conclusion applies directly to how that judged portion is arranged, and it applies more sharply than we first allowed for. A review step that depends on an agent honouring an instruction is a magic-words dependency, and he is right to treat that as a structural defect rather than something to be tuned. The answer is control flow: require every finding to cite a location that can be confirmed to exist and to fall inside the artefact under review, and discard anything that cannot clear that bar. It is cheap, it is deterministic, and it answers the objection rather than mitigating it. The same arithmetic governs the instructions themselves, since a hundred and fifty is a real ceiling measured by somebody who hit it, so instructions get a stated budget, the budget gets its own check, and they are never concatenated.
All of this converts one risk into another, and the second half is the part everyone leaves for later. Checks need a way out, because a suite that only grows becomes slow, then brittle, then a source of noise in its own right, at which point it has faithfully reproduced the problem it was built to remove. Checks that have stopped firing across a long stretch of changes should be proposed for removal on exactly the footing they were proposed for addition, and reviewed the same way. This is not a refinement to add once the suite is already slow. A mechanism that only tightens is a seizure rather than a ratchet.
The smaller claim
Two limits are worth stating in the open, not out of modesty but because both change what the thing is actually for.
Most findings cannot be mechanised at all. An observation that a design contradicts a commitment made elsewhere will never become a lint rule, and neither will the observation that the alternatives in a proposal were listed rather than weighed. What proportion of confirmed findings can become checks is an empirical question nobody has answered, and it ought to be the first thing measured rather than the first thing assumed. It will be lowest exactly where review is most valuable, which is architecture, where a poor function costs somebody an afternoon and a poor decision costs a milestone.
Which means the honest claim is that this removes toil rather than lifting quality. Whatever quality improvement arrives comes from having a second reviewer at all, a much simpler proposition that does not depend on any of the machinery above working as intended. What the ratchet buys is that the second reviewer stays useful over time, because it stops repeating itself, and that is a smaller and duller benefit than the promise usually attached to these systems, which is that they get cleverer as they go.
Three numbers would settle whether it works: the fraction of confirmed findings that turn out to be mechanisable at all, the proportion of those that actually became checks, and whether a category recurs once it has been gated. That last one should go to zero, and if it does not then the checks are not capturing what the reviews found and the whole mechanism is decoration. Nobody has run this long enough to know, and presenting it as proven would be both dishonest and unnecessary, since the first half of the argument stands without it.
What happens after
Both of these methods churned twice inside a quarter, and neither revision changed what they need underneath. Both still want deterministic verification, something that remembers between sessions, and some way of proving afterwards what actually happened. Horthy's own summary, that harness configuration and deterministic verification matter more than which frontier model you happen to pick, is an argument for building that substrate rather than another sequence of steps to sit on top of it.
The agile authors reached a version of the same conclusion twenty years later than they would have liked. Jeffries advised abandoning the named methods while keeping the values, which is another way of saying that the durable part was never the ceremony. It was the small number of things a team genuinely depends on being true, and the willingness to keep those true without being told to.
So the question to put to any of these workflows is not how much structure it adds, because structure is cheap to add and expensive to keep, and the industry has now demonstrated the point twice: once across two decades, and once in a single quarter. The better question is what a project already keeps true, and what happens to a problem after somebody solves it.
If the answer to that second half is that the problem returns next quarter in a different file, then no specification is going to help, because specifications do not remember anything. And if the problem genuinely does not come back, something in that project is already carrying the memory, which makes it worth considerably more attention than whatever workflow has been wrapped around it.
Footnotes
-
Community implementations vary in how they count and name these phases, and several published variants collapse or reorder them, so the sequence above should be read as Horthy's rather than as a settled standard. The per-step instruction ceiling is his own. ↩
-
Seventeen people signed the manifesto, and Thomas, Hunt and Jeffries are three of them, so this is a notable minority rather than a consensus. Jeffries in particular is careful to separate the named methods from the values underneath, which he continues to endorse without reservation; his argument is against the branded frameworks that grew on top, not against the original document. Several other signatories have defended the record considerably more robustly. ↩
-
These figures come from vendor and practitioner write-ups rather than independent research, and the companies publishing them are generally the ones claiming the lower end of the range, so they are best read as industry reporting rather than measurement. Cubic's account describes the same band from a different vantage point. ↩