A developer who writes code with an assistant has made a decision before the first line appears: how much of the next hour belongs to the tool and how much to the person. This chapter treats D3 Build, the function of producing software and of directing its making within a mandate, and it reaches into D4 Prove and D5 Steward, because every line that an assistant suggests becomes someone's to verify and, once it ships, someone's to own. Chapters 5 and 6 treated the work that comes before building, framing the problem and designing within constraints. Chapter 8 treats agents that plan, edit many files and open pull requests, and Chapter 9 treats the proof that a change is right.
The chapter maps the progression of coding tools from completion to agents onto the usage modes; reports what controlled studies, field experiments and surveys measured, with population, task, date and result, because the evidence on building is the most quoted and the least carefully read in the field; describes prompt and context craft and what stays human; and ends with an artefact, a coding-assistant usage profile with acceptance criteria and a measurement plan, shown for Nordvik Region.
Five conclusions of the earlier volumes frame the chapter. The usage mode, not the product name, sets the governance of an AI tool: AI Governance, Chapter 2, and AI Platform and Security, Chapter 2, defined Mode 0 Ambient AI to Mode 5 Autonomous production agents, and AI Platform and Security showed what each mode demands of the platform (162, Nordqvist, 2026); (163, Nordqvist, 2026). Mode 0 is the blind spot, because vendor AI that arrives in an update may act at an effective autonomy nobody decided. Autonomy is graded, and what verifies an action is independent of what performed it: AI Operations, Chapter 4 (170, Nordqvist, 2026). Reliance on machine advice follows conditions, which the developer who accepts a suggestion meets again: AI Leader, Chapter 8 (174, Nordqvist, 2026). Automating the routine erodes the skill of the people who must catch the errors: AI Threat, Chapter 14, applied to the developer in Chapters 13 and 28 (165, Nordqvist, 2026). And an adoption or productivity claim carries scope, method, date, result and expiry, with the defaults of 90 days for usage and 180 days for value that AI Leader, Chapters 4 and 20, set.
Primary topics explored
- What the series has already settled
- The progression of tools
- What the studies measured
- Reading the evidence together
- Prompt and context craft
- What stays human
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.
Continue with the full chapter
Chapter 7: Build: Writing Code and the Tools of the Craft 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.