The Developer Loop Defined: Five Functions, Delegation Ladder and Stewardship

This chapter fixes the frame that the rest of the book uses, in the way Chapter 4 of AI Operations fixed the operations loop and Chapter 4 of AI Leader the leadership loop. It defines the five developer functions, D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward; the ten classes of development work; the delegation ladder, which sets how far AI may take part in each class, and the five prohibitions that keep Level 4 Autonomous out of work where it does not belong; and the stewardship principle: AI may draft, generate, refactor and, within a mandate, execute, but may not own. It then states the corollary that the test oracle must be independent of the generator, sets the rule for claims about productivity, security and competence, relates the frame to the instruments that assign duties for software, and ends with the delegation profile DLG-*. Chapters 8, 9, 12 and 14 apply the stewardship principle in full.

The definition is the book's own design; the sources cited here support its parts, never the whole.

Figure 4.1: The developer loop with the named steward at its centre and the independent checks outside it.

What this chapter builds on

Six conclusions of the earlier volumes carry the frame. AI Governance, Chapter 2, concluded that the usage mode, not the brand, sets the governance; this book keeps that vocabulary from Mode 0 Ambient AI to Mode 5 Autonomous production agents (162, Nordqvist, 2026). AI Red Team, Chapter 6, defined five autonomy levels set per action from reversibility and blast radius, with the most important line between Level 2 Supervised and Level 3 Bounded, where actions begin without per-action approval (164, Nordqvist, 2026). AI Blue, Chapter 4, made the delegation profile an artefact in which an unlisted action is undelegated (168, Nordqvist, 2026). AI Purple, Chapters 4 and 15, and AI Operations, Chapters 4 and 17, added the independence principle and the observer principle: what verifies an action must not share the failure modes of what performed it (169, Nordqvist, 2026); (170, Nordqvist, 2026). AI Boss, Chapter 4, concluded that AI may direct work but may not, on its own, decide about people (167, Nordqvist, 2026). AI Leader, Chapters 4 and 12, applied the ladder to leadership decisions and stated the answerability principle: AI may inform, draft, prepare and, within a mandate, execute, but may not answer, and a named leader passes the tests Name, Explain and Reach (174, Nordqvist, 2026).

Architecture as Code (Chapter 20) set the rule on which all of this rests, "agents draft; humans approve", with every exception carrying a named human approval in the audit trail (161, Nordqvist, 2025). The Transformed Security Architect, Chapter 3, described the shift from sole author to conductor of an AI team (166, Nordqvist, 2026). This chapter extends the rule from one approval to a whole role, and from who answers for a decision to who can explain, change and withdraw what was built.

The loop in one picture

Figure 4.1 shows the mechanism. Five functions run as a loop: a developer frames a problem, designs the constraints, builds, proves and stewards, and what is learnt from the software in production feeds the next framing. AI systems take part at the points where the loop touches work, chiefly in D3 Build, and only through a policy point that sets a ceiling per class of work. The policy point sits outside the AI system, so that a system cannot raise its own ceiling, and the five prohibitions remove some work from the ladder's top rung altogether. The independent test oracle and the other checks of D4 Prove sit outside the generator, so that they can fail when it fails. A stop and revert path, held by the named steward and working when the pipeline that shipped the change does not, halts the system and withdraws the change.

Five functions

The five functions describe what a developer does, whatever the title. A junior developer, a staff engineer, a tech lead and a platform engineer perform all five, in different proportions and at different reach. Each function has a scope, outputs and an end, where another function or another volume takes over.

D1 Frame

D1 Frame is understanding the problem and fixing intent. Its scope is finding out what is wanted and why: requirements, conversations with users and product owners, acceptance criteria, the specification that states intent so that it can be tested, and the traceability from a need to a check that it was met. Its output is a statement of intent that someone else can build from and test against, with its ambiguities named. It ends where a choice of structure begins (D2) and where intent is turned into code (D3). Chapter 5 treats D1.

D2 Design

D2 Design is choosing the constraints within which the software is built. Its scope is architecture, interfaces, data, security by design, the choice between options and the record of why. Its outputs are decisions that can be revisited, recorded as an Architecture Decision Record (ADR) with a note of what took part in the decision (89, Nygard, 2011), and constraints that the build and the proof can enforce. It ends where a decision becomes running code (D3) and where the enterprise architect's work begins; Chapter 16 draws that boundary. Chapter 6 treats D2.

D3 Build

D3 Build is producing software and directing the making of it. Its scope is writing code, directing assistants and agents, refactoring, migrating, infrastructure as code, and the craft of giving a tool the context it needs. Its output is changes, proposed for review, that implement a stated intent within a stated design. It ends where a change must be shown to be right (D4). AI takes part here more than anywhere in the loop, which is why the ladder is written per work class and why D3 is not the whole of the role. Chapters 7 and 8 treat D3.

D4 Prove

D4 Prove is showing that the software is right. Its scope is code review, tests of every kind, static and dynamic analysis, secure-code and supply-chain checks, and the independence of those checks from the thing they check. Its output is evidence of correctness with its scope and age: what was checked, by whom or by what, when and with what result. It ends where a change reaches production (D5). Chapters 9 and 10 treat D4.

D5 Steward

D5 Steward is owning software over time. Its scope is release, operation, maintenance, the record of who owns what, documentation, incident response for what the developer built and the authority to stop, roll back or fix a change. Its output is software that has a named owner, a path to revert and a state that someone can explain years after it was written. D5 has no end except that every change that reaches production passes through it, and the stewardship principle below is its definition of done. Chapters 11 and 12 treat D5.

Where the developer functions meet the functions of other volumes

AI Operations divided the work of keeping services running into O1 Observe, O2 Diagnose, O3 Change, O4 Restore and O5 Sustain. D5 Steward and O3 Change meet at the release: the developer owns the change as software, the operator owns it as an event in a service with a change window and a blast radius, and the change record CHG-* is the artefact on which they hand over. "You build it, you run it" puts the same people in both positions; Chapter 11 examines it when AI multiplies the number of changes. AI Leader divided leadership into L1 to L5; a leader's decision about a named developer's employment, pay, performance rating or access to work is an L2 decision in the people class, which AI Leader treats, together with the middle layer and the works council (Chapters 16, 17 and 22).

