Should Everyone Build? A Debate

This chapter asks whether organisations should let people who are not developers build software with an AI assistant, and answers in the form of a debate: the strongest case for concern, the strongest case for calm, the facts and measures on which both sides agree, and what each role can do. It concerns all twelve steps, from Step 1 Intent to Step 12 Hand over, because the debate is about whether the method of this book is enough, and it ends with the author's own labelled projections, which this book keeps for this chapter and for Chapter 25. The five developer functions of AI Developer stand behind the debate: D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward. A builder can do the first three with an assistant from the first day. Whether the builder can do the last two, and whether the organisation can tell, is where the two positions part.

The debate: the case for concern, the case for calm, the meeting point, the actions and the verdict

Figure 20.1: The debate in four steps, ending in a verdict.

The question

Chapters 5 to 16 teach the twelve steps as if the decision to build had already been taken. Chapter 17 and Chapter 18 describe what an organisation provides so that the builder is not alone. This chapter steps back and asks the question that a board, a works council or a sceptical head of development is entitled to ask first: should this be allowed at all, and at what scale?

The question divides people who agree on the facts, because it mixes three separate questions. The first is empirical: how good, how safe and how maintainable is software built by non-developers with an assistant, compared with the alternatives? The second is about alternatives: the real alternative to a builder's tool is rarely a development team's project, which has a waiting list, and is often a spreadsheet, a manual routine or an unsanctioned online service. The third is about the organisation: who carries the consequences when such a tool fails, and who pays for the structure that makes failure less likely.

The vocabulary of the book applies. A builder is a person who is not a developer and builds software; a developer is the professional. The tiers of AI Developer, Chapter 19, set how much structure a build needs: Tier A personal (used only by the maker), Tier B team (colleagues in one unit, internal data), Tier C business (personal data, money, a record of the organisation, more than one unit, or unattended running) and Tier D project (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). Tier D is not a citizen build. The takeover test (Chapter 4) is the book's measure of a professional result: a named colleague can, in a working day, run the software, change it and ship the change, and switch it off and restore it.

The debate follows the form of the authoring guide. Each position is stated at its strongest, with the evidence of those who hold it. Within each position, what a source reports is kept apart from interpretation: the study, its population, its task and its conditions come first, and what it means for the debate comes after. Most of the studies below were made on developers, students or knowledge workers, not on builders, and the chapter says so each time. The book has found no controlled study that compares software built by non-developers who follow structured practice with software built by non-developers who do not, and that absence is itself a finding (Question Q25 in the foundations of the book).

The debate

The case for concern

The strongest argument for concern is not that builders are careless. It is that the properties which make software trustworthy are invisible to the person who built it, that the assistant makes the invisibility worse, and that the people who suffer the failure have not agreed to be part of the experiment.

The base rate of errors in software written outside development is high. Panko reviewed field audits of real organisational spreadsheets and reported that seven audits between 1987 and 2000 found errors in 24 per cent of 367 spreadsheets, and that the audits from 1997 onwards, which used better methods, found errors in 91 per cent of the 54 spreadsheets audited. He also reported that most of the audits counted only substantive errors, and his review concluded that, of the remedies then proposed, only cell-by-cell inspection of the code had been shown to work (106, Panko, 2000). A spreadsheet is the oldest form of building by non-developers. The study says that errors in such tools were common in the audits, not that every tool was wrong, and the sample is old and mixed. Those who raise concern read it as a base rate: a builder who tests only by looking at the result has the error profile of the spreadsheet author, with more places for an error to hide.

Generated applications are being deployed publicly, and the audit of them is poor. Deng, Fan and Meng collected 9,041 open-source applications built with two AI app-building tools and audited 200 publicly deployed ones. They found 1,186 vulnerabilities, at least one in 91.0 per cent of the audited applications, and 65.77 per cent of the vulnerabilities were rated Critical or High (109, Deng et al., 2026). The paper is a preprint and the sample is public applications, so it says nothing about internal tools, which may be better or worse. The concern reads it as evidence of a pattern: what an assistant produces by default is not safe by default, and a builder who cannot read the result cannot tell.

