GitClear: AI speeds up code releases, but grows 'understanding debt' and hidden risks

AI assistants accelerate development, but increasingly leave behind code that formally works, but essentially no one understands. This is indicated by both GitClear data and the experience of teams that have discovered a new hidden risk — "comprehension debt."

What GitClear Found

In the 2025 GitClear study, they analyzed 211 million changed lines of code over 2020–2024. The main signal: code churn, that is, lines rewritten within two weeks after a commit, compared to the pre-AI baseline from 2021, has essentially doubled. At the same time, the share of refactoring and code reuse declined, and duplication became more frequent than before. In simple terms, teams produce more code, but a significant portion of that volume quickly comes back for rework. This is important not only as a quality metric, but as a management problem.

In March 2026, Google engineer Addy Osmani described this as comprehension debt — the gap between the volume of code in a system and the volume of code that the team actually understands. On the surface, everything looks fine: CI is green, coverage doesn't drop, PRs merge faster. But at the first unusual incident, it turns out that no one can quickly explain why the logic is arranged that way.

"AI generates code faster than people can evaluate it."

Why Tests Fall Short

The main trap is that AI often writes not only the function itself, but also the tests for it. As a result, the team checks that the implementation matches the implementation, not how the business logic should work. With a simple webhook example, this looks harmless: the test confirms that an order changes status to paid.

But it may not check for missing order_id, event redelivery, new status in the payment API, or a situation where the system returns 200 even though the order was not found at all. Such tests create a false sense of reliability. They increase coverage, look good in reports, and allow you to close tasks faster, but do not replace understanding of domain constraints and edge cases.

This is especially noticeable in new technologies. In January 2026, Anthropic published an experiment with 52 Python developers studying the Trio library: the group with AI assistance showed 17% worse results on a comprehension test than the group without AI. Meanwhile, those who performed best were not those who delegated code entirely, but those who used the model for "why" and "what if" questions.

How to Reduce Risk

Practice shows that AI itself does not guarantee either failure or success. The process around it becomes decisive. If a team accepts huge PRs, doesn't require explanations, and considers green tests sufficient grounds for merge, it will almost inevitably accumulate code that is difficult to maintain. If review standards remain strict, AI begins to bring benefits without sharp growth in chaos.

• Split large changes into small PRs that can actually be read and discussed
• Require the author to explain solutions and explicitly document assumptions about business logic
• Write tests before implementation or at least separate intent checking from verifying the generated happy path
• Add modular rules, automated checks, and up-to-date documentation so that AI works within the project context

The paradox is that AI can be not only a source of problems, but also a tool for solving them. These same models explain old legacy code well, help find forgotten conditions, and highlight weak spots in architecture. That is, "code without an author" existed before, it's just that AI sharply increased the volume of changes and made this debt noticeable not years later, but almost immediately after merge.

What This Means

For teams, the goal doesn't change, but the quality criterion does. Those who win are not those who produce lines faster, but those who maintain system understanding while increasing speed. If AI is already writing a significant part of the code, the main skill becomes not generation, but verification, explanation, and the ability to fix that piece at night under incident pressure. This is exactly what separates accelerating development from accelerating future problems.