Build: Writing Code and the Tools of the Craft

A developer who writes code with an assistant has made a decision before the first line appears: how much of the next hour belongs to the tool and how much to the person. This chapter treats D3 Build, the function of producing software and of directing its making within a mandate, and it reaches into D4 Prove and D5 Steward, because every line that an assistant suggests becomes someone's to verify and, once it ships, someone's to own. Chapters 5 and 6 treated the work that comes before building, framing the problem and designing within constraints. Chapter 8 treats agents that plan, edit many files and open pull requests, and Chapter 9 treats the proof that a change is right.

The chapter maps the progression of coding tools from completion to agents onto the usage modes; reports what controlled studies, field experiments and surveys measured, with population, task, date and result, because the evidence on building is the most quoted and the least carefully read in the field; describes prompt and context craft and what stays human; and ends with an artefact, a coding-assistant usage profile with acceptance criteria and a measurement plan, shown for Nordvik Region.

The build loop: a framed task, chosen context, a proposed diff, two checkpoints and a named owner

Figure 7.1: The build loop with its human checkpoints: the developer frames and reads, an independent oracle and a gate outside the change check, and a named owner keeps the evidence.

What the series has already settled

Five conclusions of the earlier volumes frame the chapter. The usage mode, not the product name, sets the governance of an AI tool: AI Governance, Chapter 2, and AI Platform and Security, Chapter 2, defined Mode 0 Ambient AI to Mode 5 Autonomous production agents, and AI Platform and Security showed what each mode demands of the platform (162, Nordqvist, 2026); (163, Nordqvist, 2026). Mode 0 is the blind spot, because vendor AI that arrives in an update may act at an effective autonomy nobody decided. Autonomy is graded, and what verifies an action is independent of what performed it: AI Operations, Chapter 4 (170, Nordqvist, 2026). Reliance on machine advice follows conditions, which the developer who accepts a suggestion meets again: AI Leader, Chapter 8 (174, Nordqvist, 2026). Automating the routine erodes the skill of the people who must catch the errors: AI Threat, Chapter 14, applied to the developer in Chapters 13 and 28 (165, Nordqvist, 2026). And an adoption or productivity claim carries scope, method, date, result and expiry, with the defaults of 90 days for usage and 180 days for value that AI Leader, Chapters 4 and 20, set.

Chapter 4 applied these through the delegation ladder, Level 0 Advisory to Level 4 Autonomous, per class of work, and the stewardship principle: a named developer or team passes the tests Name, Understand and Revert, and the test oracle is independent of the generator. This chapter concerns the classes generate, refactor and, at its edge, document.

The progression of tools

The tools that developers call "AI" differ in what they may touch, how often the person must act and whose identity they use, and those differences, not the brand, decide the usage mode and the ceiling of delegation.

Completion suggests the next token, line or block while the developer types. The developer accepts, edits or ignores it, and the unit of review is a few lines read in the flow of writing. Chat answers questions about code or produces a snippet that the developer pastes. Edit modes change existing files at the developer's request, so the unit of review becomes a diff. Agent modes in the editor plan across several steps, read and write several files and run commands toward a goal that the developer describes, and background or coding agents take an assigned task, work asynchronously and return a pull request. One vendor's documentation describes this same ladder as assistive features (inline suggestions and chat), editing, multi-step agent work and an agent that picks up an issue and returns a pull request (187, GitHub, 2026). The documentation describes one product and others draw the lines elsewhere, so the categories below are this book's, not a standard.

Vibe coding is not a tool but a way of working with these tools. The term is believed to have been coined by Andrej Karpathy in a social media post of 2 February 2025, and Merriam-Webster defines it as writing computer code "in a somewhat careless fashion, with AI assistance", in which the person describes what is wanted and often does not fully understand the result (126, Merriam-Webster, 2025). The dictionary adds that the word is recent and may change meaning. This book uses it in that sense: building without reading what was built.

Table 7.1 maps the forms to usage modes. The mapping is the book's own conclusion and follows the principle of AI Platform and Security: the mode is set by whose identity the tool uses, what it can reach and whether a person acts on each step.

Form of the tool What it may touch Unit the developer reviews Usage mode Highest degree of delegation in the two organisations
Ambient completion, switched on by an update The line being typed A few lines, in flow Mode 0 Level 1 Assisted, but not decided at Nordvik until afterwards
Chat in the approved enterprise assistant Text the developer pastes A snippet Mode 1 Level 0 Advisory
Completion and chat embedded in the IDE Open files and project context Lines and snippets Mode 2 Level 1 Assisted
Edit and agent mode in the IDE or a work tool Several files, commands, a sandbox A diff and a command log Mode 3 Level 2 Supervised (Hansa Mutual); at Nordvik only the platform team, to draft and never to apply change
An assistant built on the organisation's platform A defined task such as test drafting The task output Mode 4 Level 1 Assisted (HM-DEV-002)
A coding agent that merges or deploys by itself The protected branch or production Nothing unless a gate is added Mode 5 Not used; Chapter 8