The pattern is older than the assistants. In 2021 UpGuard reported 38 million records exposed through the portals of 47 entities built on a low-code platform, because lists had table permissions disabled by default; the supplier first closed the report as by design and later made the permissions enabled by default for new portals (143, UpGuard, 2021). The report is by a security vendor and the supplier's own account was not read. A later record in the National Vulnerability Database describes an insufficient row-level security policy in one natural-language app builder that allowed unauthenticated users to read or write the database tables of generated sites; the record is tagged disputed, with the supplier stating that each customer is responsible for protecting its application's data (144, NIST, 2025). What the two cases share, beyond the technology, is a default whose responsibility was disputed between platform and customer.

The assistant widens the gap between confidence and correctness. Perry and colleagues ran a user study with 47 participants who completed five security-related programming tasks in three languages. Participants with access to an AI assistant wrote significantly less secure code than those without it, and were more likely to believe that they had written secure code. Participants who trusted the assistant less and engaged more with their prompts produced code with fewer vulnerabilities (23, Perry et al., 2023). The study measured programmers on short tasks with one assistant, and the assistant is now several generations old. Lee and colleagues surveyed 319 knowledge workers, who gave 936 examples of using generative AI at work, and reported that greater confidence in the tool was associated with less critical thinking, while greater confidence in one's own ability was associated with more (42, Lee et al., 2025). The data are self-reported and the workers were not building software. The concern interprets both as describing the builder's position exactly: a person who cannot judge the code is the person most likely to trust it.

The perception problem is documented for experts too. In a randomised trial by METR, 16 experienced open-source developers completed 246 tasks in their own mature repositories, each task randomly allowed or disallowed early-2025 AI tools. Before the study the developers forecast that AI would cut completion time by 24 per cent, afterwards they estimated that it had cut it by 20 per cent, and the measured result was a 19 per cent increase in completion time (36, Becker et al., 2025). The result concerns experienced developers working on large codebases they knew well, a setting far from a builder's small tool, and the same research group has since changed its experiment design (94, METR, 2026). The concern uses it for one point only: perceived and measured effects can diverge by a large margin, and a builder's sense that the tool works is not evidence that it does.

Failures fall on people who did not choose the risk. The data in a Tier C tool belong to citizens, customers or staff. A person whose claim is delayed or whose record is exposed is not a party to the builder's decision. A catalogue entry of July 2025 lists press reports that an agent on a hosted development platform ran destructive commands during a code freeze and that production data were lost; it lists no primary post-incident report, and the book uses it only as a reported illustration of why an agent's reach is set outside the agent (22, AI Incident Database, 2025).

The organisation's incentives point the wrong way. The last argument is about the organisation and not the builder. A programme that calls builders "citizen developers" can be read by a finance director as a way to obtain software without a development budget, without review capacity and without the cost of assurance, and a works council can read it as a way to ask staff to take on a second job. No study found for this book measures that substitution, so it carries the label speculation. It deserves a place in the debate because the records that would reveal it, headcount and review capacity set against the number of Tier C tools, are ones the organisation controls.

The case for concern ends in a proposition that a reader can test: for any build above Tier A, the default should be that a developer builds it, and the exception, not the rule, should be a builder who has shown that the gates are met.

The case for calm

The strongest argument for calm starts with a fact the concern shares: people who are not developers have always built software, and the question is only whether the organisation sees it and shapes it.

Building outside development is old, large and mostly invisible. Ko and colleagues opened their 2011 survey of end-user software engineering by noting that most programs are written by people with expertise in other domains, and cited a projection from US labour statistics of fewer than 3 million professional programmers in the United States by 2012 against more than 55 million people using spreadsheets and databases at work (105, Ko et al., 2011). The second figure counts users of a kind of tool and is a projection made before low-code platforms existed in their present form. The case for calm reads it as the right baseline: the organisation's choice is not between builders and no builders, but between builders it can see, with a template, a register and a receiving developer, and builders it cannot.

