Steward the Code: Maintenance, Legacy Modernisation, Technical Debt and Documentation

Most software spends most of its life being maintained, not written. This chapter treats what happens to code over years when AI helps to write it, to read it and to change it: how code health holds up, how legacy systems are modernised, what technical debt generated code adds and removes, who can still explain the code in five years, what is deleted, and who owns it. It concerns D5 Steward, the function of owning software over time, and D2 Design, because modernisation and deletion are design decisions about constraints, not mechanical edits. Chapter 11 treated the release; this chapter treats the years after it.

The chapter makes one claim and defends it against the evidence. Code that nobody can explain, change or revert is a liability whoever or whatever wrote it, and AI changes the rate at which such code can be produced more than it changes the duty to prevent it. The stewardship principle of Chapter 4 therefore does not expire at the release. A named developer or team still has to pass Name (the owner is identifiable to those who depend on the code), Understand (the owner can reconstruct what the code does and why without the tool that helped to write it) and Revert (the owner can undo a change outside the pipeline that made it) in the third year, when the author has changed teams and the assistant has changed model.

Figure 12.1: Lifecycle of owned code. AI systems draft, summarise and propose at several stages; the owner, the independent oracle, the yearly review and the revert path stay outside them.

Code health over time

Code health is the property that a codebase can still be changed at acceptable cost and risk. It is not measured by one number, and the first honest statement about AI-assisted codebases is that the evidence is young, mixed and mostly short. The studies below measure different things in different populations, and they do not add up to a single verdict. Table 12.1 sets out what each measured and what limits its reach.

Source	What was measured	Result as reported	Limit
GitClear, 2025 (177, GitClear, 2025)	Share of 211 million changed lines, authored January 2020 to December 2024, classified by the vendor as copy/pasted (its "cloned"), moved (which the page equates with refactoring) and so on	Copy/pasted lines 12.3 per cent in 2024 against 8.3 per cent in 2021; moved lines under 10 per cent in 2024 against 25 per cent in 2021	Vendor research; the page as read does not say how lines were attributed to AI assistance and states no limitations
He and others, 2026 (201, He et al., 2026)	Difference-in-differences of open-source GitHub projects that adopted Cursor against 1,380 matched projects that did not	Lines added rose 3 to 5 times in the first month and the gain faded within two months; static analysis warnings rose 30.3 per cent and code complexity 41.6 per cent; duplicate line density showed no significant effect	Observational; adopters chose the tool; open-source projects; warnings and cognitive complexity as measured by one static analysis tool
Borg and others, 2025 (200, Borg et al., 2025)	Randomised trial in which 75 developers evolved, without AI, code that others had written with or without an assistant	No significant difference in completion time or in code quality (a smell-based code health metric); benefits or harms at most small and uncertain	One Java web application and one feature; fewer completed tasks than planned (151 of 256), so only large effects were detectable; about 48 per cent of participants self-reported that they did not finish in one sitting
DORA programme, 2024 (221, Google Cloud, 2024)	Annual survey associations with AI adoption	Adoption accompanied by an estimated 1.5 per cent lower throughput and 7.2 per cent lower stability; a 25 per cent increase in adoption associated with 7.5 per cent higher documentation quality, 3.4 per cent higher code quality and 3.1 per cent higher code review speed	Associations from self-reported survey data, not causal effects; survey size not stated on the page read, nor the adoption increase to which the throughput and stability estimates refer
DORA programme, 2025 (42, Harvey & DeBellis, 2025)	Survey of nearly 5,000 technology professionals	A positive relationship of AI adoption with throughput, and still a negative one with stability; the report's reading is that AI amplifies what is already there	Survey; the report links more change volume to instability where controls such as automated testing, version control practice and fast feedback loops are not robust

Table 12.1: Evidence on code health in AI-assisted codebases, with what each source measured and where it stops.

What the studies measured

The GitClear report is the source most often quoted for the claim that AI degrades code. Read closely, it reports shifts in how changed lines are classified over five years: less moved code, which the vendor treats as a proxy for reuse, and more copy/pasted code. The shift coincides with the spread of assistants. The page read for this book does not explain how the vendor attributed lines to AI assistance, so it supports the statement that classification patterns changed while assistants spread and does not support the statement that assistants caused the change. The report is vendor research, and the series treats it as a signal worth testing in one's own repositories, not as a finding.

The Cursor study is stronger on design and narrower in reach. By comparing adopters with matched non-adopters over time, it separates adoption from the general drift of open-source projects. Its result has two parts that must be read together. The velocity gain is large and transient. The rise in static analysis warnings and in cognitive complexity persists, and the authors' panel models connect the accumulated complexity to a later slowdown in velocity (201, He et al., 2026). The projects are open-source, the adopters chose the tool, and the quality measures come from one analysis tool, so an enterprise with a different codebase and different review habits cannot read its own future from the figures. What the study does show is that a short-term velocity gain and a long-term maintenance cost can both be real in the same project.

