For twenty years I have argued that requirements, tests, and code are the same information at three altitudes, and that the job is to keep them in sync. The argument has not changed — the economics finally have. The correct way was always to nail the spec first, but that was the slower way, and when a human sits down at a keyboard there has always been an unspoken rule that whatever they type had better be code. Spec-writing looked like stalling. So teams typed the code, and the spec — if it ever existed — drifted into fiction. That trade-off is now dead. With an agent doing the transformation from requirement to test to implementation, the spec-first path is no longer the slow path. Getting it right is now faster than winging it, because a well-captured requirement is the thing an agent can actually execute against, and a vague one is the thing you pay for in review, rework, and slop.

I recently decided to polish my TDD talk, TDD in the Agentic Era, with exactly this in mind. The talk always rested on having the spec; the revision makes the spec mandatory. The workflow now begins at the requirement and refuses to move without one — the agent cannot write a test or a line of implementation until it has pulled the spec and turned its acceptance criteria into an executable scenario. In the 60-minute hands-on version, every artifact is real, runnable code — an MCP server, a client agent, a requirements backlog, Gherkin scenarios, and a Red/Green/Refactor state machine that refuses to let anyone, human or AI, refactor on a red bar. It is public in the tdd-bdd-agentic repository , and I use it through this post as the working proof of the argument. But the workshop is the demonstration, not the point. The point is that my old conviction is holding true, and the time to do this — and get it right — is now: why this style finally pays for itself, and why this exact idea, spec-driven development as a triangle, is the reason I joined CodiumAI. I chose them for Itamar’s vision — a vision that was not completely deliverable at the time, given where the models were, but was spot on about where this was all going. That company is the one you now know as Qodo.

What we accomplish in the hour

Everyone has watched an agent demo. Almost nobody has driven the workflow underneath one. That is the gap the workshop closes — and deliberately not by building plumbing. The MCP server and client come completed in the repo (Java, stdio transport, tested to 100% coverage); MCP gets about seven minutes as the standard way to feed your tools into whatever agent you use — Cursor, Claude Desktop, or the bundled CLI client, which narrates the handshake, discovery, and invocation that every IDE does under the hood. The rest of the hour, with 35 of the 60 minutes at your keyboard instead of looking at mine, every attendee:

1. Drafts and refines a requirement with an agent. You describe the intent in a sentence; the agent writes the requirement into the backlog; and then the spec iterates through two server feedback loops. First structure: validate_spec reports every issue — a criterion missing its Then, a duplicate id, broken JSON — and the agent fixes and re-validates until the spec is valid. Then wording: refine_requirement critiques the draft — “‘quickly’ is ambiguous,” “the story is missing its why,” “only happy paths, add an edge case” — and the LLM rewords against that deterministic feedback until the critique comes back clean. The agent drafts, the server arbitrates, the human approves the final wording.
2. Drives the full spec-to-green loop. A real LLM agent validates the spec, picks up a pending requirement through the seven workflow tools (list_requirements, get_requirement, validate_spec, refine_requirement, run_tests, get_tdd_state, start_refactor), writes the Gherkin scenario for its acceptance criteria, runs the tests to show RED, implements the simplest code to reach GREEN, and then — only then — refactors.

The kata under all of this is deliberately boring: the String Calculator. The point was never the calculator. The point is the workflow wrapped around it.

Three altitudes, one discipline

The center of the talk is a slide I call the three altitudes. It is not “just TDD.” It composes the three spec-first methodologies, each pinning the system at a different height, and the agent works across all of them:

The flow is spec-down. The agent reads a requirement (SDD), turns its acceptance criteria into a tagged Gherkin scenario (BDD), adds unit tests where useful (TDD), and the run_tests tool runs Cucumber and JUnit together — one bar, one color. Tests are generated from the spec, not reverse-engineered from the code afterward. That direction is the entire spec-driven claim.

Here is what the agent actually produces during the spec-to-green exercise, for a requirement whose acceptance criteria were already phrased Given/When/Then in the spec:

  @REQ-003
  Scenario: Two numbers separated by a comma are summed
    Given a string calculator
    When I add "1,2"
    Then the result is 3

And here is the prompt the audience pastes into their agent — notice how much of it is workflow, not code:

Using the tdd-workflow tools: validate the spec first, then find the next pending requirement, add a Gherkin scenario for its acceptance criteria to the feature file (tag it with the requirement id), reuse or add step definitions, run the tests to show RED, then implement the simplest code to reach GREEN, then refactor. Ask me before each phase change.

