insight
The AI code trust gap: adoption is settled, ownership is not
Software architect and consultant. Works with business-led product development, distributed systems, operational AI, and production software delivery.
Answer first
Around 90% of developers use AI daily, more distrust its accuracy than trust it, and its security pass rate has not moved in a year. Read together, the 2025-2026 evidence says the constraint has shifted from writing software to owning it, and that is a specification and accountability problem rather than a tooling one.
Four pieces of research published across 2025 and 2026 have quietly settled an argument the industry was still having. Taken separately each is a headline. Taken together they describe one shift, and it is not the one most of the commentary is about.
Adoption is no longer the question
DORA's 2025 report puts daily AI use at around 90% of developers. That number closes the adoption debate: there is no meaningful population of teams left to convince, and an organisation deciding whether to allow AI-assisted development is deciding about something that already happened.
What did not follow is confidence. In Stack Overflow's 2025 survey, 46% of developers actively distrusted the accuracy of AI tools against 33% who trusted them, and the trust figures have fallen year on year while usage climbed. The people closest to the output are the least willing to vouch for it.
A tool that nearly everyone uses, and that more developers distrust than trust, is not a productivity story. It is a governance story.
Syntax is solved, security is not
Veracode's 2026 testing across more than a hundred models gives that distrust a shape. Syntactic correctness is effectively a solved problem. The share of generated code that passes a security test has stalled at 56%, essentially unchanged from the previous year, with no security-specific prompting in the test conditions.
The uncomfortable part is not the number. It is that the two curves point in opposite directions from the reviewer's point of view: as generated code gets more fluent and more plausible, the cost of reading it critically goes up rather than down. Code that looks finished gets reviewed like code that is finished.
The gap that has not closed
Gartner has reported that on average only 41% of generative-AI prototypes reach production. The category is broad and the figure is not a benchmark for any single project, but it measures the same distance from a different angle: something that demos is not something an organisation can operate. We have argued the operational half of this before in operational AI versus AI pilots, and the pattern is the same whether the artefact is a model-backed pilot or a vibe-coded internal tool.
So the constraint has moved. It is no longer the cost of producing working software. It is the cost of being able to answer, about software you already have, who may change it, what it does when it fails, which data it touches, and who is accountable when it is wrong.
Why spec-driven development turned up now
The rise of spec-driven tooling — GitHub's Spec Kit is the clearest example, with its specification, plan, tasks, implementation flow — is usually explained as a way to get better output from a model. That is the smaller half of it. Its real function is to put intent somewhere durable, outside the generated code, where it can be reviewed, argued with and kept when the implementation is thrown away.
That is exactly the move we describe for business-built prototypes in turning a business-built AI prototype into production software: the prototype is an executable specification written in the wrong language, and the work is to extract the intent, classify each component as preserve, reuse-after-verification or rebuild, and require evidence before launch. Preserve intent by default; preserve generated code only where evidence justifies it.
Where this lands in four areas of practice
| Area | What the evidence changes | Where we have written about it |
|---|---|---|
| Delivery | The prototype becomes the input to a specification rather than a draft of the product, and each component is classified rather than accepted or discarded wholesale | Business-built prototypes to production software |
| Engineering practice | Review, testing and dependency scanning become gates on generated code rather than formalities, because a 56% security pass rate is a distribution, not an anecdote | Frontier models in AI-assisted implementation |
| Procurement | How a supplier's software was produced matters less than what they can show about it: tests, scans, ownership, and the ability to explain a decision | Specifying AI in a tender |
| Operations and compliance | Something that demos is not something you can operate; running systems need monitoring, accountable owners and, under the AI Act, documented deployer obligations | Knowing an AI system still works |
On the procurement side this is the argument in specifying AI in a tender: asking a supplier to attest that no AI wrote any of the code is unenforceable and increasingly meaningless, while asking for evidence of testing, scanning, traceability and named ownership is neither. On the operations side, knowing an AI system still works and the AI Act deployer obligations describe what has to be true of a system after launch, which is the half of the lifecycle a prototype never touches.
The position we would defend
Most of the current writing on this treats AI code quality as the bottleneck, and therefore treats better models, better prompts or better linting as the answer. We think that reads the evidence backwards. Quality is improving; the 2026 security number is flat rather than falling, and syntax has gone from a real problem to a non-problem in about two years.
What has not improved is the organisational capacity to absorb software that arrives faster than it can be reviewed, owned and operated. That capacity is not a tooling property. It is specifications that outlive an implementation, review that functions as a gate, and named accountability for running systems. Teams that build it will keep getting faster. Teams that do not will accumulate working software nobody can safely change, which is a more expensive problem than the one AI-assisted development was brought in to solve.
Named accountability for a running system is not a policy you write once. It has to survive the system changing hands, which is the same test we apply at the start of any operational AI engagement: if the person who built this left tomorrow, could the next person still tell what it does and why.
- Is AI-generated code less secure than human-written code?
- The useful comparison is not human against machine but reviewed against unreviewed. Veracode's 2026 testing found about 56% of generated code passed a security test when no security-specific prompting was used, and that share has not moved in a year. The practical conclusion is that generated code needs the same gates as any other code, applied at the volume it now arrives in.
- Why is developer trust in AI tools falling while usage rises?
- Because the two measure different things. Usage measures whether the tool saves time on a task. Trust measures whether the output can be relied on without checking, and as more developers use the tools on more consequential work, more of them have found cases where it could not. Stack Overflow's 2025 survey recorded 46% distrusting accuracy against 33% trusting it.
- What is spec-driven development, and why does it matter now?
- It is a flow that puts a written specification, then a plan, then tasks, ahead of implementation, with the intent kept outside the code. It matters now because generated implementations are cheap and disposable while intent is neither. A specification survives a rewrite; a prompt history does not.
- What should an organisation change first?
- Make ownership explicit before making anything else faster. Every system that reaches production needs a named owner, a specification somebody can read, and review that can actually reject something. Those three make the rest of the speed safe to use.
Research referenced
- State of AI-assisted Software Development 2025 — DORA, Google Cloud
- 2025 Developer Survey: AI — Stack Overflow
- 2026 GenAI Code Security Report — Veracode
- AI Maturity Matters: Proportion of AI and GenAI Prototypes Making It Into Production — Gartner
- Spec Kit: spec-driven development — GitHub
Newsletter
Occasional notes on building systems that hold up
A short email when we publish something worth your time. Architecture, integration, and operational AI in regulated organizations. No cadence promises, no forwarding your address.