Conclusion: The Developer with AI Judged

Thirty-two chapters have built a thesis, tested its parts one function at a time and shown it in two organisations. This chapter judges it. It concerns all five functions of the developer loop, D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward, because a conclusion that favoured one would misdescribe a loop whose five functions hold one another up. The judgement rests on the evidence the book gathered, which is narrower than the claims that circulate about developers and AI. It also says what would show the thesis wrong, whether anything seen so far does, what the author projects beyond the evidence, and what a reader can do on Monday with records an organisation already has.

Figure 33.1: The thesis judged: five parts, five labels.

How the judgement is made

The book uses three labels for every statement about the future, taken from AI Governance, Chapter 22 (162, Nordqvist, 2026). A statement is observable when it describes something happening now and documented in a source the book opened, expected when it follows from a stated trend or from an instrument that has been decided, and speculation when it is plausible and unevidenced. This chapter adds a discipline to those labels. Where an earlier chapter called something observable, the chapter asks what exactly was observed, in whom, on which task and in which year, and whether the observation bears on developers in a European enterprise or public authority. Most of what the book found is observable about a task, a codebase or a cohort, and its bearing on the organisations in the book is the book's own inference.

The word "established" is used below only for what is both observable and in force: a duty written in an instrument, a documented failure, a measured effect with its limits. No part of the thesis as a whole is established in that sense: the evidence supports mechanisms and premises more than outcomes.

A second discipline concerns the book's own conventions. The evidence clocks of Chapter 20 (90 days for usage, 180 days for value), the starting levels of the delegation profiles, the review budget of Chapter 14 and the AI-off share of Chapters 13 and 28 are recommendations, chosen to be reviewable; no study measured them.

The thesis, part by part

Part 1: the developer is transformed, not abolished

The claim is that the typing of code shrinks and the weight of the role moves to framing the problem (D1), deciding the constraints (D2), directing what is built (D3), proving that it is right (D4) and owning it over time (D5).

What is established. Assistants take defined tasks, and the effect depends on the task, the person and the codebase. In a controlled experiment in which developers wrote an HTTP server in JavaScript, those with an assistant finished 55.8 per cent faster (175, Peng et al., 2023). In three field experiments with 4,867 developers, completed tasks rose by 26.08 per cent in the pooled estimate, with wide variation between settings (176, Cui et al., 2024). In a randomised trial of 16 experienced open-source developers working in their own mature repositories, 246 tasks took 19 per cent longer with AI, although the developers had forecast a saving of 24 per cent and afterwards believed they had saved 20 per cent (63, Becker et al., 2025). These are three results and not one. They are consistent with a single reading that the book relies on: the task is the unit of analysis, and the felt effect and the measured effect can point in opposite directions. The legal premise is established as well. None of the development provisions read in Chapter 24 distinguishes code written by a person from code written with an assistant, and each attaches a duty to a named party: the manufacturer under the Cyber Resilience Act (242, European Union, 2024), the producer under Directive (EU) 2024/2853, which treats software as a product (243, European Union, 2024), the entity under NIS 2 Article 21(2)(e) (3, European Union, 2022) and the deployer of a high-risk AI system under Article 26 of the AI Act (1, European Union, 2024). "Not abolished" is partly a statement of law.

What is expected. That the weight of the work moves towards D1, D4 and D5 is expected, and it is the book's own reasoning from the unbundling of the work (Chapters 2, 5 and 9), not a measurement. The adoption on which the expectation rests is observable: 84 per cent of the respondents to the 2025 Stack Overflow survey said they use or plan to use AI tools, and about a third said they trust the accuracy of the output, in a survey of self-selected respondents (217, Stack Overflow, 2025). That total employment in software roles in the EU does not fall by 2036 is expected on the evidence of a decade of growth, with more than 10 million ICT specialists employed in 2025 and growth of 59.4 per cent from 2015 to 2025 against 9.8 per cent for employment overall (73, Eurostat, 2026), and on a statistical agency's projection for the United States of 10 per cent growth in the occupation from 2025 to 2035 (72, U.S. Bureau of Labor Statistics, 2026). The Eurostat group is wider than software developers, and the projection concerns another continent.

What is speculation. The size of a development organisation in 2036, whether specifications replace code as the main artefact, and whether the share of code written by people falls to a low figure. A chief executive's statement that more than a quarter of new code at one company was generated by AI (45, Pichai, 2024) is a count of origin, not of value, owner or defect.

Where the evidence is thin. The thesis speaks of a transformation of the role. What the book can document is use, task effects and entry-level hiring. No study the book opened follows the work of practising European developers across years. The one randomised trial on experienced developers had a follow-up whose own authors judged the signal unreliable, because developers declined to submit tasks they did not want to do without AI (186, METR, 2026).

Verdict. The direction is expected and the pace is speculation. The description is plausible and consistent with what was found, and it has not been tested against organisational outcomes.

Part 2: delegation is graded and has a ceiling

The claim is that every class of development work has a degree of delegation set by reversibility, reach, who is affected, the evidence for the tool and the strength of the independent checks, and that Level 4 Autonomous is never used for five kinds of change: a change to production without a gate the change itself cannot alter; code in a security-critical or safety-critical path without human review by a named developer; a change to the agent's own mandate, permissions, credentials, test oracles, review rules or pipeline gates; an irreversible action on production data; and a decision about a named person's employment, pay, performance rating or access to work.

