Book Blueprint and Chapter Briefs

This file records the editorial brief for each chapter of Vibe to Dev. The briefs below are generated from scripts/outline_data.py by scripts/generate_outlines.py; edit the data, not the generated section. The design of the whole book is fixed in DISPOSITION.md.

Part I: The Gap

Chapter 1: Introduction: From Vibe to Dev

File: 01_introduction.md
Status: outline
Purpose: Introduce the book to a reader who is not a developer and has perhaps already built something with an AI assistant. State the promise and its limits: following the twelve steps does not make a developer, it makes software that a developer would recognise as professionally made and a builder who knows where their own competence ends. Show the twelve steps on one page, introduce the two builders and the two organisations, define the terms used (vibe coding, builder, tier, gate, artefact, takeover test), explain how to follow the book with a build in hand, and give reading paths for builders, developers who receive their work, platform engineers, leaders, data protection officers and representatives.
Builds on: AI Developer, Chapter 19, AI Developer, Chapter 4, AI Governance, Chapter 22, AI Leader, Chapter 10
Developer functions: D1 Frame; D2 Design; D3 Build; D4 Prove; D5 Steward
Sections: A tool that worked until Monday; What this book promises; The gap, in one paragraph; The twelve steps on one page; Terms used in the book; Two builders, two organisations; How to follow the book; Rules of the book; How to read this book
Practical guides: A one-page inventory of what you have built or are building with an assistant, with who uses it and what data it touches
Worked examples: The twelve steps as a one-page checklist, with gate and artefact
Nordvik Region and Hansa Mutual: Both builders are introduced in a scene from their work; Nordvik Region's service-point-check and Hansa Mutual's claims-doc-check run through Chapters 5 to 16 and are told in full in Chapter 23. The details follow the builder 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 the builder's tools: Mode 1 conversational assistant, Mode 2 editor assistant, Mode 3 agentic work tool; Mode 5 is not for builders.
Observable, expected, speculation: Builders using assistants and app builders is observable; organisations offering sanctioned builder workspaces is expected; builders replacing developers is speculation (Chapters 20 and 25). The thesis is the book's own claim, judged in Chapters 20 and 25.
Figure: The twelve steps on one page from intent to handover, with the four tiers beneath
Planned length: 4,500-6,000 words of prose

Chapter 2: What Vibe Coding Is, and What It Does Well

File: 02_what_vibe_coding_is.md
Status: outline
Purpose: Describe vibe coding fairly: the term and its origin, the tools that make it possible (chat assistants, natural-language app builders, agentic editors), what it does well (exploration, prototypes, personal tools, learning), and what studies, vendor reports and incident reports show about the quality, security and maintainability of what it produces. Separate measurement from anecdote. Give the honest case for vibe coding before the gap is described in Chapter 3.
Builds on: AI Developer, Chapter 7, AI Developer, Chapter 19, AI Threat, Chapter 14
Developer functions: D1 Frame; D3 Build; D4 Prove
Sections: A name for a way of working; The tools; What it does well; What the evidence says about quality; What the evidence says about security; Failure patterns; The honest case; What this means for the steps
Practical guides: A self-check: which of the six failure patterns apply to the tool you have already built
Worked examples: A failure-pattern table linking each pattern to the step that prevents it
Nordvik Region and Hansa Mutual: Hanna's first prototype and Katarzyna's first attempt are shown as vibe-coded starting points with their specific failure patterns. The details follow the builder profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Usage modes 1 to 3 as the builder meets them; app builders that host the result are a Mode 3 or a platform of their own and carry hosting and data duties.
Observable, expected, speculation: The spread of builders and the failure patterns are observable; improving defaults in tools are expected; claims that tools will make structure unnecessary are speculation.
Figure: From conversation to application: what is hidden at each stage of vibe coding
Planned length: 4,000-5,800 words of prose

Chapter 3: What Developers Do: The Gap Described

File: 03_what_developers_do.md
Status: outline
Purpose: Describe the gap. Show that a developer's work is largely not typing: the iceberg of work beneath the visible code. Name twelve disciplines (the twelve steps seen from the professional's side), say for each what a professional does, what a vibe coder usually has instead and what the consequence is, and map them to the five developer functions of AI Developer. Say what AI changed (it lowers the cost of every discipline) and what it did not (ownership, independence, judgement).
Builds on: AI Developer, Chapter 2, AI Developer, Chapter 4, AI Developer, Chapter 9, Architecture as Code (Chapter 4)
Developer functions: D1 Frame; D2 Design; D3 Build; D4 Prove; D5 Steward
Sections: The visible part; The work beneath; Twelve disciplines; The gap map; What AI changed; The edge
Practical guides: Score your current build against the twelve disciplines: present, partly, absent, with evidence
Worked examples: The gap map as a table
Nordvik Region and Hansa Mutual: The gap map is applied to both builders' first versions. The details follow the builder profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Which disciplines each usage mode helps with: Mode 1 explains and drafts, Mode 3 runs tests and commands within a mandate.
Observable, expected, speculation: What developers do is observable; that AI lowers the cost of the disciplines is observable in part and expected in part; that disciplines disappear is speculation.
Figure: The iceberg: visible code above, twelve disciplines below the waterline
Planned length: 4,000-5,800 words of prose

Chapter 4: The Method: Twelve Steps, Four Tiers and the Takeover Test

