AI makes code cheaper to produce. That does not automatically make software cheaper to own.
This distinction matters because most AI productivity discussions stop at the moment code is generated, committed, or merged. They count output: more pull requests, more changed lines, shorter implementation time, or faster ticket completion.
But engineering work does not end when code appears. Someone still has to understand it, review it, integrate it with the existing system, correct its assumptions, respond when it fails, and maintain it after the original context has faded.
When AI accelerates code creation faster than a team improves those downstream systems, the work does not disappear. It moves.
Often, it moves toward the engineers who already carry the most architectural knowledge and operational responsibility.
That is the hidden maintenance tax of AI-assisted coding.
The Productivity Gain Can Be Real—and Still Incomplete
AI coding tools can create genuine local gains. A developer may reach a working implementation faster, explore unfamiliar libraries with less friction, or avoid repetitive work. None of that should be dismissed.
The mistake is treating local acceleration as proof of system-level productivity.
A pull request can be faster to create while taking longer to review. A feature can ship sooner while introducing duplicated logic that makes later changes harder. A developer can complete more tickets while a staff engineer spends more time correcting integration problems, clarifying architecture, or repairing production behavior.
All three can be true at once:
- individual output rises;
- delivery appears faster;
- total organizational effort does not fall by the same amount.
Traditional dashboards often capture the first two. The third remains largely invisible.
A Hidden Transfer of Work
A recent study offers a useful warning about this transfer.
Researchers used GitHub Copilot’s June 2021 technical preview as a natural experiment. In a difference-in-differences design, they compared Microsoft-owned repositories and contributors working primarily in Copilot-endorsed languages with control groups using non-endorsed languages, across the twelve months before and after the preview.
The results were not a simple story of universal acceleration. Peripheral contributors—particularly those in the lowest activity percentiles—increased commit activity by 43.5% and pull request submissions by 17.7%. Core contributors, however, showed a 19% decline in commit activity while increasing pull request reviews by 6.5% and reviewing work across a broader set of repositories. At the project level, pull request rework increased by 2.4% when the number of pull requests was held constant. In this study, rework was measured through follow-up commits added after a pull request’s initial submission and before integration; it was not a measure of post-merge maintenance or production incidents.
The study does not prove that every AI-enabled team will experience the same effect. It focuses on Microsoft-owned open-source projects during an early Copilot rollout, and repository activity is not a complete measure of engineering productivity. Still, the pattern is important: faster contribution at the edges can create more coordination, review, and maintenance work at the core.
In other words, AI assistance may change not only how much work gets done, but also who absorbs the cost of making that work production-ready.
Why Output Metrics Call This a Success
Suppose a team adopts AI coding tools and observes the following in the next quarter:
- more commits;
- more pull requests;
- more features completed;
- shorter time from ticket start to first implementation.
On a volume dashboard, the program looks successful.
Now suppose the same period also brings:
- longer or more demanding reviews;
- more follow-up fixes after merge;
- repeated implementations of existing capabilities;
- more interruptions for senior engineers;
- less time for architecture, refactoring, and preventive maintenance.
The apparent productivity gain may still be real. But it is being partially financed by work that the dashboard does not price.
This is why commit count, pull request count, and lines changed are weak measures of AI return on investment. They record production events. They do not tell you whether the resulting code reduced or increased the future cost of change.
The Tax Compounds Over Time
The maintenance tax is not limited to code review. Review is simply the earliest place where it becomes visible.
The full bill can include:
- Context reconstruction: understanding code that was generated faster than its author could fully explain it;
- Architectural correction: adapting a locally valid solution to system-wide constraints;
- Rework: revising or replacing code that passed an initial check but failed in integration or production;
- Duplication: adding another implementation instead of extending an existing abstraction;
- Test expansion: covering edge cases omitted by a happy-path implementation;
- Operational cleanup: diagnosing incidents, performance regressions, or unexpected dependencies;
- Knowledge concentration: increasing reliance on a small number of engineers who can recognize subtle system risks.
GitClear’s 2026 maintainability research illustrates why these downstream effects deserve attention. Across 623 million analyzed changes from 2023 through 2026, it reports declining reuse and legacy-maintenance signals alongside increases in duplication, copy-and-paste behavior, error masking, and short-term code churn. These industry-level trends do not establish that AI caused every change, and they should not be applied mechanically to a single team. They do show why faster code production cannot be evaluated independently from maintainability.
The compounding effect is what makes the tax dangerous. A duplicated block is not paid for only once. Every future change may require engineers to locate, compare, and update multiple versions. A weak abstraction does not consume effort only during review. It increases the cost of every feature built on top of it.
Speed is immediate. Maintenance debt arrives later, often under a different ticket, in a different quarter, and on someone else’s calendar.
This Is More Than a Review Bottleneck
AI can move the engineering bottleneck from coding to review. But the maintenance tax is a broader problem.
A review bottleneck describes where work queues up. The maintenance tax describes how the economic burden is distributed over time and across people.
That distinction matters. A team might reduce review cycle time by adding reviewers or using automated review agents. Yet the organization can still carry a maintenance tax if AI-assisted changes create more rework, survive for less time, or require senior engineers to repeatedly restore architectural consistency.
Faster review is useful. It is not the same as lower total cost of ownership.
Not All Review and Rework Are Waste
It would also be a mistake to classify every review comment, revision, or refactor as inefficiency.
Good review prevents defects, spreads knowledge, improves design, and protects the codebase. Rework may reflect responsible learning when requirements change or new information appears. Senior engineers should spend part of their time guiding important changes.
The question is not whether these activities exist. It is whether AI adoption changes their volume, concentration, and downstream impact.
Useful questions include:
- Did AI-assisted contributions require more iterations than comparable non-assisted work?
- Did review and corrective work become concentrated among a small group of core engineers?
- Did the resulting changes remain effective, or were they quickly rewritten, reverted, or removed?
- Did higher delivery volume preserve time for refactoring and architectural work?
- Did the organization create durable capability, or only accelerate the arrival of maintenance obligations?
These questions move the discussion from “Are developers using AI?” to “Is AI improving the engineering system?”
A Better Equation for AI ROI
The simplest AI ROI narrative is:
Faster implementation equals higher productivity.
A more realistic model is:
Net AI value = delivery gain − review cost − rework cost − maintenance cost − coordination cost.
This is a management model, not a claim that every term can be converted into a precise financial number. Its purpose is to prevent a common accounting error: recording the time saved during code creation while ignoring the effort required to make that code reliable and durable.
The right unit of analysis is not the prompt, suggestion, commit, or pull request in isolation. It is the contribution over its useful life.
What Engineering Leaders Should Measure
No single metric can capture the maintenance tax. A useful view combines output, effort, quality, and durability.
1. Human effort behind delivered work
GitMe’s Real Effort Value (REV) models the baseline engineering effort represented by a contribution. It is not a timesheet and not a measure of business value. It helps establish a more meaningful denominator than raw activity counts.
2. AI participation and leverage
AI Effort Share shows where AI-assisted work is concentrated. AI Leverage expresses the relationship between modeled delivered effort and modeled human effort as a productivity multiplier. Together, they help distinguish adoption from useful leverage.
High AI participation is not automatically high leverage. If AI-assisted work creates additional review, rework, or maintenance, the human effort required to realize the output may remain high.
3. Rework and historical comparison
Teams should compare AI-assisted changes with relevant historical baselines. Do they require more follow-up modification? Are similar changes now being completed with less human effort, or is effort merely shifting to another phase and another person?
The goal is not to punish revision. It is to identify recurring patterns that make output expensive to stabilize.
4. Effort durability
GitMe’s Effort Survival Cohort examines how modeled engineering effort remains effective over time. This adds a dimension that throughput metrics miss: whether work continues to carry value after it is delivered.
A change that survives and supports later development has a different economic profile from one that is quickly rewritten or removed—even if both initially count as one merged pull request.
5. Distribution of maintenance work
Organizations should also inspect who performs the downstream work. If a small group of senior or core engineers absorbs a growing share of review, correction, and incident response, the team may be consuming its scarcest capacity to subsidize visible output elsewhere.
That is not an individual performance problem. It is a system design problem.
What GitMe Makes Visible
GitMe is designed to help engineering organizations evaluate work beyond activity volume.
By connecting modeled effort, AI participation, AI leverage, work categories, rework patterns, historical comparisons, and effort durability, GitMe helps teams ask whether AI-assisted output becomes lasting engineering value.
It should not be used as a simplistic employee score, a substitute for engineering judgment, or a complete financial ROI calculator. Its value is in making previously disconnected parts of the engineering system comparable:
- how much modeled effort a contribution represents;
- how much AI participated in producing it;
- how much human effort the model estimates remained necessary;
- how the work changed after delivery;
- how long the effort continued to survive in the codebase.
That is the evidence leaders need to separate genuine leverage from deferred cost.
The Real Question Is Who Pays Later
AI-assisted coding can make an engineering organization faster. But speed at the point of creation is only one part of the result.
If code arrives faster while review, rework, and maintenance quietly accumulate around the people with the most system knowledge, the organization has not eliminated effort. It has redistributed it—and may have made it harder to see.
The goal is not to slow AI adoption. It is to manage AI with a complete accounting of engineering work.
Measure the delivery gain. Then measure the work required to preserve it.
That is how teams turn AI-generated output into durable engineering value instead of a maintenance bill that arrives later.
Sources
- Xu, F. (Amber), Medappa, P. K., Tunc, M. M., Vroegindeweij, M., & Fransoo, J. C. AI-assisted Programming May Decrease the Productivity of Experienced Developers by Increasing Maintenance Burden. arXiv, 2025.
- Kamalı, H. Ö., et al. Rethinking Code Review in the Age of AI: A Vision for Agentic Code Review. arXiv, 2026.
- GitClear. The Maintainability Gap: AI Code Quality in 2026.