AI writes over half of our production code. Every line still gets reviewed by a senior engineer before it ships. Unsupervised AI development creates IP you can’t protect, security gaps nobody tested for, open-source obligations you didn’t agree to, and technical debt that compounds at machine speed. The responsible approach is AI-augmented, human-governed delivery, where AI provides the speed and engineers provide the judgement.
AI coding tools are genuinely impressive. I say that as someone whose team uses them every day to build and support mission-critical systems for our clients. We’ve measured the impact carefully: 51 percent of our code is now AI-authored, delivery is 40 to 50 percent faster, and quality is increasing alongside speed.
But there’s a version of this story being told in the market that worries me. It goes something like: “AI writes the code, we just deploy it.” Or “our AI-first approach means we don’t need traditional development teams.” Or, most commonly, a vague claim that AI has made everything cheaper and faster with no acknowledgement of the trade-offs involved.
If you’re a CTO, CIO, or Head of Digital being pitched this story, this post is for you. The speed is real. The risks are also real. And the difference between the two outcomes is whether anyone competent is watching.
The pitch you’re hearing
The market for AI-assisted software development has exploded. Vibe coding platforms promise working applications from a text prompt. Agencies advertise AI-first delivery at a fraction of traditional cost. Open-source AI tools mean anyone with a laptop can generate thousands of lines of functional code in an afternoon.
Some of this is genuinely transformative. We’ve embraced it ourselves. Our engineers are now prompt-first rather than code-first, spending more time on specification, review, and architecture, and less time typing boilerplate. The result is better software delivered faster.
The problem is not with AI tools. The problem is with the assumption that AI tools are sufficient on their own, that the speed they provide eliminates the need for the engineering discipline that surrounds them.
What actually goes wrong when nobody’s watching
The risks of unsupervised AI development are not theoretical. We see the consequences regularly, often when organisations come to us to rescue projects that started with cheaper, faster, AI-driven approaches and ended up in difficulty.
IP you can’t protect
In most jurisdictions, copyright requires human authorship. Code produced entirely by an AI, with no meaningful human creative input, may not be legally owned by anyone. This means a competitor could, in theory, reproduce identical output without infringing your copyright, because there may be no copyright to infringe.
When a senior engineer directs the AI, reviews its output, makes architectural decisions, and modifies the result, the case for human authorship is considerably stronger. When an agency runs a prompt and ships the output wholesale, your IP position is weaker.
This matters in M&A due diligence, investor scrutiny, and any situation where your software is a core business asset. For a thorough treatment of the legal landscape, read our guide on who owns AI-written code.
Security gaps nobody tested for
AI doesn’t threat-model. It doesn’t know your compliance requirements, your data classification, or the specific attack vectors relevant to your industry. It will generate code that works, but “works” and “is secure” are not the same thing.
We’ve seen AI-generated applications with misconfigured access controls, exposed API endpoints, hardcoded credentials, and authentication implementations that look correct but fail under adversarial conditions. These aren’t edge cases. They’re the predictable result of generating code without a security-aware review process.
At Talk Think Do, every project operates within our ISO 27001 framework. That means access control, incident response, change management, and security review are built into the delivery process, not bolted on at the end. AI-generated code goes through the same security scrutiny as manually written code.
Open-source contamination you didn’t agree to
Large language models are trained on vast datasets of public code, including open-source repositories with a range of licence types. When AI generates code, it can produce output that closely resembles (or exactly reproduces) existing open-source code.
If that code carries a GPL, AGPL, or SSPL licence, you may have inadvertently accepted obligations to open-source your own codebase. If it carries an MIT or Apache licence, you may have attribution requirements you’re not meeting. Without automated licence scanning in the CI/CD pipeline, these obligations accumulate silently.
This is not a theoretical concern. It’s why we run licence scanning tools on every build and treat AI output as a third-party contribution that requires the same diligence as any open-source dependency.
Technical debt at AI speed
AI generates code fast. It also generates inconsistency, duplication, and architectural drift fast.
Without spec-driven guardrails, AI tools make different architectural decisions between sessions. Component patterns shift. Naming conventions change. What was a clean codebase after the first sprint becomes an increasingly tangled one by the third, because the AI is optimising for the immediate prompt, not for the long-term coherence of the system.
This is the iteration ceiling that catches teams off guard. The first few weeks feel fast and effortless. Then the pace drops sharply as every change requires understanding and compensating for the accumulated inconsistencies.
We address this with spec-driven development using Open Spec, which anchors AI output to a consistent specification across the entire project lifecycle. When AI drifts, the spec brings it back. For organisations that have already hit this ceiling with a vibe-coded prototype, our prototype-to-production service helps get the codebase to a state they can depend on.
No compliance story for your auditors
If your organisation holds Cyber Essentials, ISO 27001, or operates under sector-specific regulation, you need to be able to explain how your software was built, who made the decisions, and what controls were in place during development.
“An AI wrote it” is not an acceptable answer to an auditor. You need evidence of human oversight, documented review processes, controlled access to production environments, and a clear audit trail from requirement to deployment.
Partners who use AI responsibly will have this documentation as a natural output of their delivery process. Partners who don’t will leave you to construct the compliance narrative after the fact, which is expensive, incomplete, and often reveals gaps that should have been caught during delivery.
What supervised AI development actually looks like
The opposite of unsupervised AI is not “no AI.” It’s AI-augmented, human-governed delivery, where AI provides speed and engineers provide judgement.
In practice, at Talk Think Do, this means:
-
Quarterly AI evaluation cycles that assess the latest models and tools, deploy what proves itself, measure outcomes, and retire what doesn’t perform. Our AI approach page describes this in detail.
-
Spec-driven development using Open Spec to anchor AI-generated code to a consistent architectural specification, preventing the drift that causes projects to slow down over time.
-
Senior engineer review of all AI-generated code before it reaches production. Every pull request is reviewed by a human with the context to assess whether the code is correct, secure, and architecturally sound.
-
ISTQB-qualified testing that validates AI-generated code against functional requirements, edge cases, and regression risks.
-
Licence scanning in CI/CD to catch open-source contamination before it reaches your codebase.
-
Full audit trail from requirement to deployment, so compliance documentation is a natural output of the delivery process, not a retrospective exercise.
The result is the speed benefit of AI without the governance gap. We deliver faster, but with the same (or higher) standard of quality, security, and compliance that our clients depend on.
The cost of getting this wrong
The cheapest AI build is rarely the cheapest outcome.
We now regularly receive enquiries from organisations that need help rescuing software built with unsupervised AI approaches. The pattern is consistent: a project was delivered quickly and cheaply, it worked initially, and then the problems started to surface. Security issues found during a penetration test. Licence obligations discovered during due diligence. Architectural debt that made the system expensive to change. An inability to explain to regulators how the software was built.
The rescue is always more expensive than doing it properly the first time. Our prototype-to-production service and vibe coding rescue service exist because this pattern has become common enough to warrant dedicated offerings.
The organisations that avoid this path are the ones that asked the right questions during partner evaluation. If you’re currently shortlisting development partners, our evaluation checklist for 2026 covers what to look for and what to be wary of.
Frequently Asked Questions
Does this mean AI is too risky to use for software development?
No. AI-augmented development is delivering measurable gains in speed, cost, and quality. The risk is not in using AI; it’s in using AI without adequate human oversight, security review, and compliance governance. When supervised properly, AI is a significant advantage.
What percentage of code should be AI-generated?
There is no universal target. In our team, 51 percent of code is AI-authored, with higher percentages in front-end systems where patterns are consistent. The right percentage depends on the project’s complexity, the maturity of the AI tooling, and the quality of the review process around it. The percentage matters less than the governance.
How do you audit AI-generated code for compliance?
Through a combination of automated and human processes: licence scanning tools in the CI/CD pipeline catch open-source contamination, senior engineers review all code for security and architectural quality, and ISTQB-qualified testers validate functional correctness. The process generates an audit trail that maps requirements to deployed code.
What is the difference between AI-augmented and AI-generated development?
AI-generated development treats AI as the primary author with minimal human involvement. AI-augmented development uses AI as a tool within a human-led engineering process. The distinction matters for IP ownership, security, compliance, and long-term maintainability. We practise AI-augmented development exclusively.
Should I ask my current development partner how they use AI?
Yes. Ask what models they use, what percentage of code is AI-authored, how they evaluate and update their tooling, and what governance processes are in place for AI-generated output. If they can’t answer these questions specifically, you may be carrying risks you haven’t been told about.
How do I know if my existing codebase was built with unsupervised AI?
Common indicators include inconsistent architecture between modules, duplicated logic, variable naming patterns that shift across the codebase, missing or generic test coverage, and no documentation of design decisions. A professional code audit can identify these patterns and assess the remediation effort required.
Build with confidence
If you want the speed benefits of AI without the governance gap, we’d welcome the conversation. We’re transparent about how we use AI, we measure its impact, and we don’t let it ship anything unsupervised.
Book a consultation to talk about your project.