Book Blueprint and Chapter Briefs

This blueprint records the editorial intent of AI Developer: How the Developer Role Changes When AI Is Used Broadly in European Enterprises and Public Authorities, Book 12 of The Architecture as Code Series. The authoritative design is DISPOSITION.md; the chapter briefs below are generated from scripts/outline_data.py by scripts/generate_outlines.py.

Premise

The series has treated AI from many positions: governance (Book 2), platform and security (Book 3), cyber defence (Books 4, 8 and 9), threat (Book 5), the security architect (Book 6), the worker managed by AI (Book 7), IT operations (Book 10) and leadership (Book 11). One role has been present in every volume as the person who builds what the others govern, secure, defend, operate and lead, and has been the subject of none: the developer.

Three things make this a book. First, software development has always been partly an act of translation, from need to requirement, from requirement to design, from design to code, from code to behaviour in production. Generative AI performs the translation from specification to code cheaply and fluently; it does not make cheaper knowing what to build, knowing whether what was built is right, and answering for it in production. Second, the evidence is mixed, young and contested, and a book on the developer with AI must separate what studies measured from what vendors, consultancies and executives claim. Third, European law assigns duties to named parties for software: providers and deployers under the AI Act, manufacturers under the Cyber Resilience Act, the producer under the new Product Liability Directive, the entity under NIS 2 and DORA, the controller under the GDPR, and the employer towards employee representatives. These duties do not move to a model or a code generator.

Thesis

The working thesis has five parts, tested in Parts II to V and judged in Chapters 29 and 33.

The developer is transformed, not abolished: from author of code to framer, verifier and steward of software. The typing of code shrinks; the weight moves to framing (D1), design (D2), directing and reviewing what is built (D3), proving that it is right (D4) and owning it in production over time (D5).
Delegation of development work is graded and has a ceiling. Every class of development work has a degree of delegation, Level 0 Advisory to Level 4 Autonomous, set by reversibility, blast radius, who is affected, the evidence for the tool and the strength of the independent checks. Level 4 is never used for a change to production without a gate that the change itself cannot alter, for code in a security-critical or safety-critical path without human review by a named developer, for a change to the agent's own mandate, permissions, credentials, test oracles, review rules or pipeline gates, for an irreversible action on production data, or for a decision about a named person's employment, pay, performance rating or access to work.
Verification, not generation, becomes the scarce skill, and the junior pipeline must be rebuilt, not assumed. Code is cheap to produce and expensive to trust. The entry-level tasks that taught the craft are the tasks AI performs best.
The stewardship principle: AI may draft, generate, refactor and, within a mandate, execute; it may not own. For every change in production a named developer or team passes three tests: Name, Understand and Revert. Corollary: the test oracle must be independent of the generator.
Productivity, quality and competence are claims that need evidence. Evidence expires; craft decays if it is not exercised, so the developer's own craft is kept in practice on purpose.

The thesis would be shown wrong by independent, multi-year evidence that organisations which let AI systems merge, deploy and own code without named, reachable human owners and without generator-independent checks achieve better quality, security, delivery and learning than organisations that keep them, or that developers who never write or read code by hand develop the judgement to verify it as well as those who do.

Audience

Developers at every level; tech leads and engineering managers; architects, platform engineers, site reliability engineers, testers and quality engineers; product owners, designers and analysts; leaders who decide on developer tooling and headcount; heads of public-sector IT and procurement; HR and the organisations' works councils and unions; educators; supervisors and auditors. Chapter 1 gives reading paths.

Boundaries

The book builds only on Books 1 to 11 and never refers to a later volume. It takes their conclusions as given and does not repeat them. The companions Tools and Landscape are not numbered books and are not cited.

Not a second Architecture as Code. Pipelines and testing practice stay in Book 1; this book takes the developer's role as the subject.
Not a second AI Governance or AI Platform and Security. Forums and the governance framework stay in Book 2; the platform and the pipeline for AI systems in Book 3. This book asks what happens to the developer who uses AI to build any software.
Not a second AI Red Team, AI Blue or AI Purple. Defence stays there; this book meets it at the boundary of secure code and AI-generated vulnerabilities.
Not a second AI Threat. The evidence ladder and the findings on cognitive offloading are used, not repeated.
Not a second The Transformed Security Architect. The architect is the developer's neighbour; the conductor idea is applied to the developer who directs agents.
Not a second AI Boss. Developer telemetry and performance monitoring is treated at the boundary (Chapter 22) and points to it.
Not a second AI Operations. D5 Steward meets O3 Change at the boundary; "you build it, you run it" is examined with AI.
Not a second AI Leader. That book asks what happens to leadership; the middle layer, adoption leadership and works councils are pointed to, not repeated. The answerability principle is generalised to the stewardship principle.
Defensive and constructive. Legal content is attributed to the instrument and article, verified against the live text, and framed as organisational and architectural implication, not legal advice. Effects on people are described by what studies measured; no one is called lazy, stupid or replaceable. Covert monitoring of staff and defeating employee representatives' rights are never described as methods. Attacks on the toolchain are described by class and technique only.

Red threads

The five developer functions. D1 Frame, D2 Design, D3 Build, D4 Prove, D5 Steward (Chapter 4). Every chapter in Parts II to V names, in its opening and Summary, the functions it concerns.
The delegation ladder. Every narrative chapter has an ### Across the usage modes or ### Across the degrees of delegation subsection, normally a compact table, with the Level 4 prohibitions.
The stewardship principle (Chapters 4, 9, 12 and 14): Name, Understand and Revert, with the independent test oracle as corollary.
Claims with evidence. No chapter says that a tool raises productivity, that code is secure, that a team is AI-fluent or that a role is redundant without saying what was measured, how, when and with what result.
Observable, expected, speculation. Every outlook carries one of the three labels; the author's projections stay in Chapters 29 and 33.
Constructive debate. Chapters 8, 13, 20 and 29 stage a debate in four steps before a verdict.
Two organisations. Nordvik Region and Hansa Mutual in every narrative chapter, in a short ### Nordvik Region and Hansa Mutual subsection before the Summary.
Artefacts. Role charters ROLE-*, delegation profiles DLG-*, mandate manifests MND-* (MND-NR-DEV-*, MND-HM-DEV-*), specification records SPC-*, code-ownership records OWN-*, verification plans VER-*, review records RVW-*, agent run records RUN-*, provenance records PRV-*, adoption and value records AVR-*, apprenticeship plans APR-*, competence records CMP-*, horizon registers HZN-*, AI Decision Records AIDR-1100 to AIDR-1199 (Nordvik Region AIDR-1100 to AIDR-1149, Hansa Mutual AIDR-1150 to AIDR-1199) and Architecture Decision Records (ADR).

Status

The repository was bootstrapped on 2026-11-11 from the engine of AI Leader. The table of contents (scripts/toc_definition.py) and the chapter briefs (scripts/outline_data.py) exist; all 33 chapters are written out following docs/CHAPTER_AUTHORING_GUIDE.md and carry the status complete in scripts/outline_data.py (the briefs below remain the editorial intent; a chapter that is later reopened is set back to draft).

