Chapters 1 to 30 built two development organisations record by record, and Chapter 31 follows named developers through the year in which the records were made. This chapter turns the records into conclusions for each organisation, a twelve-month plan from September 2031 to August 2032, the decisions that fall to leadership, ten measures by which the book's own claims can be judged locally, and the risks. It concerns all five functions of the developer loop: D1 Frame (what the specification and the acceptance criteria say before anything is generated), D2 Design (the constraints and the ceilings that bound the tools), D3 Build (how far the tools are allowed to write and to act), D4 Prove (who writes the oracle and who reads the diff) and D5 Steward (the owner who can explain a change with the tool switched off and revert it from outside the pipeline).
Everything here is the book's own conclusion, drawn from the records of Chapters 1 to 31 and from nothing else. Those chapters record plans, rules, decisions and dated checks and, in Chapter 31, a small number of outcomes that are marked there as illustrative. Where a result is missing this chapter says so and treats the item as open; where Chapter 31 supplies an illustrative outcome, this chapter uses it and says so. The plans below are therefore proposals, the figures in them are the baselines the earlier chapters fixed, and every outlook carries one of the three labels of AI Governance, Chapter 22 (162, Nordqvist, 2026): observable, expected or speculation. The measures are not findings. They say what each organisation would have to show for the book's claims to hold in its own setting, and what would count against them.
Three rules shaped the plans, and the reader who adapts them to another organisation should keep the rules and replace the items.
Primary topics explored
- What the conclusions rest on
- Nordvik Region
- Hansa Mutual
- Comparison
- Measures
- Risks
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 32: Nordvik Region and Hansa Mutual: Conclusions for Two Organisations in AI Developer gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “Experience and Conclusions” and is one of 37 drawn from the manuscript.