Thirty-two chapters have built a thesis, tested its parts one function at a time and shown it in two organisations. This chapter judges it. It concerns all five functions of the developer loop, D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward, because a conclusion that favoured one would misdescribe a loop whose five functions hold one another up. The judgement rests on the evidence the book gathered, which is narrower than the claims that circulate about developers and AI. It also says what would show the thesis wrong, whether anything seen so far does, what the author projects beyond the evidence, and what a reader can do on Monday with records an organisation already has.
The book uses three labels for every statement about the future, taken from AI Governance, Chapter 22 (162, Nordqvist, 2026). A statement is observable when it describes something happening now and documented in a source the book opened, expected when it follows from a stated trend or from an instrument that has been decided, and speculation when it is plausible and unevidenced. This chapter adds a discipline to those labels. Where an earlier chapter called something observable, the chapter asks what exactly was observed, in whom, on which task and in which year, and whether the observation bears on developers in a European enterprise or public authority. Most of what the book found is observable about a task, a codebase or a cohort, and its bearing on the organisations in the book is the book's own inference.
The word "established" is used below only for what is both observable and in force: a duty written in an instrument, a documented failure, a measured effect with its limits. No part of the thesis as a whole is established in that sense: the evidence supports mechanisms and premises more than outcomes.
Primary topics explored
- How the judgement is made
- The thesis, part by part
- The scorecard
- Where the book's evidence is thin
- What would show the thesis wrong
- The author's projections
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 33: Conclusion: The Developer with AI Judged 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.