Length and weighting

Narrative chapters run 3,600 to 6,000 words, with the planned range stated in each brief. Parts II and III are the book's weight; Chapters 4, 8, 9, 13 and 24 are load-bearing. A chapter that grows beyond about 6,000 words, or a section beyond about 2,500 words that treats a distinct subject, is split into a companion chapter. A reader with an hour reads Chapters 1, 4, 8, 9, 13 and 33.

Chapter briefs

Part I: The Developer Role in Question

Chapter 1: Introduction: The Developer with AI

File: 01_introduction.md
Status: complete
Purpose: Introduce the book on its own terms. The earlier volumes govern, secure, defend, operate and lead what developers build, and none took the developer as its subject. State what a developer is and does, why AI changes it now and across the organisation rather than in one tool, the five-part thesis and what would refute it, and how each audience should read the book. Define the usage modes and the degrees of delegation the book relies on.
Builds on: Architecture as Code (Chapter 4), AI Governance, Chapter 22, AI Platform and Security, Chapter 19, AI Operations, Chapter 22, AI Leader, Chapter 4
Developer functions: D1 Frame; D2 Design; D3 Build; D4 Prove; D5 Steward
Sections: A change nobody can explain; Development with AI in 2029; Why a book on the developer; The working thesis; Five functions and five degrees; Usage modes and degrees of delegation; Rules of the book; Two organisations and the series; How to read this book
Practical guides: A one-page inventory of every place where AI already takes part in a team's development work, including embedded and ambient AI
Worked examples: A one-page development delegation profile for one team: work classes, who prepares, who approves, who owns, AI contribution and level
Nordvik Region and Hansa Mutual: Nordvik Region's digitalisation unit and Hansa Mutual's IT organisation open the book with the same question about who owns a generated change. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Introduces the usage modes as the series uses them and relates them to coding tools: Modes 0 to 2 in the developer's own editor, Mode 3 in delegated tasks, Mode 5 where agents act with their own identity.
Observable, expected, speculation: Completion and chat assistants in editors are observable; delegated routine changes in narrow work classes are expected; agent-run development of whole systems is speculation, treated in Chapter 29. The thesis is the book's own claim, judged in Chapters 29 and 33.
Figure: The developer loop at the centre: five functions, the steward in the middle and the chapters that treat each function
Planned length: 4,500-6,000 words of prose
Expected existing sources: 1, 2, 3, 162, 170

Chapter 2: What Developers Did Before: Craft, Waterfall, Agile, DevOps and Open Source

File: 02_what_developers_did_before.md
Status: complete
Purpose: Describe how development organised itself before AI, as the baseline for Chapters 5 to 12: the craft tradition, structured programming, waterfall, agile and Extreme Programming, DevOps and 'you build it, you run it', open source and package ecosystems, platform engineering and earlier automation of code (compilers, IDEs, code completion, low-code). For each, say what it answered and which scarcity it addressed. Report what studies show about how developers spend their time [verify].
Builds on: Architecture as Code (Chapter 4), AI Operations, Chapter 3, AI Leader, Chapter 2
Developer functions: D1 Frame; D2 Design; D3 Build; D4 Prove; D5 Steward
Sections: A lineage of development practice; What each answered; Earlier automation of code; How developers spend their time; You build it, you run it; A pre-AI role description and a charter-as-code
Practical guides: Classifying the practices a team has by lineage, scarcity answered and what remains of it
Worked examples: A pre-AI developer job description contrasted with a role charter (ROLE-*) for the same post
Nordvik Region and Hansa Mutual: Nordvik Region's in-house teams grew out of a waterfall-era procurement tradition; Hansa Mutual's product teams run agile and DevOps with a platform team. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Pre-AI baseline; marks where Mode 0 features already sit in editors and review tools.
Observable, expected, speculation: The history is observable; the claim that each practice answered a scarcity is the book's own reading, stated as such.
Figure: The lineage of development practice, with the scarcity each answered
Planned length: 3,600-6,000 words of prose
Expected existing sources: 41, 77, 161

Chapter 3: The Pressure on Developers: Productivity Claims, Adoption, Legacy and Accountability

File: 03_the_pressure_on_developers.md
Status: complete
Purpose: Explain why the developer's role strains: adoption pressure from vendors and executives, headcount expectations, backlog and legacy, security and supply-chain demands, regulatory duty and adversaries using the same tools. Place each claim on the evidence ladder and label survey claims as survey claims (Stack Overflow Developer Survey, DORA programme research, GitHub, vendor studies [verify each]).
Builds on: AI Threat, Chapter 4, AI Operations, Chapter 3, AI Leader, Chapter 3, AI Boss, Chapter 26
Developer functions: D1 Frame; D2 Design; D3 Build; D4 Prove; D5 Steward
Sections: Adoption pressure; Backlog and legacy; Security and supply-chain demand; Regulatory duty; Claims and the evidence ladder; A work-and-load map
Practical guides: Mapping a developer's week by activity, load and AI contribution
Worked examples: A developer's work-and-load map for one sprint, with the activities AI touches marked
Nordvik Region and Hansa Mutual: Nordvik Region's pressure comes from the council's savings targets and a legacy estate; Hansa Mutual's from a licence-seat target and supervisory duty under DORA. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: Survey results and adoption figures are observable (labelled as survey claims); headcount effects are expected or speculation as the evidence supports.
Figure: The pressure points on the developer and the evidence behind each
Planned length: 3,600-6,000 words of prose
Expected existing sources: 1, 2, 3, 42, 63

Chapter 4: The Developer Loop Defined: Five Functions, Delegation Ladder and Stewardship

File: 04_the_developer_loop_defined.md
Status: complete
Purpose: The central chapter. Define D1-D5 with scope and boundaries; the classes of development work (specify, design, generate, refactor, test, review, deploy, operate, document, migrate); the delegation ladder with the Level 4 prohibitions; the stewardship principle with the tests Name, Understand and Revert and the independent test-oracle corollary; claims with evidence; the usage modes applied to coding tools; and the relation to AI Act Articles 4, 14, 25 and 26, the Cyber Resilience Act, the Product Liability Directive, NIS 2 Article 21 and DORA [verify].
Builds on: AI Operations, Chapters 4 and 17, AI Purple, Chapter 15, AI Leader, Chapter 4, AI Red Team, Chapter 6, AI Boss, Chapter 2, The Transformed Security Architect, Chapter 3
Developer functions: D1 Frame; D2 Design; D3 Build; D4 Prove; D5 Steward
Sections: The loop in one picture; Five functions; Classes of development work; The delegation ladder; The Level 4 prohibitions; The stewardship principle; The independent test oracle; Claims with evidence; Mapping to law; The delegation profile as an artefact
Practical guides: Writing a delegation profile for one team's development work classes
Worked examples: DLG-NR-DEV-01: a delegation profile with a work-class table for a coding assistant and an agent
Nordvik Region and Hansa Mutual: Nordvik Region sets Level 0 and Level 1 for most classes and names a team as owner of every merged change; Hansa Mutual allows Level 2 for tests and documentation and keeps security-critical paths at Level 1. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of usage modes against work classes and the highest level each has been allowed; Mode 0 as the blind spot in editors and review tools.
Observable, expected, speculation: The frame is the book's own design, built on observable practice and on the earlier volumes; the mappings are interpretation, stated as such.
Figure: The developer loop with the steward at its centre and the independent checks outside it
Planned length: 4,500-6,000 words of prose
Expected existing sources: 1, 2, 3, 169, 170, 230