What is established. Each prohibition has a footing outside the book, though not each in the same kind of ground. The first rests on the requirement of controlled, recorded and approved change that DORA Article 9(4)(e) places on financial entities (2, European Union, 2022) and on the documented failures of release paths in which the check shared the assumption of what it checked or did not exist: the CrowdStrike content update of 19 July 2024, in which a content template defined 21 input fields while the code that used it supplied 20, and the mismatch passed validation and testing partly because the tests used a wildcard for the 21st field (28, CrowdStrike, 2024), and Knight Capital in 2012, where a deployment reached one of eight servers, the firm had no second technician reviewing it and the attempted remedy made matters worse, for a loss above USD 460 million in about 45 minutes (29, U.S. Securities and Exchange Commission, 2013). Neither involved AI. They show what AI-era volume makes more likely, which is the book's inference. The second rests on Article 21(2)(e) of NIS 2 and on the Cyber Resilience Act's requirement of due diligence on components in Article 13(5) (242, European Union, 2024). The third rests on the evidence that errors are correlated across models, so that a second model is not an independent check by default: across more than 350 models, two models agreed about 60 per cent of the time when both were wrong on one leaderboard dataset, on tasks that were not software tasks (35, Kim et al., 2025). The fifth rests on the employer's duties towards employee representatives (Chapter 22) and on the treatment of employment and worker-management decisions in Annex III, point 4, of the AI Act (1, European Union, 2024).

What is expected. That the ceiling holds while the instruments stand. That Level 3 Bounded is used for narrow, mechanical, reversible classes under a recorded mandate with a gate the change cannot alter: in the book's illustration, Hansa Mutual's patch-level dependency updates under MND-HM-DEV-01 (Chapters 8 and 29).

What is speculation. That a ceiling should be raised on any particular evidence, and that agents will merge broad classes of ordinary code, or code in security-critical paths, with better outcomes than a person-gated process. Chapter 8 found no evidence that supports it.

Where the evidence is thin. The levels in the starting profiles are the author's recommendation. No study measures the levels of a delegation profile against outcomes. The studies of AI-generated security that Chapter 10 drew on cut in different directions and concern tools of 2021 and 2022: roughly 40 per cent of 1,689 programs vulnerable in one (228, Pearce et al., 2021), less secure code and more confidence in another (34, Perry et al., 2023), and risky flaws in 45 per cent of a vendor's 2025 tests (229, Veracode, 2025).

Verdict. The ceiling is firm where law and documented failure make it firm and recommended where it is the author's design. A reader who finds a good reason to raise a level has the means in the book, a recorded decision by a named authority with evidence, an expiry and a stop path outside the pipeline, and has not found a reason to doubt the prohibitions that rest on instruments.

Part 3: verification becomes the scarce skill, and the junior pipeline must be rebuilt

The claim is that code is cheap to produce and expensive to trust, that review, tests and specification absorb the cost, and that the entry-level tasks that taught the craft are the tasks AI performs best, so that an organisation which removes them without a replacement route has no future seniors.

What is established. The pressure on the entry route is observable, with the qualifications its authors give. Payroll data for the United States show employment of workers aged 22 to 25 in AI-exposed occupations 19 per cent below where it would have been had it kept pace with less-exposed peers, with the adjustment running through reduced hiring and not through separations, in a working paper whose authors call the results descriptive (51, Brynjolfsson et al., 2025). A study linking Danish surveys to administrative records found precise null effects on earnings and recorded hours two years after the launch of ChatGPT, ruling out effects larger than 2 per cent, for exposed occupations in general and not for junior developers (53, Humlum & Vestergaard, 2025). Learning beside an assistant depends on how it is used: in a preregistered preprint with 52 participants, the assisted group scored 4.15 points lower out of 27 on an unassisted quiz about a new library, 17 per cent, and some patterns of use preserved learning (67, Shen & Tamkin, 2026). In an experiment with nearly 1,000 school pupils, unguarded access raised performance on practice problems, by 48 per cent for one version of the tool, and lowered later unaided performance by 17 per cent (66, Bastani et al., 2025). The volume problem is arithmetic that Chapter 9 sets out: when generation is cheap, review capacity bounds the merge rate, and the choice is a visible cap or an invisible thinning.

What is expected. That organisations which cut the junior intake without a replacement route will have fewer developers able to supervise generated code in a few years, because the decline is a decision by employers (Chapter 13). That review capacity becomes the constraint in teams with a large volume of generated change (Chapters 9 and 14). The survey associations support the direction without proving it: the DevOps Research and Assessment (DORA) programme's 2025 report associated AI adoption with higher delivery throughput and with continuing lower delivery stability (42, Harvey & DeBellis, 2025).

What is speculation. That the junior role disappears, and equally that juniors who use assistants learn faster than their predecessors. No study measured either.

