Conclusion

This book made a claim in its first chapter and has spent twenty-three chapters testing it. This last chapter judges the claim. It concerns all twelve steps, from Step 1 Intent to Step 12 Hand over, and the five developer functions behind them (D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward). It does four things: it takes the five parts of the thesis one by one and says which parts hold and on what evidence; it sorts what the book has said into what is established, what is expected and what is speculation; it gives the author's own projections, labelled as such; and it ends with five things a reader can do on Monday and with what would show the thesis wrong.

The tone of the verdict matters, because the subject attracts two kinds of overstatement. One says that anyone can now build software and that the old disciplines are obsolete. The other says that software built by non-developers is a hazard that should be stopped. The book's thesis sits between them and has to be judged on its own terms, which means saying plainly where the evidence is thin. For the most part it is thin, and that fact is part of the finding.

The five parts of the thesis, the verdict on each, and the way to Monday

Figure 25.1: The thesis judged. Each part has a verdict that says how well it is supported; all five lead to actions that produce evidence, and to the conditions under which the thesis would be shown wrong.

The thesis tested

Part 1: the gap is a set of habits, not a gift

The first part says that what separates a prototype made by conversation from a service others can rely on is a set of disciplines that professional developers practise without naming, and that a non-developer can practise them with an assistant. The book called the practice of building by conversation without reading or structuring the result vibe coding, following the term's attribution to Andrej Karpathy in February 2025 (55, Merriam-Webster, 2025), and it set twelve steps against it.

Two things can be said with some confidence. The first is that the gap is real in the samples that have been measured. An audit of 200 publicly deployed applications built with two assistants found at least one vulnerability in 91.0 per cent of them, and 65.77 per cent of the 1,186 vulnerabilities were rated Critical or High, clustered in broken access control, injection and authentication; the study is a preprint and has not been peer reviewed (109, Deng et al., 2026). The National Vulnerability Database records a case in which an insufficient row-level security policy in one app-builder let unauthenticated remote attackers read or write the database tables of generated sites, tagged as disputed, with the supplier stating that each customer is responsible for protecting its application's data (144, NIST, 2025). An interview study of 22 product team members examined how vibe coding reconfigures prototyping and collaboration in product teams (104, Li et al., 2025). Together they say that the gap shows up where people look for it.

The second is where the evidence stops. None of these studies shows that habits are what is missing. The inference from "these applications have faults that a developer's practice would prevent" to "a non-developer who acquires that practice would avoid them" is the book's own, drawn in Chapters 3 and 4. It is a reasonable inference, because each of the twelve disciplines is established professional practice and each leaves an artefact that a reviewer can inspect. It has not been tested by comparing builders who follow the steps with builders who do not. The verdict is therefore partly established (the gap exists in measured samples) and expected (that habits close it).

Part 2: structure is proportionate

The second part says that the four tiers of AI Developer, Chapter 19 (A personal, B team, C business, D project) set how much of each step applies, and that Tier D is not a citizen build (86, Nordqvist, 2026). This is a design conclusion and not an empirical one. It follows from the observation that the cost of a failure grows with the data, the audience and the irreversibility of what the tool does, and that a rule which asks a personal macro to meet the standard of a claims tool will be ignored.

The two builds illustrate it without proving it. service-point-check began at Tier B and moved to Tier C when it started to run on a schedule, because unattended running changed what could go wrong. claims-doc-check was Tier C from the first day because it handled claimant personal data. Both stayed out of Tier D by a written never-do rule. The builds are fictional and consistent with one another, which shows that the proportion table of Chapter 4 can be applied; it does not show that the proportions are right. The verdict is expected: sound as a design, untested as a package, and dependent on the organisation having a place to say no.

Part 3: the takeover test is the measure of professional

The third part says that a named colleague who did not build the software, given a working day, the repository and the handover pack, can run it, change it and ship the change through the pipeline, and switch it off and restore it, and that this is the measure the book uses for "professional". It is the builder's form of the stewardship principle of AI Developer: Name, Understand, Revert.