Part II: The Craft of Developing

Chapter 5: Frame: Problems, Requirements and Intent

File: 05_frame.md
Status: complete
Purpose: Treat framing without AI first: understanding the problem, requirements, user research, acceptance criteria and the specification as the source of intent; spec-driven development; ambiguity as the cost. Then ask what AI adds (drafting, clarifying questions, summarising feedback) and its failure modes (plausible but wrong requirements, scope inflation).
Builds on: Architecture as Code (Chapter 4), AI Governance, Chapter 13, AI Leader, Chapter 5
Developer functions: D1 Frame
Sections: Understanding the problem; Requirements and acceptance criteria; Specification as the source of intent; What AI adds; Failure modes; A specification record
Practical guides: Turning a need into a specification record with acceptance criteria that a test can check
Worked examples: SPC-NR-*: a specification record for a citizen-service form change, with acceptance criteria and links to tests
Nordvik Region and Hansa Mutual: Nordvik Region frames work from case-handler needs and legal requirements; Hansa Mutual from product hypotheses and regulatory change. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: Drafting of requirements with AI is observable; spec-driven agent workflows are expected; fully AI-framed products are speculation.
Figure: From need to executable specification, with the human decision points
Planned length: 3,600-6,000 words of prose
Expected existing sources: 1, 161, 162

Chapter 6: Design: Architecture, Decisions and Constraints with AI

File: 06_design.md
Status: complete
Purpose: Treat design as the choice of constraints: architecture decision records, interfaces, boundaries, data and security by design; AI as design reviewer and option generator; architectural drift in AI-generated codebases [verify evidence]; the boundary to the architect, with pointers to Books 1 and 6.
Builds on: Architecture as Code (Chapter 4), The Transformed Security Architect, Chapter 4, AI Platform and Security, Chapter 19, AI Leader, Chapter 7
Developer functions: D2 Design
Sections: Design as the choice of constraints; Decision records; AI as option generator and design reviewer; Architectural drift; The boundary to the architect; An ADR with AI involvement
Practical guides: Writing an ADR in which an assistant proposed options and a named developer decided
Worked examples: An ADR for a service boundary with the AI contribution, the human decision and a review date
Nordvik Region and Hansa Mutual: Nordvik Region's design decisions must survive a freedom-of-information request; Hansa Mutual's pass an architecture forum. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: Option generation with AI is observable; automated design review is expected; AI-owned architecture is speculation.
Figure: A design decision with its human decision points and its record
Planned length: 3,600-6,000 words of prose
Expected existing sources: 161, 163, 166

Chapter 7: Build: Writing Code and the Tools of the Craft

File: 07_build.md
Status: complete
Purpose: Treat building: the progression of tools from completion through chat and edit modes to agentic modes and vibe coding, mapped to Modes 0-5; what controlled studies and field experiments found (Peng et al. 2023, Cui et al. 2024, the METR 2025 randomised trial on experienced developers, DORA 2024 and 2025 [verify each]); where the effect varies by task, experience and codebase; prompt and context craft as the new interface; what stays human.
Builds on: AI Operations, Chapter 4, AI Threat, Chapter 14, AI Leader, Chapter 8
Developer functions: D3 Build
Sections: The progression of tools; What the studies measured; Where the effect varies; Prompt and context craft; What stays human; A usage profile
Practical guides: Writing a coding-assistant usage profile with acceptance criteria and a measurement plan
Worked examples: A coding-assistant usage profile for one team, with modes, allowed work classes and the evidence it will collect
Nordvik Region and Hansa Mutual: Nordvik Region pilots one assistant in two teams; Hansa Mutual has licences for most developers and measures acceptance rate. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: Study results are observable with their conditions; wider productivity gains are expected only where the evidence supports; vibe-coded production systems are speculation and a risk.
Figure: The build loop with human checkpoints
Planned length: 3,600-6,000 words of prose
Expected existing sources: 42, 62, 63, 68

Chapter 8: Build with Agents: Delegated Coding, Mandates and Sandboxes

File: 08_build_with_agents.md
Status: complete
Purpose: Treat coding agents that plan, edit many files, run commands and open pull requests: mandates (MND-*-DEV-*), sandboxes, credentials, tool permissions, budgets, run records and stop paths outside the agent. Stage a constructive debate on whether agents should write and merge the code, and give a verdict with labels.
Builds on: AI Operations, Chapter 17, AI Red Team, Chapter 6, AI Purple, Chapter 15, AI Leader, Chapter 8, AI Platform and Security, Chapter 13
Developer functions: D3 Build; D4 Prove
Sections: What a coding agent is; The mandate; Sandboxes and permissions; Stop paths outside the agent; Run records; The debate; Verdict
Constructive debate: Concern: Agents that write and merge code remove the human who understands the change; review volume overwhelms reviewers; the agent's own tests and permissions can be altered by it; supply-chain and injection risks multiply. Calm: Much code is routine and reversible; agents work in sandboxes with tests; human reviewers also miss defects; withholding merge rights wastes the benefit and drives shadow use. Where they meet: Both accept that the class of work, its reversibility and the independence of the checks decide the level; that an agent never changes its own mandate, gates or test oracles; and that a named developer passes Name, Understand and Revert. What can be done: Write mandates per work class, put the stop path outside the agent, require generator-independent checks, keep run records and review the level on evidence.
Practical guides: Writing a mandate and a run record for a coding agent that opens pull requests
Worked examples: MND-NR-DEV-01 mandate manifest and a RUN-NR-* run record for a dependency-update agent
Nordvik Region and Hansa Mutual: Nordvik Region allows an agent only to open draft pull requests in a sandbox; Hansa Mutual allows merge of documentation and test-only changes under MND-HM-DEV-*. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of usage modes against agent authority, with the level allowed and the stop path.
Observable, expected, speculation: Observable: agents opening pull requests under review. Expected: delegated merges in narrow, reversible classes. Speculation: agents owning services.
Figure: A delegated coding task from mandate to run record and review
Planned length: 3,600-6,000 words of prose
Expected existing sources: 33, 230

Chapter 9: Prove: Review, Tests and Verification