File: 04_the_method.md
Status: outline
Purpose: The central chapter. Define the method: the twelve steps with their gate and artefact each; the four tiers (A personal, B team, C business, D project) from AI Developer, Chapter 19, and the proportion table of what each step requires at each tier; the takeover test; the stewardship principle (Name, Understand, Revert) and the independent test oracle applied to the builder; the builder's mandate for the assistant and the delegation ladder with the Level 4 prohibitions; the usage modes for builders; the build record BLD as the one artefact that carries the whole build; the five developer functions as the professional practice behind the steps.
Builds on: AI Developer, Chapter 4, AI Developer, Chapter 19, AI Operations, Chapter 17, AI Leader, Chapter 4, AI Purple, Chapter 15
Developer functions: D1 Frame; D2 Design; D3 Build; D4 Prove; D5 Steward
Sections: Why a method; The twelve steps; The four tiers; Proportion; The takeover test; The stewardship principle for a builder; The assistant's mandate; The build record; Usage modes for builders
Practical guides: Create a build record for your own build and set its tier provisionally
Worked examples: BLD record template; proportion table as data; takeover-test checklist
Nordvik Region and Hansa Mutual: The two build records BLD-NR-2031-0001 and BLD-HM-2031-0001 are shown at the start. The details follow the builder profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: The full table of the usage modes against the builder's assistant with the highest degree of delegation each may have; the Level 4 prohibitions restated.
Observable, expected, speculation: The method is the book's own; that organisations adopt tiers and registers is expected; that a registry of builders is mandated by law is speculation.
Figure: The twelve steps, four tiers and takeover test in one figure
Planned length: 5,000-6,200 words of prose

Part II: Getting Ready

Chapter 5: Step 1 Intent: Say What You Are Building, for Whom and How You Will Know

File: 05_step_1_intent.md
Status: outline
Purpose: Step 1 Intent. Say what you are building, for whom, and how you will know it works. Teach the one-page intent: purpose in one sentence, the user, the problem now, the success measure, what done looks like, what it is not (non-goals), who else is affected. Show how to use the assistant as an interviewer who asks questions, not as the author of the requirement. Step chapters share one form (authoring guide, rule 19): what a developer does at this step; what vibe coding does instead and the gap; how AI helps and where it misleads; proportion by tier (A to D); the practical guide with its exit gate and artefact; the worked example of the two builds; when to call a developer.
Builds on: AI Developer, Chapter 5, AI Governance, Chapter 22
Developer functions: D1 Frame
Sections: What a developer does first; What vibe coding does instead; The one-page intent; Using the assistant as interviewer; Proportion by tier; Practical guide: Writing the intent; When to call a developer
Practical guides: Practical guide: Writing the one-page intent with an assistant as interviewer
Worked examples: The intent section of BLD-NR-2031-0001 and BLD-HM-2031-0001
Nordvik Region and Hansa Mutual: Hanna Wikström (Nordvik Region, service-point-check) and Katarzyna Nowak (Hansa Mutual, claims-doc-check) at this step. Nordvik Region: Hanna's intent: one consistent set of opening hours and service notices for the 24 service points; success measure is fewer mismatch calls to the phone service. Hanna's first sentence. Hansa Mutual: Katarzyna's intent: a list of missing documents per motor property-damage claim and a draft request text for the handler; success measure is time to complete file. The details follow the builder profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the degrees of delegation (Level 0 Advisory to Level 4 Autonomous) for what the builder's assistant may do at this step, with the usage mode of the tool (Mode 1 Conversational assistant to Mode 3 Agentic work tool for most builders) and the Level 4 prohibitions that apply.
Observable, expected, speculation: That an assistant can interview a builder well is observable in part; that intent can be captured once and stay valid is not: it expires with the work.
Figure: From a first prompt to a one-page intent with a gate
Planned length: 3,800-5,800 words of prose

Chapter 6: Step 2 Tier: Decide How Much Structure the Work Needs

File: 06_step_2_tier.md
Status: outline
Purpose: Step 2 Tier. Decide how much structure the work needs. Teach the five questions (who uses it, what data, what can go wrong, which law, does it run unattended) and the classification into Tier A to D, with crossing signals and the stop signs of Tier D. Explain GDPR, AI Act and sector screening in plain terms and say when the data protection officer and a developer must be involved. Teach that saying no, or stopping at Tier A, is professional. Step chapters share one form (authoring guide, rule 19): what a developer does at this step; what vibe coding does instead and the gap; how AI helps and where it misleads; proportion by tier (A to D); the practical guide with its exit gate and artefact; the worked example of the two builds; when to call a developer.
Builds on: AI Developer, Chapter 19, AI Developer, Chapter 24, AI Governance, Chapter 13
Developer functions: D1 Frame; D2 Design
Sections: What a developer asks before building; What vibe coding does instead; The five questions; Four tiers and what changes; Law in plain terms; Tier D: the stop signs; Practical guide: Classifying a build; When to call a developer
Practical guides: Practical guide: Classifying a build and recording the tier decision
Worked examples: The tier decision of both builds, with the signals that would reclassify
Nordvik Region and Hansa Mutual: Hanna Wikström (Nordvik Region, service-point-check) and Katarzyna Nowak (Hansa Mutual, claims-doc-check) at this step. Nordvik Region: service-point-check is Tier B as a manual, one-team tool on public data and becomes Tier C when it runs on a schedule and serves service-point managers in other units. Hansa Mutual: claims-doc-check is Tier C from the start (personal data of claimants); free-text may contain injury and health data, so the scope is limited to property-damage claims; injury claims are out of scope and the reason is recorded. The details follow the builder profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the degrees of delegation (Level 0 Advisory to Level 4 Autonomous) for what the builder's assistant may do at this step, with the usage mode of the tool (Mode 1 Conversational assistant to Mode 3 Agentic work tool for most builders) and the Level 4 prohibitions that apply.
Observable, expected, speculation: Tier classification is the book's own and follows AI Developer; that supervisors expect such classification is expected; none of it is legal advice.
Figure: Five questions to a tier, with the stop signs of Tier D
Planned length: 3,800-5,800 words of prose

Chapter 7: Step 3 Workshop: Version Control, Environments, Secrets and the Assistant's Rules

