Three years ago the debate about AI and software development was whether it would put developers out of work. That argument is over, and not because anyone won it. It is over because AI-assisted development became normal, and a more practical question replaced it:
can you trust the code, and who is checking?
If you are commissioning software in 2026, that is the question worth asking your supplier, and this is why.
The adoption numbers are not in dispute. Around 90% of professional developers now use AI tools in their work, according to both Google's DORA research in 2025 and JetBrains' developer survey in January 2026. At companies tracking it properly, roughly 22% of merged code is AI-authored at the median (DX, Q4 2025).
So it is everywhere. What is interesting is what happened to confidence over the same period.
In Stack Overflow's 2025 developer survey, the share of developers who trust the accuracy of AI output fell to 29%, down from 40% the year before. The share who actively distrust it rose to 46%. And 45% said debugging AI-generated code takes them longer than writing it themselves would have, with two-thirds citing "solutions that are almost right, but not quite" as their main frustration.
Adoption up. Trust down. Those are not contradictory findings — they are what it looks like when a tool becomes genuinely useful and its failure modes become better understood at the same time.
Veracode tested more than 100 language models across 80 coding tasks in 2025 and found that 45% of the AI-generated code contained security vulnerabilities. Apiiro reported a tenfold increase in security findings from AI-assisted development between December 2024 and June 2025, and found that exposure of cloud credentials roughly doubled among AI-assisted developers compared with their non-AI peers.
None of that means AI-assisted code is unusable. It means the code needs the same scrutiny any other code needs, applied consistently, by someone who knows what they are looking at. The risk is not the tool. The risk is the assumption that because something was generated quickly and looks right, it has been checked.
We use AI tooling. It is genuinely good at the parts of the job that are repetitive: scaffolding, test coverage, working through unfamiliar libraries, spotting the obvious problem in a stack trace. It gets work to a first draft faster, and that is worth having.
What we have not changed is what happens next. Everything goes through review by a person who is accountable for it. Security scanning runs on every release. Errors are monitored in production. Rollbacks are rehearsed rather than theoretical. That pipeline existed before AI and it is exactly what makes AI-assisted work safe to ship — which is the opposite of how the technology is usually sold.
The honest summary: AI has made the first 60% of a build faster. It has made the remaining 40% — the integration, the edge cases, the security, the bit where it has to work on a Monday morning for someone who did not ask for any of this — slightly harder, because there is more code to review and some of it is confidently wrong.
Two things are worth asking any supplier, including us.
"What is your review process for AI-assisted code?" If the answer is vague, that is the answer.
"What happens if a vulnerability is found in six months?" This has always been the right question. It matters more now, because the volume of code being produced has gone up and the proportion that has been read carefully has not necessarily kept pace.
Speed is not the differentiator it briefly looked like it would be. Everyone has the same tools. What separates one supplier from another is what they do with the output — and whether they are still there in three years when it needs changing.
The useful applications for most organisations are not "replace your developers". They are narrower and duller and they work: automating the manual step someone does every day, extracting sense from data you already hold, handling the routine end of enquiries so people can deal with the rest.
Those are worth doing. They are also worth scoping properly, because the failure mode of an AI project is rarely the model — it is discovering that the data it depends on is inconsistent, or that nobody agreed what "good" looks like.
If you are being told AI will transform your business and nobody has asked what state your data is in, be sceptical.
Talk to us about where AI would actually help — and where it wouldn't.
