Introduction: From Vibe to Dev

This book is for the person who is not a developer and builds software anyway. A sentence typed to an AI assistant now returns a working tool, and a good many tools made that way end up carrying real work: a tracker that a whole unit uses, a script that produces a weekly report, a form that other people fill in. The book shows how to take such a tool from a prototype made by conversation to something that others can rely on, in twelve steps, each of which ends in a gate that is passed by showing an artefact. The twelve steps are Step 1 Intent, Step 2 Tier, Step 3 Workshop, Step 4 Specification, Step 5 Design, Step 6 Build, Step 7 Prove, Step 8 Secure, Step 9 Ship, Step 10 Run, Step 11 Own and Step 12 Hand over. Behind them stand the five developer functions of AI Developer (Nordqvist, 2026), D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward, which are the professional practice that the steps teach a non-developer to carry out with an assistant at their side. This chapter introduces all twelve steps, the two builders and the two organisations who follow them through the book, the words the book uses, and the ways to read it.

The twelve steps on one page, in four groups, each step ending in a gate, with the takeover test at the end

Figure 1.1: The twelve steps in four groups, each step ending in a gate, the tiers that set how much applies and the takeover test at the end.

A tool that worked until Monday

The following scene is illustrative. It is a composite of the kind of case that the sweeps of citizen-built applications described in AI Developer, Chapter 19, brought to light, not a documented incident (86, Nordqvist, 2026).

A case handler in a public authority builds a tracker in the spring. It lists the applications waiting for a document from the applicant, shows who has asked for what, and sends a reminder after fourteen days. She makes it in an afternoon by describing what she wants to a hosted application builder, a service that generates the application, its small database and its web address from a description in ordinary language. By summer eleven colleagues use it every day. In the autumn she moves to another unit, and her old colleagues keep using the tracker because it works.

On a Monday in November the tracker shows an empty list. The builder's free plan has reached its limit for stored rows, and the service has stopped accepting new ones. The unit manager asks who owns the tool and nobody answers. The handler who made it is reachable but no longer has time, and she remembers that the login was her own private address. Nobody knows whether the data is saved anywhere else. Nobody knows whether the reminders went to the right people last week, because nobody ever wrote down what right meant. Someone suggests asking the assistant to rebuild it, and someone else points out that the assistant would build something, but not necessarily the same thing, and that nobody could say which cases the new version had to handle.

Nothing in this scene is the handler's fault. She solved a problem that was hers to solve, with a method that took an afternoon, and it worked. The scene shows the distance between a tool that works and a tool that someone owns, and that distance is the subject of this book. The questions nobody could answer on Monday morning (who owns it, what does correct mean, where is the data, how is it restored, who can take it over) are the ones that professional developers settle as a matter of routine before anyone relies on their work, and that a builder can settle too.

What this book promises

The book promises a method. Followed in order, with a build in hand, the twelve steps lead to software that a developer would recognise as professionally made: its purpose and its user are written down, its limits are known, its data is kept where it should be, its history is recorded, what correct means is stated and tested by someone other than the person who wrote the code, its secrets are kept out of sight, it reaches its users by a path that can be undone, someone watches it run, and a named colleague can take it over. The builder who has followed the steps also knows something about themselves: where their own competence ends, and when to call a developer.

The book does not promise that its reader becomes a developer. A developer's craft takes years, and the book does not claim to shorten it. It does not promise that every tool can safely be built by its user. The method includes a step that classifies each build into one of four tiers, and the highest tier, Tier D project, is not a citizen build at all: a tool that ranks or decides about a named person, that is or feeds a high-risk AI system, that sits in a security-critical path or that acts irreversibly on production data belongs to the development organisation, and the book's advice for that case is to stop and ask for help. Saying so early is part of the promise. A builder who stops at the right moment has practised the method as fully as one who completes all twelve steps.

Nor does the book promise that following the steps makes software secure, correct or ready. No chapter says that something is secure, tested, backed up or ready without saying what was checked, by whom, when and with what result, and evidence expires: a restore test that passed in September says little about a tool that changed in November.