Prohibition has the weakest evidence. Gillespie and colleagues, funded by KPMG, surveyed more than 48,000 people in 47 countries between November 2024 and January 2025, among them 32,352 employees. Almost one in two employees who use AI reported doing so in ways that contravene organisational policies and guidelines; 48 to 49 per cent reported having uploaded sensitive company information or copyrighted material to public AI tools; and 56 per cent reported using AI at work without knowing whether it was allowed. Such uploading was most common among employees who reported that their organisation had banned generative AI (67 per cent) or had a policy guiding its use (56 per cent), compared with employees in organisations with no policy (33 per cent) and those unsure whether there was one (38 per cent); the authors read this as suggesting that outright bans may be ineffective and that clear guidance and education are needed (32, Gillespie et al., 2025). The data are self-reported, the authors note possible under-reporting, the survey concerns AI use in general and not building, and the association does not show that a ban caused the behaviour. The case for calm reads it as consistent with a position held across the series: a sanctioned route that is at least as good for the task as the unsanctioned one does more than a prohibition (AI Developer, Chapter 19; AI Leader, Chapter 10) (86, Nordqvist, 2026) (85, Nordqvist, 2026).

Structure changes the outcome, and the studies of governance say how. Viljoen and colleagues drew on 30 interviews with citizen developers and low-code platform experts and reported that the hazards are poor software quality, shadow IT and technical debt, that technical experts play a central role in governing citizen development, and that platform-specific features matter (123, Viljoen et al., 2024). Stegmann and colleagues interviewed companies that operate internationally about their governance of low-code platforms and reported preliminary findings that the strict, centralised governance favoured in the literature is not always suitable and that more differentiated structures are needed (124, Stegmann et al., 2024). Both are qualitative studies of low-code platforms, not of assistants, and neither measured outcomes against a control. The case for calm uses them for the design they point to, which is the tier system of this book: governance in proportion to what can go wrong, with developers in a supporting role. Platform vendors document the same pattern in their own terms, for example as data policies that decide which connectors may be combined in which environment, which by default are not implemented in a tenant (107, Microsoft, 2025); the pattern, not the product, is the point.

The evidence of harm is not uniform, and the worst findings are conditional. Sandoval and colleagues ran a user study with 58 student programmers who implemented a shopping-list structure in C and reported that assisted users produced critical security bugs at a rate no greater than 10 per cent more than the control, concluding that in that low-level setting the assistant did not introduce new security risks (139, Sandoval et al., 2023). The setting was one task in one language with students, and it sits beside the result of Perry and colleagues, which went the other way. The case for calm does not claim that one study cancels the other. It claims that the effect depends on the task, the person and how the assistant is used, a conclusion that the studies on learning (next section and Chapter 21) also reach, and that a design which controls how the assistant is used (a mandate, a specification, tests the assistant did not write) addresses the mechanism that the concern describes.

Practice has value that a waiting list does not. Li and colleagues interviewed 22 product team members about vibe coding in product teams and reported that it speeds iteration, supports creativity and lowers barriers to taking part in product development, while participants also reported unreliable code, difficulty integrating generated output and concerns about over-reliance and deskilling (104, Li et al., 2025). A builder who automates a manual reminder removes a delay that the development backlog would not have reached for a year. The illustrative builds of this book are examples of such gains: a weekly mismatch report across 24 service points, and a list of missing documents per motor claim. Their measures are before-and-after counts without a control and say that the problem they target moved, not that the tool caused the move.

Most builds are small. The sweeps of the two illustrative organisations in 2030, reported in AI Developer, Chapter 19, classed 31 of 60 applications at Nordvik Region and 96 of 150 at Hansa Mutual as Tier A, and 18 and 31 as Tier B (86, Nordqvist, 2026). The organisations are fictional and the figures illustrative. They stand for a pattern that the register is designed to reveal in a real organisation: a small share of builds carries the personal data and the unattended running that make a failure serious.

The case for calm ends in a proposition that a reader can also test: for Tier A and Tier B, a builder who follows the steps is a better outcome than the unsanctioned alternative, for Tier C the builder works with a receiving developer under gates, and the organisation that provides this lane is safer than the one that forbids building.

Where the positions meet

Read side by side, the two cases do not contradict each other on any measured fact. They differ in the weight they give to four things, and they share more than the debate usually admits.

Both accept the Level 4 prohibitions. For the builder's assistant, Level 4 Autonomous 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. A build that would need any of these is Tier D and not a citizen build. Mode 5 Autonomous production agents is not for builders.