Table 7.1: Forms of coding tool, the unit of review and the usage mode.

Three observations follow. The risk grows with the unit that the developer must review and with the identity the tool uses, not with the sophistication of the model: a completion is reviewed in the act of typing, a diff of forty files, if at all, in a pull request. A single developer may use all of these in a week, so "the team uses an AI assistant" says nothing about the classes of work delegated. Mode 0 is where a profile is most often wrong. Nordvik Region's IDE vendor switched on completion by default in an update in March 2030, and the Region recorded its decision only afterwards (AIDR-1102): it did not decide that completion was allowed, it discovered that the question had been answered for it.

What the studies measured

The evidence on AI and coding is large, uneven and quoted without its conditions. A claim in this book about the effect of a tool carries what was measured, in whom, over what period and by what method, and the studies below are read in that way. Figures are reported as the authors give them. Where the authors' interpretation matters, it is marked as theirs.

A controlled task in a lab setting

Peng and colleagues recruited 95 professional programmers on a freelancing platform in 2022, shortly before GitHub Copilot became generally available, and asked them to implement an HTTP server in JavaScript as quickly as possible. The treated group (45 developers) had access to the assistant and saw a short video on its use; the control group (50) had no assistant but could use internet search and Stack Overflow. Among those who completed the task, the average time was 71.17 minutes for the treated group and 160.89 minutes for the control group, which the authors report as 55.8 per cent faster (95 per cent confidence interval 21 to 89 per cent). The treated group's success rate was seven percentage points higher, a difference that was not statistically significant (confidence interval -0.11 to 0.25). Less experienced developers, those who programmed more hours a day and developers aged 25 to 44 benefited more. The authors state that the study does not examine code quality and that effects may vary across tasks and languages (175, Peng et al., 2023). Only 35 of the 95 developers completed the task and survey, and the times above are for them. Becker and colleagues later described the task as unrepresentative of most development work and likely to resemble a large amount of training data (their interpretation, not Peng's).

A second controlled study ran inside one company. Paradis and colleagues at Google randomly assigned 96 full-time software engineers to use or not use three AI features on a complex, enterprise-grade task in the summer of 2024. Their best estimate, controlling for other factors, was that AI shortened time on task by about 21 per cent, but the confidence interval was large (-0.51 to 0.03 on the logarithm of time, p = 0.086) and the authors report that the estimate was not statistically significant at the 5 per cent level in that model. More senior engineers and engineers who coded more hours a day were faster on the task in general, and the interaction between AI use and hours coded was large but not significant. The authors warn that the effect found with internal tooling in 2024 need not carry across tools and time (185, Paradis et al., 2024).

Field experiments in ordinary work

Cui and colleagues pooled three randomised field experiments run by Microsoft, Accenture and an anonymous Fortune 100 electronics manufacturer as part of their ordinary business, with 4,867 developers in all. At Microsoft, 1,746 developers took part from September 2022, of whom 50.4 per cent were randomly given access to Copilot for eight months. At Accenture access was withheld from the control group for four months. At the third company, access dates were randomised over two months. The authors' preferred estimate uses assignment as an instrument for use and so measures the effect on those who used the tool: a 26.08 per cent increase (standard error 10.3) in weekly completed tasks, measured as pull requests, with increases of 13.55 per cent in commits (standard error 10.0) and 38.38 per cent in builds (standard error 12.55). The experiments differed. The estimates for pull requests were 27.38 per cent at Microsoft (standard error 12.88), 17.94 at Accenture (18.72) and 54.03 at the third company (42.63), and only the Microsoft estimate was statistically significant. The build success rate fell by 17.40 per cent at Accenture (standard error 7.12), and the pooled estimate for it was not significant. Adoption was partial: at Microsoft only 8.5 per cent of the treated group signed up in the first two weeks, 42.5 per cent after reminder emails, and across the experiments 30 to 40 per cent of the engineers did not try the tool. Where tenure and seniority were observed, at Microsoft, the gains were significant for recent hires and more junior staff and not for longer-tenured and more senior staff (176, Cui et al., 2024). The figures are those of the February 2025 working paper; the study has since appeared in Management Science (volume 72, issue 11, 2026), whose text was not opened.

A randomised trial on experienced developers in their own codebases

