Introduction: The Developer with AI

The eleven earlier volumes of this series govern, secure, defend, operate and lead what developers build. Every one of them rests on software that somebody wrote, reviewed, tested and released, and none took that person as its subject. This book does. It asks what happens to the developer, and to the development organisation, when AI writes, reviews, tests and deploys code across the organisation: not in one tool or one team, but in the editor, the pull request, the pipeline, the ticket, the legacy migration and the citizen's low-code application. It concerns all five functions of the developer loop that Chapter 4 defines: D1 Frame (understanding the problem and fixing intent), D2 Design (choosing the constraints), D3 Build (producing and directing the making of software), D4 Prove (showing that the software is right) and D5 Steward (owning software over time).

The chapter has a plain purpose. It states what a developer is and does, why AI changes it now and across the organisation, what the book claims and what would show the claim wrong, which vocabulary the book relies on, and how each kind of reader should use it. The conclusions of the earlier volumes are summarised where they are needed, so that no reader has to have read them.

The developer loop: five functions, the named developer or team that owns the change, the test oracle independent of the generator and the revert path outside the pipeline

Figure 1.1: The developer loop with the chapters that treat each function, the named steward, the independent test oracle and the revert path outside the pipeline.

A change nobody can explain

Two changes of the same kind open the book. Both are illustrative; the organisations that make them are fictional and are described in full below, and their facts are those of the book's canonical profiles.

At Nordvik Region, a public authority with about 6,000 employees, a developer in the integration and data team merged a fix to a national-register interface in August 2030. One colleague approved the pull request, as the team's rule requires. Weeks later a second developer, reading the code to extend it, asked who had written a conversion routine in the middle of the change. The author remembered accepting a number of completion suggestions while writing it, because the completion feature of the Region's development environments had been switched on by default in the vendor's update of March 2030. The Region keeps no log of which lines came from a suggestion. The reviewer had read the change as a colleague's work. The repository's ownership file named a team, and the Region's own inventory of July 2030 had found that 31 per cent of its 96 repositories named an owner who had left the Region or changed team. Nobody could say who should explain the routine, and nobody had decided that the question would arise.

At Hansa Mutual, an insurance group with about 9,500 employees, an agent in the engineering group's agentic work tools opened a pull request against a claims service in the autumn of 2030. The group's rule is that such agents work in a sandbox, open pull requests and never merge to the protected branch, and the rule held: two developers approved the change, as the group's change policy requires for production changes in its critical or important functions. A month later an auditor asked who could explain the change without the agent's help. The first approver had reviewed the diff the agent produced and the tests the agent produced for it. The second had approved on the strength of the first. Both had done what the process asked. Neither could reconstruct, from the code and the ticket alone, why the agent had restructured a validation step, and the tests that passed were the tests written by the same agent that wrote the change.

The two cases differ in everything except the question. One concerns a suggestion that no record shows and the other an agent whose every step is recorded; one a small public authority, the other a financial group under supervision. In neither did an AI system take a decision that was formally delegated to it. That is the point. The harm the book is concerned with does not require an agent that merges and deploys on its own. It arises when AI takes part in a change that reaches production and the organisation has not written down who owns the result, who can explain it and who can revert it. The first test is simple to state and rarely run: pick a change that reached production last month and ask who owns it, in the sense that the owner is known, can explain it and can stop it.

Development with AI in 2030

The year that the book follows in its two organisations runs from September 2030 to August 2031. The evidence it cites was read in November 2026 and mostly dates from 2023 to 2025, so it is older than the year it describes; every claim carries its date, and the organisations' own figures are fictional and illustrative.

Developers already meet AI in at least five places. Ambient AI (Mode 0) completes the next line in the editor and proposes a summary at the top of a pull request. Conversational assistants (Mode 1) answer a question about an unfamiliar library or draft a regular expression. Embedded assistants (Mode 2) sit in the development environment with the developer's permissions, completing code and answering questions about the open repository. Agentic work tools (Mode 3) take a task, read the repository, propose a change, run the tests and open a pull request, and built applications (Mode 4) draft tests or explain legacy code for a team. Autonomous production agents (Mode 5) act without a person approving each step; in the two organisations none of them writes or merges code, and the operations agent of AI Operations acts under that book's mandates.

Observable. Use is widespread among developers, though not uniform. The 2025 Stack Overflow Developer Survey, answered by more than 49,000 self-selected respondents in 177 countries, reports that 84 per cent use or plan to use AI tools in their development process. In the same survey 46 per cent said they distrust the accuracy of the output of AI tools and 33 per cent said they trust it, and about 31 per cent said they use AI agents in their work, development or otherwise (217, Stack Overflow, 2025). The sample is self-selected and the questions concern attitude and use, not outcome. The enterprise-level figure is lower: Eurostat reports that 20.0 per cent of EU enterprises with ten or more employees used AI technologies in 2025, up from 13.5 per cent in 2024, and says nothing about software development in particular (80, Eurostat, 2025).