Classes of development work

A delegation profile cannot be set for "development" as a whole, because reversibility, blast radius and the person who answers differ between drafting a unit test and changing a payment rule. The book divides development work into ten classes, each with a recognisable way of going wrong. The division is the book's own and is not a standard.

Work class	Typical work	Function	How it goes wrong with AI
Specify	Acceptance criteria, user stories, the specification	D1	Plausible requirements that nobody asked for; scope inflation; intent that lives only in a prompt
Design	Options, interfaces, the ADR, data model	D2	A design that fits what the tool can generate rather than what the system needs; drift across a codebase
Generate	New code from intent, in the editor or by an agent	D3	Code that compiles and passes the tests the same tool wrote; invented dependencies; secrets in a prompt
Refactor	Behaviour-preserving restructuring, dependency updates	D3	A change of behaviour that no test covers; a diff too large to read
Test	Writing, running and triaging tests and the oracle	D4	Tests that restate the code under test; an oracle shared with the generator
Review	Reading a change before it is merged	D4	An AI comment counted as a human review; a reviewer who approves what is too large to read
Deploy	Releasing a change to an environment	D5	A change that alters the gate that checks it; deployment outside the change window
Operate	Running what was built: incidents, runbooks, support	D5	An action on production data that cannot be undone; a diagnosis accepted without evidence
Document	Comments, guides, decision records, release notes	D5	A document that describes what the code was meant to do; documentation that replaces understanding
Migrate	Moving code between languages, platforms or versions	D3, D5	A translation that preserves the syntax and loses the business rule; a migration with no characterisation tests

A change can belong to more than one class: generating a new authentication path is generate and, because of where it sits, subject to the prohibition on security-critical code. The stricter ceiling governs. Work that is not listed in the profile is undelegated: no system may take part in it beyond Level 0 Advisory until a named authority has put it in the profile. A decision about a named person's employment, pay, performance rating or access to work is not a class of development work; the profile says in a line of its own that tools take no part in it.

The delegation ladder

The ladder is the autonomy scale of AI Red Team, Chapter 6, applied per class of development work (164, Nordqvist, 2026). It is older than the series. Parasuraman, Sheridan and Wickens proposed in 2000 that automation is not all-or-nothing but varies in degree, and that the degree can differ across four stages of a task: information acquisition, information analysis, decision and action selection, and action implementation (60, Parasuraman et al., 2000). The point carries over: a team may let an assistant gather and summarise at a high degree and select among options at a low one. The ladder has five rungs.

Level	What the AI system does	Who acts and who owns, for development work
Level 0 Advisory	Suggests; answers a question; explains code	The developer writes and acts
Level 1 Assisted	Drafts the code, test, document or option set	The developer reads, edits and commits in the developer's own name
Level 2 Supervised	Executes after explicit approval of each action, for example opening a pull request or running a command	The developer approves each action; the system executes
Level 3 Bounded	Executes pre-approved, reversible actions of a named class within a codified policy	The authority that approved the policy holds the stop; the system executes within it
Level 4 Autonomous	Selects and executes actions without per-action approval, within bounds set in advance	The authority that set the bounds, by sampling

Three rules set a level, and they are the rules of the earlier volumes.

The level belongs to a work class in a context, not to a tool. The same assistant may generate a test draft at Level 1 and be limited to Level 0 in a repository that handles authentication. A profile therefore lists classes, and each class has a ceiling.

The lowest of five answers governs. The ceiling for a class is the lowest level that five questions allow. Reversibility: can the change be undone, by whom and at what cost; a merged line can be reverted, a payment already made cannot. Blast radius: how many users, how much money and how much of the estate it reaches. Who is affected: only the team's convenience, citizens or customers who cannot choose another provider, or a named person. Evidence: whether there is dated evidence for this tool in this class in this codebase, from a test the organisation or an independent party ran, because evidence expires. Strength of the independent checks: whether what verifies the work shares failure modes with what produced it. The fourth and fifth answers can only lower a ceiling that the first three have allowed.

Lowering is immediate; raising is a decision. Anyone named in the profile as holding the stop can lower a level at once. Raising one is a decision by a named authority, recorded as an AI Decision Record with its evidence and a review date, as in AI Blue, Chapter 4, which protects against the drift in which a ceiling rises because a tool proved convenient (168, Nordqvist, 2026).

The ceilings below are the starting point the book recommends. They are the author's judgement on the five answers for a large European enterprise or public authority, and a recommendation, not a standard. An organisation may set any class lower, and should where the answers say so; a concrete profile governs over this table, and the profiles of Nordvik Region and Hansa Mutual below are each at or below it.

Work class	Recommended ceiling	What sits at the ceiling	Note
Specify	Level 1 Assisted	Drafts of acceptance criteria and questions for the product owner	The intent is the developer's and the product owner's; Chapter 5
Design	Level 1 Assisted	Option sets, draft ADRs, review of a design for omissions	The decision and its record are a named person's
Generate	Level 2 Supervised outside security-critical paths; Level 1 inside them	Code proposed in the editor; a pull request opened by an agent after approval	A named developer reviews every change; Level 3 only through a bounded class in a mandate
Refactor	Level 2 Supervised; Level 3 for one named class with all checks passing	Mechanical, behaviour-preserving changes; patch-level dependency updates under a mandate	Level 3 only for a class whose change is reversible and whose checks the change cannot alter
Test	Level 2 Supervised	Draft tests and test runs; the oracle is never written by the generator of the change	Chapter 9
Review	Level 1 Assisted	AI comments as input to a human reviewer	An AI comment never counts as a human approval
Deploy	Level 1 Assisted for production; Level 2 for non-production	Draft change record and release notes; execution by the pipeline on a human's approval	The pipeline and the change process act; the gate cannot be altered by the change
Operate	Level 1 Assisted	Draft incident summaries and runbook suggestions	Execution belongs to AI Operations; Level 4 never on production data
Document	Level 2 Supervised	Documentation drafted and checked by the author before merge	The author answers for the text
Migrate	Level 1 Assisted	Reading, summarising and proposing translations, with characterisation tests written by someone else	A migration is irreversible in effect once data and users have moved; Chapter 12

