How spec-driven development keeps you in control of AI code

Ewan Mc Phail, Lead AI Engineer at DVT.

---

Back in 1979, an IBM training manual included a warning that feels strangely fitting today: "A computer can never be held accountable, therefore a computer must never make a management decision." In software engineering, every line of code is a decision. The architecture you choose, the edge cases you handle and the way you structure your data are all choices that decide whether a system succeeds or fails. With generative AI now part of our toolkit, there's one question worth asking: who is making those decisions in your codebase?

As a Lead AI Engineer, I see daily how AI has upended traditional engineering workflows, says Ewan Mc Phail, Lead AI Engineer at DVT. While it accelerates delivery, it introduces significant risks if left unmanaged. Spec-driven development means making your intent explicit before you start coding. You capture the constraints, assumptions, knowns and unknowns, requirements, non-negotiables and expected behaviours that define what good delivery looks like.

In my experience, it's the best way to get real value from AI assistants while staying in control of delivery. The principle is simple: skipping the upfront thinking now costs far more than it used to. We can't afford to figure things out as we write code anymore.

The basic rule of working with AI in your pipeline is what I call the amplifier principle: AI multiplies whatever input you give it. Feed it precise intent and sharp requirements, and you'll get clean, well-suited code back. Feed it ambiguity, and you'll get guesswork.

The old rule of computing still applies: garbage in, garbage out. The difference now is that AI delivers that garbage 10 times faster and with 10 times the confidence. When developers write code by hand, they have time to spot structural flaws and bad assumptions along the way. When AI generates hundreds of lines in seconds from a vague prompt, those flaws end up buried deep inside a mountain of text.

Without a clear specification, the model fills the gaps with assumptions that sound plausible. The output might look elegant, compile cleanly and pass basic happy-path smoke tests, but it can still be completely wrong for your business.

If you skip the upfront thinking, AI quickly generates mountains of technical debt, leaving you with a difficult to maintain architecture and application. You don’t notice this in the pull request – you notice it three sprints later, when nothing is maintainable.

Traditional workflows let developers work things out as they go, often discovering the solution right there in the code editor. With an AI assistant, that ad hoc approach can lead to inconsistencies. You need to move the thinking to the start of the process. The specification becomes the place where you set out what you know, what you don't know and what's important and what isn't.

To build a specification an AI can work from properly, I follow a four-step process:

1. The brain dump. Write down everything you know about the feature or module: user needs, technical constraints, engineering limits and non-negotiables. Relevant knowns and unknowns. Don't worry about formatting yet, just get it all down.
2. AI interrogation. Hand that raw dump to the model and ask it to question you. Get the AI to look for logical flaws, missing edge cases and hidden assumptions. This back and forth usually uncovers technical challenges you didn't know were there, and you can keep refining until there are no surprises left.
3. Lock the non-negotiables. Set out clearly the boundaries the model can't cross: your security policies, compliance standards, performance budgets and integration contracts. These are your guardrails.
4. Define done. Set out exactly what “done” actually looks like, including the test requirements, observable behaviours and edge cases that prove the system works under real conditions.

You don't need a perfect, fixed document on day one. The specification is a living document that you refine alongside the AI as requirements change. But you do need to be deliberate about it, because everything that follows depends on that foundation.

Context economics is about managing a model's working memory during a session, how much relevant, structured information you can keep coherent across a session and a codebase. Many teams focus purely on token costs, but the real bottleneck in software delivery today is context retention.

Large language models lose context over time. In a long session, or after thousands of tokens have passed, models start to forget earlier constraints and design choices. A well-maintained specification works as external memory. It lets you re-anchor the model's understanding quickly every time you start a new session.

This has real cost implications right now. With major platforms like GitHub Copilot moving to usage-based billing in June 2026, wasted tokens from context drift translate straight into engineering costs. If code gets generated 10 times faster, the waste happens 10 times faster too.

To manage your context economics well, use a tiered model selection strategy based on task complexity:

Knowing when to wipe the slate clean and restart a session is just as important as picking the right model. Reset the session as soon as you notice contradictions creeping in, when you move to a new module or feature, or when the model starts repeating an earlier mistake.

Many valuable tools currently exist to help with context and token economics – consider tools like Claude mem, Coedegraph, Graphipy, Headroom, KiroGraph, RTK, etc.

Treating an AI assistant like an unsupervised autopilot rather than a colleague invites architectural risk. There are three risks developers need to watch for:

The IBM problem. This arises when the AI implements an architectural decision that escapes notice. It delivers an implementation that looks plausible but quietly changes system behaviour, misses an important edge case or introduces a security flaw that ships straight to production.

The drift problem. Over a long session, the model's understanding of your application slowly drifts from reality. It starts contradicting design decisions made hours earlier. Without a stable specification to check against, you often only spot this after deployment.

The confidence trap. AI models are remarkably persuasive; they excel at producing plausible-sounding code that passes surface-level tests but lacks deep structural integrity. The risk here isn't just bad code; it's the false sense of security that develops when the AI seems to be 'getting it right' consistently, blinding you to the structural weaknesses accumulating beneath the surface.

AI can't fill a gap it doesn't know exists, which means it amplifies both your skill and your blind spots equally. This is why experienced developers are more important now than ever.

We still need human judgment for security. If a developer has never manually checked code for OWASP vulnerabilities, they won't be able to tell whether their AI assistant has introduced a serious security hole. We need human engineers for architecture decisions too. An AI executes patterns it has seen before, but it can't judge whether a pattern fits Conway's Law or your organisation's long-term maintainability needs. Testing strategy is also a human skill. An AI will happily write tests for the code it just generated, but it doesn't know which tests will actually surface deeper architectural flaws.

Ultimately, whoever ships the code owns it: legally, professionally and practically. Copyright, liability and professional responsibility all sit with you. It doesn't matter how many lines of code the AI produced; that code is your responsibility. When a system breaks at two in the morning, nobody calls the AI. They call you. That's what settles the question of who's really in charge.

When your specification is solid, writing the code becomes the easy part. Models are very good at turning an accurate prompt into working software, which makes the implementation phase almost straightforward.

This changes what we value in engineering. We're moving away from an era where value was about how fast you could type out boilerplate, build repetitive CRUD apps or fix trivial syntax errors.

By adopting spec-driven development, you raise the standard of your engineering practice. At DVT, I've used this spec-first approach to deliver a focused application in just three days, with no scope creep, since the AI stuck to the plan. For larger, multi-component systems with multiple integrations, a living specification lets you handle mid-project changes with confidence instead of crossed fingers.

You stop spending hours on tedious scaffolding and start focusing your energy on architecture, system intent and the harder problems. Our ability to deliver software has evolved; it is now defined less by how fast we type code and more by how precisely we frame the problem.

Spec-driven development is how you stay in control of that process, and how you build the right thing the right way.