Both accept the need for ownership and handover. The concern's strongest examples, the open data stores and the exposed records, are failures of nobody being responsible for a default. The calm position's strongest example, the register, is a means of naming an owner. Nobody in the debate defends an unowned tool. The stewardship principle (Name, Understand, Revert) applies to the builder as it does to the developer: a named owner and deputy, an understanding that does not live only in the assistant's context, and a tested way to switch the tool off and restore it.

Both accept proportion by tier. The concern asks for a developer where the calm position asks for a gate. At Tier A the disagreement is small, because the damage is limited to the maker. At Tier C it is also small in practice, because the calm position already requires a receiving developer. The disagreement lives in Tier B and in the transition from B to C. The book's answer, set out in AI Developer, Chapter 19, and in Chapter 4 of this book, is that a prototype becomes production by use: a second unit begins to use it, personal data of people outside the team enters it, or it runs unattended. The promotion criteria are data, the evidence expires, "not tested" counts as not met, and a pipeline identity promotes, never the maker.

Both accept synthetic data in development, independent checks and evidence with age. The independent test oracle, cases written by someone other than the builder and the assistant, answers the finding that the builder cannot judge the generated code, and the evidence-age rule answers the finding that perceived and measured effects diverge. Both therefore accept that a claim such as "tested" or "secure" is incomplete without what was checked, by whom, when and with what result.

The positions differ on three points that no study settles. They differ on capacity: the concern holds that the review a Tier C tool needs is a cost that the organisation will not pay, and the calm position holds that the cost is smaller than the cost of unseen tools. Question Q29 of the foundations asks how many builds a development organisation can receive before review becomes the bottleneck, and no study answers it. They differ on learning: the concern holds that builders who delegate the work do not become able to judge it, and the calm position holds that structured use teaches. The studies of skill formation say that both can happen, depending on how the assistant is used, which the next chapter treats. They differ on motive: whether the programme is introduced to help staff or to avoid cost. The only available evidence is the organisation's own records, which is the argument for publishing them.

The practical consequence of the shared ground is that the choice is not "everyone builds" or "nobody builds". It is "which builds, with which structure, with whose review", and that question can be answered with a table.

What can be done

The actions that follow from the shared ground differ by role.

Builders follow the steps and stop at the tier boundary. The concrete rules are those of the earlier chapters: write down the intent and the tier before opening the assistant (Steps 1 and 2); keep secrets and production data out of the repository and the assistant's reach (Step 3); have the cases that define correct written by someone other than the assistant (Steps 4 and 7); and name the owner and the deputy (Step 11). A builder stops and calls a developer when the tool would touch personal data of people outside the team, money, a record of the organisation, a second unit or unattended running, because each of these moves the build to Tier C, and when it would rank or decide about a named person, because that is Tier D.

Developers coach, receive handovers and publish golden paths. A receiving developer runs the takeover test and says what failed. The time a developer spends coaching and receiving is work and needs a budget, which is the first measure of whether the programme is honest.

Leaders provide the lane, measure with evidence and refuse headcount-driven substitution. Providing the lane means the workspace, the template, the register and the named receiving developers (Chapter 17). Measuring with evidence means that a claim about adoption, productivity or quality carries its scope, method, date and result, and that "not measured" is an admissible entry (AI Developer, Chapter 20). Refusing substitution means a written statement, agreed with employee representatives, that the programme is not a means of reducing development capacity and that a change in that capacity is reported against the number of Tier C tools. Chapter 24 returns to this for the two organisations.

Representatives agree what is monitored and by whom. A register records the tool, the data and the owner role; it does not record how often a named person used it, and a measure that logs the tool use of identifiable people is a technical device that can monitor behaviour or performance, which in Germany brings it within section 87(1) no. 6 of the Works Constitution Act whatever the employer intends (7, Germany, n.d.) (162, Bundesarbeitsgericht, 2024) and which in Sweden is a matter for the employer's duty to negotiate before an important change under section 11 of the Co-determination Act, which concerns an important change of operations or of working conditions and runs towards unions with which the employer has a collective agreement (10, Sveriges riksdag & Regeringskansliet, 1976). Representatives can also ask for the sweep figures by tier and for the review capacity set against them.

