# The Impact of AI on Code Quality, 2026

> AI is helping developers ship more code, but it is also accelerating complexity that compounds fast. Left unchecked, that complexity will build up silently, in code that is becoming slower and riskier to change.

Kerno, October 2026. Web version: https://kerno.io/the-impact-of-ai-on-code-quality-2026/ · PDF: https://kerno.io/reports/the-impact-of-ai-on-code-quality-2026.pdf

## Key takeaways

- **New code is denser.** Since AI adoption, every 100 new lines carry 8.1 decision points (`if` statements, loops and similar), up from 5.2. That is 50% more paths to understand and test.
- **Each engineer ships 71% more code.** In the median codebase, each engineer now writes 424 production lines a week, up from 293. The 71% is the median of each codebase's own change; the change between those two medians is 45%. Team size hasn't changed in any consistent way.
- **Less code is thrown away, but AI commits are revisited more.** The share of new code rewritten within 90 days fell from 18% to 12%. AI-marked commits are revisited 43% more often than other commits and are 17% more likely to add a hard-to-test function.
- **More testing hasn't reduced bug fixes.** Test commits rose from 4.7% to 8.3% of all commits, but bug fixes still make up a quarter. One possible reason, which the data can't confirm, is that testing has kept up with the volume of code and fallen behind its complexity.
- **Complexity was flat until 2025, then rose.** It held near 5 decision points per 100 lines from 2022 through 2024 and reached about 10 by October 2026. Codebases where AI use isn't marked also rose, but codebases that adopted AI rose faster.
- **Claude-marked commits are bigger.** Claude signs 69% of AI-marked commits, largely because Claude Code marks commits by default and most other tools don't. In the same codebases, Claude's commits are 54% larger than unmarked ones and are revisited 55% more often.
- **Complexity keeps rising.** On the current trend, new code will carry 42% more decision points by late 2028, rising from 9.0 to 12.8 per 100 lines. If growth keeps compounding at 3.5% a month, the increase would be 128%, to 20 per 100 lines. Every extra branch is another path to reason through, test and maintain.

**What this means for engineering leaders.** Each engineer now owns more code, and that code is denser. The cost is building up in code that is slower and riskier to change. We expect delivery metrics such as DORA to be the last to show it.

## Introduction

### Since AI arrived, new code carries more complexity, and it's compounding faster

This is the first edition of The Impact of AI on Code Quality, Kerno's study of how AI is changing the code teams ship. In under two years, AI coding assistants and agents have gone from experiment to the default way much software is written. To see what this means for the codebases themselves, we analyzed 201,576 commits across 46 open-source projects between October 2024 and October 2026, and traced complexity back to October 2022.

New code got denser, and its complexity grows faster each month.

- **8.1** Decision points per 100 new lines, up from 5.2. About 50% more paths to understand and test, in pull requests that are already larger than before.
- **−0.4%** Monthly change in complexity from 2022 to 2024, when it was flat and even eased slightly.
- **+3.1%** Monthly growth in the complexity of new code since January 2025, or about 44% a year.
- **+14%** Excess complexity across whole codebases after AI adoption. The build-up is slower, but still real.

Most teams won't see this, because the industry measures delivery, not structure. DORA metrics track how fast teams ship, not how each change reshapes the codebase. That gap was manageable when engineers understood all the code they shipped. With agents writing more of it, we expect the problem to stay hidden until it shows up as incidents and stalled features.

**None of this is inevitable.** That is Kerno's view, which this data doesn't test. Teams that invest in agent-native Local Code QA can keep complexity in check by moving quality checks into the agent loop. That means running static analysis (SAST), runtime analysis and verbosity checks locally while code is generated, rather than after a pull request is opened, when the feedback loop is already strained.

> The fundamentals of code quality haven't changed. What has to change is where and when teams apply them.

## Finding 1. Since AI adoption, new code carries 50% more decision points per 100 lines, and complexity growth has gone from −0.4% to +3.1% a month

A decision point is any place where code can take one of two paths, such as an `if`, a loop or a `case` in a `switch` (McCabe, 1976). Each one is another path an engineer has to understand and a test has to cover.

The rise is recent. From October 2022 to December 2024, complexity held steady at about 5 decision points per 100 new lines. From January 2025 it began to climb, slowly at first and then sharply in 2026, reaching 10.3 in October 2026 (Exhibit 1). The median across all codebases grew about 3.5% a month. The typical codebase's own growth was 3.1%, the figure in this section's heading (Appendix C).

**Complexity held near 5 for two years, then climbed to about 10.** Decision points per 100 new lines, median codebase each month, October 2022 to October 2026.