The Borg trial answers a different question: does code written with an assistant cost the next maintainer more? In its second phase, developers who worked without AI on solutions produced with or without an assistant were not measurably slower or worse. The authors conclude that they found no systematic maintainability advantage or disadvantage within the scope of their tasks and measures, and they flag code bloat and a loss of understanding as risks for later work (200, Borg et al., 2025). The design is strong because of the randomisation, and the scope is small: one application, one feature, one sitting for most participants. It speaks to the question whether a competent developer can maintain code that an assistant helped to write. It says nothing about the third year of a codebase that nobody understands.

The DORA material adds the organisational view. The 2024 figures associate AI adoption with lower delivery stability and, for documentation and code review speed, with modest gains; the 2025 report associates adoption with higher throughput and still lower stability, and reads the pattern as amplification of the surrounding practice (221, Google Cloud, 2024) and (42, Harvey & DeBellis, 2025). The programme's 2024 report page states that adoption negatively affects delivery stability and throughput and that fundamentals such as small batch sizes and robust testing remain crucial (216, Google Cloud, 2024).

What the evidence supports

Three statements survive the limits. First, observable: in at least one observational study, assistant adoption was followed by a persistent rise in static-analysis warnings and complexity after a transient rise in output (201, He et al., 2026). Second, observable: in one randomised trial, code written with an assistant was not measurably harder for the next developer to evolve in a small task (200, Borg et al., 2025). Third, the book's own conclusion: the two results are compatible, because the first concerns accumulation across a project and the second concerns a single hand-over. Debt that no single change shows can still accumulate when each change is accepted on its own merits and nobody owns the sum. The remedy is not to stop using assistants. It is to measure the sum, which means a code-health measure that the team reads over time, owned by a named person, with a threshold that triggers action. Chapter 9 describes the independent checks that a single change passes; this chapter asks what watches the trend across all of them.

Legacy modernisation

Legacy code is code that earns money or serves residents today and that nobody wants to change. Its defining property is not age but the loss of the people and tests that made change safe. Both organisations have it in quantity. Nordvik Region inherited nine case and registry systems in the 2024 reorganisation, five of them on the same PL/SQL and Java 8 stack, and its case-management system SVC-NR-003 is about 1.1 million lines of Java and PL/SQL on a vendor product whose support ends in 2033. Hansa Mutual's policy administration platform SVC-HM-003 is about 6.5 million lines of COBOL and PL/I written between 1989 and 2008, maintained by twelve people.

What the public reports show

Public reports of AI-assisted migration are real, uneven and mostly self-reported. They are worth reading for the pattern they share more than for their totals.

Google has published an experience report on LLM-assisted migrations in its monorepo. In a migration that widened 32-bit identifiers, 80 per cent of the code modifications in the landed changelists were fully AI-authored, measured by a per-character comparison of the generated version with the committed one; engineers reported that the total time was reduced by an estimated 50 per cent compared with a similar exercise without the tooling, and that they still had to revert some model changes that were incorrect or unnecessary. In a test-framework migration, the pipeline migrated 5,359 files and changed more than 149,000 lines in three months, and about 87 per cent of the AI-generated code was committed without change. The authors write that the bottleneck was the speed at which engineers could review, and that they limited the weekly volume to avoid overwhelming reviewers (267, Nikolov et al., 2025). The authors call the paper an experience report and make no comparison with other approaches. The time estimates come from the engineers who did the work.

Amazon reported that its internal use of Q Developer's Java transformation moved tens of thousands of production applications from Java 8 or 11 to Java 17, and estimated the saving at over 4,500 years of development work. The vendor's post says the time estimate rests on the number of dependencies migrated, calls the estimates conservative, and does not describe an independent audit (268, Arisoy Cholkar, 2024). Morgan Stanley, according to trade press, reports that its in-house platform has modernised more than 17 million lines of COBOL, Natural and Perl code, with a stated saving of over one million hours of manual coding and, in the words of its technology executive, full human oversight. The same report carries Gartner's warning that more than 70 per cent of mainframe migrations started in 2026 will fail because of overestimation of generative AI's ability (269, Holland, 2026). The figures are the organisations' own and the warning is an analyst's forecast, which this book reports and does not adopt.

The shared pattern is more useful than the totals. In each report the work was bounded, mechanical and repeated: a type widening, a framework replacement, a language-level upgrade, each with a tooling pipeline that built and tested the result and sent failures back for another attempt. Each report names human review as the limit on speed. And in each, the organisation could say what a correct result looked like before the tool started, because it had builds, tests and a definition of done for the migration. None of the three reports is an account of translating an undocumented, untested system whose behaviour nobody can state. For that case the public record offered here is thin, and the safest reading of the thinness is that the hard part of legacy modernisation was never the typing.

