46% of Your Code Is Now AI-Generated: What That Means for Quality

In files where AI is active, roughly 46% of the code is now AI-generated. That single number captures how quickly software development has changed: close to half of the code being written in those files is produced by a model rather than typed by a person. For most teams, this is not a future scenario, it is already how the work happens day to day.

The productivity gain is real and worth having. But more code, written faster, by a tool that does not understand your business, raises an obvious question: what does this do to quality, and what do you have to keep doing to protect it?

What the 46% actually tells us

It is worth being precise about the figure. In files where AI is active, around 46% of the code is AI-generated. That is not all code everywhere, but in the work AI touches, it is now close to an even split between human and machine. The trend line points one way, and it is steep. Whatever your policy on AI tools, a large and growing share of your codebase is being shaped by them.

The practical takeaway is simple: this is not a debate about whether to allow AI, it is a question of how to manage a reality that is already here. Pretending the number is smaller than it is, or that it applies to someone else's codebase, only means the quality risks go unmanaged while the code keeps shipping.

Where AI-generated code falls short

AI is a remarkable accelerator, and it has real weaknesses. The code it produces can be less secure, reaching for patterns that look right but miss validation, leak secrets, or skip an authorisation check. It can be inconsistent, solving the same problem three different ways across three files because it has no memory of the decisions made elsewhere. And it is confident regardless, which is precisely what makes the gaps so easy to miss.

• Security: plausible code that quietly omits the checks that keep data safe.
• Consistency: the same problem solved differently in different places.
• Context: no real understanding of why your system is built the way it is.
• Confidence: output that looks finished whether or not it is correct.

It is worth being clear that none of these weaknesses make AI a bad tool. They make it an unsupervised junior with an enormous output and no sense of your context. Used with that picture in mind, it is extraordinarily useful. Trusted blindly, it ships exactly the kinds of problems that surface weeks later, at the worst possible moment.

Review still belongs to humans

When code was slow and expensive to write, review was the safety net. Now that code is cheap and fast to produce, review matters more, not less, because there is far more of it and the author cannot vouch for its intent. A human still has to ask the questions a model will not: is this the right approach, does it fit the architecture, what happens at the edges, and is this safe with real users and real data?

Reviewing AI-written code is also a slightly different discipline from reviewing a colleague's. There is no shared context to lean on and no author to ask what they were thinking, so the reviewer has to reconstruct intent from the code alone. That makes clear specifications and small, focused changes more valuable than ever, because they keep review tractable.

Tests are your seatbelt

If AI is going to write a lot of your code, tests are how you keep changes from quietly breaking things. They turn 'it looked fine' into 'it still works', and they let you accept generated code with confidence because you can prove the critical paths behave. There is a pleasing irony here: AI is also very good at helping write those tests, as long as a person decides what actually needs covering.

Good tests also give you the confidence to move fast, which is the whole reason you reached for AI in the first place. When the critical paths are covered, you can accept a large generated change, run the suite, and know within seconds whether anything important broke. Without that safety net, every sizeable change becomes a slow, nervous read-through.

Architecture and observability do not write themselves

Two things AI consistently will not give you for free are a coherent architecture and the ability to see what your software is doing in production. Left alone, generated code tends toward a pile of locally sensible decisions that never add up to a maintainable whole, so someone has to hold the overall shape. And observability, logging, monitoring and alerting, has to be designed in deliberately, so that when something breaks you find out before your customers do.

Both of these are far easier to build in early than to retrofit later. A coherent structure decided at the start saves you from untangling a sprawl of generated code down the line, and observability added before launch means your first production incident is something you can see, not something you have to guess at while customers wait.

The discipline that keeps quality high

None of this is an argument against AI-generated code. It is an argument for the engineering discipline that lets you use it safely: clear standards, real review, solid tests, a coherent architecture, and observability built in from the start. Use AI to go fast, and keep the senior judgement that decides what is actually good enough to ship.

In practice, this discipline does not slow good teams down; it is what lets them speed up safely. The guardrails are what make it sensible to accept more generated code, not less, because you can trust the system to catch what the model misses. Speed and safety stop being a trade-off and start reinforcing each other.

As more of your codebase becomes AI-generated, the value of senior engineering does not fall, it rises, because someone has to be the final reviewer that AI cannot be. Making fast, AI-assisted code genuinely safe to ship is one of the most common things teams ask us to help with.