A rule that follows from the debate

The shared ground can be written down. The guide below turns it into one file that a builder reads, a developer enforces and a representative reviews.

Practical guide: A decision aid for a leader: what to permit at which tier

Purpose. To turn the debate into a rule that a builder can read, a developer can enforce and a representative can review: for each tier, which data a build may use, whether a register entry and approval are needed, which gates apply and how long evidence stays valid.

Roles. The head of IT or development owns the table. The platform engineer or platform lead puts it into the workspace and the pipeline. A receiving developer applies it to Tier C. The data protection officer reviews the data column. Employee representatives review what the register may and may not record.

Inputs. The latest sweep (counts by tier); the tier definitions of AI Developer, Chapter 19; the Level 4 prohibitions; the gates of Chapters 5 to 16; the review capacity of the receiving developers, in days per quarter.

Steps.

  1. List the tiers and, for each, the data classes allowed. Tier A allows the maker's own and public data. Tier B adds internal data. Tier C allows personal data, money and records of the organisation, and Tier D is not offered.
  2. For each tier, say whether a builder may start without approval. Tier C needs approval and a named receiving developer before the first line of code, not after the first release.
  3. For each tier, list the gates required, by the names of the steps. The proportion tables of the step chapters give the content, and the permit table gives the minimum.
  4. For each tier, set how long evidence stays valid. This book uses 90 days for tests of a running tool at Tier C as an illustrative convention. Expired evidence counts as not met.
  5. Write the common prohibitions once: no production data in a prompt or a repository; no change by the assistant to its own mandate, tests or pipeline gates; no decision about a named person's employment, pay or access to work.
  6. Check the table with a short script that fails when a tier permits Level 4 or when a tier with personal data lacks a receiving developer. Keep the table and the script in version control.
  7. Set a review date. A table that is not reviewed on a date is a statement of intent.

Gate. The table is in the repository, the check passes, the review date is set, and the representatives have seen the register fields.

Artefact. permit-by-tier.yaml, with the check below.

# permit-by-tier.yaml: what a builder may do at each tier (Nordvik Region, illustrative)
version: 1
adopted: 2031-12-17
owner_role: Head of IT and Digitalisation
review_every_days: 180
assistant_level_ceiling: 3        # Level 3 Bounded, never Level 4 Autonomous
never:                            # applies at every tier
  - production data in a prompt or a repository
  - a change to the assistant's own mandate, tests or pipeline gates
  - a decision about a named person's employment, pay or access to work
tiers:
  A:
    data: [own, public]
    may_start_without_approval: true
    register_entry: optional
    gates_required: [intent]
    evidence_valid_days: 365
  B:
    data: [internal]
    may_start_without_approval: true
    register_entry: required
    gates_required: [intent, specification, prove, own]
    evidence_valid_days: 180
  C:
    data: [personal, money, record]
    may_start_without_approval: false
    register_entry: required
    gates_required: [intent, specification, prove, secure, ship, run, own, hand_over]
    evidence_valid_days: 90
    receiving_developer: required
  D:
    citizen_build: false
    route: development project with a mandate and an impact assessment

# check_permit.py: fail the pipeline if the table permits what the book prohibits
import sys, yaml

policy = yaml.safe_load(open(sys.argv[1]))
assert policy["assistant_level_ceiling"] <= 3, "Level 4 is never permitted"
for name, tier in policy["tiers"].items():
    if tier.get("citizen_build") is False:
        continue
    for key in ("data", "register_entry", "gates_required", "evidence_valid_days"):
        assert key in tier, f"tier {name} lacks {key}"
    if "personal" in tier["data"]:
        assert tier["receiving_developer"] == "required", f"tier {name}: personal data needs a receiving developer"
print("permit table ok:", ", ".join(policy["tiers"]))

Run it with python3 check_permit.py permit-by-tier.yaml. The script reads the file with PyYAML, stops with a message when a rule is broken and prints the tiers when the table is sound.

A permit-by-tier table, read by a builder

Worked example (illustrative). The same table, in the words a builder reads.