The gap, in one paragraph

The gap between a prototype made by conversation and a service that other people depend on is made of habits, not of talent. It consists of things that professional developers do without thinking much about them: they find out what is being built and for whom before they build it, they keep a history of every change, they separate the place where they experiment from the place where users are, they write down what correct means and test against it, they keep passwords and keys out of the code, they ship by a route that can be reversed, they watch what runs, and they arrange for someone else to be able to take over. None of these needs a degree. Each leaves a piece of evidence, such as a one-page statement, a history, a test result or a record of ownership, which a reviewer can inspect. This is the book's central claim, and it is the book's own: it is tested step by step in Parts II to V, and Chapters 20 and 25 judge it against the evidence and say what would show it wrong. The next chapter sets out what is known about the quality and security of software made by conversation, so that the claim rests on evidence about the starting point and not on impressions of it.

The twelve steps on one page

A step is finished when its gate is passed, and a gate is passed by showing an artefact, a file or record that exists and can be read by someone else. The gate is never "when you feel ready". Table 1.1 gives each step with the question it answers, its gate, its artefact and the developer function behind it. The artefacts are defined in Chapter 4 and shown in full in Appendix A. They are named here so that the reader can see from the start that every step leaves something behind.

Step	The question it answers	Gate: shown, not asserted	Artefact	Function
1 Intent	What am I building, for whom, and how will I know it works?	The user has read the one-page intent and confirmed it	Section 1 of the build record `BLD-*`	D1 Frame
2 Tier	How much structure does this work need?	The tier is decided and recorded with the answers to five questions, and agreed by a named person	Section 2 of the build record	D1 Frame, D2 Design
3 Workshop	Where do I work, so that I can always go back?	A colleague can clone the repository and restore the working tool from it	Repository, `AGENTS.md`, mandate `MND--BLD-`	D3 Build, D5 Steward
4 Specification	What does correct mean, in examples?	The specification record is approved and the oracle owner is named	`SPC-*` with acceptance cases	D1 Frame
5 Design	How will it hold together, and who can reach the data?	A reviewer can read the one-page design and its decisions	One-page design, decision records (ADR)	D2 Design
6 Build	Can one small slice work from end to end?	A slice runs, is committed, and its assistant session is recorded	Commits, run record `RUN-*`	D3 Build
7 Prove	Does it do what the specification says, shown by someone other than its author?	Tests that come from the specification pass, and a person other than the builder has reviewed the change	Verification plan `VER-`, review record `RVW-`	D4 Prove
8 Secure	What could go wrong with data, access and dependencies?	The checklist for the tier is complete, dated, with a result for each item	Security checklist with date and result	D4 Prove
9 Ship	Can it reach its users by a route that can be undone?	A release went out through the pipeline and a rollback was practised	Change record `CHG-*`	D5 Steward
10 Run	Who notices when it fails, and can it be restored?	A restore test passed and a failure alert reached a named person	Runbook `RBK-`, restore test `RST-`	D5 Steward
11 Own	Who answers for it, and can they explain it without the assistant?	The owner and deputy passed an explain-it-back drill	Ownership record `OWN-*`	D5 Steward
12 Hand over	Can someone else take it over in a working day?	The takeover test passed: a named colleague ran it, changed it, shipped the change and switched it off and restored it	Handover pack `HND-*`	D5 Steward

Table 1.1: The twelve steps with gate, artefact and function. The gates and artefacts are defined in Chapter 4; this table is the overview.

The twelve steps are in four groups. Getting ready (Steps 1 to 3) fixes what is being built, how much structure it needs and where the work lives. Building (Steps 4 to 6) turns the intent into a specification, a design and a first working slice. Proving and securing (Steps 7 and 8) shows that the tool does what was specified and does not put data or access at risk. Shipping, running and owning (Steps 9 to 12) carries the tool to its users and keeps it available, and ends in a handover that someone else tests. The order matters, because each step supplies what the next one needs: a specification cannot be tested before it exists, and a tool that has not been shipped by a pipeline cannot be rolled back by one.