There are two hard human checkpoints in the loop. The first is a spec review: when the agent writes the scenario, the room stops and reads it aloud — is this the behavior we want? The second is diff approval after GREEN. The agent turns the crank; the human steers. And the discipline is not a suggestion living in a prompt — it lives in the tool. Ask the server to start_refactor while the bar is red and it refuses. Guardrails belong in code, not in vibes.

Twenty years a convert

I have been a convert to this style for twenty years. Test-first, behavior-first, and above all requirements-first — the conviction that you cannot build the right thing until someone has written down, in a form that can be checked, what the right thing is. I lived through the era when the spec was a Word document that was obsolete before the first sprint ended. Cucumber and Gherkin were the first tools that let the requirement itself become executable, and I never went back.

But I should be honest: being a convert and getting to practice it were two different things. The conviction was mostly private, because in most places I worked the requirement either did not exist at all or arrived from someone outside engineering — a product owner, a stakeholder, a business analyst — who was never equipped to turn what they wanted into a technical requirement or a PRD an engineer could build against. What came across was rarely close. That was not their failing. They knew the business cold; they simply were not trained to interrogate a request the way it needs to be interrogated — to dig for the edge cases and the unstated assumptions, to ask the questions that actually need asking, and to pin the answers down in a form that can be checked. So I spent twenty years believing in requirements-first while working in organizations that rarely produced a requirement worth the name.

Which is the whole point, because it tells you where the scarce skill always lived. It was never typing the code. It was extracting what is actually needed — from the ticket, from the stakeholder, from the silence between what they said and what they meant — and pinning it down in a testable form. That is why the agentic era feels like vindication rather than disruption to me. An agent is a phenomenal crank-turner, but it can only turn the crank on requirements someone captured well — and if that skill was scarce when a human wrote the code, it is scarcer and more valuable now that an agent will faithfully execute whatever you hand it, good spec or bad. Which leads me to believe the developer’s real emerging role is requirements gatherer for the agent — but that is another post, and I intend to write it.

The triangle that made me join

In July 2024 I was deciding whether to join a startup called CodiumAI. Plenty of companies were pitching AI code generation; what convinced me was that the CEO, Itamar Friedman , was saying the same thing I had spent twenty years believing — and he had drawn it as a triangle: spec, tests, code, kept in sync. He lays it out most explicitly in his Gen 3.5 framing , where agents collaborate around three core artifacts, Specs → Code → Tests, improving the spec, transforming it into code, generating and executing tests, and keeping all three tightly aligned as each evolves. I was not joining a company that bolted testing onto generation as an afterthought; I was joining one whose founding thesis was that the three corners are the same information at different altitudes and the job of AI is to keep them aligned. When I joined, that vision was ahead of what the models could deliver. Reading it now, with the workshop in this post running exactly that loop on my laptop, we are close — if not already there.

The workshop is the triangle, running

Look back at the workshop with the triangle in mind and the mapping is one-to-one:

• Spec corner: requirements.json, versioned, with acceptance criteria — drafted with the agent, held structurally valid by validate_spec and iterated to clean wording by refine_requirement, and the source of truth the agent implements from.
• Tests corner: the Gherkin feature file and the JUnit tests, generated from the spec, executed together as one bar.
• Code corner: StringCalculator.java, written last, as the simplest thing that makes the bar green.

The MCP server is the connective tissue — the standard way for an agent to discover your workflow tools and respect your discipline. The human sits at the two checkpoints where judgment lives: is this the right spec? and is this the right code? Everything between those checkpoints is crank-turning, and the crank no longer needs to be turned by hand.

Twenty years ago, keeping the three corners in sync was a manual discipline that most teams abandoned under deadline pressure. The spec drifted, the tests decayed, and the code became the only truth — unreadable, unverifiable truth. What the agentic era changes is the cost of the discipline. The alignment work that teams always skipped is exactly the work agents are good at.

The talk ends with homework: on trunk — the exact starting point the class clones — requirements REQ-004 through REQ-006 are still pending, and the requirement the room drafted in Exercise 1 is waiting to be taken to green. Clone the repo , point your agent at the tools, and finish the kata on the plane home. Watch the bar go RED, then GREEN. And if you want the answer key, the complete branch is the kata fully driven through the loop — every requirement implemented, every scenario tagged and green — with CI telling the story on both branches: trunk deliberately fails a class-completeness check because the work is still ahead of you; complete passes everything. Then ask yourself who really wrote the requirement — because that person, not the agent, decided what got built. That’s the next post.