The hidden cost of AI-generated code: a maintenance accounting worksheet

The invoice arrives after the merge

An engineer uses a coding agent to produce a service endpoint in two hours instead of six. The time saving is visible, real, and lands in the same sprint. What does not appear on any dashboard is the cost that follows: a reviewer spends 90 minutes understanding unfamiliar patterns, a second engineer rewrites the error-handling path three weeks later because it swallowed exceptions silently, and a third engineer discovers during a feature extension that the generated module resists modification because its internal structure was optimized for the original prompt, not for the next change.

None of those costs belong exclusively to AI-generated code. Human-written code produces the same categories of expense. The difference is that AI-assisted workflows can shift the cost profile -- front-loading volume while deferring comprehension, review, and adaptation work -- in ways that are easy to miss if you only measure time-to-merge.

This guide is for the engineering budget owner (director, VP, or staff engineer with cost accountability) who wants to measure that shift honestly. It does not assume AI-generated code is more expensive to maintain. It gives you a structure to find out, for your codebase, with your team, using numbers you can defend and limitations you can name.

Quick-start path

1. Pick a cohort. Select 15-30 shipped changes from the last 60-90 days. Include a mix of AI-assisted and human-only changes. Match them roughly by size, domain, and author seniority.
2. Set an observation window. Choose a fixed period after merge -- 30, 60, or 90 days. Every cost you record must fall inside this window.
3. Fill the maintenance ledger. For each change, record costs across five categories (defined below). Mark shared and ambiguous costs explicitly.
4. Compare cohorts. Calculate per-change and per-surviving-line averages. Note confidence levels.
5. Review monthly. Extend the observation window as data matures. Adjust cohort selection based on what you learn.

If you need to present results to leadership within a week, start with a cohort of 10 changes and a 30-day window. You will get directional signal, not conclusive evidence. Label it accordingly.

Five cost categories and who owns each

Every shipped change generates downstream cost. The categories below are not unique to AI-generated code -- they apply to all changes -- but tracking them separately for AI-assisted and human-only cohorts reveals where the profiles diverge.

Acquisition cost

What it took to produce and land the change. This includes the author's time, the agent's compute cost (if tracked), prompt iteration, and the time to get the change to a reviewable state. Ownership: the authoring engineer and their manager.

Why it matters for AI-assisted work: acquisition cost is where the savings are most visible. If you skip this category, you cannot calculate the net cost difference. You need the baseline.

Review cost

Time spent by reviewers understanding, questioning, and requesting changes. Include all review rounds, not just the first pass. Ownership: the reviewing engineer(s) and the team lead who assigns review load.

Why it matters: AI-generated code can be syntactically correct but structurally unfamiliar. If reviewers spend more cycles on AI-assisted PRs, that cost offsets some of the acquisition savings. If they spend fewer (because the code is well-structured or well-tested), that amplifies the savings.

Repair cost

Time spent fixing defects, incidents, or incorrect behavior traced to this change within the observation window. Include investigation time, not just the fix. Ownership: the on-call engineer and the team lead responsible for the affected service.

Why it matters: a change that ships fast but causes an incident two weeks later has a repair cost that does not appear in sprint velocity. Attribution is hard -- a nearby guide on defect attribution covers this in depth -- so mark confidence levels (high, medium, low) on every repair entry.

Operating cost

Ongoing runtime expense the change introduces or increases: additional compute, monitoring, alerting, or manual operational tasks. Ownership: the platform or SRE team and the service owner.

Why it matters: AI-generated code sometimes favors straightforward but resource-intensive approaches (e.g., loading full datasets into memory instead of streaming, or polling instead of event-driven patterns). These choices may be correct for the scale at hand, or they may quietly increase cloud spend.

Future-change cost

The effort required to modify, extend, or remove the code during the observation window. If another engineer needed to change this code and found it easy or hard, that experience is a future-change cost signal. Ownership: the engineer who made the subsequent change and the architect or tech lead responsible for the module.

Why it matters: this is the hardest category to measure and the most consequential for long-term budgets. Code that resists modification imposes a tax on every feature built on top of it. But code that is never modified during the observation window has a future-change cost of zero in your ledger -- which does not mean it will be zero forever. Mark unobserved entries as "no data," not "no cost."