The steps are not a waterfall to be completed once. A build moves through them in small slices, and a failing gate sends the builder back: a test that cannot be written because the specification is vague returns to Step 4, and a restore that fails returns to Step 3. Developers work the same way, and keep an artefact at each stage so that returning is not starting again.

Terms used in the book

The reader is assumed to have no programming background. Every technical term is defined when it first appears, and the glossary in Chapter 26 collects them. A few terms carry the book and are defined here.

Vibe coding is building software by conversation with an AI assistant without reading or structuring the result. The word comes from a social media post of 2 February 2025 by Andrej Karpathy, in which he described forgetting that the code even exists, and the dictionaries have recorded it since (55, Merriam-Webster, 2025). Chapter 2 traces the term and its use. In this book it is a description of a way of working and not a verdict on it: vibe coding is often exactly the right thing to do (Chapter 2 says when), and the book's subject is what to add to it when the result starts to matter to other people.

A builder is a person who is not a developer and who builds software, with or without a low-code platform or an AI assistant, in order to do their own work or the work of their team better. The word is used in lower case in prose and is not a rank. A developer is a person whose profession is to design, build, prove and look after software. The book keeps the two words apart without ranking them: builders know the work the software is for, and developers know what keeps software working. Each needs the other, and the book treats the developer as a colleague who coaches and receives, never as a gatekeeper.

An assistant is an AI system that suggests, generates, drafts, explains or, within a mandate, executes. It may be a chat assistant in a browser, an assistant inside an editor, or a tool that runs commands on the builder's behalf. The book never says that an assistant understands, wants, intends or decides. It says what the assistant did: it generated the function, it drafted the specification, it ran the tests. "Decides" is used only for a system to which a decision was formally delegated, and the record then says who delegated it.

A repository is a folder whose history is recorded by a version control system, so that every change is stored with who made it and when, and any earlier state can be restored. The usual system is called git, and a recorded change in it is a commit. A pipeline is an automated path that takes a change from the repository to the place where users reach it, running checks on the way. These three words return in Steps 3 and 9.

A tier is one of four classes that set how much structure a build needs. The definitions come from AI Developer, Chapter 19 (86, Nordqvist, 2026), and are the book's reference throughout. Tier A personal: the tool is used only by its maker, holds no personal data of others and has no write access to shared systems. Tier B team: it is used by colleagues in one unit, holds internal data only and no personal data of people outside the team. Tier C business: it holds personal data of citizens, customers or staff, or money, or a record of the organisation, or is used by more than one unit, or runs unattended. Tier D project: it ranks or decides about a named person, is or feeds a high-risk AI system, touches a security-critical path or acts irreversibly on production data; it is not a citizen build. A tool moves up a tier by use, not by code: when a second unit begins to rely on it, when personal data of people outside the team enters it, or when it begins to run unattended. Chapter 6 teaches the classification.

A gate is the point at which a step is finished, passed by showing an artefact. An artefact is a file or record, kept in the repository where possible, that shows the gate is passed. The two words are this book's own, though the practice is old: a release checklist in a developer team does the same work.

A mandate is the written statement of what the assistant may read, change, run and reach. It is kept in the repository, and the assistant's work is recorded in run records. The book's rule for the builder's assistant follows the delegation ladder of AI Developer, Chapter 4, which grades delegation from Level 0 Advisory to Level 4 Autonomous. 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 path without review by a named developer, for a change to the assistant's own mandate, permissions, credentials, test oracles 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 (86, Nordqvist, 2026). Chapter 4 applies the ladder to the builder.

The stewardship principle of AI Developer, Chapter 4, is that AI may draft, generate, refactor and, within a mandate, execute, but may not own. It has three tests for the person who owns the result: Name (the owner is identifiable in the ownership record), Understand (the owner can explain the change and reconstruct it without the tool that generated it) and Revert (the owner has the authority, the access and the time to stop, roll back or fix the change). Its corollary is that the test oracle, the source against which a result is judged correct, must be independent of the generator. A test that the assistant wrote for its own code proves less than it appears to. In this book the oracle is a person, a specification or the running system, and it is never only the assistant that produced the code.

