What a 70%-AI-generated codebase actually looks like

Last updated: July 2026

The industry data on AI-generated code is inconsistent because everyone measures it differently. Sonar's 2026 developer survey puts the share of AI-generated code across all committed code at close to 50% early this year. Larridin's engineering benchmarks put the "sweet spot for mature teams" at 25-40%. GitHub Copilot's own telemetry puts the accepted-suggestion rate at about 30%. Twistag runs closer to 70% AI-generated on greenfield engagements — a number worth being specific about, because at that percentage the review layers, the PR shape, the test discipline, and the definition of a senior engineer's job all change. This post is what changes. It is the pillar of our cluster on AI-native product engineering (F).

Key takeaways

• 70% AI-generated is a delivery outcome, not a target. The number falls out of a specific review discipline. Missing the discipline and pushing the AI harder produces slop faster; missing the discipline and pushing it less loses the productivity.
• The review layer count doubles. Classical review is one layer (senior engineer reads the PR). AI-native review is four layers (AI author agent → AI reviewer agents → senior engineer → integration tests as executable spec). Each layer catches a different failure mode.
• The PR shape shrinks and the PR count grows. A 70%-AI-generated feature ships in five or six small PRs, not one large one. Each PR is small enough for a reviewer agent and a human to fully understand. This is the biggest visible change in the codebase.
• Tests are written first, more often than not. Not classical TDD. The pattern is: senior engineer writes the spec and the test cases; AI writes the implementation; the tests are the acceptance signal. Test coverage on AI-authored code is systematically higher than on human-authored code from the same team.
• The senior engineer's job becomes editorial. Less typing, more judgement about what to accept, what to reject, what to redesign. This is a bigger shift in the role than most engineering leaders have priced in.

The percentage question — what "70%" actually means

Any measurement of AI-generated code is contested because there are at least four things you could count. The pattern in 2026 that produces the least ambiguous number:

• The unit of measurement is lines of code in merged PRs (not suggestions, not accepted suggestions, not "AI-assisted" self-reports).
• The classification is whether the line was originally authored by an AI tool or a human — including lines the human later edited. If the human touched a line the AI wrote, it still counts as AI-originated.
• The scope is a specific service or repository over a specific time window (a sprint, a month, a release). Aggregating across the whole engineering org washes out the interesting variation.

By that definition, our greenfield engagements in 2026 sit around 70%. Brownfield engagements sit closer to 40-50%, because integration and migration work has more one-off human logic. The Sonar and Larridin numbers are believable industry averages — 25-40% for mature teams. The gap between 40% and 70% is not tool selection; the tools are converging. The gap is the review and integration discipline.

The four review layers

At 70% AI-generated, the classical single-reviewer PR model breaks. The bugs it lets through are different from human-authored bugs — subtle logic errors on paths that look plausible, off-by-one issues on boundary conditions, incorrect assumptions about the shape of upstream data. The review response is four layers.

Layer 1 — the author agent's self-check. The AI that wrote the code is prompted to review its own output before it opens the PR. It runs the tests, reads its own diff, catches trivial issues (missing imports, obvious type mismatches, unreachable branches). This layer removes noise from what reaches the reviewer.

Layer 2 — reviewer agents. Anthropic's Claude Code Review multi-agent system, launched in March 2026, is the reference implementation. When a PR opens, a fleet of specialised agents examines the diff — one for logic errors, one for boundary conditions, one for API misuse, one for security issues, one for project-convention compliance. A verification step tries to disprove each finding before it gets posted. The surviving findings become inline PR comments.

Layer 3 — the senior engineer. A human reads the diff, reads the reviewer agents' comments, decides what to accept and what to override. This is the editorial layer, and it is where most of the seniority now sits. The senior engineer is not typing the code; they are judging the code.

Layer 4 — integration tests as executable spec. The tests that were written first (see below) are the final gate. If they pass, the change ships. If they fail, the AI is prompted to fix — often successfully in one iteration, sometimes escalating back to layer 3 for a design change.

Skipping any of the four layers is where the failures happen. Skip layer 1 and the reviewer agents drown in noise. Skip layer 2 and the human reviewer misses the subtle logic errors. Skip layer 3 and the codebase drifts from the team's convention. Skip layer 4 and edge cases ship broken.

The PR shape change

The single biggest visible difference in an AI-native codebase is the size and count of pull requests. Classical shape: one PR per feature, 400-1500 lines, one reviewer. AI-native shape: five or six PRs per feature, 80-200 lines each, layered review on every one.