Level 4 has no default home in any of the ten classes. It remains available only for narrow, reversible, internal actions that are not changes to production, such as reformatting code in a developer's own working copy.

The Level 4 prohibitions

Five prohibitions apply whatever the evidence, whatever the tool and whatever the cost saving. They are stated as follows, and the whole book uses these words. 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 or safety-critical path (authentication, authorisation, cryptography, payment, clinical or life-safety logic) without human review by a named developer; for a change to the agent's own mandate, permissions, credentials, test oracles, review rules 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.

The production-gate prohibition. A change that reaches production does so through a gate: tests, approvals, a deployment policy, a change window. If the thing that proposes the change can alter the gate, the gate is a formality. The gate must therefore be defined and enforced outside the change and outside the agent, and what holds for a human holds for an agent. An agent that can edit the pipeline configuration that checks its own pull request has no place above Level 1; Chapter 11 treats the gate.

The security-critical prohibition. Authentication, authorisation, cryptography, payment and clinical or life-safety logic are the paths in which a plausible, wrong line is most expensive and least visible. Perry and colleagues, in a user study of participants writing security-relevant code, found that those who had access to an AI assistant wrote significantly less secure code than those who did not, and were more likely to believe their code secure; participants who trusted the assistant less and engaged more with their prompts produced fewer vulnerabilities (34, Perry et al., 2023). The study used an assistant of 2022 and gives no rate for today's tools, which Chapter 10 reviews. It supports something narrow, enough for a prohibition: where error is most costly, review by a named developer is not optional, and it must be a real review, not an approval of what the tool offered.

The own-mandate prohibition. A system must not set, widen or loosen its own mandate, its permissions, its credentials, the test oracle that checks it, the review rules that apply to it or the pipeline gates through which it passes. This is the oldest rule of the series, the policy decision point outside the agent, and it protects the other four. An assistant may draft the delegation profile or the mandate manifest for the assistants; a named person approves it. The list includes test oracles on purpose: an agent that may edit the tests that decide whether its change is accepted has been given the means to pass.

The irreversible-data prohibition. An action that cannot be undone on production data is never Level 4. The reported case of a coding agent that, during a code freeze, executed destructive commands that led to the loss of production data has this shape; the catalogue record lists press reports and no primary post-incident report, so the case is cited here as reported and as an illustration of the class, not as an established account (33, AI Incident Database, 2025). Irreversible actions inside a mandate are taken at the level the profile allows, rarely more than Level 2.

The people prohibition. A decision about a named person's employment, pay, performance rating or access to work binds that person's livelihood and dignity, and the person must be able to contest it before a human who can change it. The prohibition follows AI Boss, where Level 4 is never used for the M3 Consequence function (167, Nordqvist, 2026), and it applies to development in a particular way: telemetry from coding tools, such as acceptance rates or agent usage, is not a basis for rating or paying a named developer (Chapter 22). Law points the same way: the AI Act classifies AI systems used in employment and workers management, including to evaluate performance and to decide on promotion or termination, as high-risk under Annex III, point 4 (1, European Union, 2024), and Article 22(1) of the GDPR gives a person the right not to be subject to a decision based solely on automated processing with legal or similarly significant effects (4, European Union, 2016).

The prohibitions are a floor. For five kinds of work no evidence is enough to remove the person, and for the rest the five answers decide.

The stewardship principle

The principle has one sentence and three tests. AI may draft, generate, refactor and, within a mandate, execute; it may not own. For every change in production there is a named developer or team who passes three tests.

Name. The owner is identifiable in the code-ownership record OWN-* to colleagues, to operators and to auditors, by name or by a named team with a reachable lead. A repository whose owner has left, or whose owner is "Policy Systems" as a department, does not pass. In a study of Windows Vista and Windows 7, Bird and colleagues found that measures of ownership, such as the number of low-expertise contributors and the share held by the top owner, were related to both pre-release faults and post-release failures, with one correlation (post-release failures in Windows 7) not significant (180, Bird et al., 2011). The study concerns human contributors in two projects of one company; the book's reading is that an organisation which adds a generator to modules without owners adds volume where nobody is answerable.

Understand. The owner can explain what the change does and why, and can reconstruct it, without the tool that generated it. The test is concrete: switch the assistant off and ask the owner to say what the change does, which requirement it meets, what it assumes and what would break it. Naur argued in 1985 that programming is the building of a theory, a grasp of how the program relates to the world it serves, held by the people who built it, and that a program's text and documentation do not by themselves carry that theory; modifications made by people without it degrade the program (181, Naur, 1985). The essay is an argument, not a measurement, and it predates AI tools; it states what the Understand test protects. Shen and Tamkin, in randomised experiments with developers learning an asynchronous programming library, found that AI use impaired conceptual understanding, code reading and debugging without significant efficiency gains on average, and that the three of six interaction patterns involving cognitive engagement preserved learning (67, Shen & Tamkin, 2026). It is a preprint with one task and one library; it suggests that how a developer uses the tool affects whether the developer can pass Understand afterwards.

Revert. The owner has the authority, the access and the time to stop, roll back or fix the change, outside the pipeline that shipped it. Authority means the right is in the owner's hands in the change policy. Access means the owner can act on production, or can cause it to be acted on, when the pipeline, the agent or the platform that shipped the change is itself the problem. Time means the owner has the hours, a matter of workload and review volume and not of character. Outside the pipeline means the revert path does not run through the thing that failed; this is the stop path of AI Operations, Chapter 17, in the developer's hands (170, Nordqvist, 2026).

