41% of Your Codebase Was Written by AI. Who's Checking It?

The afternoon session was going well.

Advanced students. The kind of class where you don’t have to explain the basics; you can go straight to the difficult things, the subtle things, the places where mastery and instinct meet. I was in the middle of a point when one of the participants slipped out quietly. No disruption. Just a glance at his phone, a word to the person beside him, and he was gone.

He was the champion of his organization. The most technically advanced person in the room. Also, it turned out, the only one who could fix what had just broken in production.

Severity-1. Live. Customers affected.

After the session, the group went to find him. What we found instead was a bug that no human had written and no test had caught. Someone had been adding a new feature using an AI-assisted tool. The code was immature. It had been inserted into an upstream part of the application, quietly, correctly formatted, passing all automated checks. And then, at some point in a sequence nobody had fully traced, it had failed.

We stood around a screen in the fading winter light. One of the participants asked the question that changed the atmosphere of the room.

“How much of our codebase looks like this?”

Someone opened GitHub. The number came back quickly.

Roughly 30% of their codebase had recently been touched by AI.

The silence that followed was not the silence of panic. It was something colder. Nobody knew whether that 30% was good code or code like the one we were looking at. Nobody knew where to start. In the darkening window, against the last light of a short winter afternoon, what rose was not an immediate problem but the shape of a much larger one; a nightmare not yet fully formed, but unmistakably arriving.

30% was not an outlier

This is the part that is important to understand clearly.

The number that came back on that screen, 30%, felt like a local discovery. A single organization, a specific moment, a particular combination of speed and inattention. What deeper research has shown is something different.

41% of all new code written globally is now AI-generated, according to GitHub’s own adoption data. That figure has been rising steadily since 2023, and the trend is not reversing. In most organizations, the conversation about what percentage of the codebase was written or modified by AI has not yet happened. When it does happen, most teams are surprised by the answer. Not because the number is small.

The champion’s organization was not behind the curve. They were, statistically, slightly ahead of average. The question they could not answer, “is this code safe to trust?“, is the question most organizations cannot answer either.

What the delivery data reveals

Before the security picture, there is a stability picture; and it is also darker than most organizations expect.

DORA’s 2024 research, which tracks software delivery performance across thousands of organizations globally, found that AI adoption correlates with a 7.2% decrease in delivery stability. Teams using AI tools are shipping more. They are also experiencing more incidents.

This is not a paradox if you understand what is happening. AI generates code faster than teams can verify it. The volume grows. The review cycles stay the same length, or shorten under velocity pressure. The gap between what is generated and what is understood by the humans who deploy it widens. Stability decreases not because the AI is unreliable in isolation, but because the governance layer; the human judgment that sits between generation and production, has not kept pace.

METR’s 2025 randomized controlled trial found something that connects directly to this: teams using AI believed they were working 20% faster. Measured, they were working 19% slower. A 39-point gap between perception and reality, in one of the most rigorous studies conducted on the question.

When your team does not know how fast they are actually moving, they also do not know how much unverified code is moving with them.

The security picture

GitClear’s 2024-2025 analysis of AI-assisted code found a 23.7% increase in security vulnerabilities compared to pre-AI baselines. That number would be concerning on its own. It becomes a pattern when read alongside the rest of what GitClear found: a 39.9% drop in refactoring activity and an 8x increase in duplicate code blocks.

What this describes is code that works, passes tests, deploys, and accumulates. Code that is never revisited. Code that copies patterns from elsewhere without understanding why those patterns exist. Code that, at 30% of your codebase, or 41%, represents an invisible layer of technical assumptions that nobody has fully reviewed.

Veracode’s 2025 GenAI Code Security Report tested more than 100 large language models across Java, Python, C#, and JavaScript. The finding: 45% of AI-generated code introduced OWASP Top 10 security vulnerabilities. Not edge-case vulnerabilities in exotic languages. The most common, most impactful, most well-documented categories of security failure in production software.

Java was the highest-risk language, with a failure rate above 70%.

The numbers are consistent across every serious study of the question. CSET Georgetown found approximately 48% of AI-generated code snippets vulnerable under controlled conditions. The methodologies differ; the direction does not.

Nearly half.

Your team is not writing insecure code because they are careless. They are working at the speed the market demanded, with tools that generate plausible code faster than human judgment can evaluate it. The security problem is structural. The 30% you may find when you open your own GitHub is not a failure of your team. It is the consequence of a gap nobody warned you to close.

The regulatory clock

This is where the terrain shifts from uncomfortable to urgent.

Until recently, the security and stability questions were engineering problems. Leadership might be concerned; boards might ask questions. But the consequences were bounded by what the organization could contain.

That changes on August 2, 2026.

The EU AI Act’s full enforcement begins that day. For organizations in Europe, or organizations with European customers or operations, AI-generated code is no longer solely an engineering matter. It is a compliance matter, with penalties reaching €35 million or 7% of global annual turnover, whichever is higher.

The Act does not distinguish between AI that was used to write customer-facing features and AI that was used to write infrastructure code. It requires traceability, documentation, and human oversight of AI outputs in covered applications. If your team cannot answer the question, “who reviewed this AI-generated code before it went to production?“, that is not a quality gap. It is a compliance exposure.

