The next article initially appeared on Markus Eisele’s e-newsletter, The Foremost Thread, and is being republished right here with the creator’s permission.
There’s a psychological mannequin spreading via the developer group 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 aim loosely, let the agent discover, and proper as you go. Quick. Versatile. Trendy.
It’s fallacious. 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 appears essentially completely different, as a result of the assessments are the oracle. Cross or fail. The human doesn’t have to personally consider each output—the spec does it routinely, repeatedly, with out fatigue.
What you’re truly buying and selling off is when you pay and in what foreign money. 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 full price of each approaches traces a U-shaped curve while 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 downside 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 arduous half was agreeing what ought to exist, what ought to by no means occur, which trade-offs matter, what the system is allowed to neglect, and what “performed” means when the world is messier than the ticket.
Brokers don’t take away that downside. They make it extra seen.
For many years, we hid the specification downside inside conferences, backlogs, code opinions, QA cycles, incident retrospectives, and the personal psychological fashions of senior engineers. A number of software program engineering was by no means “writing code.” It was dragging an underspecified thought via sufficient friction that the lacking items have been compelled into the open.
Brokers scale back the friction of manufacturing code. That’s great. 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, obscure necessities bumped into human slowness. Within the agent world, obscure necessities run into machine pace.
However writing the spec is simply 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 acknowledged plainly. In follow, it’s systematically ignored.
Whenever you write a spec—even a cautious one—it could fail in methods which can be invisible till the agent executes in opposition to it. It may be internally inconsistent: two necessities that contradict one another, neither clearly fallacious in isolation. It may be incomplete: It covers the completely happy path completely and says nothing about what occurs when the third-party API returns a 429. It may be technically appropriate 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 troublesome to debug. It handed each test 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 you must 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—nevertheless it isn’t zero. The second you add it to the ledger truthfully, the image adjustments.
How brokers can write specs
There’s a 3rd technique this two-pole framing systematically ignores: use brokers to jot down and validate the spec, then use implementation brokers to execute in opposition to it.
This adjustments the price construction of the spec facet of the curve. As an alternative of heavy human effort to supply acceptance standards or BDD eventualities, a spec-drafting agent produces a primary model from tough intent. A spec-validation agent—with a special function and system immediate, probably 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 evaluate the consequence, which is quicker than writing it from scratch.
The vital element is that the agent mustn’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 upon human judgment. It ought to determine the failure modes a lazy implementation would in all probability miss. It ought to ask what should be invariant throughout legitimate options.
The most effective immediate isn’t “write me a spec.” It’s nearer to this:
Draft the smallest spec that might let one other agent implement this safely. Embrace assumptions, nongoals, acceptance standards, edge instances, observable outcomes, and open questions. Then mark which components can develop into automated assessments and which components require human evaluate.
You then 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 may move 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 adjustments who does it and at what price. The structural requirement—that the spec be validated earlier than the implementation brokers run—stays. What adjustments is that brokers at the moment are doing a part of that work.
How BDD partially solves this
Habits-driven improvement, when performed nicely, collapses spec writing and spec validation into the identical artifact. A Gherkin state of affairs is concurrently an outline of intent and an executable check. You may run the spec in opposition to a skeleton implementation instantly and observe whether or not the outline produces coherent conduct. The act of creating the spec executable forces a sort of validation that prose acceptance standards don’t—some sorts of ambiguity need to be resolved earlier than the state of affairs may even run.
This is the reason the minimal of the overall price curve doesn’t simply replicate decreased 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 jot down the eventualities nicely. Gherkin may be written badly. Enterprise-language specs may 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, nevertheless it isn’t an alternative choice to self-discipline.
Multi-agent pipelines break the whole lot
If you happen to’re operating a single agent on a well-bounded job, underspecification is recoverable. The suggestions loop is tight, correction is native, and the price is bounded.
Multi-agent pipelines are a special class of downside 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 arduous and confidently on the fallacious basis. By the point the output surfaces to a human, the error has been amplified and obscured via 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 need 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 fallacious factor—you’ve gotten all of them, in parallel, doing in another way fallacious issues.
What survives from methodology
So does this make the whole lot 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 folks recite standing into the air, estimation rituals that produce fictional precision, ticket ceremonies whose fundamental 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. Quick 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 vital, as a result of they will generate a whole lot of convincing wrongness in a short time. The suggestions loop has to get tighter, not looser.
XP survives even higher. Check-first pondering survives as a result of executable oracles are extra worthwhile when implementation will get cheaper. Pair programming mutates into human-agent pairing, however the underlying thought stays: maintain 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 appropriate and structurally mediocre. Small releases survive as a result of massive invisible deltas are the place each people and brokers lose the plot.
What in all probability 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 attention-grabbing query shouldn’t be whether or not Agile or XP “wins” within the agent period. The attention-grabbing query is which practices nonetheless scale back the price of discovering that the spec was fallacious.
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 job dependent, and the trustworthy calculation contains spec validation as an actual price.
For a single agent on a small, well-bounded job, the candy spot is normally structured intent: a aim, 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, information transformations—the breakeven level sits additional proper. Extra specification pays off sooner as a result of the area is constrainable and the assessments are automatable. Skimping on spec right here is simply deferring rework.
For exploratory or inventive work—structure choices, novel downside 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 programs, 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 instances: Validate your spec. Whether or not that’s a human evaluate, 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 downside continues to be ours.