The takeover test is the book's own term and its own measure, so no study stands behind it, and the book has said so. Its merits are practical. It is a test that someone other than the builder can run, it fails visibly (the rollback note in the Nordvik Region build failed on 11 December 2031 and was fixed the next day), and it asks for the thing an organisation needs when a builder leaves. Its weaknesses are also practical. It depends on a receiving developer who has the time, and a test that nobody has time to run becomes a certificate. The verdict is expected: a good measure by design, one whose value depends on being run by someone with the authority to say that it failed.

Part 4: AI may draft, generate, explain and execute within a mandate, but may not own and may not be the only judge

The fourth part is the one with the most support. It says that the assistant works inside a written mandate, that the builder remains the named owner, and that the tests and the review are independent of the assistant that wrote the code. Most of this follows from principles already argued in the earlier volumes. The stewardship principle and the independent oracle come from AI Developer; the observer principle and the independence principle behind them come from AI Operations and AI Purple.

There is also evidence on parts of the argument. A study of correlated errors across large language models (24, Kim et al., 2025) bears on the point that a second assistant is not an independent check of the first. A randomised trial of experienced open-source developers measured the effect of early-2025 tools on their work (36, Becker et al., 2025), and its authors later reported that the data of their follow-up were unreliable because developers declined to work without AI or withheld tasks (94, METR, 2026); that is a warning about measuring the effect of assistants on speed, and it applies to the book's own outcome counts. A two-phase experiment with 151 participants, 95 per cent of them professional developers, tested the downstream effect of assistants on how well other developers could evolve the solutions without assistance (102, Borg et al., 2025); it shows that maintainability is a question that can be put to a controlled test. A study of 21 novice students examined the benefits and harms of generative AI for novice programmers (161, Prather et al., 2024). The studies concern different tools, people and tasks, and none tests the mandate or the oracle as the book defines them.

The verdict is that the principle is mostly established as a matter of reasoning from earlier work and from the failure modes of generated code, and that the evidence for the book's particular implementation (a mandate in the repository, an oracle written by a person) is expected and rests on the two builds, in each of which the principle caught a fault.

Part 5: both sides close the gap, and evidence ends the argument

The fifth part says that builders learn the habits and that organisations provide sandboxes, templates, golden paths, a register and receiving developers, and that claims about safety or recklessness are claims with scope, method, date and result, or they are opinions. The first half is a conclusion of Chapters 17 and 21 and of the two builds, in which the route the organisation provided mattered as much as the builder's habits. The second half is the book's method, applied throughout: no chapter says that software is secure, tested or ready without saying what was checked, by whom, when and with what result.

The duty that organisations bear is partly set in law. Article 4 of the AI Act requires providers and deployers of AI systems to take measures to support the development of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf, taking into account their knowledge, experience, education and training and the context of use; it does not require them to guarantee a specific level of literacy of any individual (1, European Union, 2024), and the Commission explains the duty in guidance (45, European Commission, 2026). The book's conclusion is that builders are among those persons, and that a learning plan and a competence record are the evidence that the measures were taken. Whether a particular organisation provides the route is its own decision, and the book can only say what the decision costs when it is not taken. The verdict is expected: it depends on organisations doing what they have said they will do, and on someone measuring it.

Established, expected, speculation

The three labels are those of AI Governance, Chapter 22: observable (happening now and documented), expected (supported by a stated trend or a decided instrument) and speculation (plausible but unevidenced). The table sorts the book's main statements by the strength of their support.

Statement Label Basis Evidence age
Applications built by prompt contain faults in access control, injection and authentication in measured samples Observable An audit of 200 deployed applications (preprint) and a vulnerability record; vendor and sample limits apply Read in November 2026; the field moves in months
The faults are what the twelve steps prevent Expected The book's inference from professional practice; no controlled comparison Untested
Non-developers can produce all twelve artefacts alongside a day job Expected The two builds, which are fictional and illustrative Illustration, not evidence
The independent oracle finds faults the builder's own tests miss Expected One case in the Hansa Mutual build (glass-03); the study of correlated errors in language models as background One build
The takeover test predicts that a tool survives its builder Speculation The book's own measure; no outcome data None
A before-and-after count shows an effect of the tool Speculation Both counts lack a control and are labelled so One to four months
Organisations that provide the route will see fewer unregistered builds Expected The reasoning of Chapter 17; no data in this book Per sweep
Assistants will write more of the specification and the tests Expected The direction of the tools described in Chapter 2 Moves quickly

