Is AI-generated code safe to ship?

Is AI generated code safe to ship? If you are funding software built in 2026, a large share of it was written by a machine. That is not a scandal and it is not something to stop — it is how software is now made, and the alternative is paying considerably more for the same result.

But it does change your risk profile, in ways that are specific enough to manage. You do not need to read code to do it.

The actual problem is arithmetic

Writing code got dramatically cheaper. Reading and understanding code did not.

That is the whole thing. Every consequence below follows from it. When production is cheap and verification is not, the natural drift is toward shipping more code that fewer people have genuinely read — not because anyone decided to, but because that is where the path of least resistance leads.

DORA's 2025 research found this playing out at industry scale: AI adoption correlating with higher delivery throughput and higher instability, with more change failures and more rework. Their reading is that AI exposes existing bottlenecks in testing and review rather than creating new problems.

Four risks that reach the business

Dependencies nobody checked. This is the one with hard numbers. A USENIX Security study generated 2.23 million code samples across sixteen models and found them importing packages that do not exist at rates from 5.2% on commercial models to 21.7% on open-source ones. A 2026 replication on frontier models measured 4.62%–6.10% — better, not solved.

The invented names are predictable, which means attackers can register them in advance and wait. The attack has a name, slopsquatting, and it is not hypothetical.

The fix is mechanical and cheap: lockfiles committed, a registry allowlist or proxy, and a build that fails if a package appeared out of nowhere. Ask whether you have it.

Security flaws that look like ordinary code. Missing permission checks, unsafe handling of user input, secrets in the wrong place. Generated code is fluent and well-formatted, which means it triggers less scrutiny than messy code doing the same wrong thing.

Silent failures. Generated code has a habit of catching errors, logging them and continuing. The system stops failing loudly, so you learn about problems from customers rather than from monitoring.

Code nobody can explain. The expensive one. It costs nothing until something breaks at 3am and the person on call is reading it for the first time, under pressure, with no idea why it was built that way.

The perception problem

One research finding is worth knowing because it undermines the most common way this gets evaluated.

METR ran a randomised controlled trial: sixteen experienced developers, 246 real tasks from their own backlogs, randomised as to whether AI tools were allowed. Developers were 19% slower with AI — and estimated afterwards that they had been 20% faster.

That population was unusual — maintainers working in code they knew intimately, roughly the worst case for these tools. The result should not be read as "AI makes everyone slower". But the perception gap is the part that generalises, and it means one thing for you:

AI code quality risk, broken down by severity

Not every risk category above carries the same weight, and treating them as equivalent produces governance that either overreacts to minor issues or underreacts to serious ones. Breaking down AI code quality risk by actual business severity:

Severe — can cause direct financial or legal harm. Dependency supply-chain compromise via slopsquatting; authentication or authorisation bypass; unencrypted handling of regulated personal data. These deserve mandatory, non-negotiable controls — the dependency verification and security review practices covered throughout this piece are not optional hardening for these categories, they are the minimum bar.

Significant — can cause a costly incident but is recoverable. Silent error handling that delays discovery of a production issue; a critical subsystem only one person understands; a change failure rate creeping upward without anyone noticing. These deserve active measurement and a standing response, but not necessarily a hard gate on every change — the two metrics covered below are designed to catch this category before it becomes severe.

Moderate — code quality issues that slow the team but do not directly threaten the business. Verbose or inconsistent style, minor duplication, structure that is not how a human would have organised it. These are real costs, and they are the ones engineering teams tend to focus on because they are the most visible in a code review — but they are also the ones a non-technical founder should worry about least, since they rarely translate into the kind of incident that shows up in a board meeting.

The governance worth building maps directly onto this hierarchy: hard, automated gates for the severe category; measured metrics with an escalation path for the significant category; and normal engineering judgement, not founder-level policy, for the moderate category. Most AI governance conversations spend disproportionate energy on the third category because it is the one engineers naturally discuss, while the first category — the one that can actually hurt the business — gets a single line item nobody revisits.

An AI code review policy that survives contact with a real team

A concrete version of the policy sketch that appears later in this piece, written at the level of detail a CTO or lead engineer could actually implement rather than as a set of principles.

On dependency verification. CI fails the build if any imported package cannot be resolved against a pinned lockfile and a maintained-package check — this is fully automatable and should never depend on a human remembering to look.

On change size. Pull requests above a defined line-count threshold require an explicit justification comment and a second reviewer, rather than being blocked outright — the goal is friction proportional to risk, not a hard ceiling that gets routinely overridden and therefore ignored.

On test-first for anything non-trivial. A failing test, written or explicitly approved by a human, exists before implementation begins on any change touching a critical path — defined as anything touching authentication, payments, or personal data specifically, rather than applied uniformly to every change regardless of stakes.

On review attention. Reviewers are explicitly told, as a matter of team practice, to spend disproportionate time on the parts of a diff that look most routine and least on the parts that look most complex — inverting the natural instinct, because routine-looking sections are where an AI-introduced assumption is most likely to hide unnoticed.