The takeover test is the book's measure of the word "professional". A named colleague who did not build the software is given a working day, the repository and the handover pack. They run it, change it and ship the change through the pipeline, and they switch it off and restore it. A pass is shown in the handover pack; a failure is a finding to fix, not a verdict on the builder. The test is the builder's form of the stewardship principle, and Chapter 4 gives its procedure.

The usage modes are the series' names for how AI is used, from Mode 0 Ambient AI to Mode 5 Autonomous production agents (AI Governance, Chapter 2) (75, Nordqvist, 2026). The builder meets three of them: Mode 1, a conversational assistant used in a browser or an app; Mode 2, an assistant embedded in a tool such as an editor; and Mode 3, an agentic work tool that carries out tasks, such as editing files and running commands, within a mandate. Mode 0 is the ambient AI in software the builder did not choose, and Mode 5 is not for builders: an agent that acts on production systems with an identity and permissions of its own is a matter for the platform and operations teams, and the book stops at its door.

Two builders, two organisations

Two fictional organisations run through the book, as they do through the whole series. Both are invented, and every name, figure and date is illustrative. Each has a builder who follows the steps from September to December 2031, and their builds are told step by step in Chapters 5 to 16 and in full in Chapter 23.

Nordvik Region is a regional public authority in a Nordic member state of the European Union, with about 6,000 employees and 450,000 residents. It is cautious, accountable to elected politicians and the public, short of engineering capacity and strongly concerned with the transparency of its work. Its builder is Hanna Wikström, product owner of the e-services team. She is not a developer. She has built prototypes with a conversational assistant since 2030, and she has a problem that her team knows well: the Region publishes the opening hours and service notices of its 24 service points in three places, the citizen portal, the printed leaflet export and the phone-service script, and the three disagree after every change. Residents go to service points that are closed, and then they ring the phone service. Hanna's build is service-point-check, a small Python job that reads the three sources, compares them and writes a weekly report of mismatches. It never writes to any of the three sources, and it holds no personal data of residents. It starts as a tool for her own team, a Tier B build, and moves to Tier C when it runs on a schedule and is used by service-point managers in other units.

Hansa Mutual is a mutual insurance group headquartered in Hamburg, with about 9,500 employees and subsidiaries in several countries inside and outside the European Union. It is commercially driven, has strong engineering capacity and a shared group platform, and works under financial-sector supervision. Its builder is Katarzyna Nowak, team lead of a motor claims team in the group's service centre in Poland. She is not a developer either; she has ten years of claims experience. Motor property-damage claims arrive with attachments, such as photographs, an accident report and a repair estimate, and her handlers spend time working out what is missing from each file and writing request letters. Her build is claims-doc-check, a Python command-line tool that reads a list of claims from an export, finds the documents still missing from each file by the group's rules and drafts a request text in the claimant's language for the handler to review and send. It decides nothing about any claim and sends nothing itself. It holds claimants' personal data, so it is a Tier C build from the start. Claims for personal injury are out of scope because free-text fields may hold health data, which the General Data Protection Regulation places in a special category under Article 9 (4, European Union, 2016), and including them would raise the tier.

Table 1.2 sets the two side by side. The similarities are as useful as the differences: both builders have a real problem, a deputy, a receiving developer and a date by which the tool must be handed over, and both meet one gate that fails.

	Nordvik Region	Hansa Mutual
Builder	Hanna Wikström, product owner	Katarzyna Nowak, claims team lead
Deputy for the build	Elin Berg, business analyst	Marek Zieliński, senior claims handler
Build	`service-point-check`	`claims-doc-check`
Data	Public and internal	Claimants' personal data
Tier	B, then C when it runs on a schedule	C from the start
Law in focus	Public law, records, accessibility	GDPR, group rules, three languages
Receiving developer	Rasmus Holm, in the integration and data team	Tomasz Wrona, Group Application Development