The table shows a book that rests mostly on reasoning from established professional practice, supported by measured samples of the problem and illustrated by two constructed cases. That is an honest description of where the field stands in November 2026, and it is the reason the book asks its readers to produce evidence of their own.

The author's projections

The following projections are the author's own judgement, in this chapter and in Chapter 20 only. Each carries a label and none is a forecast with a date.

  1. Expected. The share of software that is first built by someone who is not a developer will keep growing in organisations that give them a sanctioned workspace, because the cost of a first version has fallen and the cost of asking a development team for one has not. The organisations that do not provide a workspace will find the same builds outside it.
  2. Expected. The scarce skill will move from producing the first version to verifying it. Assistants will draft specifications, tests and runbooks well, and the independent oracle and the person who writes it will be the part that organisations cannot generate. The receiving developer will become a named role in organisations that take builds seriously.
  3. Expected. Supervisors and auditors will ask for the register and for dated evidence before they ask for the code. A register of builds with tiers, owners and evidence ages is the cheapest answer to a question that will be asked.
  4. Speculation. The twelve steps will be absorbed into templates and golden paths to the point that a builder meets most of them as defaults rather than as steps. If that happens, the book becomes a description of what the template does and not a guide to what the builder does, and the gates remain only where a person must decide.
  5. Speculation. A few kinds of builds will leave the citizen's reach by regulation or by incident, and the line between Tier C and Tier D will move towards caution before it moves away from it.

None of these is a prediction that a particular tool or law will arrive on a particular date. They are the author's reading of the direction of the evidence in this book, and a reader who disagrees with them can still use the twelve steps.

Five things to do on Monday

The book's practical conclusion is five actions. They are small on purpose, each produces an artefact, and each can be done in a day by the person named. The roles differ and the actions do not: the first four belong to a builder, and the fifth belongs to whoever receives or provides.

  1. Open a build record for the one thing you have built that others use. Write its purpose, its user, its tier and its owner. If you cannot say who the user is, that is the first finding.
  2. Answer the five questions of Step 2 Tier in writing. Who uses it, what data it holds, what can go wrong, what law applies, and whether it runs unattended. If any answer puts it in Tier D, stop and call a developer.
  3. Write the mandate for your assistant and put it in the repository. State what it may read, change and run, and what it may not do. Write down that it may not read secrets or production data, may not push to the main branch, and may not edit its own rules, the pipeline or the oracle.
  4. Ask someone else to write five tests that you have not seen. That is the start of an independent oracle. Run them and record the result with the date.
  5. Name a deputy and book a takeover test. If you are a developer, tech lead or platform engineer, offer to be the receiving developer for one build. If you are a leader, ask the register's owner which builds have no deputy.

Practical guide: Your own Monday, the first hour with your build record

Purpose. To leave on Monday with the one artefact that carries the whole build: a build record with an honest gate status.

Roles. The builder; for the last step, one colleague.

Inputs. The repository of the thing you built (create one if there is none), the assistant you use, and 60 minutes.

Steps.

  1. Minutes 0 to 10: create docs/build-record.yaml with the fields in the example below. Fill in the purpose and the user in your own words, not the assistant's.
  2. Minutes 10 to 25: answer the five questions of Step 2 Tier and write the tier and the reasons.
  3. Minutes 25 to 40: for each of the twelve steps, write the state of its gate as one of met, open or not applicable at this tier, with the artefact that shows it. Most gates will be open. Record that.
  4. Minutes 40 to 50: write the evidence date next to every met gate. If you cannot say when it was checked, it is open.
  5. Minutes 50 to 60: send the file to the colleague who will be your deputy and ask them to read it and tell you what they do not understand.