Where the evidence is thin. This is the part with the most inference between evidence and claim. The learning studies concern pupils and 52 programmers for one session, and the book found no study of a designed apprenticeship, in either direction. Skill loss after sustained use of an aid is observable in other domains, in the manual flying of 16 airline pilots (64, Casner et al., 2014) and in endoscopists whose detection rate in colonoscopies without AI fell from 28.4 to 22.4 per cent after exposure (65, Budzyń et al., 2025), and Chapter 28 found no study that followed practising developers over years. The design of Chapter 13 (attempt first, review first, AI-off practice, ownership of a small change with a revert drill) is the book's own conclusion from mechanism.

Verdict. Conditional. The pressure on the route is observable and the case for a designed route stands without waiting for the dispute about size to be settled. The part holds as a design rule and not as a finding about outcomes, because there is none.

Part 4: the stewardship principle

The claim is that AI may draft, generate, refactor and, within a mandate, execute, and may not own. For every change in production a named developer or team passes three tests: Name (the owner is identifiable in the code-ownership record), Understand (the owner can explain the change and reconstruct it without the tool) and Revert (the owner has the authority, access and time to stop or roll back, outside the pipeline that shipped it). Its corollary is that the test oracle must be independent of the generator.

What is established. The mechanism of failure is documented without AI. The release path fails where the gate sits inside what it governs, where a name is trusted and not checked, and where a count replaces an outcome (Chapter 30). A researcher who registered an empty package under a name that models had hallucinated counted more than 30,000 authentic downloads over three months (241, Lanyado, 2024), which is trust in a name that no one checked. In the book's own illustration, INC-HM-2029-0207, in which 312 claims were paid twice in June 2029, failed Name and Understand before any assistant was in use, and OWN-NR-2030-00 found that 31 per cent of Nordvik Region's 96 repositories had an owner who had left the Region or changed team. Chapter 23 reads incidents as questions about the system: who owned the change, what the tool did, whether the oracle was independent, and who could stop the change and how long that took. Legal form is found in Chapter 24: Article 13(5) of the Cyber Resilience Act asks for due diligence on every integrated component (242, European Union, 2024), and under Article 25(1)(c) of the AI Act a change of intended purpose can make a deployer the provider of a high-risk AI system (1, European Union, 2024).

What is expected. That supervisors, auditors and, in a dispute, courts ask who was named, who could explain and who could revert, once the Cyber Resilience Act applies from 11 December 2027 and the Product Liability Directive applies to products placed on the market after 9 December 2026 (242, European Union, 2024) (243, European Union, 2024). That organisations which can answer from records dated before the event are treated differently from those which reconstruct afterwards is the author's projection (Q2 below).

What is speculation. That an organisation could meet a duty attached to a named party with an owner who cannot reconstruct the change.

Where the evidence is thin. The principle is supported by cases and by arguments. The claim that an independent oracle yields better outcomes rests on the correlated-error result for models (35, Kim et al., 2025) and on mechanism, and the book found no study that compares outcomes with and without an independent oracle in software. The Understand test assumes that an owner could pass it before AI, and the book found no baseline for that in the literature. Chapter 12 proposes the inventory with named owners and recorded conversations with the people who hold the theory of the system as the means of taking one.

Verdict. Strongest as a design principle and best supported by the failures it would have prevented. It is untested as a predictor of better outcomes. The corollary about the oracle is one of the two propositions the thesis names as refutable, and it is the one the author would most like to see tested.

Part 5: productivity, quality and competence are claims that need evidence

The claim is that "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, that acceptance rate is not productivity, that evidence expires, and that craft decays if it is not exercised.

What is established. Of the five parts this one has the most direct support, because it is partly a method. Perceived and measured effects diverge in the randomised trial (63, Becker et al., 2025). Vendor and consultancy figures describe what their authors have an interest in (Chapters 3 and 20), and the two organisations' dashboards show how a figure changes on its way upwards. Nordvik Region's "a third faster" rested on a 31 per cent acceptance rate among 12 pilot developers, a survey answered by 9 of them and no measurement of delivery time, and it was written into a note to the executive committee in April 2030 (AVR-NR-2030-01). Hansa Mutual's quoted 42 per cent of committed lines as AI-assisted became 27 per cent in a sample of 40 merged pull requests in August 2030, by a count that could be verified for that sample (AVR-HM-2030-01). Both are illustrations, not evidence about real organisations.

What is expected. That claims expire faster than organisations re-measure them, and that boards and supervisors ask for the method and date behind adoption claims. Management bodies of financial entities already oversee ICT risk under DORA Article 5 (2, European Union, 2022).

What is speculation. That developers who keep a measured practice will verify better, and that competence records of the kind Chapter 27 specifies predict anything. The studies the chapter reads show that confidence and measured performance diverge, and none measures the records it proposes.

Where the evidence is thin. The 90-day and 180-day clocks are conventions, and the right share of AI-off practice is a design choice that the evidence does not fix.

Verdict. This part holds, and its force is that it can be checked in an afternoon against an organisation's own records, which is why the Monday actions below begin with the records and not with the tools.

The scorecard

The table gathers the verdicts; the sections above carry the detail.