File: 09_prove.md
Status: complete
Purpose: Treat proving: code review (what it is for, evidence on its effectiveness), testing strategy, property tests, mutation testing, formal methods at the edge and static analysis; the independent test oracle; review fatigue and the volume problem when AI produces the diffs; AI as reviewer and its limits; evaluation of AI output.
Builds on: AI Purple, Chapter 15, AI Operations, Chapter 17, Architecture as Code (Chapter 4), AI Leader, Chapter 12
Developer functions: D4 Prove
Sections: What review is for; Testing strategy; The independent test oracle; The volume problem; AI as reviewer; A verification plan
Practical guides: Building a verification plan with an oracle that does not share the generator's blind spots
Worked examples: VER-HM-* verification plan with an independent oracle and an RVW-HM-* review record
Nordvik Region and Hansa Mutual: Nordvik Region requires two-person review for citizen-facing changes; Hansa Mutual adds mutation testing on claims calculations. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: Review findings from AI reviewers are observable; mutation testing as a gate on generated code is expected; machine-verified correctness of whole systems is speculation.
Figure: Evidence of correctness across independent checks
Planned length: 3,600-6,000 words of prose
Expected existing sources: 43, 61, 169

Chapter 10: Prove Security: Secure Code, Supply Chain and the Toolchain as Attack Surface

File: 10_prove_security.md
Status: complete
Purpose: Treat secure development with AI: what studies measured about vulnerabilities in AI-generated code [verify]; dependencies and package hallucination, secrets, licences, provenance and SBOMs (PRV-*); prompt injection and excessive agency in coding tools (OWASP LLM Top 10, MITRE ATLAS [verify]); the toolchain as Tier 0; SLSA and signing. Defensive only.
Builds on: AI Platform and Security, Chapter 19, AI Red Team, Chapter 6, AI Blue, Chapter 11, AI Operations, Chapter 17
Developer functions: D4 Prove; D5 Steward
Sections: What studies measured; Dependencies and package hallucination; Secrets and licences; Prompt injection and excessive agency; The toolchain as Tier 0; Provenance
Practical guides: Writing the controls for a coding agent: allow-listed registries, secret scanning, signed provenance
Worked examples: A PRV-* provenance record for a generated service and its dependencies
Nordvik Region and Hansa Mutual: Nordvik Region runs a private registry mirror for public code; Hansa Mutual's supply-chain duties follow DORA and the Cyber Resilience Act. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: Vulnerable generated code and malicious packages are observable; signed provenance for generated code is expected; autonomous supply-chain attacks at scale are speculation.
Figure: The toolchain trust boundary
Planned length: 3,600-6,000 words of prose
Expected existing sources: 1, 230

Chapter 11: Steward the Release: CI/CD, Change and Operating What You Build

File: 11_steward_the_release.md
Status: complete
Purpose: Treat stewarding the release: pipelines, trunk-based development, feature flags, progressive delivery, the four key metrics and their limits, change risk, 'you build it, you run it' with AI-generated change volume; the gate that a change cannot alter; rollback and the Revert test; pointer to AI Operations (O3 Change).
Builds on: AI Operations, Chapter 17, Architecture as Code (Chapter 4), AI Platform and Security, Chapter 19
Developer functions: D5 Steward
Sections: Pipelines and trunk-based development; Progressive delivery; The gate a change cannot alter; The four key metrics and their limits; You build it, you run it; A change record
Practical guides: Adding a generator-independent gate and a rollback rehearsal to a release path
Worked examples: A CHG-NR-* change record with the independent gate, the owner and the rollback evidence
Nordvik Region and Hansa Mutual: Nordvik Region's releases follow a monthly window; Hansa Mutual releases continuously with a change advisory board for critical functions. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: Faster change volume is observable; progressive delivery as default is expected; fully autonomous deployment is speculation.
Figure: A release path with independent gates and a stop path
Planned length: 3,600-6,000 words of prose
Expected existing sources: 28, 29, 42, 170

Chapter 12: Steward the Code: Maintenance, Legacy Modernisation, Technical Debt and Documentation

File: 12_steward_the_code.md
Status: complete
Purpose: Treat stewarding the code over years: maintenance, legacy modernisation, technical debt and documentation; evidence on churn, duplication and maintainability in AI-assisted codebases [verify GitClear, DORA, others]; COBOL and mainframe migration with AI (public cases [verify]); knowledge loss; deleting code; ownership over years.
Builds on: AI Operations, Chapter 26, Architecture as Code (Chapter 4), AI Leader, Chapter 19
Developer functions: D2 Design; D5 Steward
Sections: Code health over time; Legacy modernisation; Technical debt; Documentation and knowledge loss; Deleting code; An ownership record
Practical guides: Writing an ownership record for a generated service and running a yearly ownership review
Worked examples: OWN-NR-* code-ownership record for a citizen-portal module
Nordvik Region and Hansa Mutual: Nordvik Region's legacy estate includes mainframe case systems; Hansa Mutual's claims platform is in step-wise modernisation. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: Maintainability studies are observable with their limits; AI-assisted migration as routine is expected; self-maintaining systems are speculation.
Figure: The lifecycle of owned code
Planned length: 3,600-6,000 words of prose
Expected existing sources: 56, 77, 170

Part III: Developer Roles Across the Organisation

Chapter 13: The Junior Developer and the Apprenticeship Problem

File: 13_the_junior_developer.md
Status: complete
Purpose: Treat the junior developer and the apprenticeship problem: how juniors learned; what AI changes in entry-level work; what studies measured on employment of early-career developers and on skill formation with assistance [verify, e.g. the Stanford payroll study 2025 and the 2026 skill-formation experiments]; designing the apprenticeship (review-first learning, deliberate practice, AI-off exercises). Stage a constructive debate on whether juniors will disappear.
Builds on: AI Threat, Chapter 14, AI Operations, Chapter 26, AI Leader, Chapter 11, The Transformed Security Architect, Chapter 14
Developer functions: D3 Build; D4 Prove
Sections: How juniors learned; What AI changes; What studies measured; The debate; Designing the apprenticeship; An apprenticeship plan
Constructive debate: Concern: The tasks that taught the craft are the ones AI does best; organisations that remove them without a replacement route will have no future seniors, and early-career employment is already falling in some data. Calm: Every tool wave changed what juniors do; juniors who use AI well may learn faster; demand for software is large and juniors bring fresh skills and low cost. Where they meet: Both accept that the route must be rebuilt, not assumed; that learning needs struggle as well as output; and that evidence on skill formation is young and conditional. What can be done: Write apprenticeship plans, protect review-first and AI-off practice, measure skill rather than output, and keep a junior intake with a review date.
Practical guides: Designing a first-year plan for a junior developer with defined AI-off exercises and review practice
Worked examples: APR-HM-* apprenticeship plan for a junior in a claims team
Nordvik Region and Hansa Mutual: Nordvik Region hires through a graduate programme and apprenticeships; Hansa Mutual reduced junior intake in one team and now reviews that decision. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: Falling entry-level postings in some studies are observable with their conditions; redesigned apprenticeships are expected; the disappearance of the junior role is speculation.
Figure: The apprenticeship route with and without AI
Planned length: 3,600-6,000 words of prose
Expected existing sources: 64, 67, 68