Exit gate. A colleague has read the record and has named the three gates they would check first. The gate is met by their reply, not by your feeling that the record is complete.

Artefact. docs/build-record.yaml, in the repository, dated.

# docs/build-record.yaml (a starting point for your own build)
build:
  id: BLD-XX-2032-0001
  name: my-tool
  owner: your name
  deputy: to be named
  purpose: one sentence, in your words
  user: who uses it and how many
  tier: B            # A, B, C or D; D is not a citizen build
  tier_reasons:
    - data held: internal only
    - unattended: no
  gates:
    step_01_intent:        {status: met,  artefact: docs/intent.md, date: 2032-02-09}
    step_02_tier:          {status: met,  artefact: this file, date: 2032-02-09}
    step_03_workshop:      {status: open, artefact: null, date: null}
    step_07_prove:         {status: open, artefact: tests/oracle/cases.yaml, date: null}
    step_09_ship:          {status: open, artefact: null, date: null}
    step_12_hand_over:     {status: open, artefact: docs/handover.yaml, date: null}
  note: the remaining steps follow the same pattern; open means not shown yet

Across the usage modes

The table sets the conclusions of the book against the usage modes, from the ambient assistant to the autonomous agent, and gives the highest degree of delegation the builder should allow.

Usage mode What the builder uses it for Highest degree of delegation for the builder What the book concludes
Mode 0 Ambient AI Suggestions in documents and tools already in use Level 0 Advisory Not a build tool; the builder remains responsible for what is copied out of it
Mode 1 Conversational assistant Interviewing about intent, drafting the specification, explaining a diff Level 0 Advisory The place to learn and to ask; nothing it says is evidence
Mode 2 Embedded assistant Writing code and tests in the editor, on a branch Level 2, edits a branch The builder reads the diff; the assistant does not own the result
Mode 3 Agentic work tool in a sandbox Delegated tasks inside a mandate, with a run record Level 3 Bounded Useful with a mandate in the repository and a run record per session
Mode 4 Built AI applications A built tool that calls a model Governed by the platform Goes to the platform's rules; not a builder's decision
Mode 5 Autonomous production agents None Not used Not for builders

Level 4 Autonomous is never used for the builder's assistant on production data, on credentials, on the gates of the pipeline, on its own mandate or on a decision about a named person. The reason is the one in Part 4 of the thesis: what verifies an action must be independent of what performed it.

Nordvik Region and Hansa Mutual

The two organisations close the book as they opened it. Hanna Wikström's service-point-check runs on Mondays at 06:00 and reports mismatches in the opening hours and notices of the Region's 24 service points to the e-services team's wiki. The Region's next question is how many builds the platform team and one receiving developer can support, and the answer is in Chapter 24. Katarzyna Nowak's claims-doc-check lists the documents missing from motor property-damage claims in the Polish service centre, and the group's next question is how far the evidence from one team in one country extends. Each organisation holds a dated record of what was checked and by whom. Neither has proof that the method causes the better results the counts suggest, and both know what they would have to do to find out. That is what the book asks of an organisation: not that it be certain, but that it can show what it did.

What would show the thesis wrong

The disposition of the book named three conditions under which the thesis would be wrong. They are repeated here, with a way to look for each.

  1. Independent evidence that non-developers who follow structured practice with assistants produce software that is no better in quality, security or maintainability than that of those who do not. To look: compare matched builds, with and without the twelve steps, in organisations that have a register; score them by an assessor who does not know which is which, using the same checks (a standard secure-development baseline, a restore test, a takeover test) and the same dates. The comparison needs a few dozen builds and a year, which a large organisation or a group of authorities could supply.
  2. Evidence that the twelve steps cost more than the failures they prevent at every tier. To look: record the hours spent on each gate and the incidents, rework and data protection events of builds in the same register, by tier. If the cost at Tier A exceeds the harm it prevents, the book's proportion table is wrong at that tier and should be cut.
  3. Evidence that production software built by non-developers without developer review does as well on incidents, data protection and continuity as software built through the development organisation. To look: compare incident and restore records of Tier C builds with and without a receiving developer. If there is no difference, the receiving developer is a ritual.