| Month | Median | Middle half of codebases | Codebases |
| --- | --- | --- | --- |
| 2022-10 | 5.7 | 4.46 to 7.4 | 29 |
| 2022-11 | 5.57 | 2.4 to 6.52 | 31 |
| 2022-12 | 4.38 | 2.82 to 6.39 | 36 |
| 2023-01 | 5.19 | 3.76 to 7.12 | 35 |
| 2023-02 | 3.96 | 2.62 to 5.96 | 39 |
| 2023-03 | 4.9 | 3.48 to 6.43 | 35 |
| 2023-04 | 5.3 | 3.45 to 7.15 | 41 |
| 2023-05 | 4.86 | 3.62 to 7.62 | 35 |
| 2023-06 | 4.44 | 3.16 to 6.88 | 39 |
| 2023-07 | 4.52 | 3.01 to 5.81 | 38 |
| 2023-08 | 5.85 | 4 to 7.32 | 38 |
| 2023-09 | 4.72 | 3.46 to 6 | 37 |
| 2023-10 | 4.73 | 2.65 to 6.58 | 39 |
| 2023-11 | 4.12 | 3.37 to 6.63 | 37 |
| 2023-12 | 4.53 | 2.92 to 6.86 | 39 |
| 2024-01 | 5.21 | 3.14 to 6.08 | 36 |
| 2024-02 | 4.34 | 3.46 to 5.83 | 37 |
| 2024-03 | 4.29 | 2.33 to 6.38 | 38 |
| 2024-04 | 5.11 | 3.52 to 6.99 | 38 |
| 2024-05 | 3.98 | 1.59 to 5.34 | 40 |
| 2024-06 | 4.63 | 3.19 to 7.88 | 39 |
| 2024-07 | 5.22 | 3.23 to 7.16 | 39 |
| 2024-08 | 5.3 | 3.62 to 6.27 | 35 |
| 2024-09 | 4.88 | 3.58 to 7.47 | 37 |
| 2024-10 | 5.76 | 3.32 to 6.98 | 38 |
| 2024-11 | 4.64 | 3.52 to 6.51 | 36 |
| 2024-12 | 5.03 | 2.6 to 6.93 | 30 |
| 2025-01 | 4.51 | 2.82 to 5.77 | 36 |
| 2025-02 | 4.9 | 3.03 to 6.68 | 38 |
| 2025-03 | 5.81 | 3.86 to 6.34 | 36 |
| 2025-04 | 4.8 | 3.49 to 7.32 | 37 |
| 2025-05 | 5.51 | 3.95 to 6.61 | 36 |
| 2025-06 | 5.58 | 3.5 to 7.23 | 36 |
| 2025-07 | 5.65 | 4.05 to 7.18 | 39 |
| 2025-08 | 5.4 | 3.92 to 6.96 | 35 |
| 2025-09 | 5.98 | 3.76 to 8.82 | 36 |
| 2025-10 | 5.73 | 4.27 to 8.39 | 37 |
| 2025-11 | 5.92 | 4.95 to 7.38 | 36 |
| 2025-12 | 5.93 | 4.12 to 7 | 36 |
| 2026-01 | 6.34 | 4.7 to 8.43 | 37 |
| 2026-02 | 6.42 | 4.02 to 8.85 | 36 |
| 2026-03 | 7.95 | 4.97 to 9.31 | 36 |
| 2026-04 | 7.91 | 6.46 to 9.33 | 35 |
| 2026-05 | 8.42 | 6.43 to 9.41 | 35 |
| 2026-06 | 8.12 | 5.66 to 10.52 | 38 |
| 2026-07 | 7.43 | 5.72 to 9.83 | 38 |
| 2026-08 | 9.17 | 5.86 to 9.8 | 38 |
| 2026-09 | 9.85 | 7.22 to 10.97 | 39 |
| 2026-10 | 10.31 | 7.26 to 12.42 | 36 |

About 4.8 in a typical 2023–24 month.

_Source: Kerno Codebase Analysis, four-year re-run of all 46 codebases, October 2022 to October 2026; 29 to 41 codebases a month; a fixed set of 24 codebases shows the same rise (Appendix C); months with fewer than 1,000 production lines left out._

The rise is just as clear when we measure it around each codebase's own adoption date. Before adoption, the typical codebase added 5.2 decision points per 100 new lines. After adoption, it added 8.1. The rise appeared in 27 of 30 codebases.

It also shows up in the functions that are hardest to work with, those with more than 10 decision points, where testing every path becomes impractical (Exhibit 2).

**25 of 30 codebases now add more hard-to-test functions per 1,000 new lines.** Functions with more than 10 decision points added per 1,000 new production lines, before vs after AI adoption.