Tier May start without approval Data allowed Register entry Receiving developer Evidence valid for
A personal Yes Own and public Optional No 365 days
B team Yes, with a register entry Internal Required Named, consulted 180 days
C business No: approval first Personal data, money, records Required Required, before the first line 90 days
D project Not a citizen build Not applicable Not applicable Development project Not applicable

The numbers of days are conventions of the illustrative organisation and are not drawn from a study. The point of the table is that it can be wrong in a reviewable way: a review date that passes without a change is a finding.

Verdict

The verdict separates what is observable from what is expected and from what is speculation, as the authoring guide requires, and it states what people and organisations can influence.

Observable. Non-developers build software in large numbers, and have done for decades (105, Ko et al., 2011). Applications built with assistants are deployed publicly by people who did not write them, and an audit of 200 of them found a vulnerability in nine of ten (109, Deng et al., 2026). Access failures from defaults recur across low-code and natural-language builders (143, UpGuard, 2021) (144, NIST, 2025). In a controlled study an assistant was associated with less secure code and higher confidence in it (23, Perry et al., 2023), and in another with no more than 10 per cent more critical bugs (139, Sandoval et al., 2023). Prohibition did not coincide with less risky behaviour in a self-reported survey (32, Gillespie et al., 2025). Governance studies of low-code platforms point to differentiated, expert-supported governance (123, Viljoen et al., 2024) (124, Stegmann et al., 2024). No controlled study compares structured and unstructured building by non-developers.

Expected. The number of builders in a given organisation rises, because the cost of a first working version has fallen. Registers, tiers and promotion criteria become ordinary practice in organisations of this size, because instruments in force assign duties to the controller, the deployer and the provider whoever typed the tool (GDPR Articles 25, 30 and 32; AI Act Articles 3 and 25), and a duty of record is hard to meet without a register. The support burden on development organisations rises with the number of Tier C tools. These are inferences from stated trends and decided instruments, not measurements.

Speculation. That most business software will come to be built by non-developers is plausible and unmeasured. That the programme will be used to reduce development capacity is plausible and unmeasured. Both can be tested by the organisation's own records.

What people and organisations can influence. The verdict of the book is that the choice is the lane and not the permission. A builder can influence the quality of a build by following the steps and by calling a developer at the boundary. A developer can influence the outcome by coaching and by publishing paths that are easier to follow than to avoid. A leader can influence it by funding the receiving developers, by publishing the sweep figures by tier and by writing down that the programme is not a substitute for capacity. A representative can influence it by agreeing the register fields. The result depends on three things that the organisation controls: whether the receiving developers have time, whether the evidence is kept and dated, and whether Tier D is kept out of the lane.

The author's projections

This section is the author's own judgement, kept apart from the findings above and labelled as this book requires. Each projection carries a label and the observation that would change it.

  1. Expected. The author expects that in organisations that keep a register, most builds will remain Tier A and Tier B for as long as the cost of review is borne by developers, because the cost of Tier C is borne at the boundary and the builder has a reason to stay below it. The illustrative sweeps (about 52 and 64 per cent Tier A, about 30 and 21 per cent Tier B, and about 18 and 15 per cent Tier C at the two organisations) are consistent with this and do not demonstrate it. A register kept for several years in which Tier C grows faster than the number of receiving developers would show the projection wrong.
  2. Expected. The author expects the unit of governance to move from the tool to the builder's practice: organisations will ask what a builder has shown (a specification, an independent test, a restore test) and not whether the builder has been trained. This follows from the argument of Chapter 21, that competence is shown by evidence and not by attendance, and from the evidence-age rule. A finding that attendance predicts outcomes better than evidence would change it.
  3. Speculation. The author considers it plausible that the line between builder and developer will blur for small tools and sharpen for tools that carry personal data, because the second kind needs the review and ownership that the first does not. No study measures this. The share of Tier C tools that are passed to a developer team within two years of promotion would be the number to watch.
  4. Speculation. The author considers it plausible that a serious incident in a builder-made tool at a European public authority or insurer will lead a supervisory or audit body to ask for the register before it asks for the tool. If that happens the registers will be read as evidence, and an organisation that kept one with dates and results will be in a different position from one that kept a list. This is a view about regulators' behaviour and is unsupported by a record.
  5. Speculation. The author does not project that builders replace developers. The evidence of this book points the other way: the work that grows with the number of builders is review, receiving, coaching and stewardship, which are developers' work (AI Developer, Chapter 29, labels the question "fewer, more or different" and answers "different") (86, Nordqvist, 2026). A reduction of development capacity justified by the programme would be a decision about the organisation, not a consequence of the technology.

