Why AI Coding Agents Still Need Clear Specs
Markus Eisele · rss · 2026-07-08 source ↗ Reader 🖥️
Agile & XPCoding AgentsCoordination CostMulti-Agent OrchestrationSpec-Driven DevelopmentTest-Driven Development
AI coding agents don't eliminate the cost of specification, they relocate it into downstream correction loops and human review, so the real discipline is locating — and validating — a task-dependent sweet spot on a U-shaped completeness-vs-cost curve, one that shifts toward much stronger contracts as more agents are chained together.
practical · argumentative — Builds a cost-accounting argument (minimal spec doesn't eliminate cost, it defers and hides it) toward a concrete recommendation: validate specs and size specification effort to the task, with multi-agent pipelines needing the most. Illustrated with conceptual diagrams rather than data, but the intent throughout is to change how readers act, not just how they understand.
Structure
| Part | Role |
|---|---|
| Two poles, two hidden costs | problem setup |
| The old problem was always the spec | reframing/context |
| But writing the spec is only half the problem | complication |
| How agents can write specs | proposed solution |
| How BDD partially solves this | supporting mechanism |
| Multi-agent pipelines break everything | escalation/complication |
| What survives from methodology | reassessment |
| Where to actually invest | conclusion / practical guidance |
Key terms
- spec validation
A distinct cost category, separate from writing the spec and running the agent, that checks whether a spec is internally consistent, complete, testable, and actually describes what was meant — not just what was written. - oracle
Whatever determines whether an agent's output is correct — extended beyond automated tests to include a human acting as the arbiter of every output, or a critic agent stress-testing a spec. - handoff contract
The structured interface between two agents in a pipeline — schema, invariants, allowed ambiguity, validation checks, failure behavior — treated as the actual coordination mechanism, not just documentation. - U-shaped cost curve
Total cost (upfront authoring + downstream correction) plotted against specification completeness, with a minimum somewhere between zero spec and full formal spec — the location of that minimum is the article's central practical claim.
Propositions
- explicitMinimal specification does not eliminate the cost of building software with agents; it defers that cost into downstream correction loops and human-judgment review.conf: high
- explicitHeavy formal specification (TDD/BDD/acceptance criteria) front-loads human effort but makes downstream verification automatic, so its cost doesn't scale with the number of runs.conf: high
- explicitTotal cost, plotted against specification completeness, traces a U-shaped curve whose minimum sits around well-structured acceptance criteria or BDD scenarios, not at either extreme.conf: medium
- explicitA spec must be validated for internal consistency, completeness, testability, and fidelity to actual intent before it is handed to an agent, and this validation is a distinct cost usually left off the ledger.conf: high
- explicitUsing a spec-drafting agent plus an adversarial spec-critic agent lowers the cost of moving toward a more complete specification, without eliminating the need for validation.conf: medium
- explicitIn multi-agent pipelines, interpretive drift from one agent's output compounds silently into the next agent's work, shifting the cost-minimizing point decisively toward stronger, typed handoff contracts.conf: high
- explicitAgile and XP practices survive the agent era selectively: ceremony and status theater fade, while short feedback loops, test-first thinking, CI, refactoring, and small releases survive because they cheaply expose that a spec was wrong.conf: high
- explicitdevelopedThe optimal specification investment point is task-dependent: exploratory work wants loose intent plus boundaries, deterministic work wants heavier BDD/contract-style specs, and multi-agent work wants the most (typed contracts).conf: highextends ←When AI Writes the Code, Specifications Need an Exit Strategy · p4 — Sharpens the earlier piece's task-dependent 'sweet spot on a completeness curve' into an operational rule: scope every spec to the delta of the current change, and discard the rest after release.
- implicitThe article treats upfront human authoring effort, token cost, and downstream human-judgment time as commensurable quantities that can be summed into one 'total cost' and traded off against each other, without establishing a common unit of account.conf: medium
- implicitThe article implicitly treats 'the human' as a single, already-aligned oracle who reliably knows what the spec should say, sidestepping the more common situation of multiple stakeholders disagreeing about intent.conf: medium
- implicitdevelopedThe proposal to use a spec-critic agent to catch flaws in a draft spec implicitly assumes that agent-based critique is reliable enough to trust, without addressing what validates the critic agent itself.conf: mediumextends ←Netflix Open-Sources Agentic Workflow for Causal Inference · p2 — eisele's piece flags that a spec-critic agent's own reliability goes unaddressed; Netflix's design partially answers this by pairing the critic with process audits (inspectable, re-executable artifacts) and human oversight rather than trusting the critic's rating alone — though this article shows the same underlying question (who validates the critic) is still unresolved (see g2).
Arguments
The optimal amount of upfront specification is task-dependent, sitting at the minimum of a U-shaped total-cost curve rather than at either the 'zero spec' or 'full formal spec' pole. strength: medium
Explicit premises:
- Minimal spec has near-zero upfront cost but generates downstream correction loops and human-judgment cost on every run.
- Heavy formal spec has real, visible upfront human cost, but the tests act as an automated oracle, so verification cost does not scale with the number of runs.
- Plotting total cost against specification completeness therefore produces a U shape rather than a monotonic line.
Implicit premises:
- Upfront authoring effort and downstream correction effort are commensurable and can be summed into a single 'total cost' metric.
- The curve's basic shape holds across most software tasks, differing mainly in where its minimum sits.
Inferences:
- If the curve is genuinely U-shaped, teams could locate their task's minimum empirically (e.g., by tracking rework counts across spec-completeness levels) rather than by ideology — a concrete measurement practice the article gestures at but never spells out.
Multi-agent pipelines need much stronger (typed) handoff contracts than single-agent tasks, because interpretive drift compounds and gets obscured across handoffs. strength: medium
Explicit premises:
- When Agent A's output becomes Agent B's input, any drift in A's interpretation propagates into B's work without B detecting it.
- By the time a human sees the final output, the error has been amplified and obscured through multiple layers of apparently coherent work.
- A spec in a multi-agent system therefore functions as a coordination contract between agents, not just guidance for a single execution.
Implicit premises:
- Agents cannot currently self-detect when their upstream input is subtly wrong, so drift goes unchecked by default.
- Stronger/typed contracts materially reduce interpretive freedom without destroying the agents' usefulness.
Inferences:
- Pipeline depth (number of agent hops), not just task type, should size the investment in contract precision — implied but never quantified or stated directly.
Narratives
- Agent A produces output that becomes Agent B's input; B doesn't know A drifted slightly off-course and works confidently on the wrong foundation, so by the time a human sees the result the error has been amplified and obscured through multiple layers of apparently coherent work.
→ Makes the abstract claim about compounding interpretive drift concrete, motivating the call for stronger typed handoff contracts in multi-agent pipelines. - A spec covers the happy path thoroughly but says nothing about what happens when the third-party API returns a 429.
→ Illustrates 'incomplete spec' concretely — a spec can look finished while silently omitting failure-mode behavior, which only surfaces later as expensive-to-diagnose agent output.
Questions addressed
- ✅ Should teams minimize upfront specification when using AI coding agents, on the theory that agents are smart enough to fill the gaps?
No — this only defers cost into downstream correction loops and human review; the real question is where the task's total-cost minimum sits on the completeness curve. - ✅ Does using agents to draft and critique specs eliminate the need for spec validation?
No — it changes who performs validation (agent instead of human) and lowers its cost, but the structural requirement that specs be validated before implementation agents run still stands. - ✅ Do Agile and XP practices still matter once agents can produce code quickly?
Selectively — ceremony and status theater fade, while feedback-generating practices (short cycles, test-first, CI, refactoring, small releases) survive because they cheaply expose that a spec was wrong. - ⭕ Who validates the spec-validation (critic) agent itself, and what happens when its critique misses something or is wrong?
Gaps
- incompleteThe U-shaped cost curve and its variants (single- vs multi-agent, BDD vs prose) are presented as illustrative line charts with no axis units, no measured data points, and no cited study — the model is asserted as intuitively obvious rather than empirically demonstrated.
Read next: Look for empirical studies quantifying rework/correction cost under varying spec completeness with AI coding agents (e.g., controlled comparisons of BDD vs prose-spec agent tasks, or DORA-style research) to test whether the curve's shape and minimum location actually hold. - incompleteThe essay proposes a spec-validation ('critic') agent as a cost-lowering step but never addresses who or what validates that critic, or what happens when its critique is itself wrong or incomplete — an infinite-regress problem inherent to using agents to check agents.
Read next: Look at multi-agent debate and self-consistency literature, or formal-verification framing of 'who verifies the verifier,' for how (or whether) this regress is bounded in practice. - uninformedThe claim that specification, not implementation, has always been the hard part of software engineering closely tracks Fred Brooks's essential-vs-accidental-complexity distinction, but the piece never engages that lineage or the decades of requirements-engineering literature built on it.
Read next: Fred Brooks, 'No Silver Bullet — Essential and Accidental Difficulties of Software Engineering' (1986); also classic requirements-engineering work distinguishing validation ('are we building the right thing') from verification ('are we building it right'). - incompleteThe cost ledger treats 'the human' as a single, already-aligned oracle who knows what the spec should say; it never addresses the more common real-world case of multiple stakeholders disagreeing about intent, which is a large share of why specs are hard to write and validate in the first place.
Read next: Organizational and requirements-engineering material on stakeholder conflict and specification as a negotiated artifact, not merely an accuracy artifact — relevant to team-space and change-adoption thinking about how groups actually converge on shared intent.
Related documents
- [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero
- Agentic AI and Code Reviews
- No Vibes Allowed: Solving Hard Problems in Complex Codebases – Dex Horthy, HumanLayer
- Kent Beck's Post
- Jimmy Nilsson's Post — reflections after the Thoughtworks 'Future of Software Development' retreat
- LIVE: Uncle Bob on Software Fundamentals in the Age of AI
- When AI Writes the Code, Specifications Need an Exit Strategy
- Why did Martin Fowler invite 60 engineers to a ski resort?
- agent-skills/docs/comparison.md at main · addyosmani/agent-skills · GitHub
- Have your agent record video demos of its work with shot-scraper video