A developer rarely works alone on a change that reaches production. Before the first line is written, an architect has set constraints that the design must respect. While it is written, a platform team has decided which template, pipeline, scanner and package registry the code passes through, and, increasingly, which AI tools may touch it. After release, a site reliability engineer holds a number, the error budget, that says whether the next change may go out. These three neighbours do not write the application, but each one holds a decision that shapes what the developer and the developer's tools may do. When AI generates change at a higher volume than before, those decisions stop being background and become the places where the organisation's control over AI-assisted development actually sits. This chapter concerns D2 Design and D5 Steward: how the architect's role, the platform team's golden paths and the reliability engineer's error budget change when AI takes part in development, and where the boundaries and handovers between them and the developer must be written down.
The chapter builds on conclusions of earlier volumes. In Architecture as Code (Chapter 4), architectural decisions are kept as short, numbered, immutable records beside the code, and in Architecture as Code (Chapter 17) platform teams act as internal service providers that own common toolchains and guardrails (161, Nordqvist, 2025). AI Platform and Security, Chapter 4, set out a reference architecture in which every model call and tool call passes a policy point outside the model, carried by the AI gateway, with every tool registered and its credentials held by the platform, and Chapter 19 added that containment must not depend on intent (163, Nordqvist, 2026). The Transformed Security Architect, Chapters 4, 7, 16 and 17, described the architect's role as a charter with decision rights, as the designer of boundaries that hold whatever anyone intends, and as one voice in a role map and a design authority that works through gates instead of meetings (166, Nordqvist, 2026). AI Operations, Chapter 4, gave the autonomy budget and the observer principle, and its Chapters 21 and 22 gave operating models and decision rights (170, Nordqvist, 2026). This chapter does not repeat them. It asks what a developer needs from these neighbours, and what they need from the developer, when the volume and the origin of change have shifted.
The three roles are defined in different traditions and are staffed differently in the two organisations of this book. Nordvik Region has an enterprise architect and an AI architect, a platform team of seven, and no site reliability function. Hansa Mutual has about 25 architects and designers in Group Application Development beside the enterprise and security architects counted elsewhere, an internal developer platform called Hansa Forge with 24 people, and a site reliability function of about 95. The problem they share is that each of them decides something about development without writing the code, and that the decision is now exercised against a stream of change that includes machine-generated proposals.
Primary topics explored
- Three neighbours, one problem
- The architect (D2 Design)
- The platform team (D5 Steward, D2 Design)
- Site reliability engineering (D5 Steward)
- Boundaries and handovers
- Practical guide: Writing a golden-path specification with AI tooling defaults
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 16: Architects, Platform Engineers and Site Reliability Engineers 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.