File: 07_step_3_workshop.md
Status: outline
Purpose: Step 3 Workshop. Set up a workshop that can be trusted: version control from nothing (what a repository, a commit and a branch are, in plain language), the repository and its README, separate places for experiments and for users (environments), secrets and configuration kept out of the code, synthetic data for development, and the assistant's project rules file (AGENTS.md) and mandate. Teach the clone-and-restore test. Step chapters share one form (authoring guide, rule 19): what a developer does at this step; what vibe coding does instead and the gap; how AI helps and where it misleads; proportion by tier (A to D); the practical guide with its exit gate and artefact; the worked example of the two builds; when to call a developer.
Builds on: Architecture as Code (Chapter 4), AI Developer, Chapter 8, AI Developer, Chapter 11
Developer functions: D3 Build; D5 Steward
Sections: What a developer sets up first; What vibe coding does instead; Version control from nothing; Environments; Secrets and configuration; Synthetic data; The assistant's rules and mandate; Practical guide: Setting up the workshop; When to call a developer
Practical guides: Practical guide: Setting up the repository, environments, secrets handling and the assistant's rules; the clone-and-restore test
Worked examples: AGENTS.md, .gitignore, an environment configuration file, the mandate MND-NR-BLD-2031-01 and MND-HM-BLD-2031-01
Nordvik Region and Hansa Mutual: Hanna Wikström (Nordvik Region, service-point-check) and Katarzyna Nowak (Hansa Mutual, claims-doc-check) at this step. Nordvik Region: Hanna works in the Region's Git service in the builder workspace, development and production separated by the platform's scheduled-job template; her mandate allows the assistant to run tests but not to read the production configuration. Hansa Mutual: Katarzyna works only on synthetic claim exports; production exports are read inside the claims analytics workspace by the pipeline identity, never by her assistant. The details follow the builder profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the degrees of delegation (Level 0 Advisory to Level 4 Autonomous) for what the builder's assistant may do at this step, with the usage mode of the tool (Mode 1 Conversational assistant to Mode 3 Agentic work tool for most builders) and the Level 4 prohibitions that apply.
Observable, expected, speculation: Version control and environments are established practice; assistants that read repository rules files are observable; that rules files are honoured reliably is not guaranteed.
Figure: Workshop: repository, environments, secrets and the assistant's mandate
Planned length: 3,800-5,800 words of prose

Part III: Building

Chapter 8: Step 4 Specification: Write Down What Correct Means

File: 08_step_4_specification.md
Status: outline
Purpose: Step 4 Specification. Write down what correct means. Teach the specification as the source of intent for both the builder and the assistant: acceptance criteria as concrete examples (given, when, then), failure and edge cases, what the tool must never do, who owns the oracle. Explain spec-driven work with an assistant, and why the examples are written before the code. Step chapters share one form (authoring guide, rule 19): what a developer does at this step; what vibe coding does instead and the gap; how AI helps and where it misleads; proportion by tier (A to D); the practical guide with its exit gate and artefact; the worked example of the two builds; when to call a developer.
Builds on: AI Developer, Chapter 5, AI Developer, Chapter 9, Architecture as Code (Chapter 4)
Developer functions: D1 Frame
Sections: What a developer writes before the code; What vibe coding does instead; Acceptance criteria as examples; Failure and never-do cases; The oracle and its owner; Working with the assistant on the specification; Practical guide: Writing the specification; When to call a developer
Practical guides: Practical guide: Writing a specification record with acceptance examples and failure cases
Worked examples: SPC-NR-2031-0001 and SPC-HM-2031-0001 with examples as YAML
Nordvik Region and Hansa Mutual: Hanna Wikström (Nordvik Region, service-point-check) and Katarzyna Nowak (Hansa Mutual, claims-doc-check) at this step. Nordvik Region: Hanna's examples come from real, published opening-hours entries; the oracle owner is Saga Edvardsson (existing, quality engineer). Hansa Mutual: Katarzyna's examples are synthetic claims; the oracle owner is a claims team lead who did not write the checker. The details follow the builder profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the degrees of delegation (Level 0 Advisory to Level 4 Autonomous) for what the builder's assistant may do at this step, with the usage mode of the tool (Mode 1 Conversational assistant to Mode 3 Agentic work tool for most builders) and the Level 4 prohibitions that apply.
Observable, expected, speculation: That specification-first work improves assistant output is plausible and partly observed; the book labels it expected where no study is cited.
Figure: From intent to executable examples, with the oracle owned outside the generator
Planned length: 3,800-5,800 words of prose

Chapter 9: Step 5 Design: Choose Boring Technology and Record Decisions

File: 09_step_5_design.md
Status: outline
Purpose: Step 5 Design. Choose boring technology and record decisions. Teach the builder to decide, with the assistant's help but not by its default: a simple stack that a developer in the organisation can maintain, where the data lives and who can reach it, identity and access, accessibility and language, cost and exit, and Architecture Decision Records. Produce a one-page design that a reviewer can read in ten minutes. Step chapters share one form (authoring guide, rule 19): what a developer does at this step; what vibe coding does instead and the gap; how AI helps and where it misleads; proportion by tier (A to D); the practical guide with its exit gate and artefact; the worked example of the two builds; when to call a developer.
Builds on: AI Developer, Chapter 6, AI Developer, Chapter 16, Architecture as Code (Chapter 4), The Transformed Security Architect, Chapter 5
Developer functions: D2 Design
Sections: What a developer decides before building; What vibe coding does instead; Boring technology; Data and access; Accessibility, language and usability; Cost and exit; Architecture decision records; Practical guide: The one-page design; When to call a developer
Practical guides: Practical guide: Writing the one-page design and three ADRs
Worked examples: ADR examples and a data-flow sketch as a Mermaid diagram
Nordvik Region and Hansa Mutual: Hanna Wikström (Nordvik Region, service-point-check) and Katarzyna Nowak (Hansa Mutual, claims-doc-check) at this step. Nordvik Region: Hanna chooses the platform team's scheduled-job template (Python) and publishes the report to the team's existing wiki; no new hosting. Hansa Mutual: Katarzyna chooses a command-line tool run by the group's pipeline inside the claims analytics workspace; no web front end; output is a CSV and a text draft. The details follow the builder profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the degrees of delegation (Level 0 Advisory to Level 4 Autonomous) for what the builder's assistant may do at this step, with the usage mode of the tool (Mode 1 Conversational assistant to Mode 3 Agentic work tool for most builders) and the Level 4 prohibitions that apply.
Observable, expected, speculation: That a few standard stacks cover most builders' needs is observable; that assistants will pick maintainable stacks unprompted is not shown.
Figure: Design decisions with human decision points and the assistant's part recorded
Planned length: 3,800-5,800 words of prose

