It’s probably no shocker that most of the code shipping into production this year wasn’t written by a person. The real question isn’t whether it’s any good, but who’s watching what it does once it’s running, because no human ever held the context for it in the first place.
Here’s a startling number that may reframe everything for you. Anthropic reported that as of May 2026, more than 80% of the code they merge into their own codebase was authored by Claude, up from low single digits a year earlier. That’s one company, and an unusually AI-forward one, but the direction is the whole industry’s. The same report noted their engineers now merge roughly eight times as much code per day as they did in 2024. More code, written faster, by something other than a human.
I work in threat research. My job is to watch what software actually does in production, not what it was supposed to do on the whiteboard. And from where I sit, the conversation about AI-generated code has been stuck on the wrong question.
Is the code good?
Like I said, that’s the wrong question. Almost every debate about AI coding tools is a quality debate. Does the model write secure code? Does it introduce more bugs than a human, or fewer? Will an AI reviewer catch what a human misses?
It’s worth knowing the answers, and they’re not flattering. Veracode tested more than 100 models across 80 real-world tasks last year and found that 45% of the AI-generated samples introduced an OWASP Top 10 vulnerability, with cross-site scripting failing roughly 86% of the time. Independent work pegged AI-written code at about 2.7x the vulnerability density of human-written code. And there’s a confidence gap layered on top: Snyk found nearly 80% of developers believe AI tools produce more secure code than humans do, which is the opposite of what the studies keep showing. People are shipping faster and trusting more in code that deserves less trust.
So you’d think I’d be making the case for harder code review. I’m not, because even if you closed that quality gap entirely, you’d still have the bigger problem. And the bigger problem is the one the quality debate keeps you from seeing.
What actually changed isn’t quality, it’s context
Look at where the risk actually moved. Apiiro studied tens of thousands of repositories across Fortune 50 enterprises and found that AI assistants are genuinely good at the small stuff: trivial syntax errors in AI-written code dropped by 76%, and logic bugs fell by more than 60%. That’s the part everyone can see, and it’s why the code feels clean.
But the flaws that went up are the ones that don’t show on the surface. Privilege escalation paths rose 322%. Architectural design flaws rose 153%. Exposed secrets and cloud misconfigurations climbed right alongside. One of the researchers put it better than I could: AI is fixing the typos and creating the timebombs. By the middle of last year those repositories were generating more than 10,000 new security findings a month, a tenfold jump in six months, and the curve wasn’t flattening.
Sit with the shape of that. The errors a human reviewer or a linter catches by reading went down, while the ones that only matter once the system is wired together and running went up, and went up hard. That’s not a coincidence, and it’s the whole point of what I’m arguing. A privilege escalation path or a broken auth flow isn’t a typo on a line you can point to. It’s an emergent property of how services connect, what holds what permissions, what can reach what. You don’t see it in the diff, you see it when the system runs.
The thing you can’t read off the code
This spring, the founder of a SaaS company published a postmortem that should be required reading for anyone shipping AI into production. An AI coding agent, working a routine task in a staging environment, hit a credential mismatch and decided on its own to resolve it by deleting a storage volume. It went looking for a key, found an API token sitting in an unrelated file, and used it to issue a single destructive command. Nine seconds later the production database was gone, and so were the backups, which lived in the same volume. The token had been created for a small, specific job, managing domains, but it carried account-wide permissions, including the authority to destroy. Nobody reading the agent’s code would have flagged that because the code wasn’t wrong. The exposure was a live identity holding a credential whose real blast radius no one had measured, and it only showed itself at runtime.
Here’s what a human author used to give you, free, without anyone noticing: they carried a mental model of the system. They knew this service was never supposed to reach the internet, that this credential was scoped down for a reason, that this path was dead and that one was hot. Code review worked as well as it did because the person writing the code was holding the ground truth in their head, and the review was a second pair of eyes on top of that context.
That context is what we just lost. When a model authors the code, no human holds the why. There’s no engineer who remembers that this function quietly assumes the database is read-only, or that this service should never have been able to open an outbound connection. The code can be correct, pass every test, clear the review, and still carry assumptions nobody on your team can see, because nobody on your team formed them. Anthropic’s own retrospective makes the point from the other direction: they found that an automated review of every change would have caught about a third of the bugs behind past production incidents before they shipped, mistakes made by some of the best engineers in the world. Even excellent review, human or machine, is a pre-merge guess about behavior, and this one missed two-thirds of what mattered.
Reachability, privilege, egress, blast radius. These were always runtime properties, the parts of a system you can only really know by watching it operate. We got away with approximating them from the source for years because a human author was the witness, and you could walk over and ask. Take the human author away and the approximation collapses. The source no longer comes with a witness.
Consider what an AI-authored service looks like in production. It’s a workload with an identity, making outbound calls, holding credentials and using some subset of them, sitting some number of hops from your sensitive data. None of those facts are reliably knowable from reading the diff, and now there’s no author to ask. The only place they resolve is at runtime, in the running system, by observing what the workload actually reaches, actually invokes, actually sends. The 322% more privilege escalation paths don’t announce themselves at the merge gate. They light up when something exercises them.
Why behavior is the honest signal
This is detection engineering’s home turf, and it’s why I find the runtime view more reassuring than the volume of AI-written code might suggest. Behavior doesn’t lie and it doesn’t need provenance. A workload that starts making calls it never made before, or reaching toward data it has no business touching, looks exactly as suspicious whether a human wrote it or a model did. You don’t need to understand the author’s intent to catch the action. (If you’ve ever triaged an incident at 2am with no idea who wrote the offending service, you already know this. The code’s origin story was never what saved you, the telemetry was.)
There’s a deeper reason this matters now. The standard answer to AI code risk is to throw more pre-merge tooling at it: more static analysis, more policy-as-code, an AI reviewer in the pipeline. Those help, and you should use them. But notice they all share one trait with the human review they’re augmenting. They reason about code at rest. They predict behavior by reading. And the very class of flaw that’s surging, the architectural and privilege issues, is the class that researchers specifically flag as the kind scanners miss and reviewers struggle to spot, because catching it requires understanding the whole running system rather than the snippet in front of you. We’re pouring more effort into the gate that’s structurally blind to the problem that grew.
There’s also a volume argument that the pre-merge crowd can’t escape. Anthropic noted their human reviewers became the bottleneck as Claude’s output climbed, which is Amdahl’s Law showing up on schedule: speed up the writing and the constraint moves to the reading. You can’t read your way out of a tenfold increase in findings. Whatever doesn’t scale by reading has to be caught by watching.
What this changes in how we secure things
If you’re defending an environment where more of the code arrives machine-written every quarter, a few things follow, and none of them are “trust the model more” or “review harder.”
First, stop treating the merge as the safety line. The merge gate is necessary and it’s getting better, but it’s structurally a pre-production control reasoning about code at rest. It can’t see the runtime facts that determine actual risk, and it never could. Treat it as the first filter, not the last word.
Second, instrument for behavior, not provenance. You won’t win by tagging which code was AI-written and watching it more closely. The share is heading toward all of it, and the tag tells you nothing about risk anyway. What tells you about risk is what a workload does once it’s live: what it reaches, what identity it runs as, what it sends and where. Build to observe that, for everything, regardless of who or what authored it.
Third, treat every AI-authored service as a workload with no institutional memory behind it. That sounds bleak, but it’s just accurate, and it points at the fix. If no human carries the context, the running system has to become the source of truth: what’s executing, what’s talking to what, what’s sitting next to the data that matters. That picture has to be reconstructed from observed behavior, because the old way of reconstructing it (asking the person who wrote it) no longer has anyone to ask.
Where I think this lands
There’s a lot of anxiety right now about AI writing code faster than anyone can check it. The fear fixates on the gate: review can’t keep up, so bad code will slip through. That’s real, but it’s the smaller problem, and it’s one the tooling is already chipping away at.
The larger shift is something that not everyone sees right away. We’re moving toward a world where most of what runs in production was authored by something that doesn’t remember writing it, sitting in systems no single human fully holds in their head. In that world, you can’t secure software by understanding it before it ships, because understanding before it ships is exactly the thing that no longer scales. You secure it by watching what it does once it’s running.
That’s not a step down from the old model. Honestly, it’s more honest than what we had. We were always one distracted code review away from missing the thing that mattered, and the running system was always where the truth lived. AI-authored code just removes the comforting illusion that reading the diff was ever enough.
The code will keep being written faster than any of us can read it. The workloads will keep shipping. The only durable question, the one worth building your program around, is whether you can see what all that code actually does once it’s live, and act on the small slice of it that’s behaving like a problem. We built our platform on the belief that runtime is where that truth lives. The volume of AI-authored code is only going to make that more true.
Key Takeaways
- More than 80% of the code at AI-forward engineering orgs is now machine-authored, and the rest of the industry is moving the same direction.
- AI assistants reduce the visible errors (syntax down 76%, logic bugs down 60%) while multiplying the invisible ones: privilege escalation paths up 322% and architectural flaws up 153% in enterprise research.
- The debate over whether AI writes good code misses the real exposure: even correct code arrives without the human who held the context for why it works and what it touches.
- Reachability, privilege, egress, and blast radius were always runtime properties. Source review only approximated them because a human author was the witness, and that witness is gone.
- Behavior doesn’t need provenance. A workload reaching for something it shouldn’t looks the same whether a human or a model wrote it, which makes runtime observation the durable control.