What a migration needs first

Naur argued in 1985 that a program is not its source text but a theory that the programmers hold, of how the program relates to the world it serves and why it is built as it is; he concluded that reviving a program from its documentation alone is strictly impossible, because the documentation does not carry the theory (181, Naur, 1985). The argument is an essay, not a finding, and it has an uncomfortable consequence for AI-assisted legacy work. A tool can summarise 6.5 million lines of COBOL into readable prose. It cannot supply the reasons that the last twelve people hold. If a migration is planned from the summary, the first discovery of what the old system did that nobody wrote down will be made in production.

Five things therefore come before any generated translation, and they are the book's own conclusion from the evidence above and from the stewardship principle.

1. An owner by name. A migration with a department as its owner has no one who can pass Name. OWN-HM-2030-00, the audit of August 2030, found that the COBOL estate was owned by "Policy Systems" as a department and not by a person. The first act is to list the estate by named owner, which the post-incident review of INC-HM-2029-0207 already recommended and nobody completed.
2. An oracle that does not come from the generator. The behaviour of the old system is the specification. Characterisation tests, recorded production inputs and outputs, and parallel runs of old and new are the oracle, and they are written or captured by someone other than the tool that produces the translation (Chapter 9). A test suite that the assistant generates from the translated code proves that the translation agrees with itself.
3. A scope in which the tool may act. Both organisations' delegation profiles (DLG-NR-DEV-01, DLG-HM-DEV-01) set migrate at Level 0 Advisory, the lowest rung of the ladder defined in Chapter 4: the tool reads and summarises legacy code for a developer and does not produce the migration. A move to Level 1 or Level 2 for a defined class, such as a mechanical upgrade with a full build-and-test pipeline, is a decision recorded under the profile, per class, and never a general permission.
4. A way back. The Revert test applies to a migration as to a release (Chapter 11): the old system keeps running in parallel, or can be restored, until the new one has passed the oracle over a period that includes the peaks, for instance a quarter-end settlement run. AI Operations, Chapters 10 and 19, treat restore and the evidence age of a restore test (170, Nordqvist, 2026).
5. The knowledge, captured before it retires. Section "Documentation and knowledge loss" below treats this; it is first on the schedule because it is the only item that cannot be recovered later.

An organisation that has none of the five will find that the tool makes the first translated module appear quickly and the first unexplained defect not long after.

Technical debt

Technical debt is the accumulated cost of choices that made change easier then and harder now. The metaphor is useful when it keeps its two halves: borrowed time and a repayment that someone owns. Generated code changes both halves, in opposite directions.

It adds debt in three ways that the evidence of the first section supports in part and the book's reasoning supplies in part. It adds volume: when a change is cheap to produce, more of them are produced, and Google's migration report names reviewer capacity, not generation, as the limit (267, Nikolov et al., 2025). It adds local plausibility: the generated function passes its test and reads well, and the cost shows only in the sum, as the rise in complexity in the Cursor study suggests (201, He et al., 2026). And it adds orphaned intent: a function exists because a prompt asked for it, and the prompt, if kept at all, is not the reason. Wright's chapter on deprecation in the Google engineering book opens from the premise that code is a liability, not an asset; its value is in the function it delivers, and unneeded code costs maintenance (272, Wright, 2020). The premise is a practitioner's, not a measurement, but it is the premise on which the rest of this section rests: producing code faster raises the liability faster unless something removes it.

It also removes debt, and the public reports show where. The mechanical class (type widening, API upgrades, test-framework replacement, version bumps) is repayment that teams postponed for years because the work was tedious and risky in proportion to the volume. Google's reports show it done at a scale and speed that manual effort would not reach (267, Nikolov et al., 2025). Hansa Mutual's one Level 3 Bounded class, patch-level dependency updates outside the security-critical and payment paths under MND-HM-DEV-01, is the same idea in its most cautious form: the human approves the class and its conditions, the pipeline checks each update, and the update is reversible.

The practical rule that follows is to track debt as a flow, not a stock. A team that knows how many warnings, how much complexity and how many unowned modules it carried a quarter ago, and how many it carries now, can see whether the assistant's net effect on its codebase is repayment or borrowing. A team that knows only its acceptance rate cannot. Chapter 20 returns to why acceptance rate and lines of code mislead.

Documentation and knowledge loss

Documentation has three jobs in a long-lived system: to say what the code does, to say why it is as it is, and to say what to do when it breaks. AI is useful for the first, weaker on the second and, for the third, depends on the second.