| Codebase | Before | After |
| --- | --- | --- |
| activepieces | 1.22 | 1.13 |
| actual | 0.65 | 1.44 |
| appsmith | 0.52 | 1.72 |
| cal.com | 0.61 | 0.77 |
| directus | 1.24 | 2.2 |
| django-cms | 1.37 | 1.71 |
| flagsmith | 0.34 | 0.59 |
| formbricks | 0.79 | 1.14 |
| grafana | 0.69 | 0.93 |
| hoppscotch | 0.9 | 2.03 |
| infisical | 1.13 | 1.09 |
| keep | 1.05 | 1.89 |
| lightdash | 0.9 | 1.43 |
| mattermost | 0.94 | 1.18 |
| n8n | 0.78 | 1.4 |
| nango | 1.52 | 1.51 |
| novu | 0.56 | 1.01 |
| outline | 0.84 | 1.14 |
| payload | 1.41 | 1.64 |
| plane | 0.39 | 0.93 |
| prefect | 0.58 | 1.33 |
| rallly | 0.17 | 0.7 |
| redash | 0.73 | 0.54 |
| sentry | 1.13 | 1.57 |
| strapi | 1.52 | 1.11 |
| twenty | 0.58 | 0.65 |
| typebot.io | 0.83 | 1.61 |
| unleash | 0.45 | 0.5 |
| vendure | 1.1 | 1.27 |
| zulip | 1.26 | 1.4 |
| Median codebase | 0.83 | 1.22 |

_Source: Kerno Codebase Analysis, 30 codebases with an AI adoption date; bots excluded._

> **Why we count per 100 lines.** Counting per line stops a large change from looking complex simply because it is large. The unit doesn't affect the result, since a 50% rise is 50% whether it is measured per 100 lines or per 1,000. We use 100 because a typical commit adds about 40 lines, so 100 lines is roughly one small pull request, and the numbers stay readable (5 to 8 rather than 52 to 81).

This hard-to-change code is also building up across each codebase as a whole. We graded every codebase from A to D by its excess complexity, meaning the decision points its overly complex functions carry beyond 10, per 1,000 lines. We split the 39 codebases into quarters by this score at the start of the period, with A the lowest and D the highest, then graded them again at the end using the same cut-offs (Exhibit 3).

**The number of codebases with the lowest maintainability grade doubled, from 10 to 20 of 39.** Each codebase's grade, from excess complexity per 1,000 lines, in October 2024 and October 2026.

| When | A | B | C | D |
| --- | --- | --- | --- | --- |
| October 2024 | 10 | 10 | 9 | 10 |
| October 2026 | 2 | 9 | 8 | 20 |

21 of 39 codebases dropped one or more grades, 3 moved up and 15 held.

Grades are quarters of this benchmark at the start (cut-offs 4.1, 7.2, 9.6), not an industry scale.

_Source: Kerno Codebase Analysis, 39 codebases with a complexity trend._

## Finding 2. Complexity began rising in 2025 across the board, including in unmarked codebases, but it rose faster where AI use is marked

We looked for a trend that appears only after AI adoption and didn't find one. Rising complexity, more code and more testing all appear in codebases where AI use isn't marked (unmarked codebases, from here on). These codebases have few AI-marked commits, but 9 of the 10 in Exhibit 4 have some (12 to 54 each), so AI is present in them. How much AI use goes unmarked can't be measured. This means they are not an AI-free comparison group. Their rise doesn't count against an AI effect, but it can't confirm one either. In codebases that did adopt AI, all three trends ran faster after adoption (Exhibit 4).

**The same trends appear in unmarked codebases, and run faster where AI use is marked.** Median growth per month.

| Metric | AI use not marked | AI codebases, before adoption | AI codebases, after |
| --- | --- | --- | --- |
| Complexity per 100 new lines | +1.9% a month | +0.7% a month | +3.5% a month |
| Production lines committed | +5.0% a month | +0.5% a month | +5.5% a month |
| Share of commits changing tests | +3.3% a month | +2.5% a month | +4.8% a month |

AI use not marked means 8 to 10 of the 16 codebases without an adoption date, with almost no AI-marked commits. The other 6 have too few active months to fit a trend. AI codebases are the 25 to 26 with enough months on each side of adoption.

_Source: Kerno Codebase Analysis, 46 codebases; growth rates from a trend line fitted to each codebase's monthly values._

The rise follows the calendar rather than each codebase's adoption date. If adoption caused it, the gap would peak at each codebase's own adoption date and fade at other dates. Instead, it appears at all 20 dates we tested (Exhibit 5). That fits an industry-wide shift starting in 2025, including AI use that isn't marked in commits. Within the same codebases after adoption, AI-marked code wasn't clearly more complex per line than other code. AI-marked commits were, however, more likely to add a hard-to-test function, because they were bigger (Exhibit 8).