Becker, Rush, Barnes and Rein of METR ran a randomised controlled trial in which 16 experienced open-source developers completed 246 tasks, averaging two hours, in repositories where they had on average five years of experience and 1,500 commits. The repositories averaged 23,000 stars, about ten years of age and more than 1.1 million lines of code. Each task was randomly assigned to allow or disallow AI tools, which were mainly Cursor Pro with Claude 3.5 and 3.7 Sonnet, in the period from February to June 2025. The developers were paid $150 an hour. Before the tasks, they forecast that AI would cut completion time by 24 per cent, and afterwards they estimated that it had cut it by 20 per cent. The measured result was a 19 per cent increase in completion time. Economics and machine-learning experts had forecast reductions of 39 and 38 per cent. Of 21 properties of the setting that might contribute to the slowdown, the authors found evidence for five, mixed or no evidence for ten and evidence against six. Developers accepted fewer than 44 per cent of the generations, 56 per cent reported often needing to make major changes to clean up AI code, and in the 44 issues with valid labelled screen recordings developers spent about 9 per cent of their time reviewing and cleaning AI output. Only 44 per cent had prior experience with the Cursor editor (63, Becker et al., 2025).

The authors list what they do not claim. They do not claim that AI fails to speed up most developers, that their repositories represent most development work, that other domains behave likewise, that future models will not speed up the same developers in the same setting, or that these developers were slowed on every task. They write that their results are consistent with small greenfield projects or unfamiliar codebases seeing substantial speedup (63, Becker et al., 2025). That caveat is part of the result.

METR then redesigned the study, and its update of 24 February 2026 is a lesson in measurement. The new experiment began in August 2025 with 57 developers (10 returning and 47 new), 143 repositories and more than 800 tasks, at $50 an hour. For the returning developers the estimated change in completion time was -18 per cent (confidence interval -38 to +9 per cent) and for the new developers -4 per cent (confidence interval -15 to +9 per cent), where a negative value means less time with AI. METR did not treat these figures as a measure of the speedup. Developers increasingly declined to take part because they did not wish to work without AI, and 30 to 50 per cent said they withheld some tasks for that reason. METR wrote that this selection likely biases the estimate downwards, that it believes developers are likely more sped up by AI tools than in early 2025, and that its data are only very weak evidence for the size of the change. It said it was redesigning the experiment again (186, METR, 2026). The update is observable evidence that the quantity gets harder to measure as the tools become part of the working day.

Surveys and telemetry

The DevOps Research and Assessment (DORA) programme asks practitioners about their ways of working and their results each year. Its 2024 report, with a survey of nearly 3,000 respondents fielded in early 2024, found that 75.9 per cent of respondents relied at least in part on AI in one or more daily responsibilities and that 75 per cent reported positive productivity gains from AI in the preceding three months. It estimated that a 25 per cent increase in AI adoption is associated with a 7.5 per cent increase in documentation quality, 3.4 per cent in code quality and 3.1 per cent in code review speed, and with a 1.8 per cent decrease in code complexity. It also estimated associations with delivery performance: a 1.5 per cent reduction in delivery throughput and a 7.2 per cent reduction in delivery stability for each 25 per cent increase in adoption, shown with 89 per cent uncertainty intervals (216, Google Cloud, 2024). The data are self-reported survey responses and the relationships are associations; the report calls the delivery result surprising. In its 2025 announcement, based on survey responses from nearly 5,000 technology professionals, the programme reported that 90 per cent of respondents used AI at work, that more than 80 per cent believed it had increased their productivity, that 30 per cent reported little or no trust in the generated code, that AI adoption now showed a positive relationship with delivery throughput and product performance and a continued negative relationship with delivery stability, and that "AI doesn't fix a team; it amplifies what's already there" (42, Harvey & DeBellis, 2025).

The 2025 Stack Overflow Developer Survey, with self-selected respondents, found that 84 per cent were using or planning to use AI tools, that 46 per cent distrusted their accuracy against 33 per cent who trusted it, that 66 per cent named "AI solutions that are almost right, but not quite" as a frustration and that 45.2 per cent found debugging AI-generated code more time-consuming (217, Stack Overflow, 2025). It measures what developers report, which the METR trial showed can diverge from what a clock measures.

Skill and security, in brief

