A change that has been written, reviewed and tested has still not been released. Between the merged pull request and the citizen or policyholder who meets the result lies the release path: the pipeline, the gates, the rollout and the person who can undo it. This chapter treats that path as the place where D5 Steward is exercised hardest, because it is where the volume of generated code meets the organisation's capacity to absorb change. It draws on D4 Prove, because a gate is only worth the independence of its oracle, and on D3 Build, because the number and size of the changes that arrive are set by how code is made.
The chapter makes one claim. When AI takes part in a change, the release path must contain at least one gate that the change cannot alter, and a named owner who can revert the change from outside the pipeline that shipped it. The first half is the corollary of the stewardship principle of Chapter 4 (the test oracle must be independent of the generator) applied to the last step before production; the second is its Revert test. The chapter then asks what the key metrics of the DevOps Research and Assessment (DORA) programme (four in the 2014-2023 formulation, five in the current guide) can say under AI, how "you build it, you run it" survives a rise in change volume, and what a change record CHG-* looks like when it carries its own evidence. "DORA" without qualification means Regulation (EU) 2022/2554, as everywhere in this book.
A delivery pipeline is the automated sequence that turns a commit into a running change. Architecture as Code (Chapters 10, 13 and 15A) made it the place where policy as code, tests and evidence as code are enforced, so that a failing control fails the build (161, Nordqvist, 2025). AI Platform and Security, Chapter 19, added that containment keeps control artefacts outside an agent's reach, with a stop path outside the system it stops (163, Nordqvist, 2026). Both conclusions concern where a control lives, which is the subject of this chapter.
Primary topics explored
- Release practice when the diffs multiply
- Progressive delivery
- The gate a change cannot alter
- Change risk and approval
- The key metrics and their limits
- You build it, you run it
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 11: Steward the Release: CI/CD, Change and Operating What You Build 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.