DVT’s Principal AI Engineer, Ewan Mc Phail
Who owns AI-generated code? And who is at fault when that code fails? As AI becomes embedded in software development, questions such as these become increasingly important.
Using AI in software development accelerates the process, reducing the time needed to complete projects.
But concerns about accountability and decision-making affect delivery because, while automation saves time and money, it may also amplify risk.
Ewan Mc Phail, Principal AI Engineer at DVT, believes spec‑driven development is becoming essential for teams to deliver software faster without losing control over critical engineering decisions.
“Spec‑driven development helps teams retain agency in AI‑assisted delivery. By making intent, assumptions and non‑negotiables explicit upfront, the approach ensures automation executes decisions rather than inventing them, even as requirements evolve during delivery.”
The goal is to use AI as a thinking and planning partner, not an autopilot. Used well, it helps teams clarify intent early, surface gaps before they become defects and ensure automation supports, rather than replaces, engineering judgment.
Mc Phail adds, “As a lead AI engineer, I see daily how AI has upended traditional engineering workflows. While it accelerates delivery, it introduces significant risks if left unmanaged. Spec-driven development means making your intent explicit by capturing the constraints, assumptions, knowns and unknowns, requirements, non-negotiables and expected behaviours that define good delivery before you start coding.”
As a practical discipline for modern engineering teams, spec‑driven development helps to reduce ambiguity, identify issues early and keep accountability with the software engineering teams responsible for delivery outcomes. Even when AI writes code, the engineers own the outcome.
Working with AI in your pipeline has changed the way the work is done. Skipping the upfront thinking comes at a far greater cost than it used to, and figuring things out as you go is no longer a viable process.
When working with AI, the principle is simple; feed it precise intent and sharp requirements and you’ll get clean, well-suited code back. Feed it ambiguity and you’ll get guesswork.
Traditional workflows allow developers to work things out as they go. This ad hoc approach doesn’t work with an AI assistant as it can lead to inconsistencies.
Spec-driven code development moves the initial thinking to the start of the process.
For Mc Phail, the specification is a living document that is refined alongside the code as requirements change.
It becomes the place where you set out the parameters of what is known, what is unknown, what is relevant and what is not. It requires deliberation, thought and persistence because everything that follows depends on that foundation.
Certain challenges arise from this new model of coding. According to Mc Phail, the bottleneck in software delivery today is context retention.
Managing a model’s working memory during a session becomes essential. 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, so a well-maintained specification works as external memory.
This has real cost implications for businesses right now. With major platforms such as GitHub Copilot moving to usage-based billing in June 2026, wasted tokens from context drift translate straight into engineering costs.
While coding happens faster, so does waste generation. Knowing when to wipe the slate clean and restart a session is just as important as picking the right model.
Resetting the session once contradictions crop up, when moving to a new module or feature, or when the model starts repeating an earlier mistake, is essential.
This is just one of the reasons experienced developers are more important now than ever.
Mc Phail says, “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.”
Putting software developers and engineers firmly in the decision-making seat answers the question of who owns the code. Ultimately, whoever ships it is legally, professionally and practically responsible for it.
“It doesn’t matter how many lines of code AI produced; that code is your responsibility,” says Mc Phail.
“When a system breaks at two in the morning, nobody calls AI. They call you. That’s what settles the question of who’s really in charge.”
Click here to find out more about Dynamic Technologies.
Read time: 6 Minutes 24 seconds
Editorial contacts:
On behalf of Dynamic Technologies
Linda Wilkins (Wilkins Ross Communications)
[email protected]
On behalf of DVT
Karen Heydenrych
[email protected]