Maintenance accounting worksheet (copyable)

Copy this worksheet into a spreadsheet or document. One row per shipped change. Columns are described below, followed by three hypothetical filled rows for illustration.

Instructions:

• Fill one row per change in your cohort.
• Use hours as the unit for all time costs. Record operating cost separately in dollars per month -- do not convert it to hours in the worksheet. Convert everything to a single unit (hours or dollars) only in the final summary row.
• Mark the Attribution confidence column as H (high), M (medium), or L (low) for repair and future-change costs. High means you can trace the cost to this specific change with evidence. Medium means this change is one of two or three plausible causes. Low means the cost is shared across several changes and you are allocating a fraction.
• Mark Shared cost as Y if the cost is split across multiple changes. Record only this change's allocated share.
• Leave cells empty rather than entering zero if you have no data. Zero means "measured and found none." Empty means "not measured."

| Change ID | Authorship   | Acq. (hrs) | Review (hrs) | Repair (hrs) | Repair conf. | Repair shared | Oper. ($/mo) | Future-chg (hrs) | FC conf. | FC shared | Lines surviving | Lines deleted | Notes                                      |
|-----------|--------------|------------|--------------|--------------|--------------|---------------|--------------|-------------------|----------|-----------|-----------------|---------------|--------------------------------------------|
| PR-1042   | AI-assisted  | 2.0        | 3.0          | 4.0          | M            | Y (50%)       | 12           | 1.5               | H        | N         | 180             | 40            | Reviewer flagged unfamiliar retry pattern   |
| PR-1058   | Human-only   | 5.5        | 1.5          | 0            | --           | --            | 8            | 0.5               | H        | N         | 210             | 10            | Author refactored during review             |
| PR-1071   | AI-assisted  | 1.0        | 2.0          |              |              |               | 8            |                   |          |           | 320             | 0             | No repair or extension observed yet         |

How to read the hypothetical rows above:

• PR-1042 saved roughly 3.5 hours in acquisition versus the human-only PR-1058, but consumed 1.5 more hours in review and 2.0 hours of allocated repair cost (4.0 hours total, 50% attributed to this change). Net difference before operating and future-change costs: 3.5 - 1.5 - 2.0 = 0.0 hours. The savings were real but were consumed downstream.
• PR-1058 cost more to write but less to review and had zero repair cost in the observation window. Its total measured cost is 7.5 hours.
• PR-1071 looks inexpensive so far (3.0 hours total), but two cost columns are empty because the observation window has not yet produced data. It would be wrong to declare it cheaper than PR-1058. It might be. You do not know yet.

Per-change summary formula:

Labor hours = Acquisition + Review + (Repair x attribution share) + (Future-change x attribution share)

Operating dollars = Operating $/mo x months observed

Keep these as two separate line items. To get a single number, convert one to the other using your blended hourly rate, but do so explicitly in a final summary -- not inside the per-change rows.

For PR-1042 over a 2-month window (hypothetical): Labor = 2.0 + 3.0 + (4.0 x 0.5) + (1.5 x 1.0) = 8.5 hours. Operating = $12 x 2 = $24. At an $85/hour blended rate, the combined equivalent is 8.5 + (24 / 85) = approximately 8.8 labor-equivalent hours, or (8.5 x 85) + 24 = $746.50 total.

Worked hypothetical scenario: the payments team ledger

A hypothetical payments team at a mid-stage company ships roughly 40 changes per month. In the last quarter, about 30% were AI-assisted. The engineering director wants to understand whether AI-assisted changes are cheaper overall or just cheaper to produce.

Setup:

• Cohort: 20 changes (8 AI-assisted, 12 human-only), selected from the last 75 days, matched by service area (payment processing) and rough complexity (each change touches 1-3 files and includes tests).
• Observation window: 60 days post-merge.
• Blended hourly rate: $85/hour (hypothetical, for dollar conversion only).

Data collection (hypothetical aggregates):

Analysis:

