If agents write the code, the specification becomes the thing you review

When implementation is cheap and fast, the bottleneck moves. It stops being typing and becomes knowing precisely what you asked for. Spec-driven development treats the specification as the primary artefact — versioned, reviewed, executable against tests — and lets agents produce the implementation from it.

  • Specifications precise enough to build from. Written so that a competent agent, or a new engineer, produces the same thing from them.
  • Review where the decisions are. Engineers reviewing intent and acceptance criteria rather than skimming large generated diffs, which is where review actually breaks down.
  • Tests derived from the spec. Acceptance criteria expressed as executable tests, so the specification is checkable rather than aspirational.
  • A pipeline your team can run. Set up in your repositories and CI, with the guardrails and the review gates that make generated code safe to merge.
Talk to us about this

What is delivered

  • Specification format

    A structure that works for your domain: intent, constraints, acceptance criteria, and the explicitly out-of-scope. Short enough to be read and precise enough to be built from.

  • Agent pipeline

    Generation, test execution, iteration and the point at which a human is asked. Configured in your CI rather than as a service somebody else runs.

  • Guardrails

    Size limits on generated changes, forbidden areas of the codebase, mandatory human review paths, and automatic rejection of anything that cannot be traced to a specification.

  • Test strategy

    Acceptance tests from the spec, property tests where they fit, and the evaluation harness for any AI component. Tests written to be independent of the implementation, or the whole thing is circular.

  • Review practice

    What a reviewer is actually looking for in generated code, and how to keep review capacity the binding constraint — because if it is not, under-reviewed code accumulates.

  • Team enablement

    Your engineers running the method, with the failure modes named. This is a working practice, not a tool you install.

How it runs

  1. 01

    Pick a bounded area

    A well-understood part of the codebase with good test coverage. Starting in the least understood area is how teams conclude the method does not work.

  2. 02

    Write specs properly

    Two or three real features specified to the required precision. Most teams discover here that their existing tickets were nowhere near specifications.

  3. 03

    Run the loop

    Generate, test, review, iterate — with the failure rate measured openly so the method is judged on evidence.

  4. 04

    Widen or stop

    Extend to more of the codebase if the numbers support it. If they do not, that is a legitimate outcome and worth knowing after four weeks rather than four quarters.

A good fit when

  • A team already using AI coding assistants ad hoc, with inconsistent results.
  • Well-covered code where the specification, not the typing, is the constraint.
  • Large volumes of similar work: integrations, adapters, migrations, CRUD surface.
  • You want the method to be your team's rather than a supplier's.

Not the right service when

  • Little or no test coverage. Generated code without tests is an unreviewable liability, and building coverage comes first.
  • Exploratory research work, where the specification only exists after the experiment.
  • You expect it to remove the need for engineers. It moves where they spend their time; it does not remove them, and a supplier promising otherwise is selling something else.

Frequently asked questions

Does this actually make development faster?
For the right kind of work, substantially — implementation stops being the constraint. For poorly specified or genuinely novel work it can be slower, because writing a precise specification is harder than writing the code. Knowing which kind you have is most of the value.
How do you stop the volume problem?
By capping generated change size, requiring every change to trace to a specification, and treating review capacity as the constraint the pipeline is sized against. Teams that measure generation speed and ignore review speed accumulate debt that arrives all at once.
Who is accountable for generated code?
The engineer who reviewed and merged it, exactly as with any other change. That is not a formality — it is the reason review cannot be relaxed, whatever the generation throughput.
Which agents and models?
Whatever performs on your codebase, kept replaceable. The method is what matters; the tooling in this space changes every few months and anything built around one vendor will need rebuilding.
Can you set this up and leave?
That is the intent. Typically four to eight weeks to establish the practice with your team, then a follow-up once they have lived with it. If we are still running your pipeline a year later, it was set up wrong.

Keep reading

Other services