**Wherever the split date falls, more codebases become more complex than less complex.** Codebases whose complexity per 100 new lines rose or fell when the same split date is applied to every codebase.

| Split date | More complex after | Less complex after |
| --- | --- | --- |
| 2024-12 | 1 | 0 |
| 2025-01 | 4 | 1 |
| 2025-02 | 5 | 1 |
| 2025-03 | 8 | 3 |
| 2025-04 | 9 | 3 |
| 2025-05 | 10 | 3 |
| 2025-06 | 12 | 2 |
| 2025-07 | 18 | 2 |
| 2025-08 | 20 | 4 |
| 2025-09 | 24 | 4 |
| 2025-10 | 27 | 3 |
| 2025-11 | 32 | 4 |
| 2025-12 | 33 | 1 |
| 2026-01 | 35 | 2 |
| 2026-02 | 35 | 0 |
| 2026-03 | 34 | 0 |
| 2026-04 | 32 | 1 |
| 2026-05 | 31 | 1 |
| 2026-06 | 31 | 1 |
| 2026-07 | 30 | 1 |

_Source: Kerno Codebase Analysis, adoption-date sweep across all codebases with enough history, December 2024 to July 2026._

> **What this rules out, and what it doesn't.** Through 2024, complexity held near 5 everywhere (Exhibit 1). From 2025, it rose almost everywhere. Codebases with few AI-marked commits rose too, by 1.9% a month, but 9 of the 10 show some AI use, so they can't tell us what codebases without AI would have done. In codebases that adopted AI, complexity climbed faster after adoption (Exhibit 4), but the data can't say how much of that is due to AI. In short, complexity rose as AI went mainstream, but this data can't prove that AI caused the rise.

## Finding 3. After AI adoption, each engineer ships 71% more production code a week, with no clear change in team size

The extra code isn't just churn. Counting only lines still in place 90 days later, output per engineer rose 75%. Commits also got bigger, and very large commits became more common. Over the two years, the typical codebase grew 40%, from 230,000 to 350,000 lines of production code (Exhibit 6).

More code per person means more code for each reviewer to read and for each engineer to own.

**Each engineer ships 71% more code a week, while team size hasn't clearly changed.** Median change per codebase, after vs before AI adoption, 30 codebases, with 95% confidence range.

| Measure | Median change | 95% range | Detail | Clear? |
| --- | --- | --- | --- | --- |
| Production lines per engineer-week | +71% | +26% to +116% | 293 → 424 | Yes |
| Lines still in place after 90 days | +75% | +33% to +130% | 251 → 369 | Yes |
| Lines per commit | +63% | +40% to +98% |  | Yes |
| Share of commits over 500 lines | +34% | +8% to +79% | 6.5% → 8.9% | Yes |
| Active contributors per week | +10% | -19% to +28% | 8.2 → 9.6 | No |

Percentages are the median of each codebase's own change. Measured between the two medians shown, lines per engineer-week rose 45% (293 to 424) and lines still in place after 90 days rose 47% (251 to 369). The 90-day figure includes recent commits that had less time to be rewritten (Appendix C).

_Source: Kerno Codebase Analysis, 30 codebases with an AI adoption date; bots excluded._

## Finding 4. Less new code is rewritten after AI adoption, but AI-marked commits are revisited 43% more often than other commits

This section uses two measures, and neither is a bug count.

- **Rework** is new code that is rewritten or deleted within 90 days.
- **A follow-up** is any later commit that touches the same code. A follow-up can be a repair (it fixes the earlier change), an extension (it builds on it) or unrelated. So a follow-up is not the same as rework, and only some follow-ups are repairs.

After AI adoption, rework fell in 24 of 30 codebases. The decline holds in the codebases with the fewest recent commits, whose code had the most time to be rewritten (Appendix C). The number of follow-ups per change didn't clearly change, but fewer of them were repairs (Exhibit 7).

**When code is revisited, it is now more often to build on it than to fix it.** What follow-up commits did to earlier changes, median codebase, % of follow-ups.

| Period | Repair | Extension | Other |
| --- | --- | --- | --- |
| Before AI adoption | 15% | 58% | 27% |
| After AI adoption | 11% | 71% | 18% |

Follow-up types were judged by an AI model, and verdicts below 0.5 confidence were dropped. Repair and extension are medians across 30 codebases; Other is the remainder.

_Source: Kerno Codebase Analysis, 30 codebases with an AI adoption date._

> **Less rework is not all good news.** It can mean code was right the first time. It can also mean code is being left alone when it should be cleaned up. The rise in complexity suggests at least some of the latter.