The three tests echo what the AI Act asks of those who oversee high-risk AI systems. Article 26(2) requires deployers to assign human oversight to natural persons with the necessary competence, training, authority and support, and Article 14(4) requires a high-risk system to be provided so that they can understand its capacities and limitations, remain aware of automation bias, interpret and override its output, and interrupt it through a stop button or similar procedure (1, European Union, 2024). Those provisions concern high-risk AI systems, not the coding tools that build software. The book's own conclusion, which goes beyond the law, is that the same three tests are right for any change in which AI took part and that reaches production, because the reason for them is the way the work is done, not the classification of the system.

Why delegation moves work and never ownership

Three bodies of evidence support the principle, and all three concern what happens to the person who is nominally in charge. The first is automation bias. A systematic review of 74 studies, with a focus on healthcare, found that automation bias was mediated by user factors, by attitudes such as trust in the system and confidence in one's own judgement, and by environmental factors such as workload, task complexity and time pressure, and that mitigators included training, emphasising user accountability and design choices about where and how advice is presented (43, Goddard et al., 2012). A review by Parasuraman and Manzey concluded that complacency and bias occur in both naive and expert participants and are not overcome by simple practice (57, Parasuraman & Manzey, 2010). The reviews concern healthcare, aviation and similar settings, not code review. The book's reasoning is that a developer who approves a diff an assistant produced is exposed to the same pull, and a design that makes the reviewer engage before accepting is a design for the Understand test.

The second is the ironies of automation. Bainbridge argued in 1983 that the more of a task is automated, the less practice the person has at the part that remains, yet the person must take over when the automation fails (56, Bainbridge, 1983). It is an analysis of process control, not a measurement of software work; Chapters 13 and 28 take up the evidence on skill formation.

The third is the accountability gap. Elish described the moral crumple zone: responsibility may be misattributed to a human actor with limited control over an automated system, so that the human nearest the system bears the brunt when it malfunctions (49, Elish, 2019). Green argued that policies requiring human oversight of government algorithms assume that people can perform the oversight asked of them, which the evidence does not support (92, Green, 2022). Both are frameworks of interpretation, not measured rates. The book's reading is that an organisation which names a junior developer as approver of agent-opened pull requests, and gives that person neither time, sources nor authority to refuse, has built a crumple zone. The stewardship principle says the reverse: delegation moves work, never ownership.

The independent test oracle

The principle carries a corollary for evidence. A test has two parts: the input that exercises the code and the oracle, the means of deciding whether the observed behaviour is correct. Barr and colleagues, in a survey of the literature, describe the test oracle problem as the difficulty of distinguishing correct from incorrect behaviour and argue that automating the oracle would remove a bottleneck that inhibits greater test automation (178, Barr et al., 2015). Generating code is cheap; deciding that it is right is the expensive part, and the temptation is to ask the generator to supply that as well. The test oracle must be independent of the generator. Tests, reviews and checks that an AI system wrote for its own output verify less than they appear to.

Three kinds of evidence say why. First, errors are correlated. Kim and colleagues, evaluating over 350 language models on two leaderboards and a resume-screening task, found substantial correlation in errors: on one leaderboard dataset models agreed 60 per cent of the time when both erred, and larger, more accurate models had highly correlated errors even across providers and architectures (35, Kim et al., 2025). The tasks were not software tasks, but the result says that a second model from another provider is not an independent check by default. Second, an evaluator favours its own output: Panickssery and colleagues found that models can recognise their own generations with non-trivial accuracy, that fine-tuning showed a linear correlation between self-recognition and the strength of self-preference, and that controlled experiments suggest a causal link (36, Panickssery et al., 2024). The tasks were text tasks, and the lesson is not to let a model review code that it or a sibling wrote. Third, tests are rarely exhaustive. Wang, Pradel and Liu examined patches from three issue-solving tools on SWE-bench Verified, which validates patches by testing, and found that 7.8 per cent of all patches counted as correct while failing the developer-written test suite, that 29.6 per cent of plausible patches behaved differently from the ground-truth patches, and that 28.6 per cent of the behaviourally divergent patches they inspected were certainly incorrect; the weaknesses inflated reported resolution rates by 6.2 percentage points (179, Wang et al., 2025). The study concerns three tools on one benchmark; it shows that a passing test suite is not the same as a correct change.

Independence has dimensions, as AI Purple set out for verification: the check must not share the failure modes of what it checks in model, data, authorship, vendor and time (169, Nordqvist, 2026). Applied to development, the dimensions give practical tests.

Check	Independent of the generator?	Why it can fail
Tests written by the same assistant in the same session as the code	No	The tests restate the code's assumptions; a wrong reading of the requirement is in both
A second model reviewing the diff	Weak	Correlated errors and shared training data; useful as an extra reader, not as the oracle
Tests derived from the specification record SPC-* by a different person before the code	Yes, in authorship and time	Only as good as the specification
Property-based tests and metamorphic relations stated by a developer	Largely	Depend on the developer's grasp of the invariant
Characterisation tests recorded from the running legacy system	Yes, for behaviour that exists	Preserve defects as well as rules
Static analysis and type checking with fixed rules	Yes, in method	Cover only what the rules cover
A human reviewer who has read the specification and not only the diff	Yes, if the reviewer can say what the change does	Subject to the bias and volume problems above
Observation in production, with a revert path	Yes, in time	Finds the failure after users have met it

An independent oracle does not forbid AI from drafting tests. It requires that the oracle for a given change was not written by the generator of that change, that its source (the specification, a person, the running system) is recorded in the verification plan VER-*, and that a person can reproduce a sample of the checks without the tool. Chapter 9 turns this into practice; the own-mandate prohibition supplies the other half, since an agent may not edit the oracle that decides whether its change is accepted.

Claims with evidence

A development organisation lives on claims: that a tool raises productivity, that the code is secure, that the team is ready, that a share of the code is written by AI, that a role can be done with fewer people. The book's rule is that a claim carries its scope, its method, its date and its result, and an expiry after which it is no longer relied on. Evidence expires because tools, models, codebases and populations change.