The EU AI Act does not operate alone. It operates alongside a regulatory landscape that has already been building for years:

GDPR requires that personal data processed by AI systems meets specific standards of accountability and data subject rights. AI-generated code that handles personal data, and in most applications it does, falls under this framework. Fines reach 4% of global annual turnover per violation.
NIS2, the EU’s updated Network and Information Security Directive, requires critical infrastructure organizations to manage cybersecurity risk across their software supply chains. AI-generated code that introduces vulnerabilities, particularly the architectural and dependency vulnerabilities growing fastest in AI-assisted development, is now a supply chain security matter, not only a code quality matter.
The EU Data Act establishes accountability for data generated, processed, and shared by AI systems. Organizations deploying AI-assisted development without clear documentation of what those systems produced are accumulating compliance exposure they may not yet have mapped.

Violations do not stack politely. GDPR, NIS2, and the EU AI Act can apply simultaneously to the same incident. The combined exposure in a serious data breach involving AI-generated code can exceed 10% of global annual turnover in penalties alone.

The champion who left the dojo to fix a severity-1 was fixing a technical problem.

The next version of that conversation, five months from now, may involve a legal team.

The four dimensions of the terrain

Here is what the AI Readiness Assessment measures; and why it exists.

After 130+ interviews with the people who built technology organizations that worked, and the people who watched organizations that did not, a pattern emerged. The gap between AI adoption and organizational readiness is not primarily a technology problem. It is not solved by better tools or stricter policies. It shows up, consistently, in four dimensions:

Focus and Cognitive Capacity. Can your team maintain the attention required to supervise AI output? Gloria Mark’s research at UC Irvine found that it takes 23 minutes and 15 seconds to regain full focus after an interruption, and developers are interrupted every 11 minutes. AI writes code faster than your brain can follow it. The volume compounds the attention problem. The vulnerability is not in the AI. It is in the gap between generation speed and human review capacity.
Technical Validation and Engineering Discipline. Can your engineers challenge AI on correctness, security, and predictability? Not accept it, not refuse it; challenge it. This is the dimension most directly implicated in the Veracode 45% finding. When engineers cannot independently evaluate what AI produced, what ships is what was generated.
Product and Backlog Clarity. Is the intent behind each feature clear enough that AI can be given unambiguous specifications? Vague intent produces plausible code. Plausible code that solves the wrong problem creates technical and product debt at AI speed; and that speed is measurable: 2x-4x.
Customer Feedback and Learning Speed. How quickly does real-world evidence correct your direction? When AI-generated code reaches production and begins producing incidents, the correction loop determines how long the exposure persists.

The severity-1 that pulled the champion from the dojo touched all four dimensions. The engineer who deployed it was moving fast, without full review. The test suite caught nothing because the tests had not been written against adversarial assumptions (core principle of nWave.ai). The feature specification had been ambiguous enough that the AI had made its own assumptions. And the feedback loop, the path from production incident to root cause to corrected process, was the emergency response of a team discovering a problem it had not prepared for.

The assessment does not find what is broken. It maps where the organization actually is; so that the path forward is a path, not a guess.

The night before the good dreams

The room where we stood around that screen was dark. The champion was still on a call. The people looking at GitHub were quiet in the way that people are quiet when they understand the size of what they have found.

But here is what is also true: they found it.

They found it before a regulator did. Before a customer data breach generated a headline. Before the board asked the question that nobody could answer. They found it in time to map the terrain, understand their position, and begin moving with intention rather than velocity.

The nightmare rising on the horizon is real. The 41%, the 45%, the 7.2%, the August deadline; none of those numbers are hypothetical. But a nightmare you can see is not the same as a nightmare you are already inside.

The AI Readiness Assessment was built for this moment. Not to tell you that you made the wrong call; you made the call the market required. To tell you exactly where you stand, so that the distance between here and governed, sustainable AI adoption is a map you can walk, not a darkness you are moving through.

The night before good dreams is still night. The difference is knowing that morning is coming, and knowing where you are when it arrives.

The assessment takes 5 minutes. It costs nothing. It maps all four dimensions. If you have not yet looked at your own GitHub number, that is where to start.

→ AI Readiness Assessment

Next week: a CTO who had the SaaS collapse on one side, a board asking questions on the other, and an engineering team moving at AI speed in the middle. What the assessment revealed when he finally looked. And what the last mile looked like when someone had walked it before.

📚 Sources:

GitHub Developer Survey 2024 (41% AI-generated code)
DORA State of DevOps Report 2024 (7.2% delivery stability decrease)
METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025 (19% slower; 20% perceived faster)
GitClear, Coding on Copilot 2025 (23.7% vulnerability increase; 39.9% refactoring drop; 8x duplicate code blocks)
Veracode, 2025 GenAI Code Security Report (45% OWASP Top 10 failures across 100+ LLMs)
CSET Georgetown, Cybersecurity Risks of AI-Generated Code, November 2024 (~48% vulnerability rate)
Gloria Mark, Attention Span, UC Irvine (23 min 15 sec refocus time; 11-minute interruption cycle)
EU AI Act (August 2, 2026 enforcement; €35M / 7% global turnover penalties)
GDPR (4% global turnover penalties per violation)
NIS2 Directive (EU cybersecurity for critical infrastructure)
EU Data Act (AI output accountability)