Two further results belong to other chapters. Shen and Tamkin, in a preprint not yet peer reviewed, assigned 52 participants (26 in each group) to learn an unfamiliar asynchronous Python library with or without an assistant; the assisted group scored 17 per cent lower on a comprehension quiz (two grade points, Cohen's d = 0.738, p = 0.010) with no statistically significant gain in speed, and three of six observed interaction patterns preserved learning (67, Shen & Tamkin, 2026). Chapter 13 takes this up. Perry and colleagues asked 47 participants to complete five security-related tasks, 33 of them with an assistant built on a 2022 code model; the assisted participants wrote less secure code and were more likely to believe it was secure, and those who trusted the assistant less and engaged more with their prompts produced fewer vulnerabilities (34, Perry et al., 2023). Chapter 10 takes this up.

Table 7.2 sets the studies side by side.

Study Who and what What was measured Result as reported Limit
Peng et al., 2023 95 freelance programmers, one JavaScript task, 2022 Time to complete 71.17 against 160.89 minutes; 55.8 per cent faster (CI 21 to 89) One synthetic task; code quality not examined; small completing sample
Paradis et al., 2024 96 Google engineers, one enterprise task, summer 2024 Time on task About 21 per cent faster; not significant at 5 per cent in the adjusted model One company, internal tools; may not carry over
Cui et al., 2024 4,867 developers at three companies, 2 to 8 months Weekly pull requests, commits, builds Pooled 26.08 per cent (SE 10.3) on pull requests; only Microsoft significant Outputs not fixed in advance; partial adoption; effect on users
Becker et al., 2025 16 experienced developers, 246 tasks in familiar mature repositories Time to complete a task 19 per cent longer with AI; forecast was 24 per cent shorter 16 people; one setting; early-2025 tools
METR update, 2026 57 developers, 800+ tasks Time to complete a task -18 and -4 per cent, CIs include zero Selection of tasks and developers; METR calls it weak evidence
DORA, 2024 and 2025 Survey respondents Self-reported use, and association with delivery measures Positive on documentation and code review; negative association with stability Self-report; association not cause
Stack Overflow, 2025 Self-selected survey Reported use, trust, frustration 84 per cent use or plan to; 46 against 33 per cent on trust Self-selection; no outcome measure

Table 7.2: What the studies measured, in whom, and with what limit.

Reading the evidence together

The studies point in different directions. Three variables account for most of the differences, and a fourth, the measure, decides how far they can be trusted.

The task. Peng's task was self-contained and well specified, Paradis's was an enterprise-grade task set by the researchers, and METR's were real issues in repositories the developers knew. The finding of Dell'Acqua and colleagues in a different profession shows the pattern: in a pre-registered experiment with 758 consultants of one firm (figures from the working paper), AI helped on tasks inside what the model could do and hurt correctness on a task outside it, by 19 percentage points on the authors' measure (91, Dell'Acqua et al., 2026). The authors call the edge the jagged frontier, and developers know it: an assistant helps with the idiomatic function and not with the interaction of three services that exists only in the team's heads.

The experience of the person. The studies disagree on direction and agree on a pattern. Peng found larger benefits for less experienced programmers, Cui found significant gains for more junior and recently hired staff and none for the longer-tenured, and METR found the largest slowdown on issues the developers knew best. Paradis found that senior engineers were faster in general and could not separate the effect of AI. A reasonable reading, labelled as interpretation, is that the tool supplies knowledge a newcomer lacks and offers less to a person who already holds the codebase in their head.

The codebase. METR found that developers' familiarity with repositories and the size and maturity of the repositories contributed to the slowdown, and that "implicit repository context" that the tool does not use was one of the factors.

The measure. Pull requests, commits and acceptance rates count output that a tool can inflate without productivity changing: METR notes that code can be more verbose but equivalent and that tasks can be split without the total work changing, which is why its own tasks were defined before randomisation. A developer's survey answer measures a perception, and the 2025 trial found a gap of 39 percentage points between the 20 per cent reduction developers believed they had gained and the 19 per cent increase measured. A telemetry figure is a count of what the tool did, and the DORA figures are associations in survey data. Each answers a different question, and a claim that moves from one to another, as the quoted figures in both organisations did, has changed its meaning on the way.

The chapter's own conclusion is this. The effect of an assistant on a developer's speed depends on task, experience, codebase and measure; the strongest effects in controlled settings were found on self-contained tasks and for less experienced developers; the one randomised trial on experienced developers in their own mature codebases found a slowdown in early 2025 and a harder-to-measure result a year later; and no study cited here shows what happens to quality, security, review load and maintenance over years, which is where the stewardship principle bites. Productivity gains at the scale of an organisation are therefore expected only where they are measured in that organisation's own work, and the figure that a vendor, a survey or a pilot supplies is a hypothesis for a measurement plan, never a result.

Prompt and context craft

Writing a prompt and choosing what the tool sees is now the developer's interface to the tool, and it is craft in the old sense: learned, uneven between people and improvable with deliberate practice. It has four parts.

State the task so that it can be checked. A task that arrives with a specification record (Chapter 5), constraints and a test that fails now and should pass afterwards can be verified; a task described as "improve the claims module" cannot. The strongest prompt is usually the specification, and the strongest specification includes the test. This is the book's recommendation; no study cited here compares prompting practices.