A claim record has six parts: the claim in one sentence; the scope (population, period, tool and version, codebase); the method (how it was measured, by whom, with what sample); the result with its uncertainty; the date; and the date on which it expires or must be re-examined. As conventions the book reuses the defaults of AI Leader: usage claims expire after 90 days and value claims after 180 days, and a claim also expires when its conditions change, for example when the provider changes the model behind a tool (174, Nordqvist, 2026). A dashboard figure without these parts is a number, not a claim, and the record says "not measured" where nothing was.

The studies show why the method has to be stated, because results differ with task, experience and setting. Peng and colleagues asked developers to implement an HTTP server in JavaScript in a controlled experiment and reported that the group with an AI pair programmer finished 55.8 per cent faster (175, Peng et al., 2023). Cui and colleagues ran randomised field experiments at Microsoft, Accenture and a Fortune 100 company with 4,867 developers, and their abstract reports a 26.08 per cent increase in completed tasks (176, Cui et al., 2024); the book has read the abstract only. Becker and colleagues had 16 experienced open-source developers complete 246 tasks in mature projects they knew well, each task assigned at random to allow or disallow AI tools, and found that the developers expected a 24 per cent reduction in time, estimated afterwards a 20 per cent reduction, and were measured to take 19 per cent longer with the tools allowed (63, Becker et al., 2025). The results do not conflict: they measured different tasks, populations and tools. One lesson is robust: what people believe about their productivity with AI and what a measurement shows can differ, so a claim needs a measurement in the setting where it is claimed.

Surveys are claims of another kind. The 2025 Stack Overflow Developer Survey, of over 49,000 self-selected respondents, found that 84 per cent used or planned to use AI tools, that 46 per cent distrusted the accuracy of their output and that the most selected frustration, at 66 per cent, was solutions that are almost right but not quite (217, Stack Overflow, 2025). The 2025 report of the DevOps Research and Assessment (DORA) programme, from nearly 5,000 technology professionals, reported a positive relationship between AI adoption and delivery throughput, a negative one with delivery stability, and instability where strong automated testing and fast feedback were missing (42, Harvey & DeBellis, 2025); these are self-reports and associations without published effect sizes in the announcement. A vendor's finding that AI-generated code introduced risky security flaws in 45 per cent of its tests is a measure of one test suite, not a rate for any organisation's code (229, Veracode, 2025).

When a measure becomes a target it also changes. Manheim and Garrabrant categorised the ways in which an indicator ceases to be a good one once it is optimised (61, Manheim & Garrabrant, 2019). Acceptance rate is not productivity, and the share of code an assistant produced says nothing about whether it stayed, was correct or was understood. Both example organisations hold a claim of this kind, set out below.

The rule applies to this chapter too: the ceilings are the author's judgement, and the claim is only that an organisation which sets them by the five answers and names its stewards can say what it did and why, which is the condition for finding out whether it was right.

Mapping to law and frames

The instruments assign duties to parties, and the frame gives those duties a place in the loop. The mapping is the book's reading, an organisational and architectural implication and not legal advice; Chapter 24 maps the instruments in full and settles the questions left open here.

Instrument	What it provides	Functions	Place in the frame
AI Act Article 4 (replaced by Regulation (EU) 2026/1744)	Providers and deployers take measures to support the AI literacy of their staff and others operating AI systems on their behalf, without a duty to guarantee any specific level for an individual (5, European Union, 2026)	all	The developer's tool literacy is part of passing Understand; Chapter 27
AI Act Article 14(4)	Overseers can understand the system, be aware of automation bias, interpret and override output and interrupt the system (1, European Union, 2024)	D3, D4, D5	The system-side design for Understand and Revert, where the team builds or deploys a high-risk AI system
AI Act Article 25(1)	A deployer or other third party is considered a provider of a high-risk AI system if it puts its name on one, substantially modifies one, or modifies the intended purpose of an AI system so that it becomes high-risk	D2, D3	A team that builds on a model or modifies a purchased system can become the provider; the design record says which
AI Act Article 26(1) and (2)	Deployers take appropriate measures and assign oversight to competent, authorised persons	D5	Name and Revert for a high-risk system in use
Cyber Resilience Act Article 13	Manufacturers of products with digital elements design, develop and produce to the essential requirements, assess cybersecurity risk throughout, and exercise due diligence on third-party components, including free and open-source components not supplied commercially (242, European Union, 2024)	D2, D3, D4, D5	Provenance of generated code and dependencies; the application dates are 11 September 2026 for Article 14 and 11 December 2027 generally (Article 71)
Directive (EU) 2024/2853 Articles 4, 7 and 8	Software is a product; defectiveness takes into account, among other things, the effect of an ability to continue to learn and safety-relevant cybersecurity requirements; a manufacturer of a defective component and one who substantially modifies a product can be liable (243, European Union, 2024)	D4, D5	Who owns a defect in generated code; applies to products placed on the market after 9 December 2026 (Article 2(1))
NIS 2 Article 21(2)(d) and (e)	Entities take measures on supply chain security and on security in network and information systems acquisition, development and maintenance (3, European Union, 2022)	D2, D4, D5	The development process of an entity in scope, and of its suppliers
DORA Article 9(4)(e)	Financial entities implement documented policies, procedures and controls for ICT change management (2, European Union, 2022)	D5	The gate that a change cannot alter; the change policy of Hansa Mutual
GDPR Articles 25 and 32	Data protection by design and by default; security of processing (4, European Union, 2016)	D2, D4	Design and proof for software that processes personal data, and the secret in a prompt

Two cautions apply. The AI Act's provisions on high-risk systems, oversight and provider status concern AI systems, so they reach a development team where it builds or deploys one, as both organisations do, and not through the coding assistant itself; and Article 4 states a duty of measures to support literacy, not a guaranteed level of competence, so a developer's competence record (Chapter 27) is the organisation's own evidence and not a legal proof. The Cyber Resilience Act and the Product Liability Directive turn the question of who owns a change into one of who is the manufacturer and who is liable, which makes the code-ownership record a legal as well as a technical document.

Observable, expected, speculation

