What is the 12-month cost of AI-generated code?

The first version of AI-generated code is cheap. The twelfth month is where the invoice arrives. Teams that budget only model fees and the minutes spent prompting confuse code production with software ownership. The cost sits in review, rework, incidents, dependency updates, migrations, and the time a future engineer needs to understand a decision nobody recorded.

I have seen this mistake before with outsourced code, low-code projects, and hurried internal tools. AI changes the production speed, not the economics of maintaining an opaque system. A useful 12-month budget treats agent output as inventory that must earn acceptance, gain an owner, and survive change. If it cannot clear those gates, its low creation cost is irrelevant.

Generated code has four separate price tags

The cost of AI-generated code has four parts: generation, acceptance, correction, and carrying cost. Most budgets record the first part because the vendor sends a visible bill. The other three consume payroll inside existing teams, so they disappear into a broad engineering line until delivery slows.

Generation includes model subscriptions or API usage, agent infrastructure, sandbox compute, and the engineer time spent preparing context and prompts. It is usually the smallest category for production work. A feature that costs $40 in tokens can still absorb days of senior attention if the agent chose the wrong boundary or duplicated an internal capability.

Acceptance is the work required before merge: reading the diff, checking the requirement, running tests, examining security-sensitive paths, verifying dependencies, and confirming operational behavior. Review is production work. Calling it overhead hides the human labor that turns a plausible patch into a company asset. Track it against the generated change, even when the same engineer prompted and reviewed it.

Correction covers defects discovered before and after release. Pre-release correction includes rejected attempts, prompt retries, rewritten tests, and manual replacement of code that technically works but does not fit the system. Post-release correction includes incident response, rollback, hotfixes, customer support, and follow-up work that removes the conditions that caused the failure.

Carrying cost begins after the patch works. Someone must update it when an API changes, patch its dependencies, explain it during review, migrate its data, observe it in production, and eventually delete it. Code that no engineer understands has a higher carrying cost even when it has no open bug. It slows every nearby change because people have to rediscover its assumptions.

Do not allocate these costs by counting generated lines. A line in a data migration can carry more risk than a hundred lines of formatting code. Use a change record with engineering hours, risk class, owner, and follow-up work. Lines can describe volume, but they cannot price responsibility.

Build a human-written baseline before claiming that an agent is expensive or cheap. Sample comparable changes from the same repositories and record their acceptance, correction, and carrying hours with the same definitions. Old code was never free to maintain; it was merely familiar. A fair comparison asks whether the agent lowers total hours for an accepted outcome without moving risk into a later quarter.

Separate generated output from accepted output in every report. An agent may produce five rejected attempts before one patch reaches production. Generation metrics should expose that waste, while the maintenance forecast should include only accepted changes. Combining the two makes rejection look like installed liability and hides whether engineers are improving the context that agents receive.

Rework rate needs a clock and a cause

A defensible rework rate measures accepted agent output that required material correction within a fixed window. Without both the clock and the cause, teams either celebrate a low number that excludes production defects or blame AI for ordinary requirement changes.

Use three windows because each catches a different failure. Measure pre-merge rejection, correction within 30 days of merge, and correction from day 31 through month 12. The first window shows whether the agent receives usable context and whether reviewers reject weak work. The second catches shallow correctness: missing edge cases, faulty assumptions, and code that passes a narrow test. The long window exposes maintainability, upgrade, and ownership failures.

Define material correction before collecting data. I count a change when an engineer must alter behavior, architecture, security controls, data handling, or tests because the accepted output was wrong or hard to maintain. Formatting, comments, and unrelated feature changes do not qualify. Requirement churn gets its own cause code. Otherwise a founder who changes the product direction will make the agent look worse than it was.

A small repository can start with a pull-request label and a CSV export. A larger one should join pull requests, incidents, and issue records. This query shape gives finance and engineering the same monthly denominator:

SELECT
  date_trunc('month', merged_at) AS cohort,
  COUNT(*) AS accepted_agent_changes,
  SUM(CASE WHEN material_rework_hours > 0 THEN 1 ELSE 0 END) AS reworked_changes,
  SUM(material_rework_hours) AS rework_hours,
  ROUND(100.0 * SUM(CASE WHEN material_rework_hours > 0 THEN 1 ELSE 0 END) / COUNT(*), 1) AS rework_rate_pct
FROM change_records
WHERE agent_assisted = TRUE
GROUP BY 1
ORDER BY 1;

The result should look like one row per merge cohort with accepted changes, reworked changes, hours, and a percentage. Keep the hours beside the percentage. Ten trivial corrections and one failed migration can produce similar rates with radically different costs.

Tag causes using a short controlled set: missing context, incorrect implementation, weak test, architectural mismatch, security or privacy issue, dependency choice, and requirement change. Allow one primary cause and an optional secondary cause. Free-form explanations remain useful, but they are miserable to aggregate.

Severity belongs beside cause. Record whether the correction stayed inside normal development, blocked a release, caused a rollback, or triggered an incident. Then record the actual hours across engineering, support, security, and operations. A single severity label cannot replace hours, but it helps leadership see why a low-frequency class deserves a larger reserve.

Measure escaped work against the original acceptance evidence. If the test suite passed because the generated test repeated the same faulty assumption as the implementation, classify the correction as a weak-test failure rather than two unrelated bugs. This matters because the remedy is better independent acceptance criteria, not a longer prompt.

Do not compare an AI-heavy team with a human-only team unless the work has similar risk and size. Agents often receive chores one month and entire features the next. Compare cohorts by change class, repository, and risk. The trend inside a stable class tells you more than a company-wide vanity number.

Ownership starts at merge, not at generation

Every accepted change needs one human accountable for its behavior and one team accountable for its life cycle. An agent can propose, test, and revise code, but it cannot carry an escalation phone, defend a tradeoff to a customer, or choose what to sacrifice during an incident.

There are three workable ownership models. In the author-owner model, the engineer who directs the agent owns the patch after merge. It is simple and works in small teams, though it breaks when prolific engineers spread agent output across domains they do not operate. In the service-owner model, the team that runs the service owns any merged code, regardless of who or what produced it. This model scales better when repository boundaries match operational responsibility.

The third model assigns a steward to a generated subsystem for a defined period. It fits migrations, internal tools, and agent-built services that cross team boundaries. The steward maintains the decision record, approves dependency changes, watches initial production behavior, and arranges a handoff. A steward without time in the plan is a name on a page, not ownership.

Ownership also needs decision rights. State who may approve a release, accept a known limitation, stop the agent, roll back the change, and retire the subsystem. During an incident, a list of responsible people without those rights creates a meeting instead of a decision. For high-risk code, connect the owner to the on-call route and record the escalation point before release.

Avoid collective ownership as the only label. Saying "the platform team owns it" means little if five people assume another person read the diff. Record a named accepting engineer and the durable owning team. The individual can change jobs; the team remains the escalation path.

The pull request should preserve enough evidence for the next owner to reconstruct intent. A compact record can live in the description or a checked-in change manifest:

agent_assisted: true
accepting_engineer: sam.lee
owning_team: payments
risk_class: high
requirements:
  - reject duplicate settlement events
  - preserve ledger ordering
validation:
  - integration:test_settlement_idempotency
  - load:replay_10k_events
known_limits:
  - manual recovery required after partial provider outage
review_after: 2026-11-15

This record does not need a transcript of every prompt. Long transcripts contain noise and may expose secrets or customer data. Preserve the requirement, relevant constraints, accepted tests, known limits, tool and model identifiers when policy requires them, and the human decision. That is the evidence maintainers use.

Legal title and maintenance duty are different questions