• Acquisition savings are real. The AI-assisted cohort saved an average of 3.1 hours per change in authoring time. At $85/hour, that is roughly $264 per change (hypothetical).
• Review absorbed some savings. Reviewers spent 0.8 hours more per AI-assisted change. Common reasons in the notes: unfamiliar abstractions, inconsistent naming, and one case where the generated code used a library the team had deprecated.
• Repair and future-change costs are higher but confidence is mixed. The combined repair + future-change difference is 0.9 hours per change, but 60% of those entries are marked M or L confidence. The director cannot claim AI-assisted code definitively costs more to maintain; she can say the signal trends that direction for this cohort and needs a longer window.
• Deleted lines are not automatically waste. PR-1042 had 40 lines deleted within the window, but 30 of those were replaced during a planned refactor that improved the module's interface. Only 10 were deleted because they were wrong. The worksheet distinguishes these in the Notes column.
• The review-to-acquisition ratio is an early warning. For AI-assisted changes, review hours divided by acquisition hours averaged 1.33 (2.4 / 1.8). For human-only changes, the ratio was 0.33 (1.6 / 4.9). A review-to-acquisition ratio above 1.0 means the team spends more time understanding the code than the author spent producing it. That inversion does not automatically indicate a problem -- some complex changes warrant long reviews -- but when it appears consistently across a cohort, it signals that comprehension debt is accumulating. In practice, high review-to-acquisition ratios in one observation cycle often precede elevated repair costs in the next, because the same comprehension gaps that slow reviewers also slow the engineers who later fix or extend the code. The director flags any AI-assisted change with a ratio above 1.5 for closer review in the next cycle.
• Net cost per change (hypothetical):
  • AI-assisted labor: 1.8 + 2.4 + 1.1 + 0.8 = 6.1 hours. Operating: $14 x 2 months = $28.
  • Human-only labor: 4.9 + 1.6 + 0.7 + 0.3 = 7.5 hours. Operating: $11 x 2 months = $22.
  • Combined equivalent at $85/hr: AI-assisted = (6.1 x 85) + 28 = $546.50. Human-only = (7.5 x 85) + 22 = $659.50.
  • Difference: AI-assisted appears roughly $113 cheaper per change (about 1.3 labor-equivalent hours), but the confidence-weighted difference shrinks to about $57 (0.7 hours) when you discount low-confidence repair and future-change attributions by 50%.

Decision: The director reports to leadership that AI-assisted changes show a net cost advantage in this cohort, but the advantage is smaller than acquisition-time savings alone would suggest, and the estimate has wide uncertainty. She schedules a follow-up with a 90-day window and a larger cohort, and adds the review-to-acquisition ratio as a standing metric to watch.

Comparing realistic approaches to maintenance cost tracking

For teams already using FeatureFactory to examine engineering delivery, the ledger data can be cross-referenced with delivery signals to identify which cost categories are growing. The worksheet itself is tool-agnostic -- it works in a spreadsheet.

Distinguishing durable reuse from code volume

A common mistake is treating lines of code as a proxy for value. AI-assisted workflows often produce more code per unit of author time. That is not automatically good or bad. What matters is how much of that code survives, gets extended, and remains comprehensible.

The worksheet tracks Lines surviving and Lines deleted separately. A high deletion rate within the observation window may indicate low-quality code, or it may indicate healthy iteration (a feature was prototyped quickly and then refined). The Notes column is where you record which interpretation applies. Without that annotation, the number is ambiguous.

A distinctive risk with AI-generated code: it can produce code that is locally correct but globally redundant -- implementing a utility that already exists elsewhere in the codebase, or creating a parallel abstraction that diverges from the team's conventions. This code may never be deleted (it works), but it quietly increases future-change cost because now two patterns exist where one should. Track this in the Notes column as "parallel implementation" and flag it during product planning discussions about technical debt.

Compounding comprehension debt when agents extend agent-written code

There is a second cost dynamic that only appears when AI-assisted code is later modified by another AI-assisted workflow -- or even by the same agent on a different prompt. Each generation of agent-written code is optimized for the prompt it received, not for the accumulated context of the module. When a human extends human-written code, they typically read the surrounding implementation, absorb its conventions, and adapt. When an agent extends agent-written code, it may layer a new pattern on top of an existing one, producing a module where two or three internally consistent but mutually incompatible styles coexist.