Table 1.2: The two builders and their builds, from the profiles of the two organisations.

Most of what the builders do is ordinary: they write a page, make a repository, ask the assistant to draft a specification and then read it, write test cases that someone else will check, and arrange for a colleague to take the tool over. Where something goes wrong the book says so: in each build one gate fails, and what the builder changed afterwards is what the book wants the reader to remember.

How to follow the book

The book is written to be followed with a build in hand. The reader who has no build yet can use a small, real task of their own, such as a weekly report or a check of two lists, and treat it as Tier A to learn the method. The reader who has already built something can start from that tool and work backwards through the steps to find what is missing. In both cases the practical guides in each chapter are the working part of the book, and the surrounding text explains why they are shaped as they are.

Chapters 5 to 16 are the steps, one chapter each, and each follows the same form: what a developer does at this step, what vibe coding does instead, how an assistant helps and where it misleads, what each tier needs, a practical guide that ends in the exit gate and its artefact, how the two builds met the gate, and when to call a developer. Parts I and VI to VII frame, place and judge the method. Part I is the case for it: Chapter 2 describes vibe coding and what the evidence says about it, Chapter 3 describes what developers do that a builder does not see, and Chapter 4 defines the method in full. Part VI turns to what the organisation around the builder provides and owes, and the debate on whether the method is enough is staged in Chapter 20.

Three rules help the reader.

First, do not skip gates. A gate that is passed by saying so is not a gate. If a step feels disproportionate for the tier, the proportion table in Chapter 4 shows what the tier needs and the answer is to do less of it, not to do none of it: a Tier A tool needs a purpose in one sentence and a repository, and no more.

Second, keep the artefacts in the repository, next to the work, and date them. Every artefact in the book records a date and a result, because a claim about what was checked is only as good as its age. As an illustration of the convention, evidence about a running tool is trusted for 90 days and then repeated; this figure is the book's illustrative default, not a standard, and Chapter 4 sets out the figures by tier.

Third, use the assistant for every step, not only for writing code. An assistant can draft the intent from an interview, propose a specification, suggest test cases, explain a change, run a scan and write the first version of a runbook. What it cannot do is own the result, and it cannot be the only judge of its own work. The builder who uses the assistant to practise the disciplines closes the gap, and the builder who uses it to skip them widens it. The one-hour path in the practical guide below is how to find out which of the two you have been doing.

Practical guide: An inventory of what you have built

Purpose. To see, on one page, what you have built or are building with an assistant, who relies on it and what data it touches, before you decide where to start.

Roles. The builder, who writes the inventory; the unit manager, who reads it; and, if the builder wishes, a developer who will later receive the work.

Inputs. Your own memory and the places where your tools live: your laptop, the hosted services you log in to, the shared drives and the team channels where you have posted a link.

Steps.

Make a file called inventory.yaml and write one entry for each tool, including the ones you consider too small to count. Use the template below.
For each entry, write who uses it today, not who it was meant for. Ask colleagues if you are unsure.
Write what data it reads and what it writes. If it holds names, identity numbers, health information, money or anything about people outside your team, say so plainly.
Write where it runs and where its only copy lives. If the answer is "on my laptop" or "at a service I log into with my own address", write that.
Write down what happens if it stops on Monday, and who would find out.
Count the entries that have a second user, personal data of others or unattended running. Those are the first candidates for Step 2 Tier.

The result is an artefact, the first of the book: a file that shows you what you have. It is not a register of the organisation and nobody needs to see it unless you choose. It is useful because it replaces a vague worry with a list.

A worked example follows, for Hanna Wikström at Nordvik Region on 8 September 2031, the day her build record is opened. The first entry is her prototype and the second is a personal macro; the entry for the prototype is the one that matters. Chapter 2 tells the story of the prototype.