A company can require an employee to maintain code even when the copyright status of some generated expression is uncertain. Teams routinely blur legal title, contractual rights, provenance, and operational responsibility. Each question needs its own control.

For United States copyright, the U.S. Copyright Office report Copyright and Artificial Intelligence, Part 2 says generative output receives protection only where a human author determined sufficient expressive elements. Prompts alone do not automatically supply authorship. Human selection, arrangement, or modification may qualify, depending on the work. That principle is useful, though it does not answer every code-specific fact pattern or the law in another country. Ask counsel about the jurisdictions and contracts that apply to your product.

Contractual rights come from employment agreements, contractor assignments, model-provider terms, and customer contracts. Review those documents before an agent becomes part of normal delivery. The clean operational rule is that every contributor, human or corporate, must have terms compatible with the company's intended use and distribution. Do not assume a paid model subscription transfers every right you need.

Provenance asks where an accepted expression or dependency came from. GitHub's Copilot documentation explains that its code-referencing feature can identify some suggestions that match public code and attach repository and license information. The same documentation states limitations: altered suggestions are not necessarily checked, private code is outside the public index, and the index can lag. A matching filter is evidence, not a complete chain of title.

SPDX makes a distinction worth adopting. Its specification can describe a snippet, associate it with a file, and record license or attribution information. You do not need an SPDX record for every agent-written loop. You do need a repeatable way to retain an identified source match, the applicable license decision, and the review outcome when a tool reports one.

Operational responsibility remains with the owning team regardless of copyright analysis. If a generated payment handler fails, the customer will not accept "the model wrote it" as an incident explanation. Budget legal review for policy and exceptional matches, then budget engineering ownership for every accepted change. Mixing the two creates either needless legal tickets or unowned production code.

A 12-month budget is a cohort model

The most practical budget follows monthly cohorts of accepted agent changes and assigns labor to the months when work is expected to return. This exposes the lag between a fast merge and expensive maintenance. It also lets a CFO revise assumptions without pretending to know the exact defects an agent will create.

Start with five inputs for each change class: expected accepted changes, average acceptance hours, probability of material rework, average hours per reworked change, and monthly carrying hours after release. Add incident loss and specialist review only where the risk class warrants them. Keep token and tooling cost visible, but do not let a precise API estimate distract from uncertain labor.

Suppose a team expects 20 medium-risk agent changes per month. Each needs 2 hours of acceptance. You estimate that 25 percent will need material correction within 12 months, averaging 6 hours. Each accepted change also creates 0.25 hours of monthly carrying work after its release. At an internal loaded rate of $120 per engineering hour, the first cohort costs $4,800 to accept, an expected $3,600 to rework, and $7,200 to carry for 12 months. Add actual model, infrastructure, security review, and incident assumptions. These are example inputs, not universal benchmarks.

Repeat that calculation for every monthly cohort. A January change carries for 12 budget months; a December change carries for one. If the team ships 20 changes every month, year-one carrying hours form a staircase rather than a flat monthly charge. The year-two budget starts with the full installed base, so maintenance can rise even if generation volume stays constant.

Use three cases instead of one false forecast. The expected case uses observed medians after enough cohorts mature. The controlled case assumes better context, tests, and review lower correction hours. The stressed case increases both correction probability and incident impact for high-risk work. Finance can reserve against the stressed case while engineering earns its way toward the controlled case.

Separate cash expense from capacity expense. Model subscriptions, outside counsel, and incident vendors create cash charges. Review and maintenance consume team hours that might otherwise ship product. A budget that records only cash will claim savings while the roadmap quietly absorbs the missing capacity.

Account for avoided work in a separate line. If an agent lets the team retire a vendor, avoid a contractor, or deliver the same accepted scope with fewer hours, record that saving against a named baseline. Do not subtract a vague productivity percentage from the cost model. A saving needs a counterfactual that finance can inspect, such as the prior three migrations or a scoped human estimate approved before work began.