Observable. Two features of the way AI reaches developers matter more than the adoption share. The first is that much of it arrives without a procurement decision, as a feature switched on by an update of software the organisation already licenses, which is why AI Governance (Chapter 2) classes AI by usage mode and not by product (162, Nordqvist, 2026). Nordvik's case is the example: the decision about ambient completion was recorded afterwards, in AIDR-1102. The second is that what AI produces is addressed to the developer as something already shaped like the developer's own work, a line, a function, a test, a diff, and therefore sits exactly where the developer's own judgement was supposed to begin.

Expected. Both features will persist and the share of code that AI takes part in will rise, because the assistants are embedded in the tools developers already use and because the organisations in this book have decided rollouts. That is a statement about direction, supported by the survey trend and by those decisions, not a forecast of a level.

Why a book on the developer

Three reasons make this a book and not a chapter in another one.

Development has always been partly translation

Software development has always been partly an act of translation: from need to requirement, from requirement to design, from design to code, from code to behaviour in production. Frederick Brooks drew a distinction that fits. He separated the essential difficulties of software, the specification, design and testing of a conceptual construct, from the accidental ones, the difficulties of representing that construct in a language and a machine (215, Brooks, 1995). The essay "No Silver Bullet", reproduced in the anniversary edition of The Mythical Man-Month, argued that no single development would remove the essential part. This book uses the distinction as a lens and does not claim that Brooks predicted anything about generative AI.

Seen through it, generative AI performs the translation from a specification to code cheaply and fluently. What it does not make cheaper is knowing what to build, knowing whether what was built is right, and answering for it in production. The work that was always bundled with typing, namely framing, deciding, proving and owning, is no longer hidden inside the typing; it becomes more visible and, the book argues, more exposed, because it is what remains when the translation is done by something else. This is the book's own reasoning, and the thesis below states it as a claim to be tested.

The evidence is mixed, young and contested

Studies of AI in software development do not agree, and they measure different things. Three are worth setting side by side because each is widely quoted and each is narrow.

In a controlled experiment, developers recruited for the study were asked to write an HTTP server in JavaScript as quickly as possible, and those with access to GitHub Copilot completed the task 55.8 per cent faster than the control group (175, Peng et al., 2023). The task was a single, well-specified, self-contained one, set by the researchers. In three randomised field experiments at Microsoft, Accenture and an anonymous Fortune 100 company, with 4,867 developers in all, the abstract of the study reports a 26.08 per cent increase in completed tasks among developers who were given an AI coding assistant (176, Cui et al., 2024); the book cites the abstract and did not read the full text, and the measure is completed tasks, which is not the same as value delivered or time spent. And in a randomised trial of early-2025 AI tools, 16 experienced developers working on mature open-source projects where they averaged five years of prior experience completed 246 tasks, each randomly assigned to allow or disallow AI. Allowing AI increased completion time by 19 per cent. The developers had forecast before starting that AI would reduce completion time by 24 per cent, and after the study they estimated that it had reduced it by 20 per cent (63, Becker et al., 2025). The sample is small, the developers worked in codebases they knew well, and the tools are those of the first half of 2025.

