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.
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.
Primary topics explored
- Code health over time
- Legacy modernisation
- Technical debt
- Documentation and knowledge loss
- Deleting code
- Ownership over years
About AI Developer
AI Developer is Book 12 of The Transformed Architecture. It takes the developer as its subject and asks what happens when AI is used broadly in software development: the five developer functions (frame, design, build, prove, steward), the delegation ladder and the Level 4 prohibitions, the stewardship principle (name, understand, revert), verification as the scarce skill, the junior pipeline, adoption and productivity as claims that need evidence, regulation (the AI Act, the Cyber Resilience Act, the Product Liability Directive, NIS 2, DORA, the GDPR), ethics, intellectual property and sovereignty in the toolchain, and the developer as a person, for European enterprises and public authorities.
It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss, AI Blue, AI Purple, AI Operations and AI Leader.
developers at every level, tech leads and engineering managers, architects, platform engineers, site reliability engineers and testers, product owners and designers, leaders who decide on developer tooling, heads of public-sector IT and procurement, works councils and unions, educators, and supervisors and auditors.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 12: Steward the Code: Maintenance, Legacy Modernisation, Technical Debt and Documentation in AI Developer gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Craft of Developing” and is one of 37 drawn from the manuscript.