Treat shared foundations as investments, not as free benefits. Repository instructions, test rigs, evaluation cases, sandboxing, and reusable agent workflows may lower costs across many cohorts. Amortize their build and upkeep across the changes that use them. Otherwise the first pilot looks expensive and every later feature looks artificially cheap.

Forecast retirement as well as accumulation. Some changes replace older code and remove its carrying cost. Credit that reduction only after the old path, dependency, data job, and alerts are actually removed. Teams often merge a replacement while operating both versions for months, which doubles the maintenance surface during the transition.

Reforecast quarterly, but do not rewrite old cohorts to make performance look good. Update future assumptions from observed acceptance hours, rework hours, and carrying demand. Mature cohorts tell you whether early quality gates worked; young cohorts tell you whether current production volume fits the ownership capacity.

Give each change class a unit cost that leadership can use in planning. Divide total generation, acceptance, expected correction, and carrying expense by accepted outcomes, then show the risk reserve beside it. The unit may be an accepted migration, endpoint, workflow, or defect repair, as long as it represents delivered behavior. This prevents a team from improving its apparent economics by splitting one feature into many tiny pull requests.

Do not use the unit cost as an individual performance score. Engineers who accept difficult, high-risk work will appear more expensive, and reviewers will gain an incentive to underreport correction. Use the measure to choose work classes, controls, and staffing. Evaluate people on engineering judgment and outcomes, including the weak generated changes they correctly reject.

Risk classes decide how much review to buy

Review effort should follow the consequence of failure, not whether a human or an agent typed the code. Agent provenance can raise uncertainty, but the data touched and action performed determine the risk class. A generated color change and a generated authorization rule should never share an approval path.

A useful classification has four levels. Low-risk changes affect presentation or reversible internal workflows. Medium-risk changes alter ordinary product behavior with bounded impact. High-risk changes touch authentication, authorization, money, personal data, destructive operations, or core availability. Restricted changes affect regulated decisions, safety, cryptography, or systems where the team lacks qualified review. Your business may use different names; the approval difference matters more than the labels.

Low-risk work may need one reviewer and automated checks. Medium-risk work needs requirement-based tests and a reviewer familiar with the service. High-risk work needs a domain owner, adversarial tests, rollback evidence, and often security or data review. Restricted work may stay human-led until the company can prove that its context controls, evaluation set, and reviewers are adequate. Refusing some automation is a sound economic choice.

NIST's Secure Software Development Framework gives a useful standard outside the AI hype cycle. Practice PW.4.4 tells organizations to verify acquired and third-party components against their requirements throughout the life cycle, including maintenance status and known vulnerabilities. Agent output is not always a third-party component, but the life-cycle principle applies: acceptance is not a permanent clearance. Dependencies and assumptions keep changing.

I argue against mandatory line-by-line human review for every generated patch. The policy sounds safe and is easy to announce, but humans skim large diffs, repeat machines' work, and miss system behavior. Buy stronger evidence instead: smaller changes, explicit requirements, tests that fail for the intended reason, static and dependency checks, isolated execution, and production observation. Reserve deep manual review for risk and ambiguity.

The risk class also sets the contingency. Low-risk cohorts may carry a small rework reserve. High-risk cohorts need explicit incident hours, specialist review, rollback practice, and possibly legal analysis. When leadership asks why agent output has different unit costs, point to the consequence of failure rather than arguing about model intelligence.

Maintenance capacity must be reserved before delivery

A team should reserve maintenance capacity when it approves agent-generated work, not when the backlog becomes painful. Every merge adds an obligation, and production speed can create obligations faster than a small team can absorb them.

Set a capacity ceiling for each owning team. Use its observed time for review, rework, incidents, upgrades, and deletion. If the next cohort pushes expected maintenance above that ceiling, reduce generation volume, narrow the change class, or add an owner. Hiring another agent seat does not repair an ownership shortage.

