Spec-Driven Development in the Age of Agents

For most of my career, the bottleneck in software was typing speed and context-switching. That bottleneck is gone. When you pair a clear specification with an agentic workflow, the constraint shifts from how fast can you write code to how clearly can you describe what you want.

That shift is the whole game.

Start with the spec, not the prompt

A prompt is a wish. A specification is a contract. When I start a feature, I write a short spec that captures intent, constraints, edge cases, and the acceptance criteria I'd want a teammate to satisfy. Tools like OpenSpec make this a first-class artifact rather than a throwaway message in a chat window.

The agent then has something durable to work against — and so do the tests.

Keep tests in the loop

The failure mode of AI-assisted development isn't bad code. It's plausible code that drifts from intent. The antidote is automation that runs continuously:

• Generate tests from the acceptance criteria in the spec.
• Let the agent iterate until the suite is green.
• Treat a failing test as the signal to refine the spec, not just patch the code.

If a change can't be expressed as a test, the spec probably isn't precise enough yet.

What changes for the engineer

You spend less time as a typist and more time as an editor and architect. The skills that compound are taste, decomposition, and the ability to spot when an agent is confidently wrong. None of that is going away — if anything, it's more valuable than ever.

I've shipped real products this way, from neurotech tooling to recruiting automation. The pattern holds: describe it well, verify it relentlessly, and let the agents move fast inside the guardrails you set.