Choose the context deliberately. The tool sees what it is given: the open files, the repository index, the instructions file, the conversation. Anthropic's engineering team describes context engineering as curating the set of tokens available at inference and treats context as a finite resource with diminishing returns, noting that a model's ability to recall information declines as the context grows, a phenomenon it calls context rot (127, Anthropic, 2025). The research behind the point is older and narrower: Liu and colleagues found that on multi-document question answering and key-value retrieval, performance was often highest when the relevant information was at the beginning or end of the input and dropped when it sat in the middle, even for models built for long contexts (188, Liu et al., 2023). A smaller, chosen context (the interface, the two files that matter, the rule that applies) is a safer default than the whole repository, and long sessions drift.

Know the failure modes. The common ones, described by mechanism: the assistant produces a plausible function that calls an interface that does not exist; Chapter 10 treats the package that does not exist. it follows the pattern of the surrounding code, including its defects; it satisfies the tests it was shown and not the intent behind them; it loses a constraint stated twenty turns earlier; it cannot use knowledge that is implicit in the repository, which METR names as a factor in its slowdown; and it receives whatever the developer pastes: Nordvik Region's incident of March 2030 (INC-NR-2030-0071), in which a consultant pasted a connection string into an unapproved assistant, is a context failure before it is a security failure, and Chapter 10 treats it as such.

Keep the unit of review small. The assistant that is safe at Level 1 for a function is a different risk when edit mode touches ten files. Keep tasks small enough that the diff can be read, ask for a plan before code and start a fresh session for a new task, again as recommendations of this book and not as findings.

What stays human

Three things stay with the developer in building, and they are the same three that the stewardship principle asks of the person who answers for the change.

Framing and judgement. The assistant answers the question as posed. Whether it is the right question belongs to D1 Frame and D2 Design and does not move because the function after them is cheaper.

Reading. Reading code is the means by which the developer passes the Understand test. A developer who cannot explain a change without the tool that generated it has not reviewed it, and a review that consists of reading the assistant's summary of its own diff verifies less than it appears to. In METR's recordings developers with AI spent proportionally more time reviewing, prompting and waiting and less actively coding and searching: the effort moved to a task that is easier to skip.

Ownership. A named developer or team owns the change in production (Name), can explain it (Understand) and has the authority and access to stop or fix it outside the pipeline that shipped it (Revert). Where AI took part in a change that reaches production, the pull request says so, and Chapter 12 describes the ownership record that keeps the answer alive for years.

Vibe coding sits outside these three by definition. It has a legitimate place in a throwaway prototype in a sandbox with no credentials and no data (Chapter 17 treats the product owner and designer who build prototypes, Chapter 19 the citizen who builds with low-code tools). It has no place in a change that reaches production without being read, and the Level 4 prohibitions of Chapter 4 say so: no change to production without a gate that the change cannot alter, no security-critical or safety-critical code without review by a named developer, no change to the agent's own mandate, permissions, test oracles or gates, no irreversible action on production data. That production systems built in the way the dictionary describes will hold up over years is speculation and a risk: no evidence cited here shows how they behave, and someone must still be able to answer for them.

The coding-assistant usage profile

A usage profile turns "the team uses an assistant" into a statement that can be checked. Beside the delegation profile of Chapter 4, it holds what the tool is, which classes of work it may touch at which level, what may be given to it, when a change containing generated code may be merged, what will be measured and when the claim expires.

Practical guide: writing a coding-assistant usage profile with acceptance criteria and a measurement plan

Purpose. State the permitted use of a coding assistant, the acceptance criteria for a change that contains generated code, and the plan by which the claimed benefit will be measured or withdrawn.

Roles. The tech lead who runs the pilot writes the first version; the head of the development unit is accountable for use; the platform engineer states what the gateway and package proxy enforce; a tester or quality engineer states which checks are independent of the generator; the employee representative or works council is told what the profile collects before it is switched on; the data protection officer and, in a public authority, the archivist and legal counsel are consulted on prompts and logs.

Inputs. The delegation profile DLG-*; the usage mode; the data classification rules; the vendor or model terms, including notice of model changes; any quoted claim with its scope and date; the existing review and ownership rules.

Steps.

  1. Identify the tool, its usage mode and where the model runs.
  2. Copy the ceilings per work class from the delegation profile; the usage profile narrows it and never widens it.
  3. List what may not be given to the tool: credentials, connection strings, special-category data and any rule set whose disclosure would weaken a control.
  4. Write the acceptance criteria for merging a change that contains generated code, so that each of Name, Understand and Revert has a criterion, and so that the oracle is independent of the generator.
  5. Write the measurement plan: outcomes the organisation already measures (lead time for a change, review time, defects after release in the files touched, share of changes reverted), the baseline period, the unit (the team, never a named developer) and what is explicitly not a productivity measure.
  6. Record the evidence age of every claim that the profile relies on, and the limit after which it counts as expired. Add the conditions that expire it earlier, such as a change of model.
  7. Write the stop rule before the pilot grows: what result, or what missing result, ends or pauses the use, and who decides.
  8. Store the file in version control, set a review date and reference the decision record.