The first job is the one where assistants help today. A model reading a module can draft a summary, a comment, a README, an API description; in both organisations' profiles the work class document sits at Level 2 Supervised, drafted by the tool and checked by the author before merge. The 2024 DORA report associates a 25 per cent increase in AI adoption with a 7.5 per cent increase in documentation quality, a survey association with the limits noted above (221, Google Cloud, 2024). The risk that goes with the benefit is that a generated description of the code is derived from the code. It restates what the code does, including its defects, in fluent prose, and it cannot reveal that the code does something other than what was intended, because the intention is not in the code.

The second job, the reason, is what Naur calls the theory, and it is carried by people and by decision records. The first volume of the series treats the Architecture Decision Record (ADR) as the short, numbered, immutable record beside the code that keeps rationale alive after its authors have moved on (Architecture as Code (Chapter 4)) (161, Nordqvist, 2025). The habit extends to AI-assisted work: where an AI-assisted decision has no traceable human rationale, the first volume's closing advice is to write one, retrospectively if need be (Architecture as Code (Chapter 27)) (161, Nordqvist, 2025). For stewardship the rule is concrete. When an assistant helps to choose between two designs, the ADR records the options, the choice and who made it; when a module is generated from a specification, the specification record is kept beside the module; and the prompt is not the record. A prompt shows what was asked, not why the answer was accepted.

The third job depends on the second, and the series' operations volume treats it from the operator's side: runbooks, problem records and the post-incident review as the carriers of knowledge, with the warning that skills erode when a tool does most of the work (AI Operations, Chapters 12 and 26) (170, Nordqvist, 2026). Bainbridge's classic observation applies to the developer: the more reliably a system is automated, the more the person who remains must still know in the rare case that it fails, and the less practice that person gets (56, Bainbridge, 1983).

Knowledge loss is therefore a concrete risk with a date. At Hansa Mutual five of the twelve COBOL and PL/I engineers are within eight years of retirement. The legacy explainer HM-DEV-003 is in a pilot at Level 0 Advisory with four of the twelve. It can help in two ways, and only one is safe. It can help a newcomer read code, and a newcomer who checks the explanation against the code and against a colleague learns faster than one who has only the code. It cannot replace the conversations in which Ralf Hauser explains why the batch order is what it is. The sensible use of the pilot is to record such conversations, with the engineers' agreement and the Betriebsrat's terms (Chapter 22), and to attach the result to the module as a decision record. A copy of a person's reasons is a different artefact from a summary of the code, and only the first is the theory.

Avelino and others studied how many people a project can lose before it is in trouble, estimating the "truck factor" of 133 popular GitHub projects, and found that most depend on very few developers: 65 per cent had a truck factor of two or less (270, Avelino et al., 2016). Open-source projects are not a proxy for an insurer's mainframe, and the study is a reminder, not a forecast. It makes the question operational: for each module, how many people can explain it, and what is the date on which that number falls to one?

Deleting code

Deletion is the neglected act of stewardship. Adding code is visible and rewarded; removing it is invisible and risky, and in a world where more code is produced faster, it becomes the main counterweight.

Google's engineers describe the case for deletion plainly in their account of the Sensenmann project: dead code keeps costing, because the test system keeps running its tests and people doing large-scale migrations keep updating code that no one runs. The project builds a dependency graph from the build system, uses a liveness signal from logs written when internal binaries run, proposes deletion changes to the owners for review, and keeps a blocklist for code that must stay, for instance because it serves as an example of an API. The post reports more than 1,000 deletion changes a week and nearly 5 per cent of all C++ at Google deleted so far (271, Norman, 2023). The figures are the company's own. The design is what transfers: a signal of use, a proposal that a human reviews, an exception list and a way back.

Wright adds the other side of the argument. Deprecation is hard because users depend on behaviour that merely happens to work, because the cost of keeping a system is hard to see, and because abandoned systems that still have users need an explicit owner whose main goal is removal (272, Wright, 2020). Both points matter once AI is involved. An agent can propose a deletion quickly; whether the deletion is safe depends on a liveness signal and on a person who accepts the consequences. Deletion changes the state of the codebase, and in a production-adjacent system it can be irreversible in effect even if the commit can be reverted, for instance when it removes the only code that reads an old data format. The Level 4 prohibitions of Chapter 4 apply: no agent deletes data or code on the production path without a gate that it cannot alter and a human who named the change.

Nordvik Region has a further constraint that is not technical. Its public-access and archives rules mean that source code and design documents can be requested and must be kept as records. Deleting code from the live tree is not the same as disposing of the record. The Region's practice is therefore to retire code by tagging a final release and moving the repository to an archive, with the archivist's agreement, and the decision goes in the ownership record. How the rules apply to prompts to coding tools is an open question for the Region's archivist and legal counsel.