# inventory.yaml: everything I have built with an assistant. Dated, so it can be re-checked.
builder: Hanna Wikström
written: 2031-09-08
tools:
  - name: hours_compare.py
    purpose: Compare opening hours in the portal export and the phone-service export
    used_by: [Hanna Wikström, Elin Berg]
    data_read: [portal export (public), phone-service export (internal)]
    data_written: [a text file with mismatches on my laptop]
    runs_on: my laptop, started by hand
    only_copy: my laptop
    if_it_stops: the e-services team gets no mismatch list; nobody would notice for weeks
    signals: {second_unit: false, personal_data_of_others: false, unattended: false}
    first_step: Step 1 Intent, then Step 3 Workshop
  - name: meeting-notes-macro
    purpose: Turn my meeting notes into a list of actions
    used_by: [Hanna Wikström]
    data_read: [my own notes]
    data_written: [my own action list]
    runs_on: my laptop, started by hand
    only_copy: my laptop
    if_it_stops: I write the list myself
    signals: {second_unit: false, personal_data_of_others: false, unattended: false}
    first_step: none needed beyond a purpose and a repository (Tier A)

Neither entry sets a signal, so both would be Tier A or B today. The first entry's if_it_stops line is the reason to continue: the tool is about to be relied on by people other than its author.

The one-hour path

A reader with an hour can do four things that will change the position of a build, in this order. Write the inventory above. Take the tool that matters most and write its purpose, its user and its success measure in three sentences, which is the content of Step 1 Intent. Put the tool in a repository with a short README.md that says what it is, who owns it and how to run it, which is the beginning of Step 3 Workshop. Then ask the assistant to explain the tool back to you, in plain language, and read what it says: where its account differs from what you thought you had built, you have found your first gap. The one-hour path does not make a build professional. It makes it findable, which is the condition for everything else.

The twelve steps as a checklist

The twelve steps can be held as a checklist in the build record, so that gate status is visible. The worked example below is illustrative and shows the shape of the record that Chapter 4 defines and that the two builds keep. It is the checklist as it stands for service-point-check at the start, before any gate has been passed.

# The twelve steps as a checklist (illustrative). Status: open, passed or failed, with a date.
build: BLD-NR-2031-0001
repository: service-point-check
opened: 2031-09-08
tier: undecided   # decided at Step 2
gates:
  - {step: 1,  name: Intent,        artefact: "intent in BLD section 1",   status: open}
  - {step: 2,  name: Tier,          artefact: "tier decision in BLD",      status: open}
  - {step: 3,  name: Workshop,      artefact: "clone-and-restore test",    status: open}
  - {step: 4,  name: Specification, artefact: "SPC record",                status: open}
  - {step: 5,  name: Design,        artefact: "one-page design, ADRs",     status: open}
  - {step: 6,  name: Build,         artefact: "slice, commits, RUN",       status: open}
  - {step: 7,  name: Prove,         artefact: "VER plan, RVW record",      status: open}
  - {step: 8,  name: Secure,        artefact: "dated security checklist",  status: open}
  - {step: 9,  name: Ship,          artefact: "CHG record, rollback",      status: open}
  - {step: 10, name: Run,           artefact: "RBK, restore test RST",     status: open}
  - {step: 11, name: Own,           artefact: "OWN record, drill",         status: open}
  - {step: 12, name: Hand over,     artefact: "HND pack, takeover test",   status: open}

A status of passed is written only with a date and a pointer to the artefact. In the real record the artefact fields point to files; here they are descriptions. The list is the book on one page, and the reader may keep it beside the build.

Rules of the book

The book follows rules that the reader may rely on and may hold it to.

Defensive only. The book describes how generated software goes wrong, by class and mechanism, at the level needed to design controls and tests. It contains no exploit code, no working payloads and no injection or jailbreak strings. Examples of instructions to an assistant are ordinary instructions of the kind a colleague would give.

Claims with evidence. Every factual claim cites a source from the bibliography or is the book's own conclusion, drawn in a conclusions section or a summary and said to be so. Claims about products are cited to the vendor's documentation and are examples of a pattern; the pattern, not the product, is the point, and the book recommends no product. A claim about what a tool did or what a study found says what was measured, in whom, when and by what method before it says what it means. A claim that something was checked says by whom, when and with what result, and it expires.