The three results do not contradict each other. They measure different people, different tasks, different codebases and different outcomes. What carries over is a shape and not a size of effect: the result depends on the task, on the developer's experience of the codebase and on how the outcome is counted, and what developers believe about their own speed can diverge from what was measured. The same shape appears outside software in the pre-registered experiment with 758 consultants, in which AI helped on tasks inside the model's capability and made correct answers less likely on a task outside it (81, Dell'Acqua et al., 2023). A survey-based finding on knowledge workers adds a caution about the person and not the output: higher confidence in generative AI was associated with less critical thinking, in a self-report study of an association (82, Lee et al., 2025). Neither study was about developers.

Claims from vendors need the same discipline. A vendor report on the share of AI-generated code with security flaws, or on the quality of changed lines, is research by an interested party using its own classification, and the book reads it as a claim with a method to be checked (229, Veracode, 2025), (177, GitClear, 2025). The DevOps Research and Assessment (DORA) programme's 2024 report, published in October 2024, states that AI adoption increases individual productivity, flow and job satisfaction and also negatively affects delivery stability and throughput; the programme's page gives no magnitudes and the report is a survey, so the book cites the direction only, as an association (216, Google Cloud, 2024).

Both organisations of the book already hold a figure of this kind. Nordvik's executive committee was told in April 2030 that a pilot made developers "a third faster", from a pilot's telemetry for 12 developers (an acceptance rate of 31 per cent) and a survey answered by nine; nobody had measured delivery time (AVR-NR-2030-01). Hansa's group CIO reported to the executive board in February 2030 that 42 per cent of committed lines in the claims product line were AI-assisted, counting 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). In both cases the figure left the team that produced it without its scope, method or date. The book keeps one discipline throughout, and the fifth part of the thesis makes it a rule for developers: say what was measured, in whom, over what period and by what method, before saying what it means.

European law assigns duties to named parties for software

The instruments that bear on software do not address "the organisation" in general. The AI Act, Regulation (EU) 2024/1689, requires in Article 4, as substituted by the Digital Omnibus on AI, Regulation (EU) 2026/1744, in force since 27 July 2026, that providers and deployers of AI systems take measures to support the development of AI literacy of their staff and of other persons who operate or use AI systems on their behalf, without requiring any specific level of literacy of any individual (5, European Union, 2026), and in Article 26(2) that deployers of high-risk AI systems assign human oversight to natural persons who have the necessary competence, training and authority (1, European Union, 2024). The Cyber Resilience Act, Regulation (EU) 2024/2847, lays down horizontal cybersecurity requirements for products with digital elements and places its duties on the manufacturers of those products (242, European Union, 2024). The Product Liability Directive, Directive (EU) 2024/2853, includes software in its definition of a product in Article 4(1), and its recital 13 states that software is a product for the purposes of no-fault liability (243, European Union, 2024). NIS 2 lists among the cybersecurity risk-management measures of essential and important entities supply chain security in Article 21(2)(d) and security in the acquisition, development and maintenance of network and information systems in Article 21(2)(e), and in Article 20(1) requires their management bodies to approve those measures and oversee their implementation (3, European Union, 2022). DORA, which in this book always means Regulation (EU) 2022/2554, places ultimate responsibility for ICT risk with the management body of a financial entity in Article 5(2) (2, European Union, 2022). The controller under the GDPR remains responsible for personal data that a coding tool or a generated application processes (4, European Union, 2016). And the employer has duties towards employee representatives: German co-determination under section 87(1) no. 6 of the BetrVG covers tools suited to monitor behaviour or performance (9, Germany, n.d.), and the Swedish Co-determination Act requires an employer to negotiate before an important change (12, Sveriges riksdag & Regeringskansliet, 1976).

Two implications follow, and both are the book's own reasoning, not legal advice. First, these duties attach to persons and bodies: an organisation, a manufacturer, a deployer, a controller, a management body. None of them moves to a model or to a code generator, so a decision about who holds them in a development organisation cannot be handed to a tool. Second, the law is mostly silent where the two cases above arose. No instrument says what a record of a change that AI took part in must contain, or who in a team must be able to explain it. Chapter 24 reads the instruments in full and states the questions that remain open for each organisation. The gap between the duties that exist and the practices that would make them real is where a book on the developer has work to do.

The working thesis

The thesis has five parts. Parts II to V test them, and Chapters 29 and 33 judge them. Each is the book's own claim, drawn from the earlier volumes and argued in this one; none is reported as an established finding.

  1. The developer is transformed, not abolished: from author of code to framer, verifier and steward of software. The typing of code shrinks. The weight moves to framing the problem and intent (D1), deciding the design and its constraints (D2), directing and reviewing what is built (D3), proving that it is right (D4) and owning it in production over time (D5). This applies to software the conclusion that AI Operations (Chapter 4) drew for operators and AI Leader (Chapter 4) for leaders: the role is transformed, and its weight moves to the work that cannot be done by the tool that does the rest (170, Nordqvist, 2026) and (174, Nordqvist, 2026).
  2. Delegation of development work is graded and has a ceiling. Every class of development work has a degree of delegation, Level 0 Advisory to Level 4 Autonomous, set by reversibility, blast radius, who is affected, the evidence for the tool and the strength of the independent checks. Level 4 is never used for a change to production without a gate that the change itself cannot alter; for code in a security-critical 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.
  3. Verification, not generation, becomes the scarce skill, and the junior pipeline must be rebuilt, not assumed. Code is cheap to produce and expensive to trust. The cost moves to review, tests, specifications and operations. The entry-level tasks that taught the craft are among the tasks AI performs best; an organisation that removes them without a replacement route has no future seniors. The apprenticeship is redesigned on purpose.
  4. The stewardship principle: 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 to colleagues, operators and auditors. Understand: the owner can explain what the change does and why, and can reconstruct it, without the tool that generated it. 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. Delegation moves work and never ownership. The principle carries a corollary for evidence: the test oracle must be independent of the generator, because tests, reviews and checks that an AI wrote for its own output verify less than they appear to.
  5. Productivity, quality and competence are claims that need evidence. "AI writes 40 per cent of our code", "velocity is up by a third" and "our developers are AI-fluent" are statements with scope, method, date and result. Acceptance rate is not productivity, lines written are not value, evidence expires, and craft decays if it is not exercised, so the developer's own craft is kept in practice on purpose.

The fourth part is the developer's counterpart to three principles that earlier volumes established for other people. AI Purple (Chapter 4) concluded that a check counts as verification only when its failure modes are shown not to be those of the thing it checks, the independence principle (169, Nordqvist, 2026). AI Operations (Chapters 4 and 17) concluded that what verifies an action must be independent of what performed it, that the observer must not depend on the system it observes and that the stop path must work when the platform does not, the observer principle (170, Nordqvist, 2026). AI Leader (Chapter 4) concluded that AI may inform, draft, prepare and, within a mandate, execute, but may not answer, and that a named leader passes the tests Name, Explain and Reach, the answerability principle (174, Nordqvist, 2026). Stewardship generalises all three to the person who owns the software: the owner must be independent of the machine that generated the change, must not depend on it for the means to explain it, and must be able to revert it from outside.

What would show the thesis wrong. Independent, multi-year evidence that organisations which let AI systems merge, deploy and own code without named, reachable human owners and without generator-independent checks achieve better quality, security, delivery and learning than organisations that keep them would refute the second and fourth parts. Evidence that developers who never write or read code by hand develop the judgement to verify it as well as those who do would refute the third part and weaken the fifth. Speculation. Neither kind of evidence exists today, and both could appear. The book states what it would take to be moved so that a reader can tell when it should be.

Five functions and five degrees

Chapter 4 defines the developer loop in full. This section gives the reader the five functions, the ladder and the principle in a paragraph each, so that the chapters that follow can use them.

D1 Frame is understanding the problem and fixing intent: requirements, acceptance criteria, the specification and the traceability from a need to something executable. D2 Design is choosing the constraints: architecture, interfaces, data, security by design, and the decisions with their records; Architecture as Code (Chapter 4) set out the Architecture Decision Record (ADR) for exactly this (161, Nordqvist, 2025). D3 Build is producing and directing the making of software: writing code, directing assistants and agents, refactoring and migrating, within a mandate. D4 Prove is showing that the software is right: review, tests, verification and secure-code and supply-chain checks, with an oracle independent of the generator. D5 Steward is owning software over time: release, operation, maintenance, ownership, documentation, incidents and the authority to revert. The functions are not the operations functions O1 to O5 of AI Operations or the leadership functions L1 to L5 of AI Leader. D5 Steward meets O3 Change at the boundary, and Chapter 11 treats that boundary.

The delegation ladder grades the degree to which a class of development work is delegated, from Level 0 Advisory to Level 4 Autonomous, and is set per class: specify, design, generate, refactor, test, review, deploy, operate, document and migrate. The idea of grading automation by level and by the stage of work it takes over is older than the series: Parasuraman, Sheridan and Wickens proposed a model of types and levels of automation across four stages, from information acquisition to action implementation (60, Parasuraman et al., 2000). The series applied it to AI in AI Red Team (Chapter 6) (164, Nordqvist, 2026) and the book applies it to development work.

The stewardship principle is the thesis's fourth part. Its purpose is practical: when something goes wrong, it separates a developer who owns a change from a developer who merely approved it. Elish's analysis of moral crumple zones describes the failure it guards against, namely that in complex automated systems a human operator close to the system can absorb the blame for outcomes that the design of the whole produced (49, Elish, 2019). A reviewer who approves a diff that a tool produced, with tests that the same tool wrote, and who cannot explain it or revert it, is in a crumple zone and is not an owner. The three tests are the means by which a code-ownership record shows that the person is the second. The research on automation bias in decision support, a systematic review of studies mostly in clinical settings, gives a reason to expect the failure: people tend to follow an automated aid's advice even when it is wrong, with the effect mediated by factors such as workload (43, Goddard et al., 2012). It was not a review of programmers, and the book treats it as a reason for a working assumption and no more.

Usage modes and degrees of delegation

The book uses two sets of terms from earlier volumes exactly. The first is the six usage modes of AI Governance (Chapter 2), which classify AI by how its output reaches a person and what it can do, because the way a model is used matters more than which model it is (162, Nordqvist, 2026).

Mode What it is Where a developer meets it
Mode 0 Ambient AI AI that people meet without having chosen it: generated suggestions inside software Next-line completion switched on by an update; generated summaries of a pull request
Mode 1 Conversational assistants A general-purpose chat interface; the person brings the context and takes the output away A question about a library or a draft of a query in an approved chat tool
Mode 2 Embedded workplace assistants An assistant that works inside the developer's tools with the developer's permissions An IDE assistant with completion and chat on the open repository
Mode 3 Agentic work tools A model in a loop with tools; a person delegates and reviews An agent that reads a repository, proposes a change, runs tests and opens a pull request
Mode 4 Built AI applications A model integrated in the organisation's own system, with its own lifecycle A test-drafting assistant or a legacy-code explainer built on the AI platform
Mode 5 Autonomous production agents An agent that acts on business systems without a person approving each step None writes or merges code in the two organisations

The second set is the degrees of delegation, the five autonomy levels the series has used since AI Red Team (Chapter 6), which this book applies per class of development work.

Degree What the AI system does Who decides and acts, for a development task
Level 0 Advisory Suggests; may answer a question The developer writes, decides and commits
Level 1 Assisted Drafts the code, the test or the text The developer reads it and commits it in the developer's own name
Level 2 Supervised Executes after explicit approval of each action A developer approves each action, for example reviewing every pull request an agent opens
Level 3 Bounded Executes pre-approved, reversible actions within a codified policy The policy was approved by a named authority and is enforced outside the model; 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 properties of the ladder carry into this book. The level is set per class of work and per action, so one assistant can draft a unit test at Level 1 Assisted and offer nothing at all in a personnel matter. The line between Level 2 and Level 3 is where approval of each action stops, and Level 3 without a written policy that is enforced outside the model and a stop held by a named person is Level 4 under another name. And the level is decided and recorded, not discovered: a team that finds out afterwards that a tool was acting at Level 2 has not delegated; the team has been bypassed. The book's reading of the two organisations is that Modes 0 to 2 supply suggestions and drafts at Level 0 and Level 1, that Mode 3 reaches Level 2 where a developer reviews every change, and that one class at Hansa Mutual reaches Level 3, discussed in Chapter 8.

Modes and degrees are different axes: a mode says how the system reaches the developer, a degree how much of the work has been handed over, and a ceiling in a profile is not a licence.

Practical guide: inventory where AI already takes part in a team's development work

Purpose. Most teams cannot say where AI already takes part in their work, because much of it arrived as a feature. The inventory is the first artefact of the book and the precondition of every delegation profile.

Roles. The tech lead of the team; the developers, testers and product owner whose work is inventoried; the platform engineer who can read the licensing, the gateway and the logs; the engineering manager; the data protection officer where prompts or code leave the organisation; and, where the inventory touches telemetry about staff, the works council or union representative.

Inputs. The list of licensed development tools and their AI features, the organisation's inventory of AI systems, the repositories and pipelines the team owns, the contracts with suppliers whose developers work in the team's repositories, and four weeks of the team's pull requests.

Steps.

  1. List every place where code, tests, text or a decision in the team's work was suggested, generated, reviewed or executed by an AI system: the usage mode, the system, the owner and whether the team chose it. Include Mode 0 features, the tools of consultants and suppliers, and citizen-built applications on the team's data.
  2. For each, record the classes of development work it touches (specify, design, generate, refactor, test, review, deploy, operate, document, migrate) and the degree at which it currently operates.
  3. For each class, record who prepares, who approves and who owns the result, and whether the owner passes the tests Name, Understand and Revert today.
  4. Mark each place where the team could not say which lines or which text came from the tool, each where the oracle for a change was written by the generator of the change, and each where the owner could not revert outside the pipeline.
  5. Store the result as a delegation profile in the same repository as the team's role charters. Review it at least every six months and on every new AI feature in licensed software.

Resulting artefact. A one-page delegation profile for one team. The profile below is a worked example for the integration and data team of Nordvik Region. It shows the ceilings of the Region's delegation profile DLG-NR-DEV-01 as one team would apply them; Chapter 4 registers the profile itself. It is illustrative.

# DLG-NR-DEV-01, view for one team (illustrative; Chapter 4 registers the profile)
profile: DLG-NR-DEV-01
team: integration and data team, Applications and Integration
tech_lead: Anders Falk            # ROLE-NR-TCL-01
accountable_for_use: Gunilla Roos # head of Applications and Integration
owner: Henrik Dahl                # CIO
reviewed: 2030-09-23
next_review: 2031-03-23
ceiling_is_not_a_licence: true
work_classes:
  - {class: specify,  level: "Level 0 Advisory",   approved_by: product owner}
  - {class: design,   level: "Level 0 Advisory",   approved_by: tech lead}
  - {class: generate, level: "Level 1 Assisted",   approved_by: author, rule: "no generated file is committed unread"}
  - {class: refactor, level: "Level 1 Assisted",   approved_by: author}
  - {class: test,     level: "Level 1 Assisted",   approved_by: author, rule: "drafts only; never the oracle for the same change"}
  - {class: review,   level: "Level 0 Advisory",   approved_by: colleague, rule: "an AI comment is not the human review"}
  - {class: deploy,   level: "Level 0 Advisory",   approved_by: pipeline, rule: "no tool acts on the pipeline"}
  - {class: operate,  level: "Level 0 Advisory",   approved_by: tech lead}
  - {class: document, level: "Level 2 Supervised", approved_by: author, rule: "checked before merge"}
  - {class: migrate,  level: "Level 0 Advisory",   approved_by: tech lead, rule: "reading and summarising legacy code only"}
people_decisions: not delegated   # employment, pay, performance rating, access to work
level_4_prohibited: true
unowned_findings:
  - "No log shows which lines came from ambient completion (Mode 0)"
  - "Ownership file names a team; 31 per cent of the Region's repositories name a departed owner"

The profile is short by design. The last field matters most: an inventory that finds nothing is more likely to be incomplete than to be clean.

Rules of the book

Six rules bind every chapter, and a reader who knows them can check the book against its own standard.

The book is defensive. Attacks on the toolchain, such as prompt injection into coding agents, hallucinated package names, secret leakage and malicious dependencies, are described by class and technique at the level needed to design controls and tests. There is no exploit code, no payload and no injection string, and the code examples are delegation profiles, mandate manifests and the other records of the series.

Every statement about the future carries a label. The three labels are those of AI Governance (Chapter 22): observable (happening now and documented), expected (supported by a stated trend or a decided instrument) and speculation (plausible but unevidenced). The author's own projections are kept to Chapters 29 and 33.

Claims carry their evidence, and systems are not given intentions. No chapter says that a tool raises productivity, that code is secure or that a team is AI-fluent without saying what was measured, how, when and with what result. An AI system suggests, generates, drafts, refactors, reviews or executes within a mandate; it does not understand, want or decide, and "decides" is used only where a decision was formally delegated and the record says by whom.

People are described by what studies measured. The book names the population, the period and the method before it draws a conclusion about skill, trust or wellbeing, never calls anyone lazy, stupid or replaceable, and names the representative body, such as the works council, the union or the European Works Council, where a measure touches staff.

Law is attributed and framed as implication. A legal statement names the instrument and the article, is checked against the live text and is read as an organisational and architectural implication, not as legal advice.

Terms are used exactly. The five developer functions, ten classes of development work, six usage modes, five degrees of delegation and three stewardship tests have fixed names, and identifiers follow the families of the series and the AI Decision Records AIDR-1100 to AIDR-1199.

Two organisations and the series

Two fictional organisations run through the whole book, and every worked example agrees with their canonical profiles.

Nordvik Region is a public authority with about 6,000 employees. Applications and Integration has 31 people, 18 of them developers (two juniors), and the platform team has seven engineers, so about 25 employees write code as their main work. The Region also buys about 22 consultant developers, relies on supplier teams whose code it does not review, and has about 140 staff who build small applications with a low-code product. Its case-management system of 1.1 million lines of Java and PL/SQL has been customised for fourteen years. It develops under public-law accountability (procurement, public-access and archives rules, published code) and negotiates with its unions before an important change.

Hansa Mutual is an insurance group with about 9,500 employees. Group Application Development has about 480 employees, about 290 of them developers in some 62 delivery teams, beside an internal developer platform of 24 people. The group buys about 190 external developers, and its policy administration platform holds about 6.5 million lines of COBOL and PL/I maintained by twelve people, five of them within eight years of retirement. It develops under financial-sector supervision (DORA, change management, the register of information), and the Konzernbetriebsrat co-determines tools suited to monitor behaviour or performance.

The two differ in scale, setting and representation, and resemble each other in what matters here. Neither has an AI coding tool above Level 2 Supervised except one Level 3 Bounded class at Hansa; both hold an adoption claim whose evidence is thinner than its audience supposed; both keep legacy that outlives its authors; and both buy development capacity under contracts with little or no clause on AI tools.

The series builds in publication order, and this book takes from each volume what it needs. Architecture as Code made the architect's work executable (161, Nordqvist, 2025) and AI Governance gave the forums, decision rights and usage modes (162, Nordqvist, 2026). AI Platform and Security built the platform and pipeline that an AI-built system passes through (163, Nordqvist, 2026). AI Red Team, AI Blue and AI Purple treated defence and the loop between emulation and defenders (164, Nordqvist, 2026), (168, Nordqvist, 2026), (169, Nordqvist, 2026). AI Threat supplied the evidence base for trust and cognitive offloading, notably its Chapter 6 (165, Nordqvist, 2026), and The Transformed Security Architect the conductor idea (166, Nordqvist, 2026). AI Boss treated the management and monitoring of people, which Chapter 22 meets and does not repeat (167, Nordqvist, 2026). AI Operations treated what happens to code once it runs (170, Nordqvist, 2026), and AI Leader the middle layer, adoption and works councils, to which this book points (174, Nordqvist, 2026).

How to read this book

The book has seven parts. Part I frames the question and defines the loop. Part II treats the craft function by function. Part III treats the roles across the organisation. Part IV treats leading change and adoption, Part V regulation, ethics and responsibility, and Part VI the developer as a person. Part VII gives experience and conclusions. The chapters can be read in order, and each reader can also take a path.

The junior developer reads Chapter 13 on the apprenticeship problem, Chapter 27 on competences and Chapter 28 on the developer's own mind, then Chapters 7 and 9 for the craft. The mid-level developer reads Chapters 7 to 10, which treat building, building with agents, proving and securing, and Chapter 12 on maintenance and legacy. The senior, staff or principal engineer reads Chapter 14, which is written for the role, and Chapters 9 and 12.

The tech lead and the engineering manager read Chapters 15, 20 and 21, on the team, on measuring adoption and on culture, and Chapter 22 on telemetry. The architect, the platform engineer and the site reliability engineer read Chapter 16 and Chapters 6, 10 and 11. The tester, the quality engineer, the product owner and the designer read Chapter 17 and Chapters 5, 9 and 19, the last on the non-developer who builds.

Public-sector IT leaders read Chapters 18, 24 and 26 on procurement, regulation and sovereignty. Leaders who decide on developer tooling and headcount read Chapters 20, 29 and 32. HR specialists, works council members and union representatives read Chapters 22, 13, 27 and 28. Educators read Chapters 13 and 27. Supervisors and auditors read Chapters 11, 12 and 24.

A reader with one hour reads this chapter, Chapter 4, the Summary and verdict of Chapters 8, 13, 20 and 29, and Chapter 33. That path gives the loop, the ceiling, the principle, the strongest case on both sides of the contested questions and the conclusion, and it does not give the evidence behind them.

Across the usage modes

The use of coding tools in the two organisations at the start of the year falls into the modes as follows, with the degree at which their delegation profiles place it, and the Level 4 prohibitions that apply wherever a mode reaches a class they cover. The profiles are those of Chapter 4.

Mode Nordvik Region Hansa Mutual Highest degree in the profiles Note
Mode 0 Ambient AI Completion in the licensed IDEs, on by default since March 2030; recorded afterwards in AIDR-1102 Ambient AI in IDEs, the repository platform and the managed provider's mainframe tooling Level 0 Advisory Arrives without a decision; no log of which lines came from a suggestion
Mode 1 Conversational assistants Approved enterprise assistant for internal code; not for credentials or special-category data Approved enterprise tiers Level 0 Advisory The developer brings the context and takes the output away
Mode 2 Embedded workplace assistants Pilot NR-DEV-001 for 12 developers on a self-hosted open-weight model HM-DEV-001 licensed to about 340 developers and testers Level 1 Assisted Completion and chat; no repository-wide edits at Nordvik
Mode 3 Agentic work tools Platform team only: four of seven engineers draft infrastructure code and runbooks, never apply change About 120 engineers through the Hansa Forge gateway; sandbox, pull requests, never a merge Level 2 Supervised A developer reviews every pull request an agent opens
Mode 4 Built AI applications None built for developers HM-DEV-002 drafts tests; HM-DEV-003 legacy-code explainer planned Level 1 Assisted for tests, Level 0 for the explainer The oracle for a change is written by someone other than its author
Mode 5 Autonomous production agents None; the Region has no autonomous production agents None writes or merges code; the operations agent acts under AI Operations Not used for code Level 4 is never used where Chapter 4 prohibits it

Nordvik Region and Hansa Mutual

Both organisations opened a commission on the question this book asks within a week of each other in September 2030. In AIDR-1100, dated 16 September 2030, the CIO of Nordvik Region, Henrik Dahl, with the endorsement of the regional director, commissions the head of Applications and Integration, Gunilla Roos, and the platform lead, Maja Lindqvist, to describe the developer role in a Region that uses AI broadly. The HR director, Ingrid Halvorsen, the IT representative of the union, Tomas Ekblad, and the regional legal counsel, Maria Åkesson, are the reviewers, and the first report to the regional executive committee is due by 30 June 2031. In AIDR-1150, dated 23 September 2030, the group CIO of Hansa Mutual, Rainer Lehmann, with the endorsement of the chief executive, asks Dr. Philipp Reinhardt, head of Group Application Development, Lukas Frey, head of the Hansa Forge platform, and the head of the group AI platform to describe the developer role in a group that uses AI broadly. The chief risk officer, Dr. Annette Krämer, the chief HR officer, Marlene Voss, and the Konzernbetriebsrat are invited to the review, and the first report is due on 30 April 2031.

The two commissions share a question and differ in setting. Nordvik's CIO answers through a regional director to an elected executive committee, and the union's representative asked in June 2030 to negotiate before the pilot is extended. Hansa's group CIO answers to an executive board whose duties under DORA Article 5 are written for ICT risk and are silent on a dashboard of AI-assisted lines. In both, the first finding of the inventory above would be the same: the organisation has a decision for the tool and none for the ownership of the change it took part in.

Summary

This chapter introduced the book on its own terms. The earlier volumes governed, secured, defended, operated and led what developers build, and none took the developer as its subject. The book asks what the developer role becomes when AI is used broadly across the organisation, and it concerns all five functions of the developer loop: D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward.

Three reasons make it a book. Development has always been partly translation, and AI does cheaply the part that was the translation into code, leaving the framing, the proving and the owning. The evidence on AI in software development is young, mixed and narrow, so the book separates what studies measured from what is claimed: a faster task in one experiment, more completed tasks in field experiments and slower work for experienced developers in their own codebases are three results, not one. And European law assigns duties to named parties for software, in the AI Act, the Cyber Resilience Act, the Product Liability Directive, NIS 2 and DORA, while saying nothing about the record that would show who owns a change that AI took part in. The thesis has five parts: the developer is transformed and not abolished; delegation is graded and has a ceiling; verification becomes the scarce skill and the junior pipeline is rebuilt; AI may draft, generate, refactor and, within a mandate, execute, but may not own, with the test oracle independent of the generator; and productivity, quality and competence are claims that need evidence.

The chapter defined the six usage modes and the five degrees of delegation that the book uses throughout, gave the rules that bind every chapter, introduced Nordvik Region and Hansa Mutual with the two cases that open the book, and set out reading paths for each audience. It left the reader with one practical task: the inventory of where AI already takes part in a team's development work, and a delegation profile for one team.

Chapter 2 asks what developers did before AI: the history of how development organised itself, which scarcity each practice answered, and what the evidence says developers actually do with their time.

Sources

  1. European Parliament and Council of the European Union. 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. 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. 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. Regulation (EU) 2016/679 (General Data Protection Regulation). Official Journal of the European Union, 4 May 2016. (4, European Union, 2016)
  5. Federal Republic of Germany. Betriebsverfassungsgesetz (BetrVG), section 87 (Mitbestimmungsrechte). Federal Ministry of Justice, gesetze-im-internet.de. (9, Germany, n.d.)
  6. Sveriges riksdag, Regeringskansliet. Lag (1976:580) om medbestämmande i arbetslivet (MBL), 10 to 12 §§. Svensk författningssamling. (12, Sveriges riksdag & Regeringskansliet, 1976)
  7. Eurostat (2025). 20% of EU enterprises use AI technologies. Eurostat news item, European Commission, 11 December 2025. (80, Eurostat, 2025)
  8. 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)
  9. Elish, M. C. (2019). Moral Crumple Zones: Cautionary Tales in Human-Robot Interaction. Engaging Science, Technology, and Society 5, 40-60. (49, Elish, 2019)
  10. 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)
  11. 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)
  12. Dell'Acqua, F. et al. (2023). Navigating the Jagged Technological Frontier. Harvard Business School Working Paper 24-013. (81, Dell'Acqua et al., 2023)
  13. Lee, H.-P. et al. (2025). The Impact of Generative AI on Critical Thinking. Proceedings of the 2025 CHI Conference, Article 1121. (82, Lee et al., 2025)
  14. Nordqvist, G. (2025). Architecture as Code. The Architecture as Code Series, Book 1. (161, Nordqvist, 2025)
  15. Nordqvist, G. (2026). AI Governance. The Architecture as Code Series, Book 2. (162, Nordqvist, 2026)
  16. Nordqvist, G. (2026). AI Platform and Security. The Architecture as Code Series, Book 3. (163, Nordqvist, 2026)
  17. Nordqvist, G. (2026). AI Red Team. The Architecture as Code Series, Book 4. (164, Nordqvist, 2026)
  18. Nordqvist, G. (2026). AI Threat. The Architecture as Code Series, Book 5. (165, Nordqvist, 2026)
  19. Nordqvist, G. (2026). The Transformed Security Architect. The Architecture as Code Series, Book 6. (166, Nordqvist, 2026)
  20. Nordqvist, G. (2026). AI Boss. The Architecture as Code Series, Book 7. (167, Nordqvist, 2026)
  21. Nordqvist, G. (2026). AI Blue. The Architecture as Code Series, Book 8. (168, Nordqvist, 2026)
  22. Nordqvist, G. (2026). AI Purple. The Architecture as Code Series, Book 9. (169, Nordqvist, 2026)
  23. Nordqvist, G. (2026). AI Operations. The Architecture as Code Series, Book 10. (170, Nordqvist, 2026)
  24. Nordqvist, G. (2026). AI Leader. The Architecture as Code Series, Book 11. (174, Nordqvist, 2026)
  25. 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)
  26. Cui, Z. (K.) et al. (2024). The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. SSRN 4945566. (176, Cui et al., 2024)
  27. GitClear (2025). AI Copilot Code Quality: 2025 Look Back at 12 Months of Data. (177, GitClear, 2025)
  28. Brooks, F. P. (1995). The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition. Addison-Wesley Professional. (215, Brooks, 1995)
  29. Google Cloud, DORA (2024). Accelerate State of DevOps Report 2024. DevOps Research and Assessment (DORA) programme. (216, Google Cloud, 2024)
  30. Stack Overflow (2025). 2025 Stack Overflow Developer Survey. (217, Stack Overflow, 2025)
  31. Veracode (2025). October 2025 Update: GenAI Code Security Report. (229, Veracode, 2025)
  32. European Parliament and Council of the European Union. Regulation (EU) 2024/2847 (Cyber Resilience Act). Official Journal of the European Union, 20 November 2024. (242, European Union, 2024)
  33. European Parliament and Council of the European Union. Directive (EU) 2024/2853 on liability for defective products. Official Journal of the European Union, 18 November 2024. (243, European Union, 2024)
  34. 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)