Spec-driven development does not buy a smaller team

When agent-written code reaches a budget discussion, it often arrives as a headcount argument. If agents produce the implementation, the reasoning goes, the same roadmap needs fewer engineers. It is an understandable hope, and planning around it is one of the more expensive mistakes available in this area.

Spec-driven development moves where engineering time is spent. It does not remove the need for that time, and a supplier who promises otherwise is selling something other than the method.

Where the time goes instead

When implementation becomes cheap, three activities that used to be squeezed in between bouts of typing become the job.

Specifying. Writing intent, constraints, acceptance criteria and what is out of scope, precisely enough that a competent agent, or a new engineer, would build the same thing from it. Most teams discover early that their existing tickets were nowhere near that standard, and closing the gap takes senior time.

Testing independently. Acceptance tests derived from the specification rather than from the generated code, because tests written from the implementation simply confirm it. Somebody has to own that independence.

Reviewing. Reading the specification first and the generated change against it, in changes small enough to review properly. Review capacity becomes the constraint the whole pipeline is sized against.

Infographic

The headcount hope and what actually changes

The headcount hope

• –Fewer engineers for the same roadmap
• –Speed measured by code produced
• –Review treated as a formality
• –A tool a supplier installs

What actually changes

• →Engineering time moves to specifying, testing and review
• →Speed measured from decision to working change
• →Review capacity is the constraint the pipeline is sized to
• →A method your own team runs

Who becomes scarce

The people who matter most under this method are those who can say precisely what a system should do, and who recognise when generated code does something subtly different. That is usually experienced engineers with domain knowledge — the people an organisation is least able to spare. It is worth knowing who they are before talking to any supplier, because the same people will have to give their time to the pilot.

So the realistic business case is not fewer people at the same output. It is more delivered change from the people you already have, in the kinds of work where the method fits, with your senior engineers spending more of their time deciding and checking and less of it typing.

That is a smaller claim than a headcount reduction. It is also one that holds up a year later.

What the first months cost

The method has a learning curve, and it is worth budgeting for honestly. The first specifications take longer than the code would have, because the team is learning what precise means in its own domain. Review feels slower at first, because reviewers read intent before they read diffs.

Expect the first weeks to look like a slowdown, and judge the method on the weeks after, in the kinds of work it was chosen for. A plan that promises savings from the first sprint will read that early dip as failure.

Accountability does not move

The engineer who reviewed and merged a change is accountable for it, exactly as before. That is not a formality. It is the reason review cannot be relaxed when generation throughput rises, and the reason a plan that treats review as overhead to be cut will sooner or later ship something nobody decided.

For a budget holder this has a practical consequence: the review practice is part of what you are buying, and it should be visible in the plan with time allocated to it. The engineers who merge the most generated code carry the most accountability, and their review time should be protected rather than squeezed.

How to recognise a sound proposal

A sound proposal names the kind of work it will start on. It describes what happens to engineers’ time rather than to their number, treats review capacity as a constraint, and leaves the method with your team rather than with the supplier.

A proposal whose savings line consists mostly of salaries has assumed its conclusion before doing the arithmetic.

Before reading any proposal, it is worth asking your own engineering leads three questions. Which of our people can already write a specification somebody else could build from? Who reviews well, and how much of their week is free to do it? Where are our tests good enough to trust generated code? The answers tell you how quickly the method can be introduced, and they are worth more than any benchmark a supplier brings.

How we approach it

Spec-driven development is set up in your repositories and CI, with your engineers running it and the failure modes named. It typically takes four to eight weeks to establish, followed by a check-in once the team has lived with it. If we were still running the pipeline a year later, it would have been set up wrong.