The book's central projection, which Chapter 25 sets beside the rest of the book's conclusions, is that the gap between a prototype and a service others can rely on does not shrink because the first version costs less. It moves to the habits and the lane, and that is a place where people and organisations can act.

Across the usage modes

The debate applies differently across the usage modes of the series.

Usage mode What a builder does The debate's position
Mode 0 Ambient AI Suggestions inside a spreadsheet or studio that the vendor switched on Both sides: visible in the register only if someone asks; the builder may not know the assistant is there
Mode 1 Conversational assistants A chat to draft code that is pasted into a file Concern: confidence without reading; calm: a route that works with a template
Mode 2 Embedded assistants Suggestions and edits in the editor, reviewed by the builder The usual builder mode; both sides accept it within a mandate
Mode 3 Agentic work tools A task handed to an assistant inside a sandbox, returned for review Accepted in the builder workspace and lane at Level 3 Bounded, with run records
Mode 4 Built AI applications The builder's tool calls a model itself The tool is an AI system with a provider and a deployer; Tier C or D, with a developer
Mode 5 Autonomous production agents An agent acts in production on its own Not for builders; Level 4 prohibitions apply

At every mode the ceiling is the same. The assistant of a builder works at most at Level 3 Bounded within a mandate, and Level 4 is not used for any of the actions that the permit table lists.

Nordvik Region and Hansa Mutual

The two organisations hold different positions, and both are partly right.

Nordvik Region is cautious about casework data. It has few developers to review Tier C tools, so its limit is reviewer capacity, and its caution is that a rule list for ordering a verification queue is the ranking of applicants for a benefit and is therefore Tier D, as the 2030 sweep found for one of the eleven Tier C applications. The Region's answer is the permit table above, adopted on 2031-12-17 by the digital steering group two days after the promotion of service-point-check to Tier C (AIDR-1203), and the builder workspace of October 2031 (AIDR-1200). The union representative for IT staff, Tomas Ekblad, is shown the register fields under MBA-NR-2030-03 before they are used. Hanna Wikström's build stays inside the table: it reads public and internal data, never writes to the portal, and has a named receiving developer, Rasmus Holm, who ran the takeover test and found one failure.

Hansa Mutual is under pressure to move fast with Flowdesk, with about 400 business builders and 150 applications in the 2030 sweep. Its caution is applied through the group data protection officer, whose screening of claims-doc-check narrowed its scope to property-damage claims because injury claims may hold health data (GDPR Article 9) (AIDR-1251). Its lane gives Katarzyna Nowak a named receiving developer, Tomasz Wrona, in the Polish service centre, and the group's pipeline reads production exports with its own identity. Her build is Tier C from the start, and the independent oracle caught a rule error that the assistant's own tests missed.

Both organisations show what the debate does not settle. Nordvik's limit is the number of Tier C tools its reviewers can receive. Hansa's limit is the number of external services that business units can reach without the group knowing. Chapter 23 tells the two builds in full, and Chapter 24 draws the conclusion for each organisation.

Summary

This chapter concerned all twelve steps and the developer functions D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward, and staged the question of whether everyone should build as a debate in four steps. The case for concern rests on the high base rate of errors in software written outside development, an audit in which nine in ten publicly deployed AI-built applications had at least one vulnerability, a user study in which an assistant was associated with less secure code and more confidence in it, and failures that fall on people who did not choose the risk. The case for calm rests on the age and scale of building outside development, a survey in which risky behaviour was most common where generative AI was banned, qualitative studies of governance that favour differentiated, expert-supported structure, studies whose results depend on the task and on how the assistant is used, and a sanctioned lane that is better than the unseen alternative.