Chapter 14: The Senior Developer, Staff and Principal Engineer

File: 14_the_senior_developer.md
Status: complete
Purpose: Treat the senior developer, staff and principal engineer: the senior as reviewer, mentor, technical decision-maker and keeper of context; leverage; the risk of becoming a bottleneck of review; protecting professional judgement; the pipeline of seniors.
Builds on: The Transformed Security Architect, Chapter 4, AI Leader, Chapter 19, AI Operations, Chapter 25
Developer functions: D2 Design; D4 Prove; D5 Steward
Sections: The senior's work; Leverage and the review bottleneck; Professional judgement; The pipeline of seniors; Staff and principal roles; A role charter
Practical guides: Writing a senior developer charter with a professional-judgement clause and a review budget
Worked examples: ROLE-NR-DEV-01: a role charter for a senior developer with decision rights, review budget and a professional-judgement clause
Nordvik Region and Hansa Mutual: Nordvik Region's seniors carry legacy knowledge in few heads; Hansa Mutual's staff engineers set standards across product teams. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: Seniors as reviewers of generated code are observable; formal review budgets are expected; senior roles absorbing most development are speculation.
Figure: The senior's leverage: decisions, review and context
Planned length: 3,600-6,000 words of prose
Expected existing sources: 77, 166

Chapter 15: The Tech Lead and the Engineering Manager

File: 15_the_tech_lead_and_the_engineering_manager.md
Status: complete
Purpose: Treat the tech lead and the engineering manager: leading development teams with AI, team agreements, review rules, metrics that do not mislead, pairing, onboarding and headcount conversations; pointer to AI Leader (Chapters 16 and 17) for the middle layer and AI Boss for people management.
Builds on: AI Leader, Chapters 16 and 17, AI Boss, Chapter 26, AI Operations, Chapter 25
Developer functions: D1 Frame; D3 Build; D5 Steward
Sections: The tech lead's job; The engineering manager's job; Metrics that do not mislead; Pairing and onboarding; Headcount conversations; A team working agreement
Practical guides: Writing a team working agreement for AI-assisted development with review rules and a metrics list
Worked examples: A team working agreement and weekly rhythm for a claims-platform team
Nordvik Region and Hansa Mutual: Nordvik Region's tech leads also manage; Hansa Mutual separates tech lead and engineering manager. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: Team agreements on AI use are observable; metrics reform is expected; teams without leads are speculation.
Figure: The team's operating loop: agreement, rhythm and review
Planned length: 3,600-6,000 words of prose
Expected existing sources: 61, 62, 167

Chapter 16: Architects, Platform Engineers and Site Reliability Engineers

File: 16_architects_platform_engineers_and_sres.md
Status: complete
Purpose: Treat the neighbours of the developer: the architect's role changes (pointer to Book 6), the platform team's golden paths and internal developer platform as the place where AI tooling is governed, SRE and the error budget. Boundaries and handovers.
Builds on: The Transformed Security Architect, Chapter 4, AI Operations, Chapter 17, AI Platform and Security, Chapter 19, Architecture as Code (Chapter 4)
Developer functions: D2 Design; D5 Steward
Sections: The architect; The platform team; AI tooling as a platform service; Site reliability engineering; Boundaries and handovers; A golden-path specification
Practical guides: Writing a golden-path specification with AI tooling defaults and an exception route
Worked examples: A golden-path specification for a service template with allowed coding assistants and logging
Nordvik Region and Hansa Mutual: Nordvik Region's platform function is small and shared; Hansa Mutual has an internal developer platform and an SRE guild. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: Platform-governed AI tooling is observable in early adopters; wide adoption is expected; platform teams run most agents is speculation.
Figure: Roles around the developer and the handovers between them
Planned length: 3,600-6,000 words of prose
Expected existing sources: 41, 166, 170

Chapter 17: Testers, Quality Engineers, Product Owners and Designers

File: 17_testers_quality_engineers_product_owners_and_designers.md
Status: complete
Purpose: Treat the roles that shift most: testers and quality engineers (test automation, exploratory testing, quality as an independent voice), the product owner and the designer who now build prototypes; where the role boundary moves.
Builds on: AI Leader, Chapter 19, AI Operations, Chapter 25, Architecture as Code (Chapter 4)
Developer functions: D1 Frame; D4 Prove
Sections: Testers and quality engineers; Quality as an independent voice; Product owners; Designers; Where the boundary moves; A role-boundary matrix
Practical guides: Building a role-boundary matrix for a team that includes testers, a product owner and a designer
Worked examples: A role-boundary matrix for a product team with owner, tester and designer roles
Nordvik Region and Hansa Mutual: Nordvik Region's testers sit in a central test function; Hansa Mutual's quality engineers are embedded in teams. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: Prototype building by non-developers is observable; independent quality functions are expected to grow in importance; the end of testing as a role is speculation.
Figure: Role boundaries around frame, build and prove
Planned length: 3,600-6,000 words of prose
Expected existing sources: 43, 161, 169

Chapter 18: Developers in the Public Authority: Procurement, Public Code and Legitimacy

File: 18_developers_in_the_public_authority.md
Status: complete
Purpose: Treat developers in the public authority: public procurement of software and AI tools, open source and public code, accessibility (the Web Accessibility Directive, the European Accessibility Act [verify]), archives and transparency, development under public-law accountability, in-house versus supplier. Organisation: Nordvik Region.
Builds on: AI Leader, Chapter 18, AI Governance, Chapter 13, AI Platform and Security, Chapter 13
Developer functions: D1 Frame; D2 Design; D5 Steward
Sections: Procurement of AI coding tools; Public code and open source; Accessibility; Archives and transparency; Accountability under public law; In-house or supplier; Procurement criteria
Practical guides: Writing procurement criteria for an AI coding tool, with data, exit and logging requirements
Worked examples: A procurement criteria sheet for an AI coding assistant at Nordvik Region
Nordvik Region and Hansa Mutual: Nordvik Region is the lead organisation of this chapter: council-governed, subject to procurement law, public access and archives; Hansa Mutual appears for contrast. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: Public tendering for AI tools is observable; common public-code programmes are expected; in-house models for all authorities are speculation.
Figure: From need to procured tool in a public authority
Planned length: 3,600-6,000 words of prose
Expected existing sources: 1, 4, 162

Chapter 19: Citizen Developers, Low-Code and the Non-Developer Who Builds

File: 19_citizen_developers_and_low_code.md
Status: complete
Purpose: Treat citizen developers, low-code and the non-developer who builds: shadow IT, low-code and natural-language app builders, governance without prohibition, support and sunset, data protection and security; the line between prototype and production.
Builds on: AI Governance, Chapter 13, AI Operations, Chapter 17, AI Leader, Chapter 19
Developer functions: D1 Frame; D3 Build; D5 Steward
Sections: When anyone can build; Shadow IT and its risks; Governance without prohibition; Prototype and production; Support and sunset; A build-your-own-tool register
Practical guides: Creating a register entry and promotion criteria for a tool built by a case handler
Worked examples: A build-your-own-tool register entry with owner, data classes and sunset date
Nordvik Region and Hansa Mutual: Nordvik Region finds spreadsheets and form builders in case handling; Hansa Mutual finds app-builder prototypes in claims. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: Non-developer building is observable; promotion pipelines are expected; most business software built by non-developers is speculation.
Figure: From prototype to production with promotion gates
Planned length: 3,600-6,000 words of prose
Expected existing sources: 1, 4, 230