The practical consequence: future-change cost does not just accumulate linearly across agent-touched modules -- it can accelerate. A module modified by agents in two successive cycles may be harder to work with than the sum of its parts would suggest, because the engineer who eventually must read the whole thing faces not just volume but inconsistency. If you notice future-change costs climbing faster than the number of agent-assisted modifications, this compounding effect is a likely explanation. The corrective action is to require a human comprehension pass (not just a review, but a deliberate restructuring to a single consistent style) after a module receives its second or third agent-assisted modification. Record this restructuring cost in the ledger as a future-change cost attributed to the most recent AI-assisted change, and note "comprehension consolidation" in the Notes column.

Failure symptoms, corrective actions, and escalation points

Explicit limitations

• Attribution is always partial. No maintenance cost belongs entirely to one change. The worksheet makes shared costs visible but cannot eliminate ambiguity. If you need certainty, you will not get it from this method or any other.
• Observation windows truncate reality. A 60-day window misses costs that appear at month four when someone extends the module. Longer windows are better but require more patience and discipline.
• Self-reported time is noisy. Engineers estimate their own review and repair time. Some round up, some round down, some forget. Ranges (e.g., "1-2 hours") are more honest than false precision.
• Small cohorts produce small-sample results. With 8 AI-assisted changes, a single outlier (one incident-causing PR) can dominate the average. Report medians alongside means, and note the sample size prominently.
• This worksheet does not measure code quality directly. It measures cost consequences of quality differences. A change with zero repair cost in the window might still contain latent defects. The absence of observed cost is not evidence of quality.
• Deleted code is not automatically waste. Prototyping, experimentation, and intentional replacement are legitimate reasons for deletion. The worksheet asks you to annotate, not assume.
• Operating cost allocation is rough. Attributing cloud spend to individual changes requires infrastructure tooling most teams lack. Use estimates and label them as such.

Ongoing review routine

Monthly (30 minutes):

• Review the ledger for changes whose observation window closed in the last 30 days. Finalize their cost entries.
• Check for new repair or future-change events that should be attributed to older changes still within their window.
• Update the cohort summary table.

Quarterly (60 minutes):

• Compare cohort averages across quarters. Look for trends, not single-quarter snapshots.
• Revisit cohort matching criteria. If AI-assisted usage has shifted to different parts of the codebase, the old matching may no longer be valid.
• Check whether any modules have received multiple rounds of agent-assisted modification and flag them for comprehension review.
• Present a confidence-adjusted summary to leadership. Include sample sizes and the percentage of entries at each confidence level.
• Decide whether to expand the cohort size, extend the observation window, or narrow the scope to specific teams or services.

When tooling or process changes:

• If the team adopts a new coding agent, changes its review process, or restructures services, start a new cohort. Do not mix pre-change and post-change data in the same comparison.

Teams using FeatureFactory for product planning can align the quarterly review with their planning cycle, so maintenance cost trends inform the next quarter's investment decisions.

Next-action checklist

• Identify the budget owner who will maintain the ledger. If nobody has cost accountability, this exercise will stall.
• Select your first cohort: 15-30 changes, mix of AI-assisted and human-only, from the last 60-90 days.
• Choose an observation window (30, 60, or 90 days). Shorter is faster; longer is more informative.
• Copy the worksheet into your team's shared document or spreadsheet.
• Brief reviewers and on-call engineers on what data you need and why. Emphasize that this is budget analysis, not individual performance measurement.
• Fill acquisition and review columns first (these are available immediately). Set calendar reminders for repair, operating, and future-change data at window close.
• At window close, finalize entries, mark confidence levels, and compute per-change totals using the two-line formula (labor hours and operating dollars separately).
• Calculate the review-to-acquisition ratio for each AI-assisted change. Flag any above 1.5 for closer attention in the next cycle.
• Write a one-page summary with cohort averages, confidence ranges, and the top two or three observations. Share with leadership.
• Schedule the first monthly review within 30 days.
• After two complete observation cycles, decide whether to expand the cohort, adjust the method, or stop (if the signal is not worth the effort).

The goal is not to produce a perfect number. It is to replace "AI saves us time" or "AI code is expensive to maintain" with a directional estimate that names its own uncertainty -- and improves with each cycle.