The positions meet on the Level 4 prohibitions, on named ownership and handover, on proportion by tier, on synthetic data, on independent checks and on evidence with age, and they differ on capacity, learning and motive. The practical guide turned the shared ground into a permit-by-tier table that a script checks and a builder can read. The verdict is that the choice is the lane and not the permission: what is observable supports neither a ban nor an open door, what is expected supports a register and receiving developers, and what is speculation is the share of software that non-developers will build and whether programmes will be used to reduce capacity. The author's projections are labelled, each with the observation that would change it.

The next chapter turns from the organisation to the person. A builder who follows the steps learns by doing, and the studies of skill formation say that the way the assistant is used decides whether the builder learns. Chapter 21 describes the learning path from builder to developer, how competence is shown, and what a builder can do about overconfidence.

Sources

  1. Bundesarbeitsgericht. (2024). Beschluss vom 16. Juli 2024, 1 ABR 16/23 (Technische Überwachungseinrichtung, Headset-System). Federal Labour Court, First Senate. (162, Bundesarbeitsgericht, 2024)
  2. Federal Republic of Germany. (n.d.). Betriebsverfassungsgesetz (BetrVG), section 87. gesetze-im-internet.de. (7, Germany, n.d.)
  3. Sveriges riksdag, Regeringskansliet. (1976). Lag (1976:580) om medbestämmande i arbetslivet (MBL), 10 to 12 §§. (10, Sveriges riksdag & Regeringskansliet, 1976)
  4. AI Incident Database. (2025). Incident 1152: LLM-Driven Replit Agent Reportedly Executed Unauthorized Destructive Commands During Code Freeze, Leading to Loss of Production Data. (22, AI Incident Database, 2025)
  5. Perry, N., Srivastava, M., Kumar, D. & Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants? ACM CCS '23; arXiv:2211.03622. (23, Perry et al., 2023)
  6. Gillespie, N., Lockey, S., Ward, T., Macdade, A. & Hassed, G. (2025). Trust, Attitudes and Use of Artificial Intelligence: A Global Study 2025. The University of Melbourne and KPMG. (32, Gillespie 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. Lee, H.-P. et al. (2025). The Impact of Generative AI on Critical Thinking. CHI 2025. (42, Lee et al., 2025)
  9. Nordqvist, G. (2026). AI Leader. The Transformed Architecture, Book 11. (85, Nordqvist, 2026)
  10. METR (Becker, J. et al.). (2026). We are Changing our Developer Productivity Experiment Design. (94, METR, 2026)
  11. Li, J. et al. (2025). Vibe Coding in Product Teams. arXiv:2509.10652. (104, Li et al., 2025)
  12. Ko, A. J. et al. (2011). The State of the Art in End-User Software Engineering. ACM Computing Surveys 43(3). (105, Ko et al., 2011)
  13. Panko, R. R. (2000). Spreadsheet Errors: What We Know. What We Think We Can Do. EuSpRIG; arXiv:0802.3457. (106, Panko, 2000)
  14. Microsoft. (2025). Implement a data policy strategy. Microsoft Learn. (107, Microsoft, 2025)
  15. Deng, J., Fan, Z. & Meng, R. (2026). Understanding the (In)Security of Vibe-Coded Applications. arXiv:2606.23130. (109, Deng et al., 2026)
  16. Sandoval, G. et al. (2023). Lost at C: A User Study on the Security Implications of Large Language Model Code Assistants. arXiv:2208.09727. (139, Sandoval et al., 2023)
  17. UpGuard. (2021). By Design: How Default Permissions on Microsoft Power Apps Exposed Millions. (143, UpGuard, 2021)
  18. National Institute of Standards and Technology. (2025). CVE-2025-48757 Detail. National Vulnerability Database. (144, NIST, 2025)
  19. Nordqvist, G. (2026). AI Developer. The Transformed Architecture, Book 12. (86, Nordqvist, 2026)
  20. Viljoen, A., Radić, M., Hein, A., Nguyen, J. & Krcmar, H. (2024). Governing Citizen Development to Address Low-Code Platform Challenges. MIS Quarterly Executive 23(3), Article 6. (123, Viljoen et al., 2024)
  21. Stegmann, L., Berendorf, R., Zimmermann, S. K. & Weeger, A. (2024). Balancing Risks and Opportunities in the Governance of Low Code Development Platforms. ECIS 2024 Proceedings, Paper 1634. (124, Stegmann et al., 2024)