Part IV: Leading Change and Adoption

Chapter 20: Measuring and Leading AI Adoption in Development

File: 20_measuring_and_leading_ai_adoption.md
Status: complete
Purpose: Treat measuring and leading AI adoption in development: adoption programmes, licences and seats, metrics (DORA four keys, SPACE, DevEx [verify]), why acceptance rate and lines of code mislead, the productivity J-curve, experiments inside the organisation and stopping what does not work. Stage a constructive debate on whether AI is making developers more productive.
Builds on: AI Leader, Chapter 20, AI Operations, Chapter 20, AI Governance, Chapter 22
Developer functions: D1 Frame; D2 Design; D3 Build; D4 Prove; D5 Steward
Sections: Adoption programmes; Metrics; Why acceptance rate misleads; The productivity J-curve; Experiments inside the organisation; The debate; An adoption and value record
Constructive debate: Concern: Acceptance rate, lines of code and vendor claims measure activity, not value; a randomised trial found experienced developers slower in their own codebases; quality and security costs arrive later than the speed. Calm: Many field experiments and telemetry studies find gains in defined tasks; developers report benefit; the tools improve quickly and early costs are a learning curve. Where they meet: Both accept that effects depend on task, experience and codebase, that evidence expires, and that only measured outcomes in the organisation's own context settle the matter. What can be done: Write adoption and value records with evidence age, run controlled experiments, drop vanity metrics and stop what does not work.
Practical guides: Designing an in-house experiment with a control group and a stopping rule
Worked examples: AVR-NR-* adoption and value record with scope, method, date, result and expiry
Nordvik Region and Hansa Mutual: Hansa Mutual's seat target and acceptance dashboard are the running case; Nordvik Region runs a controlled pilot. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: Study results are observable with conditions; measured productivity gains in some task classes are expected; broad gains of the size claimed in marketing are speculation.
Figure: From adoption claim to evidence record
Planned length: 3,600-6,000 words of prose
Expected existing sources: 42, 61, 62, 63, 68

Chapter 21: Team Practice and Culture: Pairing, Review Culture, Trust and Psychological Safety

File: 21_team_practice_and_culture.md
Status: complete
Purpose: Treat team practice and culture: working with AI as a teammate that is not one, code review culture, trust calibration, speaking up about defects, juniors' safety to ask and shadow AI.
Builds on: AI Leader, Chapter 21, AI Threat, Chapter 14, AI Operations, Chapter 24
Developer functions: D3 Build; D4 Prove
Sections: Pairing with an assistant; Review culture; Trust calibration; Speaking up; Safety to ask; Shadow AI; A team practice agreement
Practical guides: Running a retrospective on AI-assisted work with a safe way to report defects
Worked examples: A team practice agreement covering review, disclosure of AI use and reporting of defects
Nordvik Region and Hansa Mutual: Nordvik Region's culture is consensus-oriented and cautious; Hansa Mutual's is fast and metric-driven. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: Shadow AI use is observable in surveys; practice agreements are expected; cultures defined by agent teammates are speculation.
Figure: The team's trust loop: use, review, report, learn
Planned length: 3,600-6,000 words of prose
Expected existing sources: 43, 74

Chapter 22: Developers, Works Councils and Employment: Telemetry, Rights and Intellectual Property

File: 22_developers_works_councils_and_employment.md
Status: complete
Purpose: Treat developers, works councils and employment: information and consultation on developer tooling and telemetry (BetrVG, MBL, WOR as in earlier volumes [verify]), monitoring of developers (pointer to AI Boss and AI Leader Chapter 22), employment terms, who owns what a developer produces with AI and collective agreements. Defensive: no method for defeating representatives' rights.
Builds on: AI Leader, Chapter 22, AI Boss, Chapter 26, AI Governance, Chapter 13
Developer functions: D3 Build; D5 Steward
Sections: Information, consultation and co-determination; Telemetry and monitoring of developers; Employment terms; Ownership of output; Collective agreements; An agreement outline
Practical guides: Preparing a consultation file on a coding assistant with a telemetry description
Worked examples: An agreement outline for developer tooling (KBV-HM-* and MBA-NR-* style)
Nordvik Region and Hansa Mutual: Hansa Mutual's works agreement KBV-HM-* and Nordvik Region's negotiation records MBA-NR-* are the running cases. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: Co-determination on tooling is observable; agreements that name telemetry limits are expected; developer-specific bargaining is speculation.
Figure: From tooling proposal to agreement
Planned length: 3,600-6,000 words of prose
Expected existing sources: 4, 9, 10, 167

Chapter 23: When It Breaks: Incidents, Outages and AI-Generated Defects

File: 23_when_it_breaks.md
Status: complete
Purpose: Treat what happens when it breaks: post-incident practice when AI wrote or changed the code, blameless review and the Name test, analysis of AI-involved failures, verified public incidents involving automated or AI-generated change [verify, e.g. the 2024 CrowdStrike content update as a case of unsafe release practice, not of AI], communication; pointer to AI Operations.
Builds on: AI Operations, Chapter 17, AI Blue, Chapter 11, AI Leader, Chapter 23
Developer functions: D4 Prove; D5 Steward
Sections: Post-incident practice; Blameless and named; Analysing AI-involved failures; Verified public incidents; Communication; Review fields
Practical guides: Adding AI-involvement fields to the post-incident review template
Worked examples: Post-incident review fields for AI-involved change
Nordvik Region and Hansa Mutual: Hansa Mutual's review incident and Nordvik Region's rollback of a form change are the running cases. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: Public incidents are observable; routine AI-involvement fields in reviews are expected; AI-caused outages at scale are speculation.
Figure: Incident timeline with the human decision points
Planned length: 3,600-6,000 words of prose
Expected existing sources: 28, 29, 74, 75, 76

Part V: Regulation, Ethics and Responsibility

