Code Without a Custodian: Governing the Maintenance of AI-Assisted Software

The productivity story around AI-assisted development is easy to tell: faster scaffolding, quicker tests, fewer blank-page delays. The maintenance story is harder. Code produced with a model's help enters a repository with an unusual characteristic: its lineage is often thin. A developer prompted, edited, accepted, and moved on. Months later, the team responsible for uptime may have no reliable way to distinguish generated logic from hand-written logic, no record of the assumptions behind it, and no clear owner beyond 'the team.' That is not a tooling problem alone. It is a governance problem, and it tends to surface exactly when a business can least afford it.

A New Kind of Legacy Code

Legacy code has traditionally meant code written by people who have left, using patterns the current team would not choose. AI-assisted code can become legacy far sooner. It may be syntactically clean, well-commented, and still opaque in intent. A model can produce a plausible implementation of a pricing rule, a permission check, or a data transform without capturing why the business rule exists, which edge cases were considered, or which upstream system made the approach necessary. When the prompt is lost and the reviewer has moved to another project, the code remains, but its context does not.

For US businesses, the risk is compounded by speed. Teams under pressure to ship can treat model output as a draft to be accepted rather than a proposal to be examined. The result is a growing layer of code that passes tests and enters production without a durable record of ownership.

Where Ownership Breaks Down

Ownership gaps appear at three points. The first is provenance: the repository may show who committed the code but not whether a model generated it, which model, which prompt, or which version of an internal library was referenced. The second is review: a human approved the change, but approval may have focused on syntax and tests rather than on business logic, security boundaries, or long-term maintainability. The third is accountability: after the original author changes teams, the code may belong to everyone and therefore to no one.

These gaps are not solved by banning AI assistance. They are solved by making the output legible to the people who will inherit it.

Provenance Is More Than a Comment

A comment such as 'generated with AI' is a start, but it is not provenance. Useful provenance answers practical questions: What was the intended behavior? What inputs and assumptions shaped the implementation? Which human reviewer accepted it, and against what criteria? Was the code generated wholesale, partially generated, or only used as a reference? Where are the tests that encode the expected behavior?

Teams should record this information where maintenance happens—in the pull request, the issue tracker, or the repository's metadata—rather than in a separate document that will drift. The goal is not to create an audit trail for its own sake. The goal is to reduce the time a future engineer spends reconstructing intent.

A Practical Maintenance Framework

A workable framework has five parts.

1. Classify changes by risk. Not all AI-assisted code needs the same scrutiny. A generated utility function and a generated authorization rule carry different consequences. Classify changes by their blast radius: customer data, money movement, access control, regulatory reporting, and core workflows deserve deeper review.

2. Require a human owner at merge. Every change should have a named owner who understands the logic and accepts maintenance responsibility—not just a team name. For high-risk changes, that owner should be someone other than the person who prompted the model.

3. Capture intent alongside code. Require a short design note for material changes: the business rule, the assumptions, the alternatives considered, and the tests that prove behavior. This is especially important for generated code because the model's reasoning is not available later.

4. Review for maintainability, not just correctness. Reviewers should ask whether the code is understandable without the original prompt, whether it duplicates existing logic, whether it introduces dependencies that are hard to upgrade, and whether error handling is explicit. A passing test suite can hide a maintenance burden.

5. Schedule a post-merge review for high-risk code. A second look after deployment can catch logic that looked reasonable in isolation but behaves poorly under real data.

Review Gates That Match Risk

The most common mistake is applying a single review standard to every change. That either slows low-risk work unnecessarily or lets high-risk work through with a cursory check. A tiered model works better. Low-risk changes can use standard peer review plus automated checks. Medium-risk changes should require an owner with domain knowledge and a documented test strategy. High-risk changes should require a second reviewer, a written rationale, and a rollback plan.

This approach also gives teams a way to talk about AI assistance without turning it into a cultural argument. The question is not whether a model was used. The question is whether the resulting code has enough context and accountability to be maintained.

Making Ownership Survive Turnover

Ownership decays when it lives only in a person's head. Teams should maintain a lightweight map of critical code paths and their owners, review it quarterly, and update it during offboarding. AI-assisted code should be included in that map. If a system has no identifiable owner, that is a finding, not a footnote.

Documentation should be tested, too. A short runbook that explains how to change a pricing rule or rotate a credential is more valuable than a long design document no one reads. For generated code, the runbook should state which parts are safe to modify and which depend on external assumptions.

The Metric That Matters

The useful metric is not the percentage of code written by AI. It is the time required for a new engineer to make a safe change to a critical path. If that time is rising, the organization has a maintenance problem regardless of how the code was produced.

AI-assisted development can be a genuine advantage. But it shifts the burden of care onto teams that may never have seen the prompt. Businesses that treat provenance, review, and ownership as part of the development process will keep that burden manageable. Those that do not will discover that the most expensive code is the code no one can explain.