In the same codebases, AI-marked commits are revisited 43% more often than other commits and are 17% more likely to add a function with more than 10 decision points. This held in 21 of 26 codebases. When commits of the same size are compared, the gap disappears, and AI-marked code isn't clearly more complex per line than other code (Exhibit 8).

AI-marked commits also land where code changes most. They made up 9% of all commits but 20% of the edits to each codebase's most-edited functions, a pattern that held in 24 of 30 codebases. Part of the reason is size, since bigger commits touch more functions.

Denser code hasn't yet led to more fixes. Commits that added more decision points per line were no more likely to be fixed within 90 days than commits of the same size that added fewer (+3%, range −8% to +23%, 32 codebases; not statistically clear). Earlier research links complexity to failures over longer periods (Nagappan et al., 2006), which a two-year window can't yet test.

**AI-marked commits are bigger, so each one adds more complexity. Per line, the difference isn't clear.** AI-marked vs other commits in the same codebase after adoption, median difference with 95% range.

| Measure | Median change | 95% range | Detail | Clear? |
| --- | --- | --- | --- | --- |
| Follow-ups per change | +43% | +26% to +53% | 20 of 26 higher | Yes |
| Lines per commit | +42% | +25% to +77% | 23 of 27 higher | Yes |
| Share of commits over 500 lines | +27% | +9% to +57% | 19 of 26 higher | Yes |
| Follow-ups per 100 lines | +15% | -5% to +28% | 17 of 26 higher | No |
| Share adding a function over 10 | +17% | +8% to +33% | 21 of 26 higher | Yes |
| Same, commits of equal size | -1% | -11% to +14% | 12 of 26 higher | No |
| Decision points per 100 lines | +5% | -2% to +12% | 15 of 26 higher | No |
| Share of follow-ups that are repairs | -3% | -5% to +4% | 7 of 18 higher | No |

_Source: Kerno Codebase Analysis, 26 codebases with an AI adoption date and at least 20 AI-marked commits; other commits include unmarked AI use, so true gaps may be larger._

## Finding 5. Test changes rose from 4.7% to 8.3% of commits, while bug fixes held at a quarter of commits, as they did before AI adoption

Test commits per engineer rose in 29 of 30 codebases. Each engineer made more than twice as many test commits a week as before, 0.33, up from 0.15. Measured as test commits per 1,000 new lines, however, testing grew only about as fast as the code. The data has no test line counts or coverage.

Bug fixes stayed at about one commit in four. Because each engineer commits more often, bug-fix commits per engineer rose from 0.58 to 0.70 a week, although this rise isn't statistically clear. Reverts, where a change is undone, stayed rare at under 0.5% of commits (Exhibit 9).

**Test changes nearly doubled, while bug fixes held at a quarter of commits.** Median codebase, before and after AI adoption, 30 codebases.

| Measure | Commit type | Before | After |
| --- | --- | --- | --- |
| Share of all commits | Bug fixes | 24.9% | 24.8% |
| Share of all commits | Test changes | 4.7% | 8.3% |
| Commits per engineer per week | Bug fixes | 0.58 | 0.70 |
| Commits per engineer per week | Test changes | 0.15 | 0.33 |

Commit types are 70% to 88% accurate on 100 checked by hand. The per-engineer rise in bug fixes (median +14% per codebase) is not statistically clear.

_Source: Kerno Codebase Analysis, 30 codebases with an AI adoption date; commit types read from commit messages._

> **More testing has not reduced bug fixes.** One possible reason is that testing has kept pace with the volume of code but not with its complexity. Every 100 new lines now carry 50% more decision points, so the same amount of testing covers a smaller share of the paths. The new tests may also share the assumptions of the code they check. The data can't tell these explanations apart, because it has no test coverage.

## Finding 6. Claude signs 69% of AI-marked commits, which are 54% bigger than unmarked commits, though newer Claude models make smaller ones

**Claude signs 69% of AI-marked commits.** Share of 21,760 AI tool marks found in commit authors, co-author lines and messages.

| Tool | Marks | Codebases |
| --- | --- | --- |
| Claude | 15030 | 40 |
| Cursor | 3204 | 26 |
| Devin | 2266 | 7 |
| Copilot | 515 | 31 |
| Codex | 488 | 5 |
| Other or unnamed | 257 | 27 |

This shows which tools sign commits, not which tools teams use. Claude Code adds a co-author line by default. Two engineers named Devin, counted as the Devin agent by the detection rule, are excluded.

_Source: Kerno Codebase Analysis, all 46 codebases, October 2024 to October 2026._