Ownership over years

Ownership is the property that turns all of the above from advice into practice. The empirical literature on it is older than AI and is still the best available. Bird and others studied Windows Vista and Windows 7 and found that ownership measures, such as the number of low-expertise contributors to a component and the proportion of ownership held by its top owner, were related to both pre-release faults and post-release failures (180, Bird et al., 2011). The study is correlational and concerns one company's operating system, not AI. It is nonetheless the evidence for a design choice that this book makes: components should have a clear principal owner, and changes by people with little experience of a component deserve more scrutiny.

The code-ownership record OWN-* is the artefact. It names the owner and a deputy, says what the module is and does, where its tests and decisions are, how it is reverted, when it will next be reviewed and under what conditions it is retired. It also records, as claims with evidence age, the facts on which the owner's answer to Understand and Revert depends: when the owner last explained the module without the tool, and when the revert path was last tested. A record that cannot say when it was last verified is a label and not a record.

An ownership record

The first record belongs to a module of Nordvik Region's citizen portal SVC-NR-002, the adapter that calls the national population register through the Region's API gateway. The record is illustrative, in the form of the repository inventory OWN-NR-2030-00 that found 31 per cent of the Region's 96 repositories without a living owner.

id: OWN-NR-2030-04
status: active
subject:
  service: SVC-NR-002
  repository: portal-register-adapter
  scope: Adapter between the citizen portal and the gateway to the national population register
  size: approx. 18,000 lines of TypeScript and Java
owner:
  name: Anders Falk
  role: ROLE-NR-TCL-01
  team: integration and data team
  since: 2030-10-14
deputy:
  status: vacant
  must_be_named_by: 2030-12-15
provenance:
  generated_share: not measured
  assistant_use: NR-DEV-001 pilot, completion and chat only
  provenance_record: none yet
verification:
  regression_pack: portal pack, maintained by Saga Edvardsson
  oracle_independent_of_generator: true
  last_full_run: 2030-10-09
decisions: [ADR-NR-0017]
revert:
  method: redeploy previous tagged release through the GitOps pipeline
  last_tested: 2030-10-09
  result: passed
understand_test:
  last_demonstrated: 2030-10-16
  demonstrated_without_assistant: true
support:
  expected_use_until: 2034-12-31
  retirement_condition: replaced by the national register service
review:
  next_due: 2031-10-14
  triggers: [owner leaves, model change in NR-DEV-001, change of register interface]
decision_record: AIDR-1112

The record is short on purpose. The vacant deputy is a finding, not an omission: the integration team is small, and a record with no deputy shows the truck factor of one in the open. The generated_share: not measured line is an honest entry of the kind AI Operations teaches for resilience claims, where "not tested" is a legitimate entry and an unmeasured quantity is not replaced by an estimate (AI Operations, Chapter 19) (170, Nordqvist, 2026).

The second record concerns Hansa Mutual's COBOL settlement module behind SVC-HM-004, where the duplicated settlements of INC-HM-2029-0207 happened. It shows what the first listing by named owner looks like when it is done.

id: OWN-HM-2030-07
status: active
subject:
  service: SVC-HM-004
  platform: SVC-HM-003
  scope: COBOL settlement module with quarter-end batch peaks
  language: COBOL and JCL
owner:
  name: Ralf Hauser
  role: ROLE-HM-DEV-01
  since: 2030-10-21
deputy:
  name: Ewelina Maj
  role: ROLE-HM-QA-01
  deputy_for: oracle and regression suite, not code changes
second_approver_rule: a second developer outside the author's pair for any settlement change
verification:
  oracle: recorded production inputs and outputs and parallel run, maintained by Ewelina Maj
  oracle_independent_of_generator: true
  coverage_claim: settlement run of quarter-end 2030-09, scope full, result matches, date 2030-10-05
revert:
  method: restore previous load module and rerun the batch from the checkpoint
  last_tested: 2030-09-30
  result: passed
knowledge:
  recorded_conversations: 0
  target: first three by 2030-12-31
  legacy_explainer: HM-DEV-003, Level 0 Advisory, pilot
review:
  next_due: 2031-04-21
  triggers: [owner or deputy leaves, change to settlement rules, quarter-end]
decision_record: AIDR-1162

Two lines carry the lesson of the earlier incident. The deputy is a tester and not a second COBOL developer, and the record says so, because the deputy for the oracle and the deputy for the code are different roles; the second-approver rule closes the gap that allowed a single reviewer, who was also the only other person who knew the module, to approve the change that paid 312 claims twice.

Practical guide: Writing an ownership record and running a yearly ownership review

Purpose. Give every repository or module a named owner who can pass Name, Understand and Revert, and check once a year that the answer is still true.

