The next article initially appeared on Markus Eisele’s publication, The Predominant Thread, and is being republished right here with the writer’s permission.
There’s a psychological mannequin spreading by way of 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. Trendy.
It’s unsuitable. 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 really meant. Rework when it wasn’t.
On the different excessive: full formal specification. TDD, BDD, Gherkin situations, 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 assessments are the oracle. Cross or fail. The human doesn’t have to personally consider each output—the spec does it robotically, repeatedly, with out fatigue.
What you’re really 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 entire price of each approaches traces a U-shaped curve if you plot it towards specification completeness. The minimal of that curve—the candy spot—sits someplace round well-structured acceptance standards or BDD situations. Not at zero specification, and never at a 40-page formal necessities doc.
The previous drawback was all the time the spec
The true problem in software program engineering has all the time been specification.
Not typing. Not syntax. Not even structure within the summary. The onerous 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 “executed” 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. A number of software program engineering was by no means “writing code.” It was dragging an underspecified thought by way of sufficient friction that the lacking items had been compelled into the open.
Brokers scale 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 pace.
However writing the spec is just 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 observe, it’s systematically ignored.
While you write a spec—even a cautious one—it may well fail in methods which are invisible till the agent executes towards it. It may be internally inconsistent: two necessities that contradict one another, neither clearly unsuitable in isolation. It may be incomplete: It covers the completely satisfied path totally 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 towards 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 really 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 adjustments.
How brokers can write specs
There’s a 3rd technique this two-pole framing systematically ignores: use brokers to write down and validate the spec, then use implementation brokers to execute towards it.
This adjustments the price construction of the spec aspect of the curve. As an alternative of heavy human effort to supply acceptance standards or BDD situations, a spec-drafting agent produces a primary model from tough intent. A spec-validation agent—with a distinct position and system immediate, presumably with search entry or area information—stress-tests that draft for consistency, completeness, and testability. A test-writing agent interprets the surviving claims into executable checks. You evaluation the end result, which is quicker than writing it from scratch.
The necessary 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 title 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 determine the failure modes a lazy implementation would in all probability miss. It ought to ask what should be invariant throughout legitimate options.
The perfect immediate isn’t “write me a spec.” It’s nearer to this:
Draft the smallest spec that will let one other agent implement this safely. Embrace assumptions, nongoals, acceptance standards, edge circumstances, observable outcomes, and open questions. Then mark which components can turn into automated assessments and which components require human evaluation.
Then you definately run a distinct agent towards the output:
Assault this spec. Discover contradictions, ambiguous phrases, hidden dependencies, untestable claims, lacking failure modes, and locations the place an implementation might move the written standards whereas nonetheless violating the intent.
The candy spot just isn’t 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 are actually doing a part of that work.
How BDD partially solves this
Habits-driven growth, when executed effectively, 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 possibly can run the spec towards a skeleton implementation instantly and observe whether or not the outline produces coherent conduct. The act of creating the spec executable forces a form 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.
That is why the minimal of the overall price curve doesn’t simply mirror lowered 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 write down the situations effectively. Gherkin might be written badly. Enterprise-language specs might 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 all the pieces
In the event you’re operating a single agent on a well-bounded process, underspecification is recoverable. The suggestions loop is tight, correction is native, and the price is bounded.
Multi-agent pipelines are a distinct class of drawback totally.
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 onerous and confidently on the unsuitable basis. By the point the output surfaces to a human, the error has been amplified and obscured by way of 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 steering 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 unsuitable factor—you could have all of them, in parallel, doing in another way unsuitable issues.
What survives from methodology
So does this make all the pieces we discovered about coordinating software program groups out of date?
No. However it does change which components had 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 predominant 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 necessary, as a result of they will generate a number 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 helpful when implementation will get cheaper. Pair programming mutates into human-agent pairing, however the underlying thought 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 regionally appropriate and structurally mediocre. Small releases survive as a result of giant 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 just isn’t 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 unsuitable.
The place to really make investments
The sensible takeaway from this evaluation just isn’t “all the time write full BDD specs” and it’s not “all the time let brokers roam.” It’s that the optimum funding level is process dependent, and the trustworthy calculation contains spec validation as an actual price.
For a single agent on a small, well-bounded process, the candy spot is often structured intent: a objective, examples, nongoals, and some acceptance standards. BDD could also be overkill. Zero spec remains to be lazy accounting.
For deterministic, well-understood work—API integrations, CRUD companies, knowledge transformations—the breakeven level sits additional proper. Extra specification pays off quicker 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 artistic work—structure selections, 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 methods, 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 evaluation, an agent stress-test, or an executable format like BDD that forces structural consistency, the price of skipping it’s paid later, at larger curiosity, with worse diagnostics.
The seductive promise of zero-spec agent work is actual, however the ledger it ignores can be actual. The brokers are getting higher. The accounting drawback remains to be ours.