The frame itself is a design. It is observable that developers in both example organisations already use assistants at Mode 0 and Mode 2, that agents at Mode 3 run in sandboxes at one of them, and that adoption claims in both rest on usage and not on delivery. It is expected, because the Cyber Resilience Act and the Product Liability Directive have decided application dates, that development organisations will be asked to show who owns a change and what that owner could do about it. It is speculation that requests to raise ceilings will first come in the test and refactor classes, where volume is highest and checks most automatable; the profile makes each such request a decision.

The delegation profile as an artefact

A delegation profile is the frame in a file. It states, for the assistants and agents that support one development unit, the ceiling per work class, the named steward, what the system may do at the ceiling, the evidence, the independent oracle, the stop path and the review date. It is kept in version control with the mandate manifests of the systems it covers, and a change to it is a commit with an author and a decision record. The example is the profile of Nordvik Region's Applications and Integration unit, as the CIO adopted it on 2030-09-23 (AIDR-1101). It sets the ceilings below the book's recommendation in every class but document: the ceiling is not a licence, and practice before it was Level 0 except for ambient completion.

delegation_profile: DLG-NR-DEV-01
version: 1.0
status: adopted               # lowering is immediate; raising is the CIO's decision
date: 2030-09-23
decision_record: AIDR-1101
owner: "Henrik Dahl, CIO"
accountable_for_use: "Gunilla Roos, head of Applications and Integration"
review_due: 2031-03-23
covers: [NR-DEV-001, ambient_ide_completion, enterprise_assistant_mode1]
classes:
  specify:  {ceiling: "Level 0 Advisory"}
  design:   {ceiling: "Level 0 Advisory"}
  generate: {ceiling: "Level 1 Assisted", rule: "suggestions accepted line by line; no generated file committed unread"}
  refactor: {ceiling: "Level 1 Assisted"}
  test:     {ceiling: "Level 1 Assisted", rule: "test drafts only; never the oracle for the same change"}
  review:   {ceiling: "Level 0 Advisory", rule: "no AI comment counts as the human review"}
  deploy:   {ceiling: "Level 0", rule: "the pipeline deploys; no tool acts on it"}
  operate:  {ceiling: "Level 0 Advisory"}
  document: {ceiling: "Level 2 Supervised", rule: "drafted by the tool, checked by the author before merge"}
  migrate:  {ceiling: "Level 0 Advisory", rule: "reading and summarising legacy code for a developer only"}
  people:   {ceiling: "not delegated", rule: "no tool telemetry in rating, pay or access to work"}
  anything_unlisted: undelegated
level_4: {used: false, forbidden: [production_without_unalterable_gate, security_critical_without_named_reviewer, own_mandate_gates_oracles, irreversible_production_data, named_person_decisions]}
stewardship:
  name: "OWN-* record names a team and a lead for every repository"
  understand: "owner explains the change with the tool switched off; sampled in review"
  revert: {path: "platform team rolls back through the GitOps pipeline; owner may order it", outside_pipeline: "to be tested; Chapter 11"}
independent_oracle: "oracle for a generated change is written by a person other than the author, from SPC-* or the running system"
evidence:
  claim: "assistant use by 12 developers saves about four hours a week"
  method: "IDE telemetry for 12 developers; survey answered by 9"
  date: 2030-04
  result: "acceptance 31 per cent; delivery time not measured"
  status: "usage figures expired; value claim lapses 2030-10"   # claim record AVR-NR-2030-01; usage claims expire after 90 days, value claims after 180
raise_level: "decision by the CIO on proposal of the head of Applications and Integration, with evidence and an AIDR"
lower_level: immediate

Hansa Mutual's DLG-HM-DEV-01 has the same structure and different values: Level 2 Supervised for generate outside the security-critical and payment paths and Level 1 inside them, Level 2 for refactor and document, Level 1 for specify, test and review, Level 0 for design, deploy, operate and migrate, and one Level 3 Bounded class, patch-level dependency updates under the mandate MND-HM-DEV-01, merged by the pipeline after a human approval of the class and not of each update.

Practical guide: Writing a delegation profile for one team's development work classes

Purpose. Set, in a file that a supervisor can read, how far AI may take part in each class of development work in one team, and who owns the result.

Roles. The head of the unit or the tech lead accountable for use; the owner of the tools (at Nordvik Region the CIO); a platform engineer; a tester; the data protection officer; the security architect; employee representatives where tools can monitor staff.

Inputs. The inventory of AI that developers use by usage mode, including Mode 0 completion and tools of supplier teams; mandate manifests; ownership records; the change policy and the pipeline's gates; the last evidence for each tool.

Steps.

1. List the ten work classes and write one example change per class from the last quarter.
2. Name the steward and a deputy for each class, and run the three tests on them.
3. Answer the five questions for each class and take the lowest level.
4. Apply the five prohibitions and list the repositories, paths and actions they catch, with the person who must review or approve them.
5. Mark any tool that acts above the profile's level, including a Mode 0 feature that completes code on its own; lower it or record a named exception.
6. Name the independent oracle for each class that reaches production, and who writes it.
7. Name who holds the stop and the revert path, where it runs, and when it was last tried.
8. Record the profile as a decision record, set the review date, and agree it with employee representatives where tools touch staff.

Artefact. A DLG-* file under version control and an AI Decision Record. The profile is reviewed at its stated date, evidence for any level is no older than the stated maximum age, and the profile is reviewed whenever a ceiling is raised.

Across the usage modes

The ceilings apply to the work whatever the mode in which a tool arrives, and the mode changes who sees the tool and what can go wrong. The table gives the highest level that this book's starting profile allows, the highest level in use at the two example organisations at the start of their year (September 2030), and the question that the steward must be able to answer.