Chapter 10: Step 6 Build: Small Slices with an Assistant Under a Mandate

File: 10_step_6_build.md
Status: outline
Purpose: Step 6 Build. Build in small slices with an assistant under a mandate. Teach the working rhythm: ask for a plan before code, take one slice at a time, read the diff, run the tests, commit, record what the assistant did, and know when to restart the conversation. Cover debugging with an assistant, context and cost, and the limits of what a builder can judge from reading. Step chapters share one form (authoring guide, rule 19): what a developer does at this step; what vibe coding does instead and the gap; how AI helps and where it misleads; proportion by tier (A to D); the practical guide with its exit gate and artefact; the worked example of the two builds; when to call a developer.
Builds on: AI Developer, Chapter 7, AI Developer, Chapter 8, AI Threat, Chapter 14
Developer functions: D3 Build
Sections: What a developer does while building; What vibe coding does instead; The slice rhythm; Directing the assistant; Reading what you cannot write; Debugging with an assistant; Run records; Practical guide: One slice end to end; When to call a developer
Practical guides: Practical guide: Building one slice end to end with plan, tests, diff reading, commit and run record
Worked examples: A RUN record, a commit message convention, a plan prompt (ordinary instruction, no injection strings)
Nordvik Region and Hansa Mutual: Hanna Wikström (Nordvik Region, service-point-check) and Katarzyna Nowak (Hansa Mutual, claims-doc-check) at this step. Nordvik Region: Hanna builds the comparison of opening hours as slice 1, the notice check as slice 2, the report as slice 3. Hansa Mutual: Katarzyna builds the document-type rules as slice 1, the missing-document list as slice 2, the request-text draft as slice 3. The details follow the builder profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the degrees of delegation (Level 0 Advisory to Level 4 Autonomous) for what the builder's assistant may do at this step, with the usage mode of the tool (Mode 1 Conversational assistant to Mode 3 Agentic work tool for most builders) and the Level 4 prohibitions that apply.
Observable, expected, speculation: Controlled evidence on assistants (METR, Peng, Cui) is observable and mixed [verify]; that the slice rhythm is better for non-developers is the book's own conclusion, not a measured result.
Figure: The slice loop: plan, build, test, read, commit, with the stop path
Planned length: 3,800-5,800 words of prose

Part IV: Proving and Securing

Chapter 11: Step 7 Prove: Tests, Review and an Independent Oracle

File: 11_step_7_prove.md
Status: outline
Purpose: Step 7 Prove. Show that it works, by something other than the assistant's say-so. Teach what an automated test is, how tests come from the specification, the independent oracle (cases written by someone or something other than the author and the assistant), review by a person who did not write it, static checks, and why high coverage can prove little. Produce a verification plan and a review record. Step chapters share one form (authoring guide, rule 19): what a developer does at this step; what vibe coding does instead and the gap; how AI helps and where it misleads; proportion by tier (A to D); the practical guide with its exit gate and artefact; the worked example of the two builds; when to call a developer.
Builds on: AI Developer, Chapter 9, AI Purple, Chapter 15, Architecture as Code (Chapter 4)
Developer functions: D4 Prove
Sections: What a developer does to prove it; What vibe coding does instead; Tests from the specification; The independent oracle; Review by someone else; Static checks; When tests prove little; Practical guide: The verification plan; When to call a developer
Practical guides: Practical guide: Writing the verification plan, running the oracle cases and recording a review
Worked examples: VER and RVW records; a pytest file generated from the specification examples; an oracle case file
Nordvik Region and Hansa Mutual: Hanna Wikström (Nordvik Region, service-point-check) and Katarzyna Nowak (Hansa Mutual, claims-doc-check) at this step. Nordvik Region: Saga Edvardsson writes twelve of the oracle cases from real notices; Anders Falk (existing) reviews. Hansa Mutual: A claims team lead writes the oracle cases; a developer from Group Application Development reviews. The details follow the builder profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the degrees of delegation (Level 0 Advisory to Level 4 Autonomous) for what the builder's assistant may do at this step, with the usage mode of the tool (Mode 1 Conversational assistant to Mode 3 Agentic work tool for most builders) and the Level 4 prohibitions that apply.
Observable, expected, speculation: Evidence on AI review and test generation is mixed [verify]; that independent oracles are needed is the book's conclusion drawn from the series.
Figure: Evidence of correctness from independent checks
Planned length: 3,800-5,800 words of prose

Chapter 12: Step 8 Secure: Secrets, Dependencies, Access and Personal Data