Two further conditions apply to individual claims. A claim for the oracle is wrong if oracle cases written by a person find no more faults than the assistant's own tests across a sample of builds. A claim for the takeover test is wrong if tools that passed it fail no less often than tools that did not, within a stated period. Each is a question that an organisation that keeps a register can answer, and none has been answered here.

Whoever runs such a comparison should publish the method with the result: how builds were chosen, who scored them, over what period and with which checks, and what the comparison could not control. A result without those four facts is an opinion with a number attached. An organisation that finds the thesis wrong in its own setting has learned something useful, and the book's recommendation is then to narrow the steps at the tier where they failed to pay for themselves and to say so in the register, with the date.

A note on the series

Vibe to Dev is the thirteenth volume of The Transformed Architecture, and it takes the earlier books as given. Architecture as Code supplied the practice of keeping the intent, the tests and the pipeline as code. AI Governance supplied the labels and the habit of recording decisions. AI Operations supplied the practice of change, restore and runbook that Step 9 Ship and Step 10 Run apply at the builder's scale, and AI Developer supplied the principle, the tiers and the ladder that this book teaches from the builder's side. The thread through the series is that AI changes who can do a piece of work and does not change who answers for it. Each book states, for its own subject, what the person who answers has to be able to show. Here the person is the builder and the answer is a build record, a handover pack and a colleague who has run the takeover test.

Summary

This chapter concerns all twelve steps and the developer functions D1 Frame to D5 Steward. It judged the five parts of the thesis. The gap between vibe coding and professional development is real in the measured samples and the claim that habits close it is the book's own inference. Proportionate structure and the takeover test are sound designs that rest on reasoning and on two illustrative builds. The principle that AI may not own and may not be the only judge of its work is the best supported, mostly by reasoning from earlier volumes and by studies that bear on parts of it. The claim that both sides close the gap is expected, and depends on organisations providing the route and measuring it.

The book's statements are sorted by label in a table, and the author's projections are given, labelled, in this chapter. The conditions under which the thesis would be wrong are stated with a way to look for each. Five actions for Monday give a reader a build record, a tier, a mandate, an independent oracle and a deputy.

The book asks for evidence and has tried to offer it only where it exists. A reader who follows the twelve steps for one build, and keeps the record with its dates, adds to the evidence that the book could not supply.

Sources

  1. Merriam-Webster. Vibe coding. Merriam-Webster "Slang and Trending" entry. (55, Merriam-Webster, 2025)
  2. Deng, J., Fan, Z. & Meng, R. (2026). Understanding the (In)Security of Vibe-Coded Applications. arXiv:2606.23130. (109, Deng et al., 2026)
  3. National Institute of Standards and Technology (2025). CVE-2025-48757 Detail. National Vulnerability Database. (144, NIST, 2025)
  4. Li, J., Hou, Y., Lin, L., Zhu, R., Cao, H. & El Ali, A. (2025). Vibe Coding in Product Teams: Reconfiguring AI-Assisted Workflows, Prototyping, and Collaboration. arXiv:2509.10652. (104, Li et al., 2025)
  5. 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)
  6. Kim, E., Garg, A., Peng, K. & Garg, N. (2025). Correlated Errors in Large Language Models. ICML 2025; arXiv:2506.07962. (24, Kim et al., 2025)
  7. Becker, J., Rush, N., Barnes, E. & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089. (36, Becker et al., 2025)
  8. METR (2026). We are Changing our Developer Productivity Experiment Design. METR blog, 24 February 2026. (94, METR, 2026)
  9. Borg, M. et al. (2025). Echoes of AI: Investigating the Downstream Effects of AI Assistants on Software Maintainability. arXiv:2507.00788. (102, Borg et al., 2025)
  10. Prather, J. et al. (2024). The Widening Gap: The Benefits and Harms of Generative AI for Novice Programmers. ICER 2024; arXiv:2405.17739. (161, Prather et al., 2024)
  11. European Commission. AI Literacy: Questions and Answers. Shaping Europe's digital future. (45, European Commission, 2026)