Observable, expected, speculation. Every statement about the future of building, of work or of the technology carries one of three labels, taken from AI Governance, Chapter 22 (75, Nordqvist, 2026). Observable means happening now and documented. Expected means supported by a stated trend or a decided instrument. Speculation means plausible but not evidenced. The author's own projections are kept to Chapters 20 and 25 and labelled there as the author's judgement.

No anthropomorphism. An assistant suggests, generates, drafts, explains or executes within a mandate. It does not understand, want, intend or decide, and the book writes accordingly.

People are described by what studies measured. The book does not call anyone lazy, stupid or replaceable. Builders are not reckless and developers are not gatekeepers by nature; both are people doing their work with the tools and the incentives they have. Where a study measured an effect on people, the book states the population, the period and the method, and says no more than the study supports. It gives no instruction for covert monitoring of staff or for defeating the rights of employee representatives.

Legal content is attributed and framed as implication. Statements about the law name the instrument and the article and say what they mean for the organisation and the build. They are not legal advice.

How to read this book

The book can be read straight through, which is the way it is written, but the audiences it serves will use it differently. These are suggested paths and not tests.

Builders. Read Chapters 1 to 4 for the argument and the method, then go step by step from Chapter 5 to Chapter 16, doing the practical guide of each step on a build of your own. Read Chapter 22 on failures and anti-patterns when you have finished Step 8, and Chapter 23 for the two builds in full. Chapter 21 is for the builder who wants to learn more and for the one who wants to become a developer. If you have an hour only, use the one-hour path above.

Developers who receive builders' work. Read Chapters 1 to 4, then Chapters 11 to 16, which cover Steps 7 to 12, and Chapters 17 and 21. The takeover test in Chapter 16 is the work you will be asked to do, and the "When to call a developer" section of each step chapter lists what the builder has been told to bring you. The book asks you to coach and to receive, and does not ask you to gatekeep.

Platform engineers. Read Chapter 4 for the mandate and the tiers, Chapter 7 on the workshop, Chapters 13 and 14 on shipping and running, and Chapter 17 on the sandbox, the templates and the golden path that a platform provides. The test of what you build is whether a builder finds the sanctioned route easier than the unsanctioned one.

Leaders. Read Chapters 1, 2 and 4 for the argument, Chapter 17 on what the organisation provides, Chapter 20 for the debate and Chapters 24 and 25 for the conclusions. The book does not repeat what AI Leader says about leading adoption; it points there (85, Nordqvist, 2026).

Data protection officers and public-sector IT leads. Read Chapter 6 on classification and screening, Chapter 12 on security and personal data, Chapter 18 on what a public authority adds and Chapter 19 on regulation. The screening in Chapter 6 shows how a builder asks for a data protection officer's view early and in plain terms.

Employee representatives. Read Chapter 17 on the organisation's duties to builders, Chapter 19 on regulation and the rules above on monitoring and measurement. A register of builders or a lane for them may involve staff data, and the book describes the questions that representatives may ask without describing how to monitor anyone covertly.

Across the usage modes

The builder meets three usage modes, and each changes what the builder can do and what can go wrong. Table 1.3 relates them to the builder's tools and names what the builder's mandate must settle for each. Chapter 4 gives the highest degree of delegation for each mode and restates the Level 4 prohibitions.

Mode	The builder's tool	What the assistant does	What the builder's mandate must settle
Mode 1 Conversational assistant	A chat in a browser or an app	Explains, drafts and suggests; the builder copies the result	What data may be pasted into the chat, and which service is approved
Mode 2 Embedded assistant	An assistant inside an editor	Suggests and generates code in the files the builder has open	Which files and folders it may see
Mode 3 Agentic work tool	A tool that edits files and runs commands in a sandbox within a mandate	Carries out tasks, such as editing files and running tests, in a branch	What it may read, change, run and reach; never secrets, production data or the pipeline's gates
Mode 5 Autonomous production agents	Not for builders	Not applicable	Not used by builders