File: 12_step_8_secure.md
Status: outline
Purpose: Step 8 Secure. Make it safe, at the level the tier requires. Teach, in plain language and defensively, the classes of problem that generated applications show: secrets in the code, an open data store, missing access control, unchecked input, dependencies that are unmaintained or do not exist (package hallucination), personal data in logs, and prompt injection where the tool calls a model. Teach the security checklist by tier and the provenance record. No exploit code, payloads or injection strings. Step chapters share one form (authoring guide, rule 19): what a developer does at this step; what vibe coding does instead and the gap; how AI helps and where it misleads; proportion by tier (A to D); the practical guide with its exit gate and artefact; the worked example of the two builds; when to call a developer.
Builds on: AI Developer, Chapter 10, AI Platform and Security, Chapter 16, AI Red Team, Chapter 14
Developer functions: D4 Prove
Sections: What a developer does for security; What vibe coding does instead; Secrets and access; Dependencies and provenance; Input and output; Personal data; The checklist by tier; Practical guide: The security pass; When to call a developer
Practical guides: Practical guide: Running the security checklist for the tier and writing the provenance record
Worked examples: PRV record; a pre-commit secret-scan configuration; a dependency-policy file
Nordvik Region and Hansa Mutual: Hanna Wikström (Nordvik Region, service-point-check) and Katarzyna Nowak (Hansa Mutual, claims-doc-check) at this step. Nordvik Region: Hanna's tool reads public data and uses one internal wiki token held in the platform's secret store. Hansa Mutual: Katarzyna's tool processes claimant data inside the workspace; logs hold claim identifiers only; the data protection officer's screening is attached. The details follow the builder profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the degrees of delegation (Level 0 Advisory to Level 4 Autonomous) for what the builder's assistant may do at this step, with the usage mode of the tool (Mode 1 Conversational assistant to Mode 3 Agentic work tool for most builders) and the Level 4 prohibitions that apply.
Observable, expected, speculation: Studies of vulnerabilities in generated code are observable [verify]; that tools will remove these classes by default is expected only in part; none is shown.
Figure: The security pass by tier
Planned length: 3,800-5,800 words of prose

Part V: Shipping, Running and Owning

Chapter 13: Step 9 Ship: Pipelines, Environments, Releases and Rollback

File: 13_step_9_ship.md
Status: outline
Purpose: Step 9 Ship. Ship through a path that can be undone. Teach environments and promotion, the pipeline as the only way to production, versions and tags, release notes, rollback and the Revert test, and the change record. Cover what to do when there is no platform pipeline and why the answer is to ask for one. Step chapters share one form (authoring guide, rule 19): what a developer does at this step; what vibe coding does instead and the gap; how AI helps and where it misleads; proportion by tier (A to D); the practical guide with its exit gate and artefact; the worked example of the two builds; when to call a developer.
Builds on: AI Developer, Chapter 11, AI Operations, Chapter 17, Architecture as Code (Chapter 4)
Developer functions: D5 Steward
Sections: What a developer does to release; What vibe coding does instead; The pipeline; Versions and release notes; Rollback and the Revert test; The change record; Practical guide: The first release; When to call a developer
Practical guides: Practical guide: Setting up a minimal pipeline, releasing version 0.1.0 and practising rollback
Worked examples: A CI workflow as YAML; a CHG record; a rollback note
Nordvik Region and Hansa Mutual: Hanna Wikström (Nordvik Region, service-point-check) and Katarzyna Nowak (Hansa Mutual, claims-doc-check) at this step. Nordvik Region: Hanna's pipeline is the platform team's scheduled-job template; the release is promoted by the pipeline identity, not by her. Hansa Mutual: Katarzyna's release is promoted by the group's pipeline; the Revert test is run with her deputy. The details follow the builder profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the degrees of delegation (Level 0 Advisory to Level 4 Autonomous) for what the builder's assistant may do at this step, with the usage mode of the tool (Mode 1 Conversational assistant to Mode 3 Agentic work tool for most builders) and the Level 4 prohibitions that apply.
Observable, expected, speculation: Pipelines as practice are established; that builders have platform pipelines available is expected where organisations provide them (Chapter 17).
Figure: Release path with independent gates and a practised rollback
Planned length: 3,800-5,800 words of prose

Chapter 14: Step 10 Run: Watching, Backing Up, Paying for and Supporting What You Built

File: 14_step_10_run.md
Status: outline
Purpose: Step 10 Run. Run what you built: what to watch, logs without personal data, alerts that reach a person, backups and the restore test, cost limits, the support path, and the first hour of an incident. Produce a runbook and a restore-test record. Apply AI Operations at the builder's scale. Step chapters share one form (authoring guide, rule 19): what a developer does at this step; what vibe coding does instead and the gap; how AI helps and where it misleads; proportion by tier (A to D); the practical guide with its exit gate and artefact; the worked example of the two builds; when to call a developer.
Builds on: AI Operations, Chapter 17, AI Operations, Chapter 22, AI Developer, Chapter 11
Developer functions: D5 Steward
Sections: What a developer does after release; What vibe coding does instead; What to watch; Logs and personal data; Backups and restore tests; Costs; Support and incidents; Practical guide: The runbook and the restore test; When to call a developer
Practical guides: Practical guide: Writing a one-page runbook and running a restore test
Worked examples: An RBK runbook manifest, an RST restore-test record, an alert rule
Nordvik Region and Hansa Mutual: Hanna Wikström (Nordvik Region, service-point-check) and Katarzyna Nowak (Hansa Mutual, claims-doc-check) at this step. Nordvik Region: Hanna's run is a weekly job; the failure alert goes to the e-services team's channel; her deputy is Hanna's team colleague. Hansa Mutual: Katarzyna's run is on demand by handlers; failure alerts go to the claims analytics workspace support; cost limits on model use are set. The details follow the builder profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the degrees of delegation (Level 0 Advisory to Level 4 Autonomous) for what the builder's assistant may do at this step, with the usage mode of the tool (Mode 1 Conversational assistant to Mode 3 Agentic work tool for most builders) and the Level 4 prohibitions that apply.
Observable, expected, speculation: Resilience claims need evidence with an age (AI Operations); that tools ship observability for builders by default is expected in part.
Figure: What to watch and who answers, with the restore test
Planned length: 3,800-5,800 words of prose