Result. A usage profile in the repository that the pilot team, the representative and the auditor can read, and the starting point for Chapter 20.

Worked example: NR-DEV-001 at Nordvik Region (illustrative)

The Region's pilot of the IDE assistant NR-DEV-001 for 12 developers (Mode 2, self-hosted open-weight coding model, completion and chat) had an acceptance rate of 31 per cent and, from a survey answered by 9 of the 12, "about four hours saved a week" (AVR-NR-2030-01, April 2030). A note to the executive committee turned this into "a third faster", and nobody had measured delivery time. The CIO's decision AIDR-1102 continued the pilot to 2030-12-31 only. The profile below, written by the tech lead Anders Falk and accountable to Gunilla Roos, is what that continuation required.

# Usage profile for NR-DEV-001. Narrows DLG-NR-DEV-01; never widens it.
system: NR-DEV-001
usage_mode: 2                    # embedded in the IDE; completion and chat; no repository-wide edits
model_hosting: self-hosted, open-weight, Region reserved capacity
delegation_profile: DLG-NR-DEV-01
decision_record: AIDR-1102       # pilot continued to 2030-12-31 only
accountable_for_use: Gunilla Roos
valid_from: 2030-10-07
review_due: 2030-12-15
ceilings:                        # copied from DLG-NR-DEV-01
  generate: {level: 1, rule: "accepted line by line; no generated file committed unread"}
  refactor: {level: 1}
  test: {level: 1, rule: "drafts only; never the oracle for the same change"}
  document: {level: 2, rule: "author checks before merge"}
  advisory_only: [specify, design, review, operate, migrate]
  no_tool_action: [deploy]
never_give_to_the_tool: [credentials, connection strings, special-category data, benefits-triage rules]
acceptance_for_changes_with_generated_code:
  name: "CODEOWNERS names a current team; the pull request states which parts were generated"
  understand: "the author explains the change without the tool; the reviewer reads before any AI comment"
  oracle: "tests written or reviewed by someone other than the author and not drafted by the assistant"
  revert: "rollback path stated in the pull request and tried in the test environment"
measurement:
  quoted_claim: {text: "a third faster", source: AVR-NR-2030-01, status: asserted}   # no delivery time measured
  not_a_productivity_measure: [acceptance rate, suggestion count, survey hours saved]
  outcomes: [lead time per work item, review time, defects after release in touched files, share reverted]
  baseline: two preceding quarters
  unit: team                     # never a named developer; terms under negotiation in MBA-NR-2030-03
  evidence_age_limit_days: {usage: 90, value: 180}
stop_rule: "after 2030-12-31 only under a new decision record, and only if outcomes are measured and no worse than baseline"

The ceilings equal the delegation profile, so the pilot cannot quietly become a Level 2 tool. The quoted claim is shown as asserted beside the plan that would verify it. The unit of measurement is the team, because telemetry that identifies a named developer is a matter for the union (Chapter 22).

Nordvik Region and Hansa Mutual

Nordvik Region. About 25 employees write code as their main work, 18 of them in Applications and Integration, and the Region buys about 22 consultant developers through framework NR-2025-102, working inside its repositories, besides supplier teams whose code it does not review. Linnea Sjöberg, a senior developer with 17 years on the case platform, is a sceptical pilot user in the setting METR studied; the study does not predict her result, but it says that her case is where the speedup is least certain and should be measured before it is assumed. Emil Nordgren and Frida Lund, the two juniors, sit where Peng, Paradis and Cui found the larger gains and where Shen and Tamkin found the larger risk to learning, which Chapter 13 takes up in APR-NR-2030-01. AIDR-1102, filed on 2030-09-16, records ambient completion afterwards and continues the pilot to 2030-12-31 only. The tender NR-2030-041, which closes in November 2030, should take its acceptance criteria from the usage profile (Chapter 18). Whether prompts to coding tools are records under the Region's public-access and archives rules is an open question for its archivist and legal counsel, and MBA-NR-2030-03 must conclude before any measure touches named developers.

