Author: Markus Eisele
This article originally appeared in Markus Eisele’s newsletter, The Main Thread, and is republished here with the author’s permission.
A mental model is spreading in developer communities: agents are intelligent enough to figure things out, so heavy upfront specification is unnecessary bureaucratic overhead. Just describe the goal loosely, let the agent explore, and correct as you go. Fast, flexible, modern.
That notion is mistaken—not because agents can’t often produce correct results, but because the accounting is wrong. You’re not eliminating cost; you’re deferring it, fragmenting it, and making it harder to observe.
Two poles and hidden costs
There are two extreme approaches:
-
Minimal specification: describe intent loosely, let agents interpret freely, and start work immediately. Human upfront effort is near zero, but downstream costs accumulate: correction loops that consume tokens and human reengagement time, review cycles where humans act as the oracle for every output, and rework when outputs don’t match intent.
-
Full formal specification: TDD, BDD, Gherkin scenarios, acceptance criteria locked down before a line of code runs. Upfront human effort is real and visible. Downstream verification costs look different because tests act as the oracle—pass or fail—so humans don’t need to individually evaluate every output.
What you trade is when you pay and in what currency. Minimal spec front-loads token cost and back-loads human judgment. Heavy spec front-loads human effort and back-loads almost nothing because automated verification doesn’t scale with runs.
Plot total cost against specification completeness and you get a U-shaped curve. The minimum sits around well-structured acceptance criteria or BDD scenarios—not at zero specification and not at exhaustive formal documents. Multi-agent work shifts the minimum to the right because drift compounds across handoffs.
The specification problem didn’t vanish
The hard part of software engineering has always been agreeing what should exist: what must never happen, which trade-offs matter, what the system is allowed to forget, and what “done” means when reality is messy. Agents don’t remove that problem; they make it more visible.
For years we hid specification issues inside meetings, backlogs, code reviews, QA cycles, incident retrospectives, and senior engineers’ private mental models. Much of software engineering wasn’t purely “writing code”; it was dragging an underspecified idea through enough friction that the missing pieces were forced out into the open.
Agents reduce the friction of producing code, which is great. But that means missing pieces surface later, because an agent can produce a plausible implementation before anyone has truly decided what the implementation is supposed to mean.
When implementation gets cheaper, the bottleneck moves to specification and verification.
Writing the spec is only half the problem
A common omission in this debate: a spec needs validation before you hand it to an agent.
That sounds obvious, but in practice it’s often ignored. A carefully written spec can still fail in ways invisible until execution: internal contradictions, incompleteness (e.g., no handling for a third-party API returning a 429), technically correct but untestable claims, or simply being precisely what you wrote rather than what you meant.
An agent faithfully executing a flawed spec produces output that’s hard to debug: it passed every check it was given. The error is upstream, in the spec. Unwinding that reasoning is more expensive than fixing code alone.
Spec validation is therefore a distinct cost category between “write spec” and “run agent.” It asks: is the spec internally consistent? Is it complete enough to constrain the agent usefully without overconstraining valid solutions? Does it actually describe the thing we intend to build? Validation consumes human time, agent time, or ideally both—and it’s not zero. Adding it honestly to the ledger changes the picture.
How agents can help write and validate specs
A third strategy often overlooked by the two-pole framing: use agents to draft and validate the spec, then use implementation agents to execute against it.
This changes the cost structure on the spec side. Instead of heavy human effort to produce acceptance criteria, a spec-drafting agent can produce a first version from rough intent. A spec-validation agent (with a different role and prompt and perhaps access to search or domain knowledge) stress-tests that draft for consistency, completeness, and testability. A test-writing agent translates surviving claims into executable checks. You then review the result, which is typically faster than writing everything from scratch.
Crucial detail: the agent must not be a mere stenographer. A useful spec-writing agent acts like a skeptical product engineer: it names assumptions, separates goals from non-goals, produces examples and counterexamples, indicates which requirements are mechanically testable and which still need human judgment, identifies failure modes a lazy implementation might miss, and asks which invariants must hold across valid solutions.
A good prompt is closer to: “Draft the smallest spec that would let another agent implement this safely. Include assumptions, non-goals, acceptance criteria, edge cases, observable outcomes, and open questions. Then mark which parts can become automated tests and which parts require human review.”
Then run a different agent against that output: “Attack this spec. Find contradictions, ambiguous terms, hidden dependencies, untestable claims, missing failure modes, and places where an implementation could pass the written criteria while still violating the intent.”
The sweet spot is not agent-written prose alone. It’s human-approved, agent-drafted, adversarially reviewed specification with as much of the oracle made executable as the domain allows. Agents lower the cost of moving toward the useful part of the curve, but spec validation remains structurally required.
How BDD helps
Behavior-driven development (BDD), when done well, collapses spec writing and spec validation into the same artifact. A Gherkin scenario is both a description of intent and an executable test. You can run the spec against a skeleton implementation immediately and see whether the description yields coherent behavior. Making the spec executable forces a kind of validation that prose acceptance criteria don’t: some ambiguities must be resolved before a scenario can run.
This structural advantage is why the total-cost minimum sits near BDD-like practices: the format itself builds validation into the medium. That said, someone still has to write the scenarios well; Gherkin can be written badly and semantic ambiguity remains a risk.
Multi-agent pipelines break everything differently
A single agent on a well-bounded task can recover from underspecification: feedback loops are tight, corrections are local, and costs are bounded. Multi-agent pipelines are a different class of problem.
When Agent A’s output becomes Agent B’s input, interpretive drift from A compounds into B’s execution. B doesn’t know A went slightly off-course and works confidently on the wrong foundation. By the time the error reaches a human, it’s amplified and obscured across multiple coherent-looking layers.
This pushes the breakeven toward stronger specification: in multi-agent systems, a spec is a coordination contract between agents. The less precise that contract is, the more interpretive freedom introduces variance that accumulates. You want strongly typed interfaces between agents, not loose conversational handoffs. Validation of that contract matters more: a flawed coordinating spec means many agents will simultaneously do different wrong things.
What methodology survives
Not everything we learned about coordinating teams becomes obsolete, but which parts are load-bearing changes.
Agile as theater is in trouble: standups where people recite status, estimation rituals producing fictional precision, and ceremonies that primarily reassure management are less necessary. Agile as a feedback philosophy survives: short cycles, working software, customer collaboration, and the willingness to change plans remain vital. Agents make fast, convincing wrongness possible; feedback loops must get tighter.
XP’s test-first thinking survives well because executable oracles gain importance when implementations are cheap. Pair programming becomes human–agent pairing, but the core idea—keep design judgment close to code—persists. Continuous integration remains essential because every agentic change needs a fast, impartial gate. Refactoring survives because agents can create locally correct but structurally mediocre code. Small releases remain valuable because large invisible deltas are where both humans and agents lose track.
Methodology survives where it creates fast feedback; it fades where it only creates status artifacts.
Where to actually invest
The practical takeaway isn’t dogma but context-aware investment: the optimal specification point is task-dependent, and the honest calculation must include spec validation as a real cost.
- For a single agent on a small, well-bounded task: structured intent (goal, examples, non-goals, a few acceptance criteria) is often sufficient; BDD may be overkill. Zero spec is lazy accounting.
- For deterministic, well-understood work (API integrations, CRUD services, data transformations): the breakeven sits further right—more specification pays off since tests are automatable.
- For exploratory or creative work (architecture decisions, novel research synthesis): over-specification constrains useful agent flexibility; the breakeven sits left.
- For multi-agent systems: the sweet spot shifts right. The handoff is the product. Every agent boundary needs a contract (schema, invariants, allowed ambiguity, validation checks, failure behavior).
In every case: validate the spec. Whether by human review, agent stress-test, or executable formats like BDD, skipping validation only defers cost and increases interest and diagnostic difficulty.
The promise of zero-spec agent work is seductive and partly real; the ledger it ignores is real too. Agents are improving—but the accounting problem remains our responsibility.
