Before funding spec-driven development, sort your backlog

The pitch for agent-written code usually comes down to a single number: how much faster development will be. It is the wrong shape of answer. Spec-driven development makes some kinds of work dramatically cheaper and some kinds slower, and the business case depends almost entirely on the mix in your backlog.

That mix can be estimated before anybody buys anything, by the people who already know the work.

Where the method changes the economics

When agents produce the implementation from a specification, the cost of a change moves from writing the code to stating precisely what the code should do. That trade is excellent when stating it is easy and the code is laborious, and poor the other way round.

For a budget holder this changes the question. Not whether the method works in general, but how much of your work it fits, and what the rest of the work needs first.

Similar work in volume. Integrations, adapters, data migrations, the CRUD surface of an internal system. The pattern is known, the acceptance criteria can be written down, and most of the old cost was typing and checking. This is where the method pays.

Well-tested code. A generated change is only as safe as the tests that judge it. An area with good coverage can absorb generated code; an area without it absorbs liability.

Stable intent. Work where the people asking for it know what they want before it is built. A specification written once and reviewed once is cheap. One rewritten after every demo is not.

Where it does not

Exploratory work. Research, prototypes, a new product idea. The specification only exists after the experiment, so writing it first is writing fiction.

Genuinely novel design. When the hard part is deciding the architecture, a precise specification is harder to write than the code, and the method adds a step rather than removing one.

Code nobody understands. Legacy areas without tests or owners. Starting there is the most reliable way to conclude that the method does not work, when what actually failed was the choice of area.

Infographic

Where agent-written code pays, by kind of work

ResearchUntested legacyArchitecture changeNew featuresData migrationsIntegrations and adapters

Method slows downMethod pays off

Sort the backlog before you buy

The useful exercise takes an afternoon. Take the last two quarters of delivered work, or the next two of planned work, and sort each item into three piles: it could have been specified precisely before it was built; it could not; it would not have been safe to generate, because the tests were not there.

The proportions are the business case. A backlog dominated by the first pile is a strong candidate. One dominated by the second means the constraint is clarity about what should be built, and no coding method will fix that. One dominated by the third means the first investment is test coverage, which pays off with or without agents.

The exercise also tells you who should be in the room. The people who can sort the pile honestly are the engineers and leads who did the work, not the people who planned it.

What a good outcome looks like

Not a uniform speed-up. A good outcome is a clear map: these areas and these kinds of work go through specifications and agents, these stay as they are, and this one needs tests first.

The teams working in the first group spend less of their time on implementation and more on specification and review, and the time from deciding on a change to having it working shrinks in exactly those areas. Elsewhere not much changes, and that is fine, because it was never going to.

The map is worth having in its own right. It tells a board where money spent on the method works, and where it is better spent on tests or on clarifying what should be built.

What to watch for in a proposal

A supplier who promises a uniform speed-up across all of your work has not looked at your work. The honest answer varies by area, and knowing which area is which is most of what you are paying for.

Be equally careful with a pilot proposed in the hardest part of the codebase, on the grounds that it will prove the method at scale. It will prove something, usually the wrong thing, and the conclusion will be drawn about the method rather than about the choice.

How we approach it

Spec-driven development starts in a bounded, well-understood and well-tested area, with two or three real features specified properly and the failure rate measured openly. If the numbers do not support widening, that is a legitimate outcome, and it is better known after four weeks than after four quarters.