Hansa Mutual. About 290 developers and 340 licences of the IDE assistant HM-DEV-001 (Mode 2, procured under contract HM-PROC-AIDEV-2029-01 with CodeMeridian, approved in AIDR-1151 retrospectively), and about 120 engineers using agentic tools through the Hansa Forge gateway at Mode 3. The dashboard figure that 42 per cent of committed lines in the claims product line were "AI-assisted" (February 2030) counts accepted suggestions as a share of lines; a sample of 40 merged pull requests in August 2030 traced 27 per cent of lines to an accepted suggestion, with no measure of whether they stayed (AVR-HM-2030-01, evidence age at the start of the year seven months). Neither figure is an outcome of the kind the studies measured, and Stefan Brückner, who owns the figure in his claims core team, can state the difference. The measure that matters for a supervised group is the one the DORA programme's 2024 association pointed at, delivery stability: change failure and restore time on the claims product line, before and after adoption, read with AI Operations, Chapter 20. The contract has a clause of 30 days' notice of model changes, and a model change is a condition that expires a value claim, so the notice should start a re-measurement. Under Article 28(3) of Regulation (EU) 2022/2554 the contract belongs in the register of information on ICT third-party arrangements, and the profile says that it is registered as a service supporting an important function (2, European Union, 2022). Under Article 4 of the AI Act, as replaced by Regulation (EU) 2026/1744 and in force since 27 July 2026, providers and deployers must take measures to support the development of AI literacy of their staff and of others who operate and use AI systems on their behalf, without a duty to guarantee any specific level for an individual (5, European Union, 2026); for developers that means reading, verifying and prompting skills (Chapter 27). The draft annex KBV-IT-2024-DEV-01 reports telemetry by team, with a minimum group size of five, and bars acceptance rates from appraisal and pay. Aylin Demir, the junior in the claims portal team, is the subject of APR-HM-2030-01 (Chapter 13).

What the two share and where they differ. Each has a quoted figure that has reached a senior body and a measured one that is lower or absent, and each sits at or below Level 2 Supervised except Hansa's one Level 3 Bounded class of patch-level dependency updates (Chapter 8). The question each must answer differs: Nordvik, as a public authority, whether the tool leaves records the public may request and the Region must keep; Hansa, as a supervised financial group, whether the tool changes the stability of the services behind its important functions.

Across the usage modes

Table 7.3 sets out what the building evidence supports at each mode, and the highest degree of delegation that the two organisations have allowed.

Mode Coding form What the evidence in this chapter supports Highest degree allowed Owner of the change
Mode 0 Ambient AI Completion enabled by an update Peng, Cui and Paradis studied completion tools used on purpose; nothing here measures completion nobody chose Level 1 Assisted; to be decided, not discovered The developer who accepts the line
Mode 1 Conversational assistants Chat with pasted code Almost nothing controlled; survey reports only Level 0 Advisory The developer who pastes and applies
Mode 2 Embedded workplace assistants IDE completion and chat The larger part of the studies: lab, field and trial Level 1 Assisted The author and the reviewer
Mode 3 Agentic work tools Edit, agent mode, pull requests The early-2025 trial used an agentic editor; no controlled study in this chapter isolates agents Level 2 Supervised outside security-critical and payment paths The developer who reviews every pull request the agent opens
Mode 4 Built AI applications Test drafting, legacy explanation No controlled study cited; evaluate on the organisation's own code Level 1 Assisted (HM-DEV-002); Level 0 Advisory (HM-DEV-003) The team that owns the application and the team that uses its output
Mode 5 Autonomous production agents Merge or deploy without a person None Not used for code in either organisation Not assignable without a gate the change cannot alter; Level 4 prohibitions apply

Table 7.3: Building across the usage modes: evidence, ceiling and owner.

In all modes the Level 4 prohibitions of Chapter 4 hold. A coding assistant that reports a developer's acceptance rate to a manager has entered the last of these and the territory of AI Boss, Chapter 8, on performance scores and productivity metrics (167, Nordqvist, 2026).

Observable, expected, speculation

Observable. The studies of 2022 to early 2025 differ in direction by task, experience and codebase (Table 7.2). Developers' expectations exceeded the measured result in the METR trial. Self-reported use and perceived productivity are high in surveys, and the DORA programme's association between adoption and delivery stability was negative in 2024 and remained so in 2025. METR's 2026 update could not measure the effect cleanly because developers declined to work without AI.

Expected. Measured speedups for experienced developers in mature codebases are expected to rise as tools and the skill of using them improve, because METR says it believes so and because the measured length of tasks that frontier models complete has grown, with a doubling time of about seven months since 2019 in the METR time-horizon study, whose authors present the extrapolation as conditional on generalising to real work (78, Kwa et al., 2025). Organisational gains are expected to depend on foundations such as small batches, tests and a good internal platform, since the DORA 2025 announcement says AI amplifies what is already there, and the review load is expected to grow with the volume of generated diffs (Chapter 9).

Speculation. That cheaper code changes how many developers an organisation needs is speculation here and is judged in Chapters 29 and 33. That vibe-coded systems will be maintainable in production over years is speculation and a risk.

Summary