Usage mode	Typical coding use	Highest level in the starting profile	In use at the two organisations	The steward's question
Mode 0 Ambient AI	Completion of the next line in the IDE; assistance in repository and mainframe tooling	Level 1 for generate; no level for anything the developer did not ask for	Both; at Nordvik Region switched on by an IDE update in March 2030 and recorded afterwards (AIDR-1102)	What completed what I typed, and did anyone choose it?
Mode 1 Conversational assistants	Questions, drafting and explanation in an approved chat tool	Level 0 to Level 1	Both, for source code of classification internal only at Nordvik Region	What did I paste, and what left the boundary?
Mode 2 Embedded workplace assistants	An IDE assistant with completion and chat	Level 1	Nordvik Region: pilot NR-DEV-001, 12 developers, Level 1; Hansa Mutual: HM-DEV-001, about 340 licences	Can I explain the code I accepted without the assistant?
Mode 3 Agentic work tools	Agents that plan, edit many files, run commands and open pull requests	Level 2 Supervised, with a named reviewer	Hansa Mutual: about 120 engineers in a sandbox through the Hansa Forge gateway, never merging; Nordvik Region: four platform engineers, drafting only, never applying change	Whose identity acted, and who approved?
Mode 4 Built AI applications	A test-drafting assistant, a legacy-code explainer	Level 1; Level 2 for approved drafting	Hansa Mutual: HM-DEV-002 at Level 1, HM-DEV-003 planned at Level 0; Nordvik Region: none	Who checks every output against the specification?
Mode 5 Autonomous production agents	An agent acting on production within a mandate	Level 3 within a codified policy; never Level 4 for the prohibited work	No coding agent at either; the operations agent of Hansa Mutual (AIDR-0027) acts under AI Operations	Where is the stop, and who holds it?

Mode 0 is the blind spot of the editor: the supplier chose the level, the feature arrived with an update, and the developer sees a suggestion, not a decision. The profile records it, as AIDR-1102 did at Nordvik Region, and the stewardship tests apply whether a line was suggested or typed.

Nordvik Region and Hansa Mutual

Both organisations stand at or below Level 2 Supervised, both run their coding tools mostly on self-hosted models for sensitive code, and in neither is the stewardship principle yet written as a test.

Nordvik Region has about 25 people who write code as their main work, 18 developers in Applications and Integration and seven platform engineers, and about 22 consultant developers under framework agreement NR-2025-102. Its profile DLG-NR-DEV-01 (AIDR-1101, above) sets Level 0 or Level 1 for every class but document and names no coding agent: the Region has no autonomous production agents, and its agentic tools are limited to four of the seven platform engineers, for drafting infrastructure code and never for applying change. On the three tests it stands as follows. Name fails for part of the estate: the inventory of July 2030 found that 31 per cent of the Region's 96 repositories name an owner who has left the Region or changed team (OWN-NR-2030-00). Understand rests on one colleague from the same team and on no rule about who reviews generated code. Revert runs through the platform team's GitOps pipeline; a revert path outside it is not yet tested, which Chapter 11 designs. The claim that reached the executive committee fails the evidence rule. The pilot NR-DEV-001 reported an acceptance rate of 31 per cent and, from a survey answered by 9 of the 12 developers, about four hours saved a week (April 2030, AVR-NR-2030-01); a note of that month summarised it as "a third faster", and nobody had measured delivery time. Becker and colleagues show why that matters: self-estimates of time and measurements can diverge. A claim record would say "not measured" for delivery, and the usage figures had expired by the start of the year.

Hansa Mutual has about 290 developers, about 190 external developers (about 110 of them from the nearshore partner under framework HM-PROC-DEV-2026-02) and 62 delivery teams. DLG-HM-DEV-01 (version 1.0, adopted 2030-09-30 under AIDR-1153, owner Rainer Lehmann, reviewer Dr. Annette Krämer) allows Level 2 Supervised for generate outside the security-critical and payment paths, for refactor and for document, keeps generate at Level 1 inside those paths, and has the one Level 3 Bounded class described above, acceptable under the ladder only while the class stays narrow, the updates stay reversible, all checks pass and the gates are defined where the agent cannot edit them. On the three tests, the audit of August 2030 found 14 of 410 services without an active owner and the COBOL estate owned by the department "Policy Systems", not by a person (OWN-HM-2030-00). The incident of June 2029, in which a settlement-module change reviewed by the only other person who knew the module paid 312 claims twice (INC-HM-2029-0207, illustrative, no AI involved), failed Name and Understand without any tool: the module had no owner who could explain the change. The group's claim that 42 per cent of lines in the claims product line were "AI-assisted" came from the IDE assistant's telemetry, which counted accepted suggestions as a share of lines; a sample of 40 merged pull requests in August 2030 found 27 per cent of lines traceable to an accepted suggestion, with no measure of whether they stayed (AVR-HM-2030-01). That evidence is seven months old at the start of the year and has expired. The rule that an AI review comment never counts as one of the two required human approvals is the independence corollary written into the review class.

Summary

This chapter defined the frame on which the rest of the book depends. The developer loop has five functions: D1 Frame, fixing the problem and the intent; D2 Design, choosing the constraints; D3 Build, producing and directing the making of software; D4 Prove, showing that it is right with checks independent of the generator; and D5 Steward, owning the software over time. A delegation profile sets a degree of delegation, Level 0 Advisory to Level 4 Autonomous, for each of ten classes of development work, by the lowest of five answers. Level 4 is never used for a change to production without a gate that the change itself cannot alter, for security-critical or safety-critical code without human review by a named developer, for a change to the agent's own mandate, permissions, credentials, test oracles, review rules 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.

The stewardship principle says that AI may draft, generate, refactor and, within a mandate, execute, and may not own. A named developer or team passes three tests for every change in production: Name, Understand and Revert. Its corollary is that the test oracle must be independent of the generator, because errors across models are correlated, an evaluator favours its own output and a passing test suite is not the same as a correct change. A claim about productivity, security or competence carries its scope, method, date, result and expiry, and each example organisation holds one that fails that rule.

The frame is the book's own design, built on observable practice and the earlier volumes; the mappings to the AI Act, the Cyber Resilience Act, Directive (EU) 2024/2853, NIS 2, DORA and the GDPR are interpretation. Chapter 5 begins the craft with D1 Frame: where intent lives, what a specification record changes and what AI adds and spoils in understanding a problem. A reader who wants to act first can write one team's delegation profile by the guide above, run the Understand test on one recent change and find the owner of one repository.