A ceiling needs a visible queue. Show committed maintenance hours, unplanned correction, aging upgrades, and the reserve still available for new output. When the queue crosses the limit, the team needs authority to pause agent-generated feature intake. Without that authority, the ceiling is a dashboard decoration and the same engineers remain responsible for an impossible plan.

Require an expiration decision for generated experiments and internal tools. At a set review date, the owner promotes the code to a maintained service, replaces it, or deletes it. Temporary code without a date becomes permanent code with weak tests. Budget deletion because safe removal requires usage checks, data retention decisions, and communication with users.

Plan for dependency work separately. Agents often select familiar libraries that solve the immediate prompt, yet each new dependency adds update alerts, compatibility testing, license review, and possible replacement. A repository policy can limit new packages, require a justification, and favor capabilities already operated by the team. This reduces maintenance without forbidding agents.

Give agents maintenance tasks only after the repository carries trustworthy tests and operational context. An agent can update a dependency or repair a defect quickly when it can run the relevant checks and see the service contract. Without that context, it may remove a symptom, change an undocumented behavior, or widen the diff until review costs more than a manual fix.

Track concentration risk too. If one engineer supplies all the context, accepts every patch, and understands every generated subsystem, the company has preserved a bus factor of one behind a faster interface. Rotate reviewers, require handoff notes for high-risk code, and test whether another engineer can diagnose a seeded failure. That exercise gives a better ownership signal than a green test badge.

Review observability as part of acceptance. Generated code that adds a background job, retry loop, cache, or external call needs signals that show success, failure, latency, and backlog. Without those signals, the first maintenance event begins with instrumenting the system under pressure. The few hours saved at merge become the most expensive hours in an incident.

Reserve time for knowledge transfer after the initial owner leaves the immediate task. A second engineer should be able to state the contract, locate the tests, explain the rollback, and identify the dangerous assumptions. If that transfer fails, schedule cleanup while the context remains recent. Waiting six months turns a short explanation into source-code archaeology.

Maintenance reserve is a portfolio decision. New agent output competes with old agent output, human-written code, customer commitments, and infrastructure work for the same people. Protect the reserve in planning. If product leadership consumes it for features every month, record the borrowing as deferred maintenance rather than reporting an imaginary productivity gain.

Agent output is worth it when feedback is cheap

AI-generated code earns its keep where the team can state the requirement, run a fast feedback loop, bound the damage, and assign an owner. It performs well economically on repetitive transformations, test scaffolding that a human verifies, adapters against stable contracts, constrained internal tools, documentation-backed migrations, and small changes in well-tested repositories.

The weak candidates share a pattern: the organization cannot describe success or observe failure. A new domain model with unresolved product rules, a security boundary nobody on the team understands, or a legacy service without tests gives the agent room to produce persuasive guesses. Faster guesses raise the review bill.

Prototype economics also differ from production economics. A disposable prototype can accept weak provenance, light tests, and no upgrade plan if the team truly deletes it. Production code needs ownership and carrying cost from its first merge. Teams get burned when a sales prototype becomes the customer system without a deliberate acceptance pass.

Run a 90-day measurement period before promising a yearly saving. Classify work, capture acceptance time, mark agent-assisted changes, and record rework causes. Keep a comparable sample of ordinary changes inside the same risk classes. At the end, compare total engineering hours per accepted outcome, not commits or lines.

A Team & AI Audit from oleg.is can build this baseline, find where agent output lowers total engineering cost, and identify at least $50,000 a year in savings within five business days or the $5,000 audit is free. The useful deliverable is the operating model: where agents work, which controls apply, who owns the output, and what capacity the 12-month budget reserves.

Do not wait for a perfect attribution system. Add four fields to the next pull request: agent-assisted status, accepting engineer, owning team, and risk class. Those fields make the next month measurable. After twelve months, the code that survives will have named owners, evidence, and a maintenance budget, which is why it will still be cheap enough to keep.