We compared each tool's commits with unmarked commits in the same codebase and the same months. Only Claude appears in enough codebases to give a clear answer. Its commits are bigger, more often very large and revisited more often, but they are not clearly denser per line (Exhibit 11).

**Claude-marked commits are 54% bigger than unmarked commits and revisited 55% more.** Claude-marked vs unmarked commits in the same codebase and months, median difference with 95% range.

| Measure | Median change | 95% range | Detail | Clear? |
| --- | --- | --- | --- | --- |
| Follow-ups per change | +55% | +41% to +84% | 20 of 23 higher | Yes |
| Lines per commit | +54% | +13% to +97% | 21 of 27 higher | Yes |
| Share of commits over 500 lines | +37% | +10% to +87% | 22 of 27 higher | Yes |
| Share adding a function over 10 | +26% | +15% to +50% | 23 of 27 higher | Yes |
| Follow-ups per 100 lines | +15% | +8% to +51% | 16 of 23 higher | No |
| Decision points per 100 lines | +8% | -2% to +22% | 16 of 27 higher | No |

_Source: Kerno Codebase Analysis, 27 codebases with at least 20 Claude-marked commits and 20 unmarked commits in the same months; bots excluded; follow-ups counted within 30 days._

Claude Code also records which model wrote each commit. In the 13 codebases that used both, Opus 5 commits were 26% less likely than Opus 4 commits to add a function with more than 10 decision points (lower in 10 of 12 codebases) and 28% less likely to exceed 500 lines (lower in 11 of 13). Lines per commit and follow-ups also fell, but not clearly, and branching per line didn't clearly change. Because Opus 5 is newer, teams may also have learned to scope changes better in the meantime, and the data can't separate the two effects.

> **Why we don't compare tools.** Cursor, Devin, Copilot and Codex each appear in too few codebases for a fair comparison. Almost all of Devin's commits are in two codebases and almost all of Codex's are in one, so their numbers would describe those codebases rather than the tools. Claude's 69% share also reflects marking. Claude Code adds a co-author line by default, so its commits are easier to see than those of other tools.

## Where this is heading

On the current trend, complexity per 100 new lines rises another 42% by late 2028.

Complexity rarely breaks anything on the day it is written. It slows down the next change, and the one after that. It is felt when something forces a broad change, such as a security patch across many services, a framework upgrade or an incident in code that few people fully understand.

**These projections are conservative.** They assume complexity grows by a fixed amount each month. In practice, the median across all codebases has compounded at 3.5% a month since January 2025 (Exhibit 1), and each codebase's own growth after adoption was similar. If that pace held, complexity per 100 new lines would more than double in two years, well above even the faster-adoption line (Exhibit 12).

**On the current trend, complexity rises 42% in two years. If growth keeps compounding, it more than doubles.** Projected decision points per 100 new lines, median codebase, with 95% range at 12 and 24 months.

| Scenario | Today | +12 months (95% range) | +24 months (95% range) | Change |
| --- | --- | --- | --- | --- |
| Current trend | 9.03 | 10.94 (10.57 to 11.72) | 12.85 (12.1 to 14.41) | +42% |
| Faster AI adoption | 9.03 | 11.41 (10.72 to 12.47) | 13.78 (12.41 to 15.91) | +53% |
| Quality controls (illustrative) | 9.03 | 9.27 (6.94 to 9.99) | 9.5 (4.85 to 10.95) | +5% |
| Compounding at 3.5% a month | 9.03 | 13.6 | 20.6 | +128% |

"Today" is the trend level (9.0), not the latest single month (10.3, Exhibit 1). Faster adoption is the 20 codebases with the highest AI share. Quality controls (illustrative) is the 10 codebases with the flattest trends; no quality intervention was observed.

_Source: Kerno Codebase Analysis, 39 codebases with a complexity trend; straight-line projection of each scenario's median monthly slope._

The faster-adoption scenario uses the 20 codebases with the highest share of AI-marked commits. The quality-controls scenario is illustrative. It uses the 10 codebases with the flattest trends, and no quality intervention was observed.

> **A quiet codebase is not necessarily a safe one.** Bug fixes and reverts catch problems that appear within weeks. The cost of complexity comes later, in how long each subsequent change takes. We also can't yet see whether the new tests cover the new branches, because the data has no test coverage or test line counts. That is the main question for the next edition.

## What engineering teams can do