Roles. The tech lead (writes and owns the record); the engineering manager (accountable for the inventory and for assigning owners where none exists); the platform engineer (provides the catalogue and the revert test); the tester or quality engineer (owns the oracle); the architect (consulted on retirement and modernisation); the public-sector IT lead or archivist where records law applies; the works council where the record could be used to evaluate named people (see the note below).

Inputs. The repository or service catalogue; the CODEOWNERS files; the personnel list of the team; the last revert test; the ADRs; the incident records of the year; any provenance record for generated code (Chapter 10).

Steps.

1. List every repository and service and compare the named owner with the current staff list. Mark each as owned, owner left, owner changed team, or a department as owner. This produces the inventory (OWN-*-00).
2. For each unowned item, decide whether to assign an owner, to retire it, or to accept its status in writing for a stated period. Do not leave "team" or "department" as an owner.
3. For each item that stays, write the record: owner, deputy, scope, tests and who owns the oracle, decisions, revert method, support period and retirement condition. Name a deputy for the code and, where different, for the oracle.
4. Test Understand: ask the owner to explain a recent change to a colleague without the assistant and note the date. Test Revert: perform the documented rollback in a non-production environment and note the date and result.
5. Set the review trigger: a date at most a year ahead and the events that bring it forward (owner leaves, model or tool change, change of interface or rules, a production incident).
6. At the yearly review, re-run steps 1 to 4 for items whose evidence has expired, and propose retirement for anything whose usage signal has fallen to zero.
7. Report the inventory to the engineering manager and the leadership as counts with dates, not as a percentage without a date.

Result. A set of OWN-* records in version control, with the inventory as OWN-*-00. The record is a tool for the owner and the team. Using it to rank or appraise named developers, for example by counting the modules a person owns, is a monitoring use that the works agreements of Chapter 22 may cover, and it is outside the purpose stated here.

Support periods and the law

Some owners have a legal reason for the span. Regulation (EU) 2024/2847, the Cyber Resilience Act, requires a manufacturer of a product with digital elements to ensure that vulnerabilities are handled effectively for the support period (Article 13(8)). It sets the support period to reflect the time the product is expected to be in use and at least five years, or the expected use time if shorter. It requires that each security update made available during the support period remain available for at least ten years or the rest of the support period, whichever is longer (Article 13(9)), and that the manufacturer document the cybersecurity aspects of the product, including the vulnerabilities it becomes aware of (Article 13(7)). The Regulation applies from 11 December 2027 (Article 71) (242, European Union, 2024). Directive (EU) 2022/2555, NIS 2, lists among the risk-management measures of essential and important entities security in the acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure (Article 21(2)(e)) (3, European Union, 2022). As an architectural implication, an organisation that publishes software or sells it as part of a product has a duty that is measured in years and that presupposes someone who owns the code for that long. Whether Hansa Mutual's mobile claims app and broker plug-in, or Nordvik Region's published components, fall within the Regulation, and whether code built only for an organisation's own use does, are questions Chapter 24 takes up. This chapter assumes no answer.

The moral crumple zone belongs at the end of the section, as a warning against the wrong kind of ownership. Elish described how responsibility for a system's failure is attributed to the human operator nearest to it, who had limited control over the system's behaviour (49, Elish, 2019). An owner named in a record who cannot explain or revert the module, and whose only practical option is to accept what the tool proposes, is the developer's version of that pattern. The record's fields for the Understand and Revert tests exist to make sure that the name on it is a person who can act.

Conclusions for stewardship

The evidence supports a modest and checkable position. Observable: AI assistance has been followed in at least one large observational study by persistent growth in complexity and warnings, and in one randomised trial it left the next maintainer's task unchanged (201, He et al., 2026) and (200, Borg et al., 2025). Observable: organisations with strong tests and build pipelines have completed large mechanical migrations with AI at reported savings, bounded by review capacity (267, Nikolov et al., 2025). Expected, on the strength of the reports above and the vendors' continued investment: AI-assisted migration of mechanical classes will become routine in well-tested codebases, and the programmes that fail will fail on missing owners, missing oracles and missing knowledge more often than on the quality of the translation. Speculation: that systems will maintain and modernise themselves without a named steward; no study read for this chapter supports it, and the Level 4 prohibitions of Chapter 4 would rule out the parts that touch production, security-critical paths and the agent's own gates. The author's projections for the profession are reserved for Chapters 29 and 33.

Across the usage modes

The table sets the maintenance subjects of this chapter against the usage modes, with the highest degree of delegation the two organisations' profiles allow today. A ceiling is not a licence.