Part of the thesis	Established	Expected	Speculation	Thinnest point
1. Transformed, not abolished	Task effects depend on task, person and codebase; duties name parties	Weight moves to D1, D4, D5; EU software employment holds	Pace; size of the organisation in 2036; specifications replace code	No study of practising European developers across years
2. Graded delegation, ceiling	Prohibitions anchored in instruments and documented release failures	Level 3 Bounded for narrow, reversible classes	Any case for Level 4 on the five prohibited kinds	Levels are the author's design; no outcome data
3. Verification scarce, junior route rebuilt	Hiring of the youngest lower in exposed US occupations; unguarded assistance reduced learning in experiments	Thin supply of seniors without a designed route; review capacity binds	The junior disappears; juniors learn faster	No study of a designed apprenticeship
4. Stewardship	Failure mechanism documented, with and without AI; duties name parties	Supervisors and courts ask Name, Understand, Revert	Accountability without an able owner	Understand has no pre-AI baseline; oracle independence rests on mechanism
5. Claims with evidence	Gaps between perceived and measured; dashboard gaps	Claims lapse faster than re-measurement	Competence records predict quality	Clocks are conventions

Where the book's evidence is thin

The thesis is stronger where it asks for records and weaker where it predicts outcomes. Each item is a gap in what the book found, not necessarily in the world.

• Experienced developers over years (Chapters 7 and 20). One randomised trial of 16 developers, a follow-up that its authors call unreliable, and field experiments over short periods.
• Code health (Chapter 12). One observational study, one small randomised task and vendor material, including a report on 211 million changed lines classified by the vendor (177, GitClear, 2025); associations that cannot carry causal claims.
• Secure code (Chapter 10). Studies of particular tools in 2021 and 2022 and a vendor report; the models have been replaced since.
• Review under volume (Chapter 9). The caps, seeded defects and rotation proposed are design measures; the book found no measurement of their effect.
• A designed apprenticeship (Chapter 13). None found.
• The developer's own skill over years (Chapter 28). No study followed practising developers; the evidence comes from pilots, endoscopists, pupils and one short experiment.
• Agent-heavy teams (Chapter 29). No organisation has published twelve months of data on a unit with a small number of named stewards for a large number of agent-authored changes.
• Works agreements (Chapter 22). The evidence that agreements on developer tooling improve outcomes is thin, and the argument for them is from mechanism.
• The law applied to in-house, bought and published software (Chapters 24 and 26). The readings are the book's own, several points could not be verified, and no court in the Union has ruled on copyright in generated code.
• Citizen builds (Chapter 19). Self-reported and correlational evidence on bans and shadow use.

Two patterns run through the list. The studies are about tasks, cohorts, students, clinicians, pilots and a single vendor's telemetry, and the book carries their findings to developers in European organisations by inference. And the book's two organisations are fictional: they show what the instruments look like in use, not that they work. Chapter 31 follows named developers through a year and Chapter 32 draws conclusions for the two organisations; they are illustrations in the same sense.

What would show the thesis wrong

The thesis names two kinds of evidence that would refute it. The first is 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. The second is evidence that developers who never write or read code by hand develop the judgement to verify it as well as those who do. Chapter 29 adds five thresholds that would change the author's projections: a falling series for ICT specialists in two consecutive years; a multi-year outcome study showing that juniors trained mostly with the tool reach independent review as fast as those trained with deliberate unassisted periods; twelve months of published data on a unit with few stewards and many agent-authored changes; evidence that review of specifications finds fewer defects per hour than review of code, or that an independent oracle cannot be made in practice; and an amendment or ruling that lets an AI system hold a duty the instruments assign to a party.

The book found nothing that meets either bar. The randomised trial of experienced developers cuts against a strong claim of speed in their own codebases, and the field experiments that found gains cut against nothing in the thesis, which does not deny that tasks go faster. The one success case read in Chapter 30, the Google migrations (267, Nikolov et al., 2025), shows the opposite practice from the failures: a named engineer, review by the owners of the code, humans who reverted what was wrong and a measure of time saved on the whole job. It counts for the thesis only weakly, because a single success is a poor basis for a general claim.

The thesis has not been refuted, and it could not have been by the evidence the book gathered, because that evidence does not reach the outcomes the refutation requires. What would test it is the kind of data that the book's own records would produce if organisations kept them for several years.

A third challenge comes from inside the book. A critic could say that few developers ever passed Understand for a legacy module without the colleague who wrote it, so that the standard measures AI against a past that did not exist. The book accepts the point as a reason to take a baseline before the tools arrive, not to lower the standard.

The author's projections

What follows is the author's own projection, labelled as such. It extends P1 to P5 of Chapter 29, goes beyond the evidence, is offered so that it can be refuted, and was written in November 2026.