| Action | Why | Effort |
| --- | --- | --- |
| Track decision points per 100 lines alongside DORA metrics | Complexity rises before delivery metrics move (Finding 1) | Low. Most static-analysis tools already report it, or Kerno's free scanner can |
| Check AI-written code against the running system as it is written | AI-marked commits are revisited 43% more often (Finding 4) | Medium. Tooling and pipeline changes |
| Set a size limit for AI-assisted changes | Commits got 63% bigger, and AI-marked commits are a further 42% bigger (Findings 3, 4) | Low. A team policy and a pipeline check |
| Measure your own trend before judging AI | Unmarked codebases got more complex too (Finding 2) | Low. Given 8 or more months of history |
| Mark AI-assisted commits | Only 9% of commits are marked in the typical codebase, so AI use is undercounted | Low. A tool setting |

## About the research

We ran Kerno's Codebase Analysis tool on the full commit history of 46 well-known open-source codebases, from October 2024 to October 2026, with a second pass on complexity going back to October 2022. Most are commercial open-core products, and 35 are written mainly in TypeScript, so the results describe that kind of codebase. We chose the 46 by hand based on their size and popularity, so they are not a random sample of open-source projects. The data and analysis scripts behind every number in this report are public at [github.com/kernoio/kerno-impact-ai](https://github.com/kernoio/kerno-impact-ai).

|  |  |
| --- | --- |
| Commits | 201,576 |
| Authors | 6,847 |
| Codebases | 46 (30 with an AI adoption date, 16 without) |
| Window | October 2024 to October 2026 |

**How we identified AI use.** A commit counts as AI-written only when it carries an agent's mark, meaning an agent in the author field, a co-author line, or a "generated with" note. A codebase's adoption date is the month AI-marked commits pass 25% of the total, or step up and stay up. Most tools don't mark commits by default, so AI use is undercounted.

**How we compared.** Each codebase is compared with itself, before and after its own adoption date, and counts once. We report the median codebase. We call a result a finding only when it holds across most codebases and is statistically clear, and we say so when it isn't. We tested 16 before-and-after metrics (Appendix B) without correcting for multiple comparisons, so at this threshold about one of them could pass by chance. Percent changes are the median of each codebase's own change, so they can differ from the change between the two medians shown.

**What the data can't show.** This is observational data. "After adoption" means after the adoption date, not "because of AI". The data has no information on incidents, defects, test coverage or pull-request lead times.

## Benchmark your codebase against this report

Measure your own repository the same way as the 46 codebases in this report, before and after your team adopted AI coding agents.

```sh
npm install -g @kerno/cli
kerno audit
```

Run both from a checkout of your repository. Needs Node 18 or later.