Usage mode	What it does in stewardship	Highest degree in the profiles	Condition
Mode 0 Ambient AI	Completion in the IDE while a developer edits old code	Level 1 Assisted (generate)	The developer reads every suggestion; at Nordvik the ambient feature was recorded retrospectively (AIDR-1102)
Mode 1 Conversational assistants	Explaining code, drafting comments and README text	Level 2 Supervised (document)	Approved enterprise tier; not for special-category data, credentials or the benefits-triage rules at Nordvik
Mode 2 Embedded assistants	Refactoring suggestions and test drafts in the editor	Level 1 Assisted at Nordvik; Level 2 Supervised for refactor at Hansa	A named reviewer; the oracle for the change is written by someone other than its author
Mode 3 Agentic work tools	Multi-file refactors and dependency updates as pull requests in a sandbox	Level 2 Supervised at Hansa; one Level 3 Bounded class (patch-level dependency updates, MND-HM-DEV-01); at Nordvik the platform team only, never applying change	No merge to the protected branch by the agent; pipeline checks the agent cannot alter
Mode 4 AI applications	Test-drafting assistant HM-DEV-002; legacy explainer HM-DEV-003	Level 1 Assisted for test drafts; Level 0 Advisory for the explainer	The explainer reads code for a developer and does not produce the migration
Mode 5 Autonomous production agents	None in either profile for code	Not allowed for code change	No coding agent merges or deploys on its own; Level 4 is never used for a change to production without a gate that the change cannot alter, for security-critical code without a named reviewer, or for an irreversible action on production data

Table 12.2: Stewardship of code across the usage modes, with the highest degree of delegation in the two organisations' profiles.

For the work class migrate, both profiles keep Level 0 Advisory. The table shows why: the tools are being used for reading, drafting and bounded mechanical change, and the evidence for translation of systems with undocumented behaviour is thin.

Nordvik Region and Hansa Mutual

Nordvik Region. The Region's problem is breadth and capacity. It has about 25 people who write code as their main work, 96 repositories, nine inherited systems and a case platform whose vendor support ends in 2033; the 2030 budget carries EUR 1.2 million for "assessment of modernisation", unallocated. The inventory of July 2030 (OWN-NR-2030-00) found that 31 per cent of the repositories had an owner who had left the Region or changed team. On 2030-10-14, the head of Applications and Integration, Gunilla Roos, took the decision AIDR-1112 (illustrative): every repository gets a named owner and a deputy by the end of December 2030, or is proposed for archive; the first records are written for the portal and the case platform; and the modernisation assessment is not started until the regression packs for the benefits workflow and the portal, which are the only ones that exist, have been extended to the registry systems that are to be assessed. Linnea Sjöberg, who has 17 years on the case platform and is the keeper of its history, is asked to record the reasons behind the customisations of SVC-NR-003 as ADRs before any assistant is asked to summarise the code, and she is given the time to do so. The Region's stance on tools is unchanged: migrate stays at Level 0 Advisory, and the Region keeps no autonomous production agents. Its public-access and archives rules shape the retirement path, as described above.

Hansa Mutual. The Group's problem is concentration of knowledge. Twelve people maintain 6.5 million lines of COBOL and PL/I, five are within eight years of retirement, and in the audit of August 2030, 14 of 410 services had no active owner and the COBOL estate was owned by a department (OWN-HM-2030-00). On 2030-10-21, the head of Group Application Development, Dr. Philipp Reinhardt, took the decision AIDR-1162 (illustrative): the COBOL estate is listed by named owner and deputy by the end of January 2031, with the settlement module first (OWN-HM-2030-07); the second-approver rule is extended to all production changes in the estate; the pilot of the legacy explainer HM-DEV-003 continues at Level 0 Advisory with its four users; and three recorded conversations with senior engineers, subject to the terms agreed with the Betriebsrat, are to be attached to modules by the end of December. The Group's dependency-update class under MND-HM-DEV-01 is the one place where the tool acts without per-change approval. It is not extended to the estate. Hansa's DORA obligations for the EU entities (register of information, ICT risk, change management) frame the migration decision, and the Cyber Resilience Act question for the mobile app and broker plug-in is left to Chapter 24.

Both organisations arrive at the same sequence from different directions: owner first, oracle second, knowledge captured third, and translation last.

Summary

This chapter concerned D5 Steward and D2 Design: owning software over time and designing the constraints for modernisation and deletion. The evidence on code health in AI-assisted codebases is young and mixed. One observational study found a transient rise in output and a persistent rise in warnings and complexity; one randomised trial found no measurable extra cost for the next maintainer in a small task; vendor and survey material adds associations that cannot carry causal claims. The book's conclusion is that debt accumulates in the sum of changes, so the sum needs an owner and a measure.