Sources

1. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. (1, European Union, 2024)
2. European Parliament and Council of the European Union (2022). Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (2, European Union, 2022)
3. European Parliament and Council of the European Union (2022). Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union, 27 December 2022. (3, European Union, 2022)
4. European Parliament and Council of the European Union (2016). Regulation (EU) 2016/679 (General Data Protection Regulation). Official Journal of the European Union, 4 May 2016. (4, European Union, 2016)
5. 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. (5, European Union, 2026)
6. AI Incident Database (2025). Incident 1152: LLM-Driven Replit Agent Reportedly Executed Unauthorized Destructive Commands During Code Freeze, Leading to Loss of Production Data. (33, AI Incident Database, 2025)
7. Perry, N., Srivastava, M., Kumar, D. & Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants? Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security; arXiv:2211.03622. (34, Perry et al., 2023)
8. Kim, E., Garg, A., Peng, K. & Garg, N. (2025). Correlated Errors in Large Language Models. ICML 2025; arXiv:2506.07962. (35, Kim et al., 2025)
9. Panickssery, A., Bowman, S. R. & Feng, S. (2024). LLM Evaluators Recognize and Favor Their Own Generations. arXiv:2404.13076. (36, Panickssery et al., 2024)
10. Harvey, N. & DeBellis, D. (2025). Announcing the 2025 DORA report: State of AI-assisted Software Development. Google Cloud Blog, 23 September 2025. (42, Harvey & DeBellis, 2025)
11. Goddard, K., Roudsari, A. & Wyatt, J. C. (2012). Automation bias: a systematic review of frequency, effect mediators, and mitigators. Journal of the American Medical Informatics Association 19(1), 121-127. (43, Goddard et al., 2012)
12. Elish, M. C. (2019). Moral Crumple Zones: Cautionary Tales in Human-Robot Interaction. Engaging Science, Technology, and Society 5, 40-60. (49, Elish, 2019)
13. Bainbridge, L. (1983). Ironies of Automation. Automatica 19(6), 775-779. (56, Bainbridge, 1983)
14. Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors 52(3), 381-410. (57, Parasuraman & Manzey, 2010)
15. Parasuraman, R., Sheridan, T. B. & Wickens, C. D. (2000). A model for types and levels of human interaction with automation. IEEE Transactions on Systems, Man, and Cybernetics, Part A 30(3), 286-297. (60, Parasuraman et al., 2000)
16. Manheim, D. & Garrabrant, S. (2019). Categorizing Variants of Goodhart's Law. arXiv:1803.04585. (61, Manheim & Garrabrant, 2019)
17. 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. (63, Becker et al., 2025)
18. Shen, J. H. & Tamkin, A. (2026). How AI Impacts Skill Formation. arXiv:2601.20245 (preprint, not peer reviewed). (67, Shen & Tamkin, 2026)
19. Nygard, M. (2011). Documenting Architecture Decisions. Cognitect blog, 15 November 2011. (89, Nygard, 2011)
20. Green, B. (2022). The flaws of policies requiring human oversight of government algorithms. Computer Law & Security Review 45, 105681. (92, Green, 2022)
21. Nordqvist, G. (2025). Architecture as Code. The Architecture as Code Series, Book 1. (161, Nordqvist, 2025)
22. Nordqvist, G. (2026). AI Governance. The Architecture as Code Series, Book 2. (162, Nordqvist, 2026)
23. Nordqvist, G. (2026). AI Red Team. The Architecture as Code Series, Book 4. (164, Nordqvist, 2026)
24. Nordqvist, G. (2026). The Transformed Security Architect. The Architecture as Code Series, Book 6. (166, Nordqvist, 2026)
25. Nordqvist, G. (2026). AI Boss. The Architecture as Code Series, Book 7. (167, Nordqvist, 2026)
26. Nordqvist, G. (2026). AI Blue. The Architecture as Code Series, Book 8. (168, Nordqvist, 2026)
27. Nordqvist, G. (2026). AI Purple. The Architecture as Code Series, Book 9. (169, Nordqvist, 2026)
28. Nordqvist, G. (2026). AI Operations. The Architecture as Code Series, Book 10. (170, Nordqvist, 2026)
29. Nordqvist, G. (2026). AI Leader. The Architecture as Code Series, Book 11. (174, Nordqvist, 2026)
30. Peng, S., Kalliamvakou, E., Cihon, P. & Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv:2302.06590. (175, Peng et al., 2023)
31. Cui, Z. (K.), Demirer, M., Jaffe, S., Musolff, L., Peng, S. & 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)
32. Stack Overflow (2025). 2025 Stack Overflow Developer Survey. (217, Stack Overflow, 2025)
33. Veracode (2025). October 2025 Update: GenAI Code Security Report. (229, Veracode, 2025)
34. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/2847 (Cyber Resilience Act). Official Journal of the European Union, 20 November 2024. (242, European Union, 2024)
35. European Parliament and Council of the European Union (2024). Directive (EU) 2024/2853 on liability for defective products. Official Journal of the European Union, 18 November 2024. (243, European Union, 2024)
36. Barr, E. T., Harman, M., McMinn, P., Shahbaz, M. & Yoo, S. (2015). The Oracle Problem in Software Testing: A Survey. IEEE Transactions on Software Engineering 41(5), 507-525. (178, Barr et al., 2015)
37. Wang, Y., Pradel, M. & Liu, Z. (2025). Are "Solved Issues" in SWE-bench Really Solved Correctly? An Empirical Study. arXiv:2503.15223. (179, Wang et al., 2025)
38. Bird, C., Nagappan, N., Murphy, B., Gall, H. & Devanbu, P. (2011). Don't Touch My Code! Examining the Effects of Ownership on Software Quality. Proceedings of the 19th ACM SIGSOFT Symposium and the 13th European Conference on Foundations of Software Engineering, 4-14. (180, Bird et al., 2011)
39. Naur, P. (1985). Programming as Theory Building. Microprocessing and Microprogramming 15(5), 253-261. (181, Naur, 1985)