Chapter 15: Step 11 Own: Documentation, Updates, Review and Sunset

File: 15_step_11_own.md
Status: outline
Purpose: Step 11 Own. Own it over time: the ownership record with owner and deputy, documentation that survives the builder, dependency and model updates, review dates, the explain-it-back drill (the Understand test without the assistant), and sunset. Say what happens to the tool when its builder changes job. Step chapters share one form (authoring guide, rule 19): what a developer does at this step; what vibe coding does instead and the gap; how AI helps and where it misleads; proportion by tier (A to D); the practical guide with its exit gate and artefact; the worked example of the two builds; when to call a developer.
Builds on: AI Developer, Chapter 12, AI Developer, Chapter 19, AI Leader, Chapter 12
Developer functions: D5 Steward
Sections: What a developer does over years; What vibe coding does instead; The ownership record; Documentation that survives the builder; Updates; The explain-it-back drill; Sunset; Practical guide: The ownership pack; When to call a developer
Practical guides: Practical guide: Writing the ownership record and running the explain-it-back drill
Worked examples: OWN record with review and sunset dates; a README skeleton
Nordvik Region and Hansa Mutual: Hanna Wikström (Nordvik Region, service-point-check) and Katarzyna Nowak (Hansa Mutual, claims-doc-check) at this step. Nordvik Region: OWN-NR-2031-0001: owner Hanna Wikström, deputy a named e-services colleague, sunset 2033-08-31. Hansa Mutual: OWN-HM-2031-0001: owner Katarzyna Nowak, deputy a named claims team colleague, sunset 2033-08-31. The details follow the builder profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the degrees of delegation (Level 0 Advisory to Level 4 Autonomous) for what the builder's assistant may do at this step, with the usage mode of the tool (Mode 1 Conversational assistant to Mode 3 Agentic work tool for most builders) and the Level 4 prohibitions that apply.
Observable, expected, speculation: Orphaned tools are observable (AI Developer found a share of repositories with absent owners); that ownership records reduce orphaning is expected.
Figure: Lifecycle of an owned tool with review dates and sunset
Planned length: 3,800-5,800 words of prose

Chapter 16: Step 12 Hand Over: The Takeover Test and Working with Developers

File: 16_step_12_hand_over.md
Status: outline
Purpose: Step 12 Hand over. Hand over, promote or stop. Teach the takeover test in practice and the handover pack, how a Tier B build is promoted to Tier C, when and how to call a developer and what to bring, how to work with a developer as a colleague, and why stopping, handing over and retiring are professional outcomes. Close the twelve steps. Step chapters share one form (authoring guide, rule 19): what a developer does at this step; what vibe coding does instead and the gap; how AI helps and where it misleads; proportion by tier (A to D); the practical guide with its exit gate and artefact; the worked example of the two builds; when to call a developer.
Builds on: AI Developer, Chapter 19, AI Developer, Chapter 15, AI Leader, Chapter 15
Developer functions: D1 Frame; D5 Steward
Sections: What a developer does at the end; What vibe coding does instead; The takeover test; The handover pack; Promotion between tiers; Calling a developer; Stopping as an outcome; Practical guide: Running the takeover test
Practical guides: Practical guide: Preparing the handover pack and running the takeover test
Worked examples: HND record; takeover-test result record
Nordvik Region and Hansa Mutual: Hanna Wikström (Nordvik Region, service-point-check) and Katarzyna Nowak (Hansa Mutual, claims-doc-check) at this step. Nordvik Region: Anders Falk's team colleague runs the takeover test on service-point-check; one item fails (rollback note unclear) and is fixed; promotion to Tier C approved. Hansa Mutual: A developer from Group Application Development runs the takeover test on claims-doc-check; passes with two remarks. The details follow the builder profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Table of the degrees of delegation (Level 0 Advisory to Level 4 Autonomous) for what the builder's assistant may do at this step, with the usage mode of the tool (Mode 1 Conversational assistant to Mode 3 Agentic work tool for most builders) and the Level 4 prohibitions that apply.
Observable, expected, speculation: Handover practice is established; that builders routinely have developer receivers is expected where organisations provide them.
Figure: The takeover test: run, change, revert, in one working day
Planned length: 3,800-5,800 words of prose

Part VI: The Organisation Around the Builder

Chapter 17: What the Organisation Provides: Sandboxes, Templates, Golden Paths and a Register

File: 17_what_the_organisation_provides.md
Status: outline
Purpose: Describe what the organisation must provide so that the sanctioned route is easier than the unsanctioned one: a builder workspace with an approved assistant and synthetic data, templates that have the twelve steps built in, golden paths, a register, a receiving developer and a support path. Address platform teams and IT leaders. Show the cost of not providing it and how to measure the provision with evidence.
Builds on: AI Developer, Chapter 16, AI Developer, Chapter 19, AI Leader, Chapter 10, AI Operations, Chapter 17
Developer functions: D2 Design; D3 Build; D5 Steward
Sections: The gap has two sides; The builder workspace; Templates with the steps built in; The register; The receiving developer; What it costs and what it saves; Practical guide: Standing up a builder lane; Governance without prohibition
Practical guides: Practical guide: Standing up a builder workspace and template in 90 days
Worked examples: A repository template manifest; a register entry; a platform service-level note
Nordvik Region and Hansa Mutual: Maja Lindqvist's platform team opens the builder workspace in October 2031 (AIDR-1200); the template is the scheduled-job template.
Usage modes and degrees of delegation: Group Application Development provides the builder lane inside the claims analytics workspace; the receiving developers are named per market.
Observable, expected, speculation: Builder lanes are an expected development in organisations that have governed citizen development; evidence on their effect is thin and the chapter says so.
Figure: The builder lane: workspace, template, register, receiving developer
Planned length: 3,600-6,000 words of prose

Chapter 18: Builders in the Public Authority: Procurement, Records, Accessibility and Legitimacy