Public reports of AI-assisted legacy migration describe bounded, mechanical, well-tested work whose speed is limited by human review, with savings that are the organisations' own estimates. They do not describe the translation of undocumented systems whose behaviour nobody can state. Before such a migration, an organisation needs a named owner, an oracle independent of the generator, a defined scope for the tool, a way back and the captured knowledge of the people who hold the theory of the system. Documentation derived from code is useful and cannot replace the reasons; ADRs and recorded conversations are the carriers of those. Deletion is the counterweight to cheap generation, and it works when a signal of use, a human reviewer, an exception list and a way back are in place.

Ownership is the artefact that makes this practical. The OWN-* record names the owner and deputy, the oracle, the revert path and the evidence age of the Understand and Revert tests, and the yearly review keeps the name attached to a person who can act. Three things for the reader to do: run the inventory and report counts with dates; write one OWN-* record for the module whose loss of its last explainer would hurt most; and put the first recorded conversation with that explainer on the calendar this month. Chapter 13 turns to the people who inherit this code, the junior developers, and to the question how they learn a craft whose entry-level tasks the tools now perform.

Sources

1. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union, 27 December 2022. (3, European Union, 2022)
2. European Parliament and Council of the European Union. Regulation (EU) 2024/2847 of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). Official Journal of the European Union, 20 November 2024. (242, European Union, 2024)
3. GitClear (2025). AI Copilot Code Quality: 2025 Look Back at 12 Months of Data. (177, GitClear, 2025)
4. Google Cloud, DORA (2024). Accelerate State of DevOps Report 2024. DevOps Research and Assessment (DORA) programme. (216, Google Cloud, 2024)
5. Harvey, N. & DeBellis, D. (2025). Announcing the 2025 DORA report: State of AI-assisted Software Development. Google Cloud Blog, 23 September 2025. (42, Harvey & DeBellis, 2025)
6. Elish, M. C. (2019). Moral Crumple Zones: Cautionary Tales in Human-Robot Interaction. Engaging Science, Technology, and Society 5, 40-60. (49, Elish, 2019)
7. Bainbridge, L. (1983). Ironies of Automation. Automatica 19(6), 775-779. (56, Bainbridge, 1983)
8. Nordqvist, G. (2025). Architecture as Code. The Architecture as Code Series, Book 1, published at aac.geon.se. (161, Nordqvist, 2025)
9. Nordqvist, G. (2026). AI Operations: How Artificial Intelligence Transforms IT Operations in European Enterprises and Public Authorities. The Architecture as Code Series, Book 10, published at aiops.geon.se. (170, Nordqvist, 2026)
10. Borg, M., Hewett, D., Hagatulah, N., Couderc, N., Söderberg, E., Graham, D., Kini, U. & Farley, D. (2025). Echoes of AI: Investigating the Downstream Effects of AI Assistants on Software Maintainability. arXiv:2507.00788. (200, Borg et al., 2025)
11. He, H., Miller, C., Agarwal, S., Kästner, C. & Vasilescu, B. (2026). Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects. MSR '26. DOI: 10.1145/3793302.3793349. (201, He et al., 2026)
12. Google Cloud, DORA (2024). Announcing the 2024 DORA report. Google Cloud Blog, October 2024. (221, Google Cloud, 2024)
13. Nikolov, S., Codecasa, D., Sjovall, A., Tabachnyk, M., Chandra, S., Taneja, S. & Ziftci, C. (2025). How is Google using AI for internal code migrations? arXiv:2501.06972. (267, Nikolov et al., 2025)
14. Arisoy Cholkar, A. (2024). Amazon Q Developer just reached a $260 million dollar milestone. AWS DevOps & Developer Productivity Blog, 1 August 2024. (268, Arisoy Cholkar, 2024)
15. Holland, M. (2026). AI shifts mainframe modernization strategy. CIO Dive, 28 July 2026. (269, Holland, 2026)
16. Naur, P. (1985). Programming as Theory Building. Microprocessing and Microprogramming 15(5), 253-261. DOI: 10.1016/0165-6074(85)90032-8. (181, Naur, 1985)
17. Bird, C., Nagappan, N., Murphy, B., Gall, H. & Devanbu, P. (2011). Don't Touch My Code! Examining the Effects of Ownership on Software Quality. ESEC/FSE 2011. (180, Bird et al., 2011)
18. Avelino, G., Passos, L., Hora, A. & Valente, M. T. (2016). A Novel Approach for Estimating Truck Factors. ICPC 2016. DOI: 10.1109/ICPC.2016.7503718. (270, Avelino et al., 2016)
19. Norman, P. (2023). Sensenmann: Code Deletion at Scale. Google Testing Blog, 28 April 2023. (271, Norman, 2023)
20. Wright, H. (2020). Deprecation. Chapter 15 in Winters, T., Manshreck, T. & Wright, H. (eds), Software Engineering at Google. O'Reilly Media. (272, Wright, 2020)