The next article initially appeared on Markus Eisele’s e-newsletter, The Major Thread, and is being republished right here with the creator’s permission.
There’s a psychological mannequin spreading by the developer neighborhood proper now that goes one thing like this: Brokers are sensible sufficient to determine issues out, so heavy upfront specification is official overhead you don’t want anymore. Simply describe the objective loosely, let the agent discover, and proper as you go. Quick. Versatile. Fashionable.
It’s mistaken. Not as a result of brokers aren’t succesful—they typically are—however as a result of the accounting is off. You’re not eliminating price. You’re deferring it, fragmenting it, and making it more durable to see.
Let’s run the precise ledger.
Two poles, two hidden prices
At one excessive: minimal specification. You describe intent loosely, brokers interpret freely, and work begins instantly. The upfront price in human effort is close to zero. What you don’t instantly see is what accumulates downstream: correction loops, every carrying token price plus human reengagement time. Evaluation cycles the place a human acts because the oracle for each output—deciding whether or not what the agent produced is what was truly meant. Rework when it wasn’t.
On the different excessive: full formal specification. TDD, BDD, Gherkin eventualities, acceptance standards locked down earlier than a single line of code runs. The upfront human effort is actual and visual. However the downstream verification price seems essentially totally different, as a result of the checks are the oracle. Cross or fail. The human doesn’t must personally consider each output—the spec does it mechanically, repeatedly, with out fatigue.
What you’re truly buying and selling off is when you pay and in what forex. Minimal spec front-loads token price and back-loads human judgment. Heavy spec front-loads human effort and back-loads virtually nothing—automated verification doesn’t scale with runs.
The entire price of each approaches traces a U-shaped curve once you plot it in opposition to specification completeness. The minimal of that curve—the candy spot—sits someplace round well-structured acceptance standards or BDD eventualities. Not at zero specification, and never at a 40-page formal necessities doc.
The previous drawback was at all times the spec
The actual problem in software program engineering has at all times been specification.
Not typing. Not syntax. Not even structure within the summary. The laborious half was agreeing what ought to exist, what ought to by no means occur, which trade-offs matter, what the system is allowed to overlook, and what “accomplished” means when the world is messier than the ticket.
Brokers don’t take away that drawback. They make it extra seen.
For many years, we hid the specification drawback inside conferences, backlogs, code evaluations, QA cycles, incident retrospectives, and the non-public psychological fashions of senior engineers. Numerous software program engineering was by no means “writing code.” It was dragging an underspecified concept by sufficient friction that the lacking items have been compelled into the open.
Brokers cut back the friction of manufacturing code. That’s fantastic. It additionally means the lacking items floor later, as a result of the system can now produce a believable implementation earlier than anybody has actually determined what the implementation is meant to imply.
Within the previous world, imprecise necessities bumped into human slowness. Within the agent world, imprecise necessities run into machine velocity.
However writing the spec is barely half the issue
Right here’s what virtually each framing of this trade-off leaves out: A spec must be validated earlier than you hand it to an agent.
This sounds apparent said plainly. In apply, it’s systematically ignored.
Once you write a spec—even a cautious one—it might fail in methods which are invisible till the agent executes in opposition to it. It may be internally inconsistent: two necessities that contradict one another, neither clearly mistaken in isolation. It may be incomplete: It covers the glad path totally and says nothing about what occurs when the third-party API returns a 429. It may be technically right however untestable: The spec describes conduct that may’t be mechanically verified. And most insidiously, it may be exactly what you wrote however not what you meant.
An agent executing faithfully in opposition to a flawed spec produces one thing that’s tough to debug. It handed each examine it was given. The issue isn’t within the implementation—it’s upstream, within the spec itself. And now the correction loop is dearer, as a result of it’s a must to unwind not simply code however reasoning.
Spec validation is due to this fact a definite price class that lives between “write spec” and “run agent.” It asks: Is that this spec internally constant? Is it full sufficient to constrain the agent usefully with out over-constraining legitimate options? Does it truly describe the factor we intend to construct?
That validation work is human time, or it’s agent time, or ideally it’s each—however it isn’t zero. The second you add it to the ledger actually, the image modifications.
How brokers can write specs
There’s a 3rd technique this two-pole framing systematically ignores: use brokers to put in writing and validate the spec, then use implementation brokers to execute in opposition to it.
This modifications the price construction of the spec aspect of the curve. As a substitute of heavy human effort to provide acceptance standards or BDD eventualities, a spec-drafting agent produces a primary model from tough intent. A spec-validation agent—with a special position and system immediate, presumably with search entry or area data—stress-tests that draft for consistency, completeness, and testability. A test-writing agent interprets the surviving claims into executable checks. You overview the end result, which is quicker than writing it from scratch.
The necessary element is that the agent shouldn’t merely “write necessities.” That produces polished fog.
A helpful spec-writing agent behaves much less like a stenographer and extra like a skeptical product engineer. It ought to identify assumptions. It ought to separate objectives from nongoals. It ought to produce examples and counterexamples. It ought to say which necessities are mechanically testable and which of them nonetheless rely on human judgment. It ought to establish the failure modes a lazy implementation would most likely miss. It ought to ask what should be invariant throughout legitimate options.
One of the best immediate isn’t “write me a spec.” It’s nearer to this:
Draft the smallest spec that may let one other agent implement this safely. Embody assumptions, nongoals, acceptance standards, edge circumstances, observable outcomes, and open questions. Then mark which components can turn out to be automated checks and which components require human overview.
Then you definately run a special agent in opposition to the output:
Assault this spec. Discover contradictions, ambiguous phrases, hidden dependencies, untestable claims, lacking failure modes, and locations the place an implementation might go the written standards whereas nonetheless violating the intent.
The candy spot shouldn’t be agent-written prose. It’s human-approved, agent-drafted, adversarially reviewed specification with as a lot of the oracle made executable because the area permits.
This doesn’t make spec validation disappear. It modifications who does it and at what price. The structural requirement—that the spec be validated earlier than the implementation brokers run—stays. What modifications is that brokers at the moment are doing a part of that work.
How BDD partially solves this
Conduct-driven growth, when accomplished effectively, collapses spec writing and spec validation into the identical artifact. A Gherkin situation is concurrently an outline of intent and an executable take a look at. You’ll be able to run the spec in opposition to a skeleton implementation instantly and observe whether or not the outline produces coherent conduct. The act of constructing the spec executable forces a form of validation that prose acceptance standards don’t—some sorts of ambiguity should be resolved earlier than the situation may even run.
This is the reason the minimal of the full price curve doesn’t simply mirror diminished rework. It displays the structural benefit of a format the place validation is constructed into the medium.
The catch is that somebody nonetheless has to put in writing the eventualities effectively. Gherkin will be written badly. Enterprise-language specs will be ambiguous in ways in which the BDD framework doesn’t catch as a result of ambiguity lives in semantics, not syntax. The format helps, however it isn’t an alternative choice to self-discipline.
Multi-agent pipelines break every part
In case you’re operating a single agent on a well-bounded activity, underspecification is recoverable. The suggestions loop is tight, correction is native, and the price is bounded.
Multi-agent pipelines are a special class of drawback completely.
When Agent A produces output that turns into Agent B’s enter, any interpretive drift from A compounds into B’s execution. B doesn’t know that A went barely off-course. B works laborious and confidently on the mistaken basis. By the point the output surfaces to a human, the error has been amplified and obscured by a number of layers of apparently coherent work.
This shifts the breakeven level decisively towards specification. In a multi-agent system, a spec isn’t simply steerage for a single execution—it’s a coordination contract between brokers. The much less exact that contract, the extra every agent’s interpretive freedom introduces variance that accumulates. You desire a strongly typed interface between brokers, not a free conversational handoff.
Validation of that contract issues correspondingly extra. If the spec that coordinates your brokers is flawed, you don’t have one agent doing the mistaken factor—you may have all of them, in parallel, doing otherwise mistaken issues.
What survives from methodology
So does this make every part we discovered about coordinating software program groups out of date?
No. However it does change which components have been load-bearing.
Agile as theater is in hassle. Standups the place individuals recite standing into the air, estimation rituals that produce fictional precision, ticket ceremonies whose essential perform is to reassure administration that uncertainty has been domesticated—brokers don’t want these. Actually, people didn’t both.
Agile as a suggestions philosophy survives. Brief cycles survive. Working software program over summary progress survives. Buyer collaboration survives. The insistence that plans ought to bend when actuality speaks survives. If something, brokers make this extra necessary, as a result of they will generate lots of convincing wrongness in a short time. The suggestions loop has to get tighter, not looser.
XP survives even higher. Check-first considering survives as a result of executable oracles are extra beneficial when implementation will get cheaper. Pair programming mutates into human-agent pairing, however the underlying concept stays: preserve design judgment near code manufacturing. Steady integration survives as a result of each agentic change wants a quick, neutral gate. Refactoring survives as a result of brokers can produce working code that’s domestically right and structurally mediocre. Small releases survive as a result of massive invisible deltas are the place each people and brokers lose the plot.
What most likely fades is methodology as coordination theater for giant teams of people. What survives is methodology as a set of constraints that make ambiguity cheaper to find.
The fascinating query shouldn’t be whether or not Agile or XP “wins” within the agent period. The fascinating query is which practices nonetheless cut back the price of discovering that the spec was mistaken.
The place to truly make investments
The sensible takeaway from this evaluation shouldn’t be “at all times write full BDD specs” and it’s not “at all times let brokers roam.” It’s that the optimum funding level is activity dependent, and the trustworthy calculation contains spec validation as an actual price.
For a single agent on a small, well-bounded activity, the candy spot is often structured intent: a objective, examples, nongoals, and some acceptance standards. BDD could also be overkill. Zero spec continues to be lazy accounting.
For deterministic, well-understood work—API integrations, CRUD providers, knowledge transformations—the breakeven level sits additional proper. Extra specification pays off quicker as a result of the area is constrainable and the checks are automatable. Skimping on spec right here is simply deferring rework.
For exploratory or inventive work—structure choices, novel drawback approaches, analysis synthesis—over-specification constrains precisely what the agent’s flexibility is sweet for. The breakeven sits additional left. Use the agent’s interpretive freedom intentionally, however put boundaries across the exploration.
For multi-agent techniques, the candy spot shifts proper once more. The handoff is the product. Each agent boundary wants a contract: schema, invariants, allowed ambiguity, validation checks, and failure conduct. In any other case you’re not orchestrating brokers. You’re compounding interpretations.
In all circumstances: Validate your spec. Whether or not that’s a human overview, an agent stress-test, or an executable format like BDD that forces structural consistency, the price of skipping it’s paid later, at greater curiosity, with worse diagnostics.
The seductive promise of zero-spec agent work is actual, however the ledger it ignores can also be actual. The brokers are getting higher. The accounting drawback continues to be ours.