File: 24_regulation_as_constraint.md
Status: complete
Purpose: Map the instruments to the duties of developers and their organisations at article level [verify all]: AI Act Articles 4, 25, 26 and the GPAI provisions as they touch development tools; the Cyber Resilience Act (Regulation (EU) 2024/2847) for manufacturers and open-source stewards; Directive (EU) 2024/2853 on liability for defective products (software as a product); NIS 2 Article 21(2)(e) on secure development; DORA ICT risk and third-party rules; GDPR Articles 25 and 32; the Omnibus amendments.
Builds on: AI Governance, Chapter 3, AI Operations, Chapter 23, AI Leader, Chapter 24
Developer functions: D1 Frame; D2 Design; D3 Build; D4 Prove; D5 Steward
Sections: AI Act; Cyber Resilience Act; Product Liability Directive; NIS 2 and DORA; GDPR; Omnibus amendments; A mapping table
Practical guides: Keeping a regulation-to-duty mapping with an owner and a review date
Worked examples: A regulation-to-duty mapping table for development, with the artefact that evidences each duty
Nordvik Region and Hansa Mutual: The Cyber Resilience Act and DORA fall mainly on Hansa Mutual; public law and procurement law on Nordvik Region. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: In-force duties are observable; application dates and implementing acts are expected; future liability case law is speculation.
Figure: From instrument to duty to evidence
Planned length: 3,600-6,000 words of prose
Expected existing sources: 1, 2, 3, 4, 5, 6

Chapter 25: Ethics, Professional Responsibility and the Developer's Judgement

File: 25_ethics_professional_responsibility_and_judgement.md
Status: complete
Purpose: Treat where law ends and judgement starts: professional codes (ACM, IEEE, national societies [verify]), refusing to build harm, dual use, accessibility and inclusion, honesty about AI provenance, bias in what is built and whistle-blowing.
Builds on: AI Leader, Chapter 25, AI Governance, Chapter 13, AI Threat, Chapter 14
Developer functions: D1 Frame; D2 Design; D5 Steward
Sections: Professional codes; Refusing to build harm; Accessibility and inclusion; Honesty about provenance; Bias in what is built; Whistle-blowing; A values-to-rule mapping
Practical guides: Mapping three of the organisation's values to checkable engineering rules
Worked examples: A values-to-engineering-rule mapping for a development team
Nordvik Region and Hansa Mutual: Nordvik Region's public-service values and Hansa Mutual's customer-fairness values are mapped to rules. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: Codes and duties are observable; routine disclosure of AI provenance is expected; licensing of developers is speculation.
Figure: From value to rule to evidence
Planned length: 3,600-6,000 words of prose
Expected existing sources: 1, 4, 162

Chapter 26: Intellectual Property, Open Source and Sovereignty in the Toolchain

File: 26_intellectual_property_open_source_and_sovereignty.md
Status: complete
Purpose: Treat intellectual property, open source and sovereignty in the toolchain: copyright in generated code, licence contamination, the text-and-data-mining exceptions (Directive (EU) 2019/790) and the AI Act's copyright provisions [verify]; litigation as signal (public cases [verify]); open-source dependence and maintainers' load; dependence on a few model providers, exit and European alternatives; self-hosted models. Pointers to AI Operations (exit) and AI Leader Chapter 26.
Builds on: AI Leader, Chapter 26, AI Operations, Chapter 23, AI Platform and Security, Chapter 13
Developer functions: D2 Design; D3 Build; D5 Steward
Sections: Copyright in generated code; Licence contamination; TDM exceptions and the AI Act; Litigation as signal; Open source and maintainers' load; Dependence and exit; A toolchain dependency and exit record
Practical guides: Recording the dependencies of the coding toolchain with an exit route and a tested alternative
Worked examples: A toolchain dependency and exit record for an AI coding assistant and the registry
Nordvik Region and Hansa Mutual: Nordvik Region prefers European and self-hosted options where feasible; Hansa Mutual accepts a global provider with a contractual exit. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: Pending cases and provider concentration are observable; clearer licensing rules are expected; fully sovereign toolchains are speculation.
Figure: The toolchain dependency map with exits
Planned length: 3,600-6,000 words of prose
Expected existing sources: 1, 2, 170

Part VI: The Developer as a Person

Chapter 27: Competences and Developing the Developer

File: 27_competences_and_developing_the_developer.md
Status: complete
Purpose: Treat what a developer needs now: framing, reading code, verification, delegation design, system thinking and AI literacy under Article 4; evidence of competence rather than attendance; career ladders; frameworks (SFIA, e-CF, DigComp [verify]); hiring and interviewing when AI exists.
Builds on: AI Leader, Chapter 27, The Transformed Security Architect, Chapter 14, AI Operations, Chapter 25
Developer functions: D1 Frame; D2 Design; D3 Build; D4 Prove; D5 Steward
Sections: The competence profile; AI literacy under Article 4; Evidence of competence; Frameworks; Career ladders; Hiring and interviewing; A competence record
Practical guides: Writing a competence record and development plan for a mid-level developer
Worked examples: CMP-NR-* competence record with evidence dates and a development plan
Nordvik Region and Hansa Mutual: Nordvik Region ties competence to collective-agreement grades; Hansa Mutual uses a career framework with levels. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: AI literacy duties are observable; verification competence in job profiles is expected; automated assessment of developers is speculation.
Figure: From competence profile to evidence and development
Planned length: 3,600-6,000 words of prose
Expected existing sources: 1, 23, 59

Chapter 28: The Developer's Own Mind: Craft, Flow, Cognitive Offloading and Identity

File: 28_the_developers_own_mind.md
Status: complete
Purpose: Treat the developer's own mind: what studies measured on offloading, skill atrophy, complacency and overreliance with coding assistants [verify]; flow, craft pride and loss; identity when the typing goes; stress, boredom and wellbeing; how developers keep their skill in practice (AI-off days, reading, katas).
Builds on: AI Threat, Chapter 14, AI Leader, Chapter 28, AI Operations, Chapter 26
Developer functions: D3 Build; D4 Prove
Sections: What studies measured; Flow and craft; Identity; Stress, boredom and wellbeing; Keeping skill in practice; A practice plan
Practical guides: Agreeing a practice plan with AI-off sessions and code-reading time
Worked examples: A developer's practice plan for a quarter
Nordvik Region and Hansa Mutual: Nordvik Region's developers value public-service purpose; Hansa Mutual's value speed and ownership. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: Offloading effects in studies are observable with their conditions; deliberate practice schemes are expected; widespread skill loss is speculation.
Figure: The skill loop: use, offload, practise, verify
Planned length: 3,600-6,000 words of prose
Expected existing sources: 56, 57, 64, 65, 67

Chapter 29: The Future of the Developer: Fewer, More or Different?

File: 29_the_future_of_the_developer.md
Status: complete
Purpose: Give the outlook with labels: employment and demand, agent-heavy teams, specification as the main artefact, regulation, offshoring, open source and education. Stage a constructive debate on whether there will be fewer, more or different developers, give the author's labelled projections and a verdict.
Builds on: AI Governance, Chapter 22, AI Leader, Chapter 29, AI Threat, Chapter 4, AI Operations, Chapter 27
Developer functions: D1 Frame; D2 Design; D3 Build; D4 Prove; D5 Steward
Sections: Employment and demand; Agent-heavy teams; Specification as the main artefact; Regulation, offshoring and open source; Education; The debate; The author's projections; Verdict
Constructive debate: Concern: If AI performs the translation from specification to code, demand for developers could fall sharply, entry routes close and the profession shrink to a few verifiers. Calm: Software demand has always expanded when cost fell; verification, framing and stewardship are large unmet needs; earlier automation changed the role without removing it. Where they meet: Both accept that the number is less important than the shape of the work, that evidence is young, and that the route to seniority must be kept open. What can be done: Keep a horizon register, track signposts, keep the junior route, invest in verification and review the plan yearly.
Practical guides: Writing a horizon register with trigger conditions for revisiting the plan
Worked examples: HZN-NR-* horizon register with signposts and review dates
Nordvik Region and Hansa Mutual: Both organisations keep a horizon register. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the outlook against the usage modes and the delegation ladder, with labels.
Observable, expected, speculation: The author's own projections are kept in this chapter and Chapter 33 and labelled.
Figure: Trajectories for the developer role: observable, expected, speculation
Planned length: 3,600-6,000 words of prose
Expected existing sources: 42, 68, 78, 79