Q1 (author's projection, expected). The first independent evidence to arrive will concern oracles and review, and the last will concern ownership and code health. Whether a test written by the generating model catches seeded defects as often as an independent oracle can be tested in experiments of weeks, and several groups will run them. Ownership and code health need years of records that few organisations keep. An organisation that keeps its ownership inventory dated from now on will hold evidence that does not yet exist elsewhere.

Q2 (author's projection, expected). The first public examination of a failure in software that an AI system took part in changing, under the Product Liability Directive or the Cyber Resilience Act, will be conducted as an examination of ownership and of the release path, not of the model. The questions will be who was named, who could explain and who could revert. The timing is speculation: neither instrument applies to the products concerned before the dates given above, and the first decisions will follow later.

Q3 (author's projection, expected). Level 3 Bounded will be where the ladder is first raised, in mechanical, reversible and well-covered classes such as dependency patches, formatting, generated documentation and test-data maintenance, each with a gate the change cannot alter. The ceilings will rise by class, on recorded evidence, and not by product. The prohibitions will stay where they are.

Q4 (author's projection, speculation). Supervisors and auditors will begin to ask for evidence of unaided exercise, a revert drill with the agent switched off, as they now ask for evidence of a recovery test. It is speculation, because no instrument the book read requires it. The author expects the question to arrive first in financial supervision, where the duties for testing and for change are written most precisely, and does not know when.

Q5 (author's projection, speculation). The share of generated code will disappear from board reports within a few years of becoming the headline figure, replaced by measures of outcome with a method and a date, after a few episodes in which it has misled. The date is a guess. If the figure becomes a regulated or contractual measure, the author will withdraw the projection.

What would change these projections is the list of thresholds above. Add one more for Q1: if by the end of 2028 several independent studies report that tests and reviews written by a model for its own output verify as well as those written independently, the author will withdraw the corollary of the stewardship principle. The author sets the review of these verdicts for 11 November 2027, one year after this chapter was written.

Five things to do on Monday

Each of the five actions belongs to one function and needs records an organisation already has; each takes under an hour to begin.

1. D1 Frame. Take the last feature that shipped. Find the sentence that states the intent and the acceptance criterion that could fail. List every requirement that was recorded as an assumption, and give each an owner and a date, or an acceptance criterion, before the next release. Count the requirements whose source nobody can name (Chapters 5 and 23).
2. D2 Design. Choose one constraint that exists in no file, such as a boundary between two components that everybody knows. Write it as a decision record, with the five fields for AI involvement, and derive one rule that the pipeline can check, owned by someone other than the generator and beyond the reach of any agent (Chapter 6).
3. D3 Build. For the assistant or agent already in use, write one row of a delegation profile per work class: the level, the ceiling, who may lower it at once, who may raise it and the stop that sits outside the pipeline. Check the row against the five Level 4 prohibitions and test the stop once (Chapters 4 and 8).
4. D4 Prove. Take a closed change and seed one defect in a copy of it. Have a developer review the copy with the assistant's comments hidden, and note whether the defect was found and who wrote the oracle that should have caught it. If a junior reads, it is practice and not the gate (Chapters 9 and 13).
5. D5 Steward. Choose one service. Find its owner in the ownership record, ask for an explanation of the last change without the tool, and time a revert from the decision, with the date and result written down. Put the figure of evidence age next to every claim you make about the service (Chapters 11, 12 and 23).

The five results fill the action fields of the scorecard record below.

The thesis scorecard as a record

The scorecard belongs in version control, as the other records of the book do. It says, for each part of the thesis and each Monday action, what is claimed, on what evidence, how old the evidence is and when it is next read. The example is an AI Decision Record for Hansa Mutual's group CIO at the end of the year of Chapter 31. It is illustrative.

id: AIDR-1183
kind: thesis-scorecard
status: illustrative
decided_by: {role: group CIO, name: Rainer Lehmann}
reviewers: [Dr. Annette Krämer, Konzernbetriebsrat]
as_of: 2031-08-29
next_review: 2032-02-26
parts:
  - part: 1-transformed-not-abolished
    label: expected
    evidence: {record: HZN-HM-2031-01, basis: derived}
    thinnest_point: "no study of practising developers across years"
  - part: 2-graded-delegation
    label: observable
    evidence: {record: DLG-HM-DEV-01, adopted: 2030-09-30, basis: recorded}
    level_4_check: "no work class at Level 4; people class not delegated"
  - part: 3-verification-and-junior-route
    label: expected
    evidence: {record: APR-HM-2030-01, basis: recorded}
    open: "broker team intake reversed 2031-03-28 (illustrative); no outcome data on the apprenticeship plans"
  - part: 4-stewardship
    label: observable
    evidence: {record: OWN-HM-2030-00, basis: recorded, services_without_owner: 14, services: 410}
    corollary: {oracle_independent_of_generator: true, shown_by: seeded_defects}
  - part: 5-claims-with-evidence
    label: observable
    evidence: {record: AVR-HM-2030-01, quoted: 42, sampled: 27, sample_size: 40}
    status: expired                  # sample of 2030-08; re-sampled 2031-08-26, value not measured
monday_actions:
  D1: {owner: Dr. Philipp Reinhardt, due: 2031-09-01, record: none_yet}
  D2: {owner: Dr. Philipp Reinhardt, due: 2031-09-01, record: none_yet}
  D3: {owner: Rainer Lehmann, due: 2031-09-01, record: DLG-HM-DEV-01}
  D4: {owner: Ewelina Maj, due: 2031-09-01, record: VER-HM-2030-0007}
  D5: {owner: Stefan Brückner, due: 2031-09-01, record: OWN-HM-2030-00}
reading:
  rule: "an entry without a closing record is an open item, not a result"
  refutation_tests_seen: 0
  gaps_listed: 10

The record states its own limits: a claim past its expiry is marked expired and not removed, and the field that counts refutation tests seen is zero. A board that reads it should ask whether anyone has looked.

Across the degrees of delegation

The table sets the degrees of delegation against what the book's evidence supports and with which label. It confirms what the profiles of both organisations already show: the book's illustrations go no higher than Level 2 Supervised except for one narrow class at Level 3 Bounded, and that is the finding and not a mere matter of caution.

Degree of delegation	What the book's evidence supports	Label
Level 0 Advisory	Design in both organisations; specify, review and migrate at Nordvik Region	Observable as practice in the illustration
Level 1 Assisted	Generate, refactor and test drafts at Nordvik Region; specify, test drafts and review comments at Hansa Mutual; a developer reads every line and the oracle is not the generator's	Observable
Level 2 Supervised	Documentation in both organisations; at Hansa Mutual generation and refactoring outside the security-critical and payment paths, with a developer reviewing every agent-opened pull request	Observable in the illustration
Level 3 Bounded	Narrow, mechanical, reversible classes with a gate the change cannot alter, such as patch-level dependency updates	Observable for one class in the illustration, expected beyond; no outcome data
Level 4 Autonomous	Never for the five prohibited kinds of change; not recommended elsewhere on the evidence gathered	Prohibitions rest on instruments and design; any wider use is speculation

Nordvik Region and Hansa Mutual

The records of the book are illustrations of how the thesis can be read against an organisation's own evidence, not a test of whether it is true. Chapter 32 draws the conclusions for the two organisations.

Nordvik Region. The head of Applications and Integration, Gunilla Roos, and the CIO, Henrik Dahl, would read five things in the records the book has shown. Part 1 is held in the profile DLG-NR-DEV-01, which keeps generation and refactoring at Level 1 Assisted and specification, design and review at Level 0. Part 2 is held for the people class, which remains undelegated, and for the pilot NR-DEV-001, which was continued to 31 December 2030 and then, under the interim protocol, to 30 June and (in the illustration of Chapter 31) 31 December 2031 with no widening. Part 3 is an open item: the plan APR-NR-2030-01 for Emil Nordgren is an intention with a mentor, Linnea Sjöberg, and a second assessor, Saga Edvardsson, and the intake of two for 2031, confirmed in the profile review of 21 March 2031 (AIDR-1135), is the decision whose evidence is still to come. Part 4 is the weakest: 31 per cent of 96 repositories had no living owner in July 2030, and until the inventory is closed Name cannot be passed for them. Part 5 is the part the Region can fix soonest, because "a third faster" rested on a pilot of 12 developers, a survey of 9 and no measurement of delivery time, and the comparison designed in AVR-NR-2030-01 replaced it, in the illustration of Chapter 31, with "not known". The negotiation MBA-NR-2030-03 with the union representative Tomas Ekblad decides what any of it may collect.

Hansa Mutual. The group CIO, Rainer Lehmann, and the head of Group Application Development, Dr. Philipp Reinhardt, would read a different pattern. Part 5 turned first: 42 per cent became 27 per cent in a sample of 40 pull requests. Part 4 is concentrated in two numbers, 14 of 410 services without an active owner and a COBOL and PL/I estate of about 6.5 million lines kept by twelve people, five of whom are within eight years of retirement, and the horizon register HZN-HM-2031-01 carries the second as a trend with a trigger. Part 2 has the one class at Level 3 Bounded, patch-level dependency updates under MND-HM-DEV-01, which stands only while the people who could verify it are in place (Chapter 27) and which fell to Level 2 for a week when a rehearsal lapsed (Chapter 31). Part 3 shows in APR-HM-2030-01 for Aylin Demir, whose mentor Jörg Albers gives two hours a week, and in the broker interface team that took no apprentices in the 2030 intake, citing the 42 per cent figure, a decision reversed in the illustration of Chapter 31 on 28 March 2031. The Konzernbetriebsrat, represented in the group's developer-tooling annex KBV-IT-2024-DEV-01, is a party to anything the records collect.

Observable, expected, speculation

Observable. The duties that the instruments assign to named parties for software are decided and dated. Assistants take defined tasks, and the effect varies with task, person and codebase, with perceived and measured effects that diverge. Adoption is broad and trust is limited. Employment of the youngest workers in exposed occupations is lower in some American datasets, through fewer hires. Unguarded assistance reduced learning in the experiments that tested it, and skill decay after sustained use of an aid is documented in other domains. Public cases show failures of ownership, of the independence of a gate and of a count that replaced an outcome. Adoption figures without method or date are common.

Expected. The weight of the work moves towards framing, verification and stewardship. Total employment in software roles in the EU holds to 2036. The legal ceiling holds while the instruments stand. Level 3 Bounded is used for narrow, reversible classes under recorded mandates. Review capacity binds in teams with a large volume of generated change. Supervisors and courts ask who was named, who could explain and who could revert. Claims lapse faster than organisations re-measure them. The author's projections Q1 to Q3 are in this class.

Speculation. The size of a development organisation in 2036. The disappearance of the junior role, and the opposite claim that juniors will learn faster. Specifications replacing code as the main artefact. Agent-merged code in security-critical paths with better outcomes than a person-gated process. A model that can own. The author's projections Q4 and Q5.

The series' argument, closed for the developer

The series makes one argument, and the five parts of this thesis are that argument applied to the person who builds. Architecture as Code made rules executable, so that a pipeline can check what a review might miss (161, Nordqvist, 2025). AI Threat concluded that decisions should be records that can be corrected, that the ability to stop should sit outside the system being stopped, that people should stay able to judge the output, and that autonomy should match reversibility (165, Nordqvist, 2026). The Transformed Security Architect described the conductor who verifies what an AI team proposes (166, Nordqvist, 2026). AI Purple turned the argument into the independence principle for a loop that machines could close alone (169, Nordqvist, 2026), AI Operations into the observer principle (170, Nordqvist, 2026), and AI Leader into the answerability principle, in which a named leader passes the tests Name, Explain and Reach (174, Nordqvist, 2026).

The stewardship principle is the same idea at the point where the software is made: every one of those commitments ends at a person who can be named, who can explain the change without the tool and who can stop it. The book has not shown that organisations which build this do better. It has shown what building it requires, what it costs in records and practice, and what evidence would tell the organisations that it was not worth it. That is the limit of the claim, and the author prefers it to a stronger claim the evidence would not carry.

Summary

This chapter judged the five-part thesis of the book against the evidence the book gathered. It concerns all five functions, D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward. The judgement is that the thesis holds as a set of design rules and as a description of mechanisms, that its force is greatest where it asks for records that can be checked, and that it is weakest where it speaks of outcomes. Part 1, the transformation of the role, is expected in direction and speculation in pace, with no study of practising European developers across years. Part 2, the ladder and its ceiling, is firm where instruments and documented failures make it firm and recommended where it is the author's design. Part 3, verification as the scarce skill and the rebuilt junior route, is conditional: the pressure on the entry route is observable, the designed remedy is untested. Part 4, the stewardship principle, is best supported by the failures it would have prevented and is untested as a predictor of better outcomes. Part 5, claims with evidence, holds, because it can be checked against an organisation's own records.

The chapter listed ten places where the book found no study, and said that the two organisations are fictional and show the form of the instruments, not their effect. It named what would show the thesis wrong, and said that nothing seen so far meets that bar, which is a weak form of support. It gave the author's projections, labelled, for review on 11 November 2027, and ended with five things to do on Monday and a scorecard record that carries the age of each piece of evidence.

There is no further chapter of argument. The appendices that follow collect the definitions and the artefacts, and the reader's own organisation is the next place where the thesis is tested.

Sources

1. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Architecture as Code Series, Book 2, published at aig.geon.se. (162, Nordqvist, 2026)
2. Peng, S., Kalliamvakou, E., Cihon, P. & Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv:2302.06590, submitted 13 February 2023. Controlled experiment in which developers were asked to write an HTTP server in JavaScript. (175, Peng et al., 2023)
3. 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; later published in Management Science (DOI: 10.1287/mnsc.2025.00535). Randomised field experiments at Microsoft, Accenture and an anonymous Fortune 100 company with 4,867 developers; the SSRN abstract reports a 26.08 per cent increase in completed tasks. (176, Cui et al., 2024)
4. 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, submitted 12 July 2025, revised 25 July 2025. (63, Becker et al., 2025)
5. European Parliament and Council of the European Union. Regulation (EU) 2024/2847 of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union, 20 November 2024. (242, European Union, 2024)
6. European Parliament and Council of the European Union. Directive (EU) 2024/2853 of 23 October 2024 on liability for defective products and repealing Council Directive 85/374/EEC. Official Journal of the European Union, 18 November 2024. (243, European Union, 2024)
7. 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)
8. 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)
9. Stack Overflow (2025). 2025 Stack Overflow Developer Survey. Stack Overflow, over 49,000 responses from 177 countries; survey of self-selected respondents. (217, Stack Overflow, 2025)
10. Eurostat (2026). ICT specialists in employment. Statistics Explained, European Commission; reference year 2025, data extracted April 2026. Reports more than 10 million ICT specialists employed in the EU in 2025, 5.0 per cent of total employment, 19.5 per cent of them women, and growth of 59.4 per cent from 2015 to 2025 against 9.8 per cent for total employment; ICT specialists are a wider group than software developers. (73, Eurostat, 2026)
11. U.S. Bureau of Labor Statistics (2026). Occupational Outlook Handbook: Software Developers, Quality Assurance Analysts, and Testers. U.S. Department of Labor; page last modified 27 August 2026. Projects employment of this combined occupation to grow 10 per cent from 2025 to 2035 (185,400 jobs, from 1,905,400 jobs in 2025) and names continued expansion of software development for AI among the drivers; a projection by a statistical agency for the United States, not a measurement. (72, U.S. Bureau of Labor Statistics, 2026)
12. Pichai, S. (2024). Q3 earnings call: CEO's remarks. Google, 29 October 2024. (45, Pichai, 2024)
13. METR (Becker, J., Rush, N., Cunningham, T., Rein, D. & Mahamud, K.) (2026). We are Changing our Developer Productivity Experiment Design. METR blog, 24 February 2026. Reports a second study with 57 developers, 143 repositories and more than 800 tasks, and states that it gives an unreliable signal of the current productivity effect because developers declined to submit tasks they did not want to do without AI. (186, METR, 2026)
14. 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)
15. CrowdStrike (2024). External Technical Root Cause Analysis: Channel File 291, 6 August 2024; and Falcon Content Update Preliminary Post Incident Review, 24 July 2024 (updated 25 July 2024). (28, CrowdStrike, 2024)
16. U.S. Securities and Exchange Commission (2013). In the Matter of Knight Capital Americas LLC. Order Instituting Administrative and Cease-and-Desist Proceedings, Release No. 34-70694, File No. 3-15570, 16 October 2013. (29, U.S. Securities and Exchange Commission, 2013)
17. 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)
18. Pearce, H., Ahmad, B., Tan, B., Dolan-Gavitt, B. & Karri, R. (2021). Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions. arXiv:2108.09293, submitted 20 August 2021, revised 16 December 2021; accepted at the IEEE Symposium on Security and Privacy 2022 according to the arXiv page. (228, Pearce et al., 2021)
19. 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 (CCS '23); arXiv:2211.03622. (34, Perry et al., 2023)
20. Veracode (2025). October 2025 Update: GenAI Code Security Report. Veracode; code from over 100 large language models in Java, JavaScript, Python and C#, with AI-generated code introducing risky security flaws in 45 per cent of tests; vendor research. (229, Veracode, 2025)
21. Brynjolfsson, E., Chandar, B. & Chen, R. (2025, revised 12 August 2026). Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence. Stanford Digital Economy Lab. (51, Brynjolfsson et al., 2025)
22. Humlum, A. & Vestergaard, E. (2025). Still Waters, Rapid Currents: Early Labor Market Transformation under Generative AI. NBER Working Paper 33777, May 2025, revised March 2026 (circulated earlier as "Large Language Models, Small Labor Market Effects"). (53, Humlum & Vestergaard, 2025)
23. Shen, J. H. & Tamkin, A. (2026). How AI Impacts Skill Formation. arXiv:2601.20245, submitted 28 January 2026, revised 1 February 2026 (preprint, not peer reviewed). (67, Shen & Tamkin, 2026)
24. Bastani, H., Bastani, O., Sungu, A., Ge, H., Kabakcı, Ö. & Mariman, R. (2025). Generative AI without guardrails can harm learning: Evidence from high school mathematics. Proceedings of the National Academy of Sciences 122(26), e2422633122. DOI: 10.1073/pnas.2422633122 (accessed 2026-11-10). (66, Bastani et al., 2025)
25. 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)
26. Casner, S. M., Geven, R. W., Recker, M. P. & Schooler, J. W. (2014). The Retention of Manual Flying Skills in the Automated Cockpit. Human Factors 56(8), 1506-1516. DOI: 10.1177/0018720814535628 (accessed 2026-11-10). (64, Casner et al., 2014)
27. Budzyń, K., Romańczyk, M. et al. (2025). Endoscopist deskilling risk after exposure to artificial intelligence in colonoscopy: a multicentre, observational study. The Lancet Gastroenterology & Hepatology 10, 896-903. DOI: 10.1016/S2468-1253(25)00133-5 (accessed 2026-11-11; figures read in the PubMed abstract, PMID 40816301: adenoma detection rate 28.4% [226/795] before and 22.4% [145/648] after, four centres in Poland, retrospective observational). (65, Budzyń et al., 2025)
28. Lanyado, B. (2024). Lasso Research: AI Package Hallucinations. Lasso Security blog, post dated 28 March 2024 (the page also carries a site date of 2026 in its metadata); primary account by the researcher of an experiment in which he registered an empty package under a name that models had hallucinated and counted downloads over three months, reporting more than 30,000 authentic downloads and a reference in the README of an Alibaba research repository; it reports no malicious use. (241, Lanyado, 2024)
29. GitClear (2025). AI Copilot Code Quality: 2025 Look Back at 12 Months of Data. GitClear research report on 211 million changed lines of code authored between January 2020 and December 2024; vendor research using the vendor's own classification of changed lines. (177, GitClear, 2025)
30. Nordqvist, G. (2025). Architecture as Code. The Architecture as Code Series, Book 1, published at aac.geon.se. (161, Nordqvist, 2025)
31. Nordqvist, G. (2026). AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. The Architecture as Code Series, Book 5, published at aithreat.geon.se. (165, Nordqvist, 2026)
32. Nordqvist, G. (2026). The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. The Architecture as Code Series, Book 6, published at tsa.geon.se. (166, Nordqvist, 2026)
33. Nordqvist, G. (2026). AI Purple: How Red and Blue Learn Together When AI Joins the Loop in European Enterprises and Public Authorities. The Architecture as Code Series, Book 9, published at aipurple.geon.se. (169, Nordqvist, 2026)
34. Nordqvist, G. (2026). AI Operations: How Artificial Intelligence Transforms IT Operations in European Enterprises and Public Authorities. The Architecture as Code Series, Book 10, published at aiops.geon.se. (170, Nordqvist, 2026)
35. Nordqvist, G. (2026). AI Leader: How Leadership Roles Change When AI Is Used Broadly in European Enterprises and Public Authorities. The Architecture as Code Series, Book 11, published at leader.geon.se. (174, Nordqvist, 2026)
36. Nikolov, S., Codecasa, D., Sjovall, A., Tabachnyk, M., Chandra, S., Taneja, S. & Ziftci, C. (2025). How is Google using AI for internal code migrations? arXiv:2501.06972, submitted 12 January 2025. Experience report on LLM-assisted migrations in Google's monorepo; the savings figures are estimates reported by the engineers who did the work. (267, Nikolov et al., 2025)