Table 1.3: The usage modes as the builder meets them and what the builder's mandate must settle in each.

Hosted application builders sit across the modes. A service that generates the application, its database and its hosting from a description is a Mode 3 tool that also provides the platform, and it carries hosting and data duties that the builder meets whether or not the builder knows it. Chapter 2 treats these tools.

Nordvik Region and Hansa Mutual

Both builders are introduced above and appear again at every step. At Nordvik Region the platform team opens a builder workspace for builders like Hanna Wikström in October 2031, and the Region's rule of no autonomous production agents stands. Katarzyna Nowak works at Hansa Mutual, where Group Application Development provides a builder lane inside the claims analytics workspace in the same month. Neither workspace exists on the day each builder starts, which is the usual position of a builder: the first steps are taken before the organisation has built the route. Chapter 17 describes what each organisation provides, and Chapter 23 shows the dates. At the point of this chapter both builds are at the beginning of the checklist above, and both builders have an inventory.

Observable, expected, speculation

That non-developers build software with assistants and with hosted application builders is observable: the series records it as a standing fact of the organisations it describes (AI Developer, Chapter 19) (86, Nordqvist, 2026), and a Stack Overflow survey of over 49,000 respondents found that about 15 per cent said they vibe code in some form (its respondents are mostly developers and self-selected) (127, Stack Overflow, 2025). That organisations will provide sanctioned builder workspaces, templates and registers is expected, because the series' earlier volume describes them as the response and some organisations already do so; the pace is not known. That builders will replace developers is speculation and the book does not argue it; Chapters 20 and 25 judge the claim. The thesis of the book, that the gap is a set of habits and that twelve steps close it in proportion, is the book's own claim. It is tested in Chapters 5 to 16 and judged in Chapters 20 and 25.

Summary

This book is for the builder who is not a developer and wants the tool they have made to be good enough that other people can rely on it. It offers twelve steps, Step 1 Intent to Step 12 Hand over, each ending in a gate that is passed by showing an artefact, and a measure of the result, the takeover test, in which a named colleague runs the tool, changes it, ships the change and switches it off and restores it. It promises software that a developer would recognise as professionally made, and a builder who knows where their own competence ends. It does not promise to make anyone a developer, and it does not promise that a Tier D build can be a citizen build.

The chapter has defined the terms the book uses and introduced the two builders: Hanna Wikström at Nordvik Region, who builds service-point-check to compare opening hours across three sources, and Katarzyna Nowak at Hansa Mutual, who builds claims-doc-check to find missing documents in motor property-damage claims. It has given a first practical guide, an inventory of what the reader has built, and a checklist of the twelve gates. The steps concern the five developer functions D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward, which the later chapters name step by step.

The book's conclusions from this chapter are its own. The gap is made of habits and not of talent, and the first habit is to know what you have: the inventory is the cheapest evidence there is. Structure is proportionate to what can go wrong, so that the same builder may own a Tier A macro and a Tier C tracker. Professional has a test, and the test is whether a colleague can take the tool over. The next chapter describes vibe coding fairly, with the evidence on its strengths and on what it produces, so that the gap described in Chapter 3 can be seen against an honest account of where builders start.

Sources

European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). Official Journal of the European Union. (4, European Union, 2016)
Merriam-Webster. Vibe coding. Merriam-Webster "Slang and Trending" entry. (55, Merriam-Webster, 2025)
Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Transformed Architecture, Book 2. (75, Nordqvist, 2026)
Nordqvist, G. (2026). AI Leader: How Leadership Roles Change When AI Is Used Broadly in European Enterprises and Public Authorities. The Transformed Architecture, Book 11. (85, Nordqvist, 2026)
Stack Overflow (2025). 2025 Stack Overflow Developer Survey. Stack Overflow. (127, Stack Overflow, 2025)
Nordqvist, G. (2026). AI Developer: How the Developer Role Changes When AI Is Used Broadly in European Enterprises and Public Authorities. The Transformed Architecture, Book 12. (86, Nordqvist, 2026)