File: 18_builders_in_the_public_authority.md
Status: outline
Purpose: Treat builders in a public authority: accountability for a tool built in-house under public law, records and public-access rules (code, prompts and design documents as records), accessibility duties, procurement of builder platforms and assistants, and legitimacy: a resident cannot be asked to trust what an official built on a weekend. Organisation: Nordvik Region.
Builds on: AI Developer, Chapter 18, AI Governance, Chapter 14
Developer functions: D1 Frame; D2 Design; D5 Steward
Sections: A tool built by an official; Records and access; Accessibility; Procurement; Legitimacy; Practical guide: A public-authority checklist for a builder
Practical guides: Practical guide: Checking a build against public-law duties before promotion
Worked examples: A public-authority supplement to the BLD record
Nordvik Region and Hansa Mutual: Hanna's build is internal and not casework; the checklist shows why it stays so; the archivist's view on prompts is recorded.
Usage modes and degrees of delegation: Not applicable except by contrast: a note on public authorities in Hansa's markets.
Observable, expected, speculation: Accessibility and records duties are decided law; their application to prompts is open.
Figure: Public-law duties on the builder's path
Planned length: 3,600-5,200 words of prose

Chapter 19: Regulation for Builders: What Applies When

File: 19_regulation_for_builders.md
Status: outline
Purpose: Map regulation to the builder in plain terms and by tier: GDPR (controller duties, Articles 5, 25, 32, 35), the AI Act (literacy, deployer, high-risk screening), the Cyber Resilience Act and product liability (when a builder's tool becomes a product), NIS 2 and DORA (supply chain and ICT risk), accessibility and copyright of generated code. State what each means for a builder, framed as organisational implications, not legal advice.
Builds on: AI Developer, Chapter 24, AI Developer, Chapter 26, AI Governance, Chapter 4
Developer functions: D1 Frame; D2 Design; D4 Prove; D5 Steward
Sections: Law is not the builder's job and is the builder's problem; GDPR; The AI Act; Product and liability law; NIS 2 and DORA; Copyright and licences; The map by tier; Practical guide: A regulatory screening for a build
Practical guides: Practical guide: Screening a build against the regulatory map
Worked examples: A regulation-to-duty table by tier
Nordvik Region and Hansa Mutual: Nordvik: public-law duties and the AI Act deployer role; Hansa: DORA register of information and group rules for tools in the claims value chain.
Usage modes and degrees of delegation: See Nordvik Region.
Observable, expected, speculation: Decided law is observable; its application to builders' tools is expected and in part open.
Figure: Regulation mapped to tiers
Planned length: 3,800-5,400 words of prose

Chapter 20: Should Everyone Build? A Debate

File: 20_should_everyone_build.md
Status: outline
Purpose: Stage the debate on whether everyone should build. Four steps: the case for concern (the strongest argument that non-developers building production software is a mistake), the case for calm (the strongest argument that structured building by non-developers is safe enough and valuable), where the positions meet (facts and measures both accept) and what can be done (for builders, developers, leaders and representatives). End with a verdict labelled observable, expected or speculation, and the author's own labelled projections.
Builds on: AI Developer, Chapter 19, AI Developer, Chapter 29, AI Leader, Chapter 29
Developer functions: D1 Frame; D2 Design; D3 Build; D4 Prove; D5 Steward
Sections: The question; The case for concern; The case for calm; Where the positions meet; What can be done; Verdict; The author's projections
Constructive debate: Concern: Non-developers lack the habits that make software safe; AI hides that gap; failures land on people who never agreed to be the test; the evidence on security of generated code is poor; and organisations will use 'citizen' as a way to avoid headcount and assurance. Calm: Software has always been built by non-developers (spreadsheets); structure at the right tier changes the outcome; sanctioned routes beat bans; most builds are Tier A or B; a builder with a gate and a handover is safer than a shadow tool; and evidence from low-code governance supports proportion. Where they meet: Both accept the Level 4 prohibitions, the need for ownership and handover, tier-based proportion, synthetic data in development, independent checks and evidence with age; both reject unowned tools. What can be done: Builders: follow the steps and stop at the tier boundary. Developers: coach, receive handovers and publish golden paths. Leaders: provide the lane, measure with evidence and refuse headcount-driven substitution. Representatives: agree what is monitored and by whom.
Practical guides: Practical guide: A decision aid for a leader: what to permit at which tier
Worked examples: A permit-by-tier table
Nordvik Region and Hansa Mutual: Both organisations' positions are stated: Nordvik's caution about casework data; Hansa's pressure to move fast with Flowdesk. The details follow the builder profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Debate across usage modes; Level 4 prohibitions as common ground.
Observable, expected, speculation: The author's projections are labelled and kept to this chapter and Chapter 25.
Figure: The debate: concern, calm, meeting point, actions
Planned length: 4,500-6,000 words of prose

Chapter 21: From Builder to Developer: Learning, Competence and Career

File: 21_from_builder_to_developer.md
Status: outline
Purpose: Describe how a builder learns the craft over time: what to learn next and in what order, evidence of competence instead of attendance, learning with and without the assistant, cognitive offloading and what studies measured about skill and overreliance [verify], the builder's own mind (confidence, overconfidence, flow), when a builder becomes a developer and when not, and the developer's duty as coach. Produce a builder learning plan and a competence record.
Builds on: AI Developer, Chapter 27, AI Developer, Chapter 28, AI Threat, Chapter 7, AI Leader, Chapter 21
Developer functions: D1 Frame; D2 Design; D3 Build; D4 Prove; D5 Steward
Sections: A learning path, not a course; Evidence of competence; Learning with and without the assistant; Offloading and overconfidence; Becoming a developer, or not; The developer as coach; Practical guide: A builder learning plan
Practical guides: Practical guide: Writing a builder learning plan and a competence record
Worked examples: BLP plan and CMP record
Nordvik Region and Hansa Mutual: Hanna's plan is part of her e-services role; Katarzyna's is part of a claims analytics development path.
Usage modes and degrees of delegation: See Nordvik Region.
Observable, expected, speculation: Evidence on offloading is observable and limited; career effects are expected; the pipeline from builder to developer is speculation.
Figure: The learning path from builder to developer
Planned length: 3,800-5,600 words of prose

Part VII: Experience and Conclusions

Chapter 22: Failures and Anti-Patterns

File: 22_failures_and_anti_patterns.md
Status: outline
Purpose: Analyse verified public failures of vibe-coded or AI-built software with the twelve steps, and catalogue anti-patterns with the step that prevents each. Cases must be verified against primary reports; drop any that cannot be verified. Describe by mechanism and consequence, never exploit detail. Also include a case where structure helped.
Builds on: AI Developer, Chapter 30, AI Developer, Chapter 23, AI Threat, Chapter 10
Developer functions: D1 Frame; D2 Design; D3 Build; D4 Prove; D5 Steward
Sections: How to read a failure; Cases; A case where structure helped; Anti-patterns; What the cases do not show
Practical guides: Practical guide: Running a blameless review on your own build against the twelve steps
Worked examples: An anti-pattern table
Nordvik Region and Hansa Mutual: Illustrative cases are labelled as such; the public cases are not about the two organisations. The details follow the builder profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Cases by usage mode where reported.
Observable, expected, speculation: Cases are observable; their rate is unknown; the book says so.
Figure: Anti-patterns mapped to the twelve steps
Planned length: 3,800-5,600 words of prose

Chapter 23: Two Builds, Step by Step: Nordvik Region and Hansa Mutual

File: 23_two_builds_step_by_step.md
Status: outline
Purpose: Tell the two builds in full, step by step, from September to December 2031: Hanna Wikström's service-point-check and Katarzyna Nowak's claims-doc-check, showing the artefact of each step in place, the one gate that fails for each and what they changed, and the day each handed over. Written as narrative with the artefacts shown briefly.
Builds on: Chapters 5 to 16 of this book
Developer functions: D1 Frame; D2 Design; D3 Build; D4 Prove; D5 Steward
Sections: September: intent and tier; October: workshop, specification and design; November: build, prove, secure; December: ship, run, own, hand over; What the numbers show; What each builder says
Practical guides: A one-page timeline for your own build
Worked examples: The two timelines as tables; the BLD records with gate status at hand-over
Nordvik Region and Hansa Mutual: Narrative of both organisations. The details follow the builder profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Across usage modes: what each tool did at each step.
Observable, expected, speculation: The narrative is illustrative. Claims about effect carry method and date.
Figure: The two builds on a timeline, September to December 2031
Planned length: 4,500-6,000 words of prose

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

File: 24_conclusions_for_nordvik_and_hansa.md
Status: outline
Purpose: Draw conclusions for each organisation and compare them: a 90-day plan for the builder, for the platform team and for leaders; the decisions needed; KPIs of the book's own claims with evidence age; risks; and what each organisation should stop doing.
Builds on: AI Developer, Chapter 32, AI Leader, Chapter 31
Developer functions: D1 Frame; D2 Design; D3 Build; D4 Prove; D5 Steward
Sections: Nordvik Region; Hansa Mutual; Comparison; KPIs and evidence; Risks and what to stop
Practical guides: Practical guide: A 90-day plan for a builder lane
Worked examples: A plan table; KPI definitions with evidence age
Nordvik Region and Hansa Mutual: Both organisations in depth. The details follow the builder profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Plan by usage mode.
Observable, expected, speculation: Plans are the book's conclusions; outcomes are expected, not observed.
Figure: Ninety days for builders, platform teams and leaders
Planned length: 3,800-5,600 words of prose

Chapter 25: Conclusion

File: 25_conclusion.md
Status: outline
Purpose: Judge the thesis against the evidence: what is established, expected and speculation; the author's own labelled projections; five things a reader does on Monday; a closing note on the series.
Builds on: Chapters 1 to 24 of this book, AI Developer, Chapter 33
Developer functions: D1 Frame; D2 Design; D3 Build; D4 Prove; D5 Steward
Sections: The thesis tested; Established, expected, speculation; The author's projections; Five things to do on Monday; What would show the thesis wrong
Practical guides: Practical guide: Your own Monday: the first hour with your build record
Worked examples: A five-item Monday list
Nordvik Region and Hansa Mutual: Both organisations in the closing. The details follow the builder profiles in docs/EXAMPLE_ORGANISATIONS.md.
Usage modes and degrees of delegation: Final table across usage modes.
Observable, expected, speculation: Author's projections are labelled and confined to this chapter and Chapter 20.
Figure: The thesis judged against the evidence
Planned length: 3,600-5,200 words of prose

Appendices

26_glossary.md: Defines the vocabulary of the book: vibe coding, builder, the twelve steps, the four tiers, gate, artefact, takeover test, the stewardship tests (Name, Understand, Revert), the independent test oracle, mandate, project rules file, repository, commit, branch, environment, pipeline, rollback, runbook, restore test, provenance, and the usage modes and degrees of delegation.
27_appendix_a_code_examples.md: Appendix A: complete versions of the artefacts of the twelve steps: build record, specification record, ADR, AGENTS.md, mandate manifest, run record, verification plan, review record, provenance record, CI workflow, change record, runbook manifest, restore-test record, ownership record, handover pack.
appendix_templates_and_tools.md: Appendix B: the twelve-step checklist by tier, the takeover-test checklist, ordinary prompts for the assistant at each step, and a list of tool categories with what each must provide.
28_references.md: The only bibliography of the book.
29_about_the_author.md: About the author of The Transformed Architecture, placed at the very end of the book, and a note on how the book was made.