The reason is the review economics. A human reviewer at layer 3 can hold about 200 lines of a diff in their head with real understanding. Above that, they start reviewing the shape and skimming the content — which is exactly where subtle AI-authored bugs slip through. A reviewer agent at layer 2 is equivalent — its per-PR accuracy drops on large diffs. Small PRs keep both reviewers at peak performance.

The count change matters for engineering leadership because velocity metrics that count PRs shipped or merged look inflated at first glance. They are not inflated; the unit got smaller. Merged-lines-per-week or merged-features-per-week are the metrics that stay comparable across the AI-native shift.

Tests first — but not classical TDD

Classical TDD is: write the test, watch it fail, write the implementation, watch it pass. It is a discipline for humans working alone. AI-native testing looks different:

The senior engineer writes the acceptance criteria first. In plain English, or in a spec document, or as the top of the AI's context window. This is the design step — deciding what "done" means.

The AI writes the tests before the implementation. Given the acceptance criteria, the AI generates unit tests, integration tests, and edge cases. The human reviews the tests. This step is where design errors get caught — if the tests are wrong, the implementation will be wrong.

The AI writes the implementation. Iterates until the tests pass. If it cannot make them pass, it escalates to the human — which usually means the tests captured a constraint the implementation cannot satisfy without a design change.

The tests become the merge signal. Layer 4 of the review. Green tests means the change ships. Red tests block.

The result is test coverage that is systematically higher than a human-authored codebase from the same team. Not because humans are lazy — because AIs are relentless. The AI does not skip a test case because it is boring; it writes them all.

The seniority shift

The role change is the biggest thing to plan for. In a classical codebase, the senior engineer's day is a mix of typing (implementation), thinking (design), and reviewing (peers). The typing is the fungible part; the thinking and reviewing are where the seniority lives.

At 70% AI-generated, the typing collapses. The senior engineer no longer implements most of what they design; the AI does. What is left is thinking and reviewing — the parts that were always the highest-value anyway, but were mixed into a day that also included a lot of typing.

The specific skill shifts:

Judgement about what to accept. Every AI-generated diff is a proposal. The senior engineer's job is to accept it, edit it, reject it, or redesign what was asked for. This is editorial work — closer to a book editor's day than a typing engineer's day.

Framing the problem for the AI. The AI is only as good as the specification it receives. Writing acceptance criteria that are unambiguous, complete, and testable is the new craft skill. It looks like technical writing; it feels like design.

Recognising the failure modes. The subtle AI failure modes — plausible-looking wrong code, off-by-one on boundaries, wrong assumptions about upstream shape — are trainable. Senior engineers who have spent six months in an AI-native codebase spot them fast. Junior engineers still miss them. This is why the senior review burden went up 20-35% in 2026 as junior engineers leaned harder on AI.

The engineering managers who priced this shift correctly staffed differently. They kept the senior count, cut the mid-level count, and stopped hiring juniors into typing roles — because there are no typing roles left.

What does not change

Three things stay classical even at 70% AI-generated:

Architecture. The AI is bad at greenfield architecture. It follows the shape it is given and iterates locally. The senior engineer still designs the service boundaries, the data model, the interface between the new work and the rest of the system. This is where the design decisions get made.

Security-critical code paths. Authentication, authorisation, cryptographic operations, PII handling. AI assistance is used here — it is faster to generate the code — but the review discipline tightens further. Two humans review every security-critical PR, and the reviewer agent set expands to include a dedicated security agent.

Domain knowledge. The AI does not know the enterprise's business rules. Encoding those rules — into acceptance criteria, into tests, into the code — is human work. The AI helps type it up, but the senior engineer holds the model of what the business actually needs.

At 70% AI-generated, most of the codebase looks and reads familiar. The change is not in the code's style. It is in who wrote it, how it got reviewed, and what the senior engineer was doing while it happened.

What this shifts for the enterprise

The enterprise that hires an engineering partner in 2026 is buying delivery velocity that depends on this discipline being real. Ask three questions in the qualification:

• What percentage of the partner's delivered code is AI-authored, by their own definition of the measurement? The answer should be specific. "A lot" is not an answer. Vagueness is a signal that the discipline is not in place.
• What are their review layers? Four layers is the current best-practice shape. Two is what most agencies still do. The number correlates with defect rates in production.
• How do they staff? Senior-heavy is the AI-native shape. Junior-heavy is the traditional shape. Both work at different price points, but they produce different codebases.

The 70% figure is a delivery outcome of a review discipline. Any partner claiming the number without being able to explain the discipline is claiming a productivity gain they cannot systematically produce.