This chapter concerned D3 Build, with D4 Prove and D5 Steward at its edges. Coding tools progress from completion through chat and edit modes to agents, and each form has a usage mode, a unit the developer must review and a ceiling of delegation. The most common error is Mode 0: an assistant that arrived in an update and was decided afterwards.

The evidence is conditional and the conditions are the content: lab tasks showed speedups, field experiments showed more pull requests with wide variation, and one randomised trial of 16 experienced developers in their own mature repositories showed 19 per cent longer completion while they believed they had been 20 per cent faster. The effect depends on task, experience, codebase and measure, and a figure that moves from a survey to a board paper has changed its meaning on the way.

Prompt and context craft is the new interface: state the task so it can be checked, choose the context, know the failure modes and keep the unit of review small enough to read. What stays human is framing, reading and ownership: a change containing generated code has a named owner who can explain and revert it, with tests that the generator did not write. The coding-assistant usage profile records the ceilings, acceptance criteria, measurement plan and stop rule beside the delegation profile; Nordvik Region's NR-DEV-001 shows one, with its quoted claim marked asserted. Chapter 8 takes the next step: agents that plan, edit many files, run commands and open pull requests, under a mandate, in a sandbox, with a stop path outside the agent.

Sources

  1. European Parliament and Council of the European Union (2026). Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI). Official Journal of the European Union, 24 July 2026, Article 1(5), replacing Article 4 of Regulation (EU) 2024/1689. (5, European Union, 2026)
  2. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022, Article 28(3). (2, European Union, 2022)
  3. Perry, N., Srivastava, M., Kumar, D. and Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants? CCS '23; arXiv:2211.03622. (34, Perry et al., 2023)
  4. Harvey, N. and DeBellis, D. (2025). Announcing the 2025 DORA report: State of AI-assisted Software Development. Google Cloud Blog, 23 September 2025. (42, Harvey & DeBellis, 2025)
  5. Becker, J., Rush, N., Barnes, E. and Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089. (63, Becker et al., 2025)
  6. Shen, J. H. and Tamkin, A. (2026). How AI Impacts Skill Formation. arXiv:2601.20245 (preprint). (67, Shen & Tamkin, 2026)
  7. Kwa, T. et al. (2025). Measuring AI Ability to Complete Long Tasks. METR; arXiv:2503.14499. (78, Kwa et al., 2025)
  8. Dell'Acqua, F. et al. (2026). Navigating the Jagged Technological Frontier. Organization Science 37(2), 403-423. (91, Dell'Acqua et al., 2026)
  9. Nordqvist, G. (2026). AI Governance. The Architecture as Code Series, Book 2. (162, Nordqvist, 2026)
  10. Nordqvist, G. (2026). AI Platform and Security. The Architecture as Code Series, Book 3. (163, Nordqvist, 2026)
  11. Nordqvist, G. (2026). AI Threat. The Architecture as Code Series, Book 5. (165, Nordqvist, 2026)
  12. Nordqvist, G. (2026). AI Boss. The Architecture as Code Series, Book 7. (167, Nordqvist, 2026)
  13. Nordqvist, G. (2026). AI Operations. The Architecture as Code Series, Book 10. (170, Nordqvist, 2026)
  14. Nordqvist, G. (2026). AI Leader. The Architecture as Code Series, Book 11. (174, Nordqvist, 2026)
  15. Peng, S., Kalliamvakou, E., Cihon, P. and Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv:2302.06590. (175, Peng et al., 2023)
  16. Cui, Z. (K.), Demirer, M., Jaffe, S., Musolff, L., Peng, S. and Salz, T. (2024). The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. SSRN 4945566; Management Science. (176, Cui et al., 2024)
  17. Google Cloud, DORA (2024). Accelerate State of DevOps Report 2024. DevOps Research and Assessment (DORA) programme. (216, Google Cloud, 2024)
  18. Stack Overflow (2025). 2025 Stack Overflow Developer Survey. (217, Stack Overflow, 2025)
  19. Paradis, E. et al. (2024). How much does AI impact development speed? An enterprise-based randomized controlled trial. arXiv:2410.12944. (185, Paradis et al., 2024)
  20. METR (2026). We are Changing our Developer Productivity Experiment Design. METR blog, 24 February 2026. (186, METR, 2026)
  21. Merriam-Webster. Vibe coding. Slang and trending entry. (126, Merriam-Webster, 2025)
  22. Anthropic (2025). Effective context engineering for AI agents. Anthropic Engineering, 29 September 2025. (127, Anthropic, 2025)
  23. Liu, N. F. et al. (2023). Lost in the Middle: How Language Models Use Long Contexts. arXiv:2307.03172, July 2023; accepted to Transactions of the Association for Computational Linguistics. (188, Liu et al., 2023)
  24. GitHub (2026). GitHub Copilot features. GitHub Docs. (187, GitHub, 2026)