On accountability. Every merged change has a named human approver, regardless of how much of the underlying code was generated — "the AI wrote it" is never an acceptable answer to "who is responsible for this change working correctly."

A policy at this level of specificity is implementable in days, is checkable by an engineering lead without requiring a large governance project, and directly addresses the actual failure modes covered earlier in this piece rather than producing a document that restates good intentions without changing anyone's daily behaviour.

What to ask, and what to watch

Four questions for your engineering lead. None require a technical answer you cannot evaluate:

1. Has review capacity grown as fast as code output? If output tripled and the same two people review everything, that is the finding.
2. Are we shipping bigger changes and approving them faster than a year ago? This is the signature of review becoming a formality.
3. Do we verify dependencies? Lockfiles, allowlist, a check that packages exist and are maintained.
4. Could someone other than the author debug the payment path at 3am? If the honest answer is no for any critical system, that is your priority.

Two metrics to watch, both of which you probably already have:

• Change failure rate — the share of releases that cause a problem. If it is rising, generation has outpaced verification.
• Review time against change size — larger changes approved faster is the clearest early warning available.

A policy worth having

Short, and about standards rather than tools:

• The review bar is identical regardless of who or what wrote the code
• Changes have a size limit, held even when generation makes bigger ones easy
• A human writes or approves the test that defines "done" before implementation
• Dependencies are verified before they enter the build
• A named person is accountable for every merged change

Policies that try to restrict which tools engineers use do not work. They get ignored, and they teach people not to mention what they are doing — which removes your visibility at exactly the moment you need it.

The reasonable position

Use the tools. They genuinely lower the cost of building software, and refusing them puts you at a disadvantage against competitors who do not.

Then fund the other half. If code output rises and review capacity does not, you have not become more productive — you have moved work from before the release to after it, where it is more expensive and your customers find it first.

Where this shows up in diligence and delivery

The dependency-verification and review-standard practices covered here are the same ones a buyer would check for in technical due diligence — a company with clean answers to the four questions above is, not coincidentally, also a company that will score well on a diligence review, because both are measuring the same underlying discipline from different angles.

The other half of this picture is timeline: teams that skip the verification work described here tend to discover the cost later, as rework that extends a project well past its original estimate. Why AI projects run over covers the delivery-side version of the same argument made here from a risk perspective — generation speed without a corresponding investment in verification does not disappear as cost, it relocates to a later, more expensive point in the project.

The version of this that gets approved

Boards and investors do not need a technical briefing on any of the above — they need three sentences: code review standards are unchanged regardless of who wrote the code, dependencies are verified automatically before they reach production, and a named engineer is accountable for every change that ships. That is the entire governance story worth telling outside the engineering team, and it is checkable in a single conversation with whoever leads engineering.

Revisiting this as the tooling changes

The specific numbers in this piece — hallucination rates, the METR result, DORA's findings — will shift as models and tooling improve, and some of what is a live risk today will shrink or disappear. What will not change is the underlying arithmetic: verification capacity has to scale with generation capacity, whatever the current generation of tools makes possible. Revisit the two metrics — change failure rate and review time against change size — on a standing schedule rather than treating this as a one-time policy decision, because the right level of caution for a fast-moving area like this is one that gets recalibrated as the evidence changes, not set once and left alone.

In one sentence

If a board member remembers only one thing from this piece, it should be this: AI-generated code is exactly as safe as the review and verification capacity funded to check it, and that capacity is a resourcing decision within direct control, not a technical property of the tools themselves.

A practical next step

Ask your engineering lead one question this week, however the codebase is currently built: show me the last five pull requests, in order, and tell me how long each took to review relative to its size. That single piece of evidence — not a policy document, not a vendor pitch about AI governance tooling — tells you more about whether review has kept pace with generation than almost anything else you could ask for, and it takes five minutes to produce if the practice is genuinely healthy.

The uncomfortable parallel

There is a useful parallel to an earlier technology transition: the shift from manually written assembly code to compiled higher-level languages did not eliminate the need for engineering discipline — it relocated where that discipline had to be applied, from the mechanics of writing instructions to the mechanics of specifying and verifying behaviour correctly. AI-generated code is a similar relocation, not a removal of the underlying need for rigour. Teams that recognise this early and invest accordingly outperform teams that treat the new tooling as a reason to relax standards that were serving them well.

One more thing worth saying

None of this is an argument for caution over adoption. It is an argument for adoption paired with the same engineering discipline that has always separated reliable software companies from unreliable ones — applied now to a faster-moving input than before.

The teams that get this right

The engineering organisations handling this well are not the ones with the most sophisticated AI governance tooling — they are the ones that never stopped applying ordinary engineering discipline, and simply scaled the resourcing behind it as generation got faster.

Closing thought

The tools will keep changing. The discipline does not have to.

Last word

Fund the review, not just the generation, and this stops being a risk worth losing sleep over.