[Learn more about Kerno Audit](https://kerno.io/audit/)

## Appendix

### A. Definitions

| Term | Plain meaning | How it's measured |
| --- | --- | --- |
| Decision point | A place where code can go two ways (`if`, `else if`, loop, `case`, `&&`, `\|\|`) | Cyclomatic complexity (McCabe, 1976), decision points + 1 per function. In TypeScript and JavaScript, ternaries (?:), ?? and catch also count; optional chaining (?.) does not |
| Decision points per 100 lines | How much branching new code brings, independent of commit size | Decision points a commit adds ÷ production lines it adds × 100, summed over each period |
| Excess complexity | Branching in functions too complex to test easily | For each function above 10 decision points, the amount above 10, per 1,000 lines of the whole codebase |
| Maintainability grade | A to D rating of excess complexity | Quarters of the 39 codebases with a trend at the start (cut-offs 4.1, 7.2, 9.6); same cut-offs at the end |
| Rework | New code rewritten or deleted soon after it's written | Share of lines from sampled commits changed within 30 or 90 days |
| Follow-up | Any later commit that comes back to the same code | Count of later commits touching a change's lines, per change |
| Repair | A follow-up that fixes the earlier change | Judged by an AI model; verdicts below 0.5 confidence dropped |
| Extension | A follow-up that builds on the earlier change | Same as repair |
| Reimplementation | A new function that duplicates one the codebase already had | Matched by name, then logic; judged by an AI model |
| Engineer-week | One person with at least one commit in a given week | Bots excluded |
| Commit type | Bug fix, test change, revert, feature | Read from the commit's subject line; 70% to 88% accurate on 100 checked by hand |

### B. Every metric, before vs after AI adoption

| Metric | Median change | 95% range | Rose / fell (of 30) | Clear? |
| --- | --- | --- | --- | --- |
| Decision points per 100 new lines | +51.5% | +32% to +72% | 27 / 2 | Yes |
| Excess complexity per 1,000 lines | +14% | +2% to +27% | 24 / 6 | Yes |
| Functions over 10 decision points added per 1,000 lines | +38% | +21% to +78% | 25 / 5 | Yes |
| Share of commits adding a function over 10 decision points | +62% | +45% to +90% | 25 / 5 | Yes |
| Lines per commit | +63% | +40% to +98% | 26 / 2 | Yes |
| Share of commits over 500 production lines | +34% | +8% to +79% | 23 / 7 | Yes |
| Production lines per engineer-week | +71% | +26% to +116% | 23 / 7 | Yes |
| Active contributors per week | +10% | −19% to +28% | 16 / 14 | No |
| Lines rewritten within 30 days | −16% | −32% to −6% | 8 / 22 | Yes |
| Lines rewritten within 90 days | −26.5% | −34% to −20% | 5 / 24 | Yes |
| Follow-ups per change | +7.5% | −5% to +41% | 18 / 12 | No |
| Share of follow-ups that are repairs | −23% | −40% to −7% | 7 / 21 | Yes |
| Reimplementations per 1,000 lines | −26.5% | −40% to −3% | 7 / 23 | Yes |
| Share of commits that are bug fixes | −4% | −16% to +6% | 13 / 17 | No |
| Share of commits that change tests | +81% | +41% to +127% | 25 / 5 | Yes |
| Share of commits that are reverts | −50% | −61% to −21% | 6 / 17 | Yes |

"Clear" means the 95% range excludes zero and a sign test gives p ≤ 0.05. Percent changes are calculated as described under How we compared.

### C. Method notes

- Monthly growth rates come from a straight line fitted to the logarithm of each codebase's monthly values. Months with fewer than 1,000 production lines are left out.
- The step-up in complexity growth, from +0.7% to +3.5% a month, is not statistically clear on the two-year data alone (range −2.1 to +5.8 points). The four-year re-run makes it clear. In each codebase, growth went from −0.4% a month (October 2022 to September 2024) to +3.1% (January 2025 to October 2026), a step of +3.3 points (95% range +1.7 to +5.3), faster in 31 of 39 codebases (p < 0.001). The 3.5% a month used in the forecast is the growth of the median across all codebases since January 2025, while 3.1% is the median of each codebase's own growth.
- **Four-year re-run.** The same 46 codebases from October 2022 to October 2026, complexity and attribution only, with adoption months fixed from the main run. Monthly medians leave out months under 1,000 production lines. The main before-and-after result reproduces, at 5.2 to 8.2 decision points per 100 lines, up in 28 of 30 codebases. Leaving out any one codebase moves the October 2026 median by at most 0.03; leaving out the three biggest risers (Vendure, Strapi, Directus) lowers it from 10.3 to 9.7.
- **Fixed set of codebases.** On the two-year data, the 24 codebases present in at least 20 of 24 months grew 3.1% a month from January 2025, compared with 3.2% for all codebases. The 3.5% quoted elsewhere comes from the four-year re-run, a separate run with slightly different monthly values.
- **Recent commits and 90-day measures.** In the median codebase, 42% of after-adoption commits fall in the window's final 90 days, so they had less time to be rewritten. In the 14 codebases where under 40% were that recent, 90-day rework still fell 29% (12 of 14, p = 0.01). Lines still in place after 90 days have the same exposure and were not re-run.
- **Moving the date.** We applied one adoption date to every codebase, for each month from December 2024 to July 2026. More codebases got more complex than less complex at all 20 dates.
- **Forecast.** Today's median level (9.0) plus each scenario's median monthly slope, projected 12 and 24 months. The range is a 95% bootstrap interval for the median slope. Straight lines from 8 to 30 monthly points are a weak method, so read the ranges more than the lines. The straight line is deliberately conservative. Compounding at the after-adoption rate of 3.5% a month (1.035²⁴ ≈ 2.3×) would give a far steeper rise, but that rate rests on about a year of data per codebase.
- **By tool and model.** Each tool's or model's commits are compared with unmarked commits in the same codebase and the same months; codebases need at least 20 commits in each group. Follow-ups are counted within 30 days, and commits from the last 30 days are left out. Model names come from the Claude Code co-author line; other tools don't record one. Opus 4 vs Opus 5 compares each against its own human baseline in the 13 codebases that used both. Two engineers named Devin, at Prefect and Mattermost, were counted as the Devin agent by the detection rule; their roughly 350 commits are excluded.
- **Data quality.** Bots (7% of commits) are excluded from complexity and output measures. Lockfiles and vendored code are excluded too; generated code is 0.1% of file changes. Vue, Handlebars and ERB aren't parsed; 8 codebases have under 90% parser coverage (lowest 58%).

### D. Raw data and references

Every codebase's numbers, the raw benchmark output and the analysis scripts are at [github.com/kernoio/kerno-impact-ai](https://github.com/kernoio/kerno-impact-ai).

1. Nagappan, N., Ball, T., Zeller, A. (2006). Mining metrics to predict component failures. ICSE 2006
2. McCabe, T. J. (1976). A Complexity Measure. IEEE Transactions on Software Engineering, SE-2(4)