Four roles sit on either side of the code: the product owner and the designer, who say what the software is for and how it should feel to use, and the tester and quality engineer, who find out whether it does what was said. When AI generates code cheaply, these four roles change more than most, and for the same reason: the cost of producing a change falls, while the cost of knowing what to build (D1 Frame) and of showing that what was built is right (D4 Prove) does not. This chapter describes how each role moves, where the boundary between them and the developer shifts, and what must not shift. It is for testers, quality engineers, product owners, designers, the developers and tech leads who work with them, and the engineering managers who draw their boundaries.
The chapter has one argument. The boundaries around intent and prototype are moving outwards, because anyone can now produce a running prototype. The boundaries around proof and ownership must not move: the oracle that decides whether a change is right stays independent of whatever generated the change, and a named person owns what reaches production. The role-boundary matrix at the end of the chapter is the artefact that makes the argument operational.
The chapter builds on the oracle and review material of Chapter 9, on the specification record of Chapter 5 and on the stewardship principle of Chapter 4: a named developer or team passes the tests Name, Understand and Revert, and the test oracle is independent of the generator. It takes over the independence principle of AI Purple, Chapter 15, that a loop closed by machines alone verifies nothing new (169, Nordqvist, 2026), the observer principle of AI Operations, Chapter 17, and its treatment of resilience as a claim with an evidence age in AI Operations, Chapter 19 (170, Nordqvist, 2026). It also uses the conclusions of AI Leader, Chapter 19, on leading specialists: write the first judgement before reading the draft, seed known errors, disclose AI use and protect the right to override (174, Nordqvist, 2026). Testing practice as such, and the testing of infrastructure as code, are treated in Architecture as Code (Chapter 13) (161, Nordqvist, 2025) and are not repeated.
Primary topics explored
- Testers and quality engineers
- Quality as an independent voice
- Product owners
- Designers
- Where the boundary moves
- Across the usage modes
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 17: Testers, Quality Engineers, Product Owners and Designers in AI Developer gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “Developer Roles Across the Organisation” and is one of 37 drawn from the manuscript.