Part VII: Experience and Conclusions

Chapter 30: Case Studies and Anti-Patterns

File: 30_case_studies_and_anti_patterns.md
Status: complete
Purpose: Analyse verified public cases with the book's lenses (for example a code-generation tool incident, a package-hallucination or malicious-package case, a legacy modernisation with AI, a company that reversed a headcount decision, a public-sector software failure; each verified against primary reports, drop any that cannot be verified) and catalogue the anti-patterns: the acceptance-rate dashboard, the unowned agent, the generated test that proves nothing, the junior hole, the review rubber stamp, the secret in the prompt and the vibe-coded production system.
Builds on: AI Governance, Chapter 19, AI Operations, Chapter 28, AI Leader, Chapter 30
Developer functions: D1 Frame; D2 Design; D3 Build; D4 Prove; D5 Steward
Sections: How cases were chosen and verified; Cases by mechanism; Anti-patterns; What recurs; What would have prevented them
Practical guides: Reviewing one's own estate against the anti-pattern catalogue
Worked examples: An anti-pattern checklist with the function and test each one violates
Nordvik Region and Hansa Mutual: Both organisations check themselves against the catalogue. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: Verified cases are observable; recurrence of the anti-patterns is expected; attribution to AI where reports do not support it is avoided.
Figure: Anti-patterns placed on the developer loop
Planned length: 3,600-6,000 words of prose
Expected existing sources: 28, 29, 33

Chapter 31: A Year in Development: Nordvik Region and Hansa Mutual

File: 31_a_year_in_development.md
Status: complete
Purpose: Follow named developers in the two organisations through a year, month by month: a tool rollout, a review incident, a junior's first quarter, a works-council agreement, a supply-chain scare, a legacy migration and a drill with the agent switched off.
Builds on: AI Operations, Chapter 29, AI Leader, Chapter 31, AI Blue, Chapter 26
Developer functions: D1 Frame; D2 Design; D3 Build; D4 Prove; D5 Steward
Sections: January to March; April to June; July to September; October to December; What the year shows
Practical guides: Reading the year as a case for one's own team
Worked examples: A month-by-month timeline of both organisations with the records produced
Nordvik Region and Hansa Mutual: Characters are defined in the development profiles. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: The narrative is illustrative and fictional; labels apply to any forward-looking statement.
Figure: A year in development: timeline of events and records
Planned length: 3,600-6,000 words of prose
Expected existing sources: 170

Chapter 32: Nordvik Region and Hansa Mutual: Conclusions for Two Organisations

File: 32_conclusions_for_nordvik_and_hansa.md
Status: complete
Purpose: Draw per-organisation conclusions: a 12-month plan, decisions for leadership, KPIs of the book's own claims and risks.
Builds on: AI Leader, Chapter 32, AI Operations, Chapter 30
Developer functions: D1 Frame; D2 Design; D3 Build; D4 Prove; D5 Steward
Sections: Nordvik Region; Hansa Mutual; Decisions for leadership; KPIs of the book's claims; Risks
Practical guides: Using the plan as a template for an own organisation
Worked examples: A twelve-month plan table per organisation
Nordvik Region and Hansa Mutual: Both organisations' plans follow from their development profiles. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the usage modes (Mode 0 Ambient AI to Mode 5 Autonomous production agents) against the subject, with the highest degree of delegation each has been allowed.
Observable, expected, speculation: The plan is the author's recommendation; labels apply to forecasts.
Figure: Twelve-month plan for two organisations
Planned length: 3,600-6,000 words of prose

Chapter 33: Conclusion

File: 33_conclusion.md
Status: complete
Purpose: Judge the thesis against the evidence: what is established, expected and speculation; the author's projections (labelled); five things a reader does on Monday.
Builds on: AI Leader, Chapter 33, AI Operations, Chapter 31, AI Purple, Chapter 15
Developer functions: D1 Frame; D2 Design; D3 Build; D4 Prove; D5 Steward
Sections: The thesis, part by part; What would show it wrong; The author's projections; Five things for Monday; The series' argument
Practical guides: Doing the five Monday actions in one week
Worked examples: A one-page Monday plan for a developer or team
Nordvik Region and Hansa Mutual: Both organisations' next steps are summarised. The details follow the development profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the thesis parts against labels.
Observable, expected, speculation: The author's projections are kept in this chapter and Chapter 29 and labelled.
Figure: The thesis judged: five parts, five labels
Planned length: 3,600-6,000 words of prose

Appendices

34_glossary.md: Defines the vocabulary of development with AI: the five functions (D1 Frame to D5 Steward), the classes of development work, the degrees of delegation and usage modes, the stewardship principle (Name, Understand, Revert), the independent test oracle, the book's artefacts (specification record, code-ownership record, verification plan, review record, agent run record, provenance record, adoption and value record, apprenticeship plan, role charter, mandate manifest, competence record), and the terms of the AI Act, the Cyber Resilience Act, the Product Liability Directive, NIS 2, DORA, the GDPR and the co-determination regimes. Terms from the earlier volumes are repeated briefly.
35_appendix_a_code_examples.md: Appendix A: complete versions of the artefacts in the chapters: delegation profile, mandate manifest for a coding agent, specification record, code-ownership record, verification plan with an independent oracle, review record, agent run record, provenance record, adoption and value record, apprenticeship plan, competence record and change record. Each is a complete, valid file that the chapters show in part, with the field names and the identifier scheme. No attack tooling.
appendix_templates_and_tools.md: Appendix B: templates and tools: development delegation profile, stewardship test checklist (Name, Understand, Revert), verification plan template, ownership record template, adoption claim template and apprenticeship plan template.
36_references.md: The only bibliography of the book: European instruments on AI, cyber resilience, product liability, data protection and employment, frameworks and standards, AI incident and agent sources, research on software development, automation and skill, practitioner literature and the earlier volumes of the series. Only verified sources are listed.
37_about_the_author.md: About the author of The Architecture as Code Series, placed at the very end of the book. The chapter carries the author's professional background, the lineage from Architecture as Code to this book, a note on Kvadrat, and the note on how the book was made: the design of the book, the review and approval of every change, the judgement and the answer for the sources remain the author's, whatever the agents drafted.