Cover of AI Developer

Book 12 · Workbook

AI Developer

Objectives, key concepts, discussion questions, exercises and self-tests for every lesson, on one page to print.

7 modules33 lessons

The course

All courses / AI Developer / Workbook

How to use this workbook

The workbook follows the course on AI Developer lesson by lesson. Read the chapter (or its whitepaper) before each lesson, bring the workbook to the session and keep what you produce in the exercises: they add up to the final assignment.

After the course you can

Module 1 · Part I · The Developer Role in Question

Part I asks what a developer is for when AI writes, reviews, tests and deploys code across the organisation. It sets out the five-part thesis, the history of practices and the scarcity each answered, the five pressures and the grade of evidence behind each, and the frame of the book: five developer functions, ten classes of work, the delegation ladder with its Level 4 prohibitions, and the stewardship principle. Participants leave able to write a delegation profile for one team.

Chapter 1 · 75 minutes

Introduction: The Developer with AI

The lesson introduces the question of the book: what the developer role becomes when AI takes part in development across the organisation. Participants meet the two opening cases, the five-part thesis and what would show it wrong, the six usage modes and five degrees of delegation as they appear in a developer's work, and the first artefact of the book, an inventory of where AI already takes part in one team's work.

Learning objectives

  • Explain the five parts of the working thesis and state the evidence that would show it wrong
  • Classify a team's AI tools by usage mode and by degree of delegation, keeping the two axes apart
  • Compare what three widely quoted productivity studies measured and why their results do not contradict each other
  • Draft an inventory of where AI already takes part in one team's development work

Key concepts

Essential and accidental difficulty
Brooks's distinction between the specification, design and testing of a conceptual construct and the difficulty of representing it in a language and a machine. The chapter argues that generative AI makes the translation into code cheap and leaves knowing what to build, proving it and answering for it.
The working thesis
Five claims of the book: the developer is transformed, not abolished; delegation is graded and has a ceiling; verification becomes the scarce skill and the junior pipeline must be rebuilt; AI may not own; and productivity, quality and competence are claims that need evidence.
Usage mode and degree of delegation
Two different axes. A mode, from Mode 0 Ambient AI to Mode 5 Autonomous production agents, says how the system reaches the developer. A degree, from Level 0 Advisory to Level 4 Autonomous, says how much of the work has been handed over.
A ceiling is not a licence
The level in a delegation profile is the highest degree allowed for a class of work, not an instruction to work at that degree. The Nordvik Region profile DLG-NR-DEV-01 states this as a field of its own.
Inventory of AI in a team's work
The first artefact of the book: a list of every place where code, tests, text or a decision was suggested, generated, reviewed or executed by an AI system, with mode, work class, degree, who approves and who owns. An inventory that finds nothing is more likely incomplete than clean.

Interactive exercises

  • Match: Where a developer meets each usage mode
  • Scenario: The inventory that found almost nothing

Done on the lesson page, with feedback at once.

Discussion

  1. In the two opening cases, what exactly is missing: a record, an owner, or the owner's understanding, and how would you tell the difference in your own team?
  2. Which of the five parts of the thesis do you find least convincing, and what evidence would change your view in either direction?
  3. Much AI reaches developers as a feature switched on by an update. How should an organisation take a decision about something that has already arrived?

Exercise · 25 minutes

Inventory where AI already takes part

Take one team you know, or the integration and data team of Nordvik Region. 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. For each, record the usage mode, the classes of development work it touches (specify, design, generate, refactor, test, review, deploy, operate, document, migrate), the degree of delegation in practice, who approves and who owns the result. Mark each place where the team could not say which lines came from the tool, and each where the owner would not pass Name, Understand and Revert today.

Deliverable: A one-page inventory table for one team, with the unknowns marked and a date for its next review.

Self-test

  1. The chapter sets three productivity studies side by side: a task finished 55.8 per cent faster, more completed tasks in field experiments, and experienced developers working more slowly in their own codebases. What does it conclude?

    1. The laboratory result is the most reliable because its single JavaScript task was controlled, so it should guide planning
    2. The results measure different people, tasks and codebases, so a shape carries over and not a size of effect
    3. The slower result for experienced developers shows that the two positive studies were methodologically flawed
    4. The three should be averaged into one expected productivity gain for planning
  2. According to the chapter, what kind of evidence would refute the second and fourth parts of the thesis?

    1. A vendor report showing that most committed lines in large organisations are generated by AI and pass their tests
    2. A survey in which a majority of developers say that they trust the accuracy of AI output
    3. A single controlled experiment in which an agent completes a task faster than a developer
    4. Independent multi-year evidence that organisations without named owners and generator-independent checks do better
  3. At the start of the year, where do agentic work tools (Mode 3) stand in the two organisations?

    1. At Level 2 Supervised at most: a developer reviews every pull request an agent opens and the agent never merges
    2. At Level 3 Bounded for all generated code at Hansa Mutual and Level 2 Supervised at Nordvik Region
    3. At Level 4 Autonomous in sandboxes at Hansa Mutual and prohibited entirely at Nordvik Region
    4. At Level 1 Assisted in both, since neither organisation allows an agent to open a pull request

Chapter 2 · 60 minutes

What Developers Did Before: Craft, Waterfall, Agile, DevOps and Open Source

The lesson gives the pre-AI baseline. It follows the lineage of development practice from craft to platform engineering and asks which scarcity each practice answered and what it left unanswered, sets out what two field studies found about how developers spend their time, and traces the stewardship principle to 'you build it, you run it'. Participants compare a role description with a role charter as code and take a practice inventory.

Learning objectives

  • Explain which scarcity each practice in the lineage answered and what it left unanswered
  • Compare how earlier automation of code differs from generative AI in determinism and reach
  • Review what the two time-use studies measured and the limits of each
  • Draft a practice inventory that marks each practice as evidenced, not evidenced or lapsed

Key concepts

Scarcity answered by a practice
The chapter's reading of the lineage: craft answered skill, structured programming the ability to reason about code, waterfall predictability, agile feedback, DevOps production feedback and ownership, open source the effort to write common parts, and platform engineering cognitive load.
Layered practice
No practice replaced its predecessor. A team with two-week sprints still writes a requirements document when a tender requires it and still depends on open source, so real teams, including both example organisations, carry several layers at once.
You build it, you run it
The ownership idea behind DevOps: a team that is paged for its service has an answer to who owns it that does not depend on a document. The stewardship principle of Chapter 4 generalises it.
Role charter as code
A versioned artefact in the repository with a mandate, accountabilities, decision rights and evidence, changed through a pull request. Unlike a role description, which lists activities, it states what a person answers for and may stop.

Interactive exercises

  • Put in order: The lineage of development practice
  • Match: What each practice left unanswered

Done on the lesson page, with feedback at once.

Discussion

  1. Which practice in your team has outlived the scarcity it answered, and which answers a scarcity that AI is about to make worse?
  2. The chapter says a role description can be satisfied by a developer who accepts everything an assistant offers. What would have to be in the charter to prevent that?
  3. Both organisations will meet AI on top of their oldest layer first. Why is that where the backlog is, and what does it mean for ownership?

Exercise · 20 minutes

A practice inventory for one team

Follow the practical guide for one team you know or for the case platform team of Nordvik Region. List the practices the team runs by what it does, not by what it calls itself: how work is specified, designed, reviewed, tested, released and owned. Place each practice in the lineage, state in the team's own words the scarcity it answered, and mark its status as in force and evidenced, in force and not evidenced, or lapsed, where evidence means a record and not a recollection. Add the developer function each practice serves and whether a Mode 0 feature already touches it.

Deliverable: A dated practice inventory with at least six practices, each with lineage, scarcity, status, function and a review date.

Self-test

  1. In the chapter's table of the lineage, what did agile and Extreme Programming leave unanswered?

    1. The cognitive load of the toolchain on a product team
    2. The late discovery of wrong requirements in large projects
    3. The durability of knowledge and the ownership of code
    4. The effort needed to write the common parts of a system
  2. What did the logging study by Meyer and colleagues of 20 professional developers find about coding?

    1. Coding took 21.0 per cent of the logged time, the largest single share but a minority of the day
    2. Coding took about 58 per cent of the logged time, with seniors coding more than juniors
    3. Coding took less time than using the debugger, reviewing code and using version control together
    4. Coding could not be separated from program comprehension in the logged categories
  3. In what two respects does the chapter say generative AI differs from compilers, frameworks and earlier code generation?

    1. It is cheaper to buy and it needs no change to the pipeline
    2. It is slower to run and it works only on modern languages
    3. It removes essential difficulty and it makes review unnecessary
    4. Its output is not deterministic and its reach across the developer's work is wider

Chapter 3 · 75 minutes

The Pressure on Developers: Productivity Claims, Adoption, Legacy and Accountability

The lesson examines five pressures on developers: adoption and headcount expectations, backlog and legacy, security and supply-chain demand, regulatory duty, and adversaries with the same tools. Each claim is graded as measured, surveyed, vendor or argued, and participants learn to say how far a result carries. The lesson ends with a work-and-load map of one developer's sprint, estimated by the developer and never built from covert monitoring.

Learning objectives

  • Classify a claim about AI and developers as measured, surveyed, vendor or argued, and state how far it carries
  • Explain why the three productivity results in the chapter cannot describe the same quantity
  • Compare the adoption claims of Nordvik Region and Hansa Mutual with the measurements behind them
  • Draft a work-and-load map for one sprint that shows where a tool could take part

Key concepts

Four grades of evidence
Measured rests on a study with a stated sample and method or an official text; surveyed on self-reported answers; vendor on a study by a company that sells in the area, read as a hypothesis; argued on reasoning from mechanism, only as strong as its premises.
Perceived and measured speed
In the randomised trial with 16 experienced open-source developers, allowing AI tools increased completion time by 19 per cent although the developers had forecast a 24 per cent reduction. The chapter uses it to show that belief about speed and measurement of speed can diverge.
Duties attach to named parties
The AI Act, the Cyber Resilience Act, the Product Liability Directive, NIS 2 and DORA address deployers, manufacturers, entities and management bodies. The chapter's implication is that none of these duties moves to a tool.
Evidence age
A claim has a date and an expiry. Under the defaults the book uses, usage figures expire after 90 days and value claims after 180 days; Nordvik's usage figures had expired by July 2030 and its 'a third faster' claim lapses in October 2030, and Hansa's 42 per cent of committed lines was past expiry.
Work-and-load map
An estimate by the developer of one sprint's hours by activity, with interrupted hours, the usage mode in which a tool could take part and the degree the delegation profile allows. It is compared at team level, never per named person.

Interactive exercises

  • Sort: Grade the evidence
  • Scenario: Who may see the work-and-load map

Done on the lesson page, with feedback at once.

Discussion

  1. The chapter concludes that the headcount expectation outruns the evidence in both directions. What would a measurement have to tie together before a smaller team could be defended?
  2. Why does the chapter treat the written duties as firmer ground than any of the productivity or security studies?
  3. The work-and-load map is an estimate by the developer and is compared only at team level. What would be lost, and what risked, if it were built from instrumented data instead?

Exercise · 25 minutes

Map one sprint by activity, load and AI contribution

For your own last sprint, or for a senior developer in Nordvik Region's case platform team, list the activities under the headings read and understand code, write code and tests, review colleagues' changes, specify and clarify, release, document, and meet and coordinate. Estimate the hours of each and the hours that were interrupted. For each activity enter the usage mode in which a tool could take part and the degree of delegation the team's profile allows for that work class. Mark the hours with no tool touchpoint and those where only Level 0 Advisory is allowed. State the basis and the evidence age of the estimate.

Deliverable: A work-and-load map for one sprint with hours, interruptions, tool touchpoints by mode and degree, and a stated basis.

Self-test

  1. How does the chapter grade Veracode's report on generated code and GitClear's analysis of changed lines?

    1. As measured evidence, because both rest on large datasets of real code
    2. As surveyed evidence, because both rest on what developers said
    3. As vendor evidence, useful as a hypothesis and weak as a finding
    4. As argued evidence, because neither contains any measurement at all
  2. Nordvik Region's executive committee was told that the pilot made developers 'a third faster'. What did the claim rest on?

    1. A comparison of delivery times before and after the pilot across four teams
    2. IDE telemetry of a 31 per cent acceptance rate and a survey answered by 9 of 12 developers
    3. A sample of 40 merged pull requests in which 27 per cent of lines were traced to suggestions
    4. A randomised trial run by the platform team with a control group of consultants
  3. What is the chapter's own conclusion for the whole of Part I about where the strain on the developer role falls?

    1. On the capacity to prove and to own, more than on the capacity to produce
    2. On the capacity to produce code fast enough to meet the backlog
    3. On the capacity to learn new tools faster than they are replaced
    4. On the capacity to negotiate tool budgets with senior management

Chapter 4 · 90 minutes

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

The lesson fixes the frame of the book. Participants learn the five developer functions, the ten classes of development work, the delegation ladder and the rule that the lowest of five answers sets a ceiling, the five Level 4 prohibitions, the stewardship principle with its tests Name, Understand and Revert, the independent test oracle and the claim record. They apply all of it by writing a delegation profile for one team.

Learning objectives

  • Explain the five developer functions and assign a piece of work to one of the ten classes of development work
  • Set a ceiling for a work class by answering the five questions and taking the lowest level
  • Apply the tests Name, Understand and Revert to a recent change and to the owner of a repository
  • Draft a delegation profile for one team with an independent oracle and a stop path

Key concepts

The developer loop
Five functions that run as a loop: D1 Frame, fixing the problem and the intent; D2 Design, choosing the constraints; D3 Build, producing and directing the making of software; D4 Prove, showing that it is right; and D5 Steward, owning the software over time.
The lowest of five answers governs
The ceiling for a work class is the lowest level allowed by reversibility, blast radius, who is affected, evidence, and the strength of the independent checks. The fourth and fifth answers can only lower a ceiling that the first three have allowed.
The Level 4 prohibitions
Level 4 Autonomous is never used for a production change without a gate the change cannot alter, for security-critical or safety-critical code without review by a named developer, for the agent's own mandate, oracles or gates, for irreversible actions on production data, or for decisions about a named person.
The stewardship principle
AI may draft, generate, refactor and, within a mandate, execute; it may not own. A named developer or team passes three tests for every change in production: Name (identifiable in the ownership record), Understand (can explain it without the tool) and Revert (authority, access and time outside the pipeline).
The independent test oracle
The oracle is the means of deciding whether observed behaviour is correct. The corollary of the principle is that it must be independent of the generator: tests written by the same assistant in the same session restate the code's assumptions.

Interactive exercises

  • Sort: Prohibition or five answers
  • Put in order: The rungs of the delegation ladder

Done on the lesson page, with feedback at once.

Discussion

  1. The fourth and fifth answers, evidence and independent checks, can only lower a ceiling. Why does the chapter not let strong evidence raise a ceiling that reversibility or blast radius has capped?
  2. Switch the assistant off and ask the owner what the change does. Which recent change in your team would pass the Understand test, and which would not?
  3. Hansa Mutual allows one Level 3 Bounded class, patch-level dependency updates. What has to stay true for that class to remain acceptable under the ladder?

Exercise · 30 minutes

Write a delegation profile for one team

Choose one team. List the ten work classes and write one example change per class from the last quarter. Name a steward and a deputy for each class and run Name, Understand and Revert on them. Answer the five questions for each class and take the lowest level as the ceiling. Apply the five prohibitions and list the repositories, paths and actions they catch, with who must review them. Mark any tool that acts above the ceiling, including a Mode 0 feature. Name the independent oracle for each class that reaches production and who writes it, and name who holds the stop, where the revert path runs and when it was last tried.

Deliverable: A delegation profile in the DLG form: ten classes with ceilings, stewards, prohibited paths, oracle, stop and revert path, and a review date.

Self-test

  1. What ceiling does the chapter recommend for the work class review?

    1. Level 0 Advisory, because no AI comment may appear on a pull request
    2. Level 2 Supervised, because an AI approval counts once a developer confirms it
    3. Level 3 Bounded, for changes whose checks have all passed in the pipeline
    4. Level 1 Assisted: AI comments are input to a human reviewer, never an approval
  2. Which of these checks does the chapter classify as not independent of the generator?

    1. Characterisation tests recorded from the running legacy system
    2. Tests written by the same assistant in the same session as the code
    3. Static analysis and type checking with fixed rules
    4. Tests derived from the specification record by a different person before the code
  3. Under the Name test, which ownership entry fails?

    1. A named team with a reachable lead recorded in the ownership record
    2. A named developer with a deputy recorded for periods of absence
    3. A department such as Policy Systems recorded as owner of the estate
    4. A tech lead recorded as owner of the repositories of one product team

Module 2 · Part II · The Craft of Developing

Part II treats the craft function by function, each first without AI and then with it: D1 Frame, D2 Design, D3 Build with assistants and with agents, D4 Prove in general and for security, and D5 Steward for the release and for the code over years. Participants leave with the working artefacts of the book: a specification record, an ADR with a stated AI contribution, a usage profile, a mandate, a verification plan, toolchain controls, a change record and an ownership record.

Chapter 5 · 75 minutes

Frame: Problems, Requirements and Intent

The lesson treats D1 Frame: finding the problem behind a request, writing requirements with a reason and a source, and keeping the specification as the source of intent. Participants learn what AI adds to framing (drafting, clarifying questions, summarising, surfacing what is missing), the six failure modes that follow, and how a specification record SPC keeps the acceptance criteria as an oracle the generator does not own.

Learning objectives

  • Classify an ambiguity as one of vocabulary, scope or condition and choose its remedy
  • Explain why a change to an acceptance criterion is a change to the oracle
  • Review an AI-drafted specification for the six failure modes of framing
  • Draft a specification record with provenance, assumptions, out-of-scope list and dissent

Key concepts

Three kinds of ambiguity
Vocabulary (a word such as household means different things in the form and in the case system), scope (a request with no edge) and condition (a rule that does not say how it is established). Each needs a different remedy: a glossary entry, an out-of-scope list, a boundary scenario with a named rule owner.
Specification as the source of intent
A specification kept as code in version control, so that it can be tested, versioned with the change and found by an agent. Traceability runs both ways between need, requirement, criterion and test.
The same ambiguity, moved
A generating tool does not stop at a gap in the specification; it fills it with something plausible. The control is an assumptions field and a review step asking which decisions an artefact embodies that no record contains.
Circular verification
The most consequential failure for the book: one assistant drafts requirements and criteria, another generates the code and a third writes the tests, so the loop is closed by machines alone. The control is criteria owned by a person who is not the generator, written before code is generated.
Specification record
The artefact SPC, for example SPC-NR-2030-0001, that links need, requirement, criterion and test, names the owner and the oracle owner, and records what the assistant did. Generation of code begins only after the criteria are committed.

Interactive exercises

  • Match: Failure modes of framing and their controls
  • Put in order: From a request to a committed specification record

Done on the lesson page, with feedback at once.

Discussion

  1. A summary of seven interviews shows the majority view. How would you make sure that the case handler who works the hardest cases is still heard in the specification?
  2. Assistants tend to agree with the framing they are given. What does that mean for a product owner who asks an assistant whether a proposed scope is right?
  3. Nordvik Region sets specify at Level 0 Advisory and Hansa Mutual at Level 1 Assisted. What in the two organisations explains the difference, and which would you choose for your team?

Exercise · 25 minutes

Turn a need into a specification record

Take a real request from your backlog, or the home-care application form of Nordvik Region. Restate it as a problem for a named group of users and record the evidence, including one source the requester did not choose. List legal and policy requirements with their source. Draft three requirements, each with a reason and a source. Write an acceptance criterion as a scenario for each, with at least one boundary case, and name the person who owns the criteria and is not the generator. Add the assumptions, the open questions, an out-of-scope list and a dissent field, and state what an assistant was or was not used for.

Deliverable: A specification record with owner, oracle owner, requirements with provenance, scenarios, out-of-scope list, dissent field and a review date.

Self-test

  1. The form says household and means the applicant's family; the case system uses the same word for everyone at the address. Which kind of ambiguity is this, and what remedy does the chapter give?

    1. Scope ambiguity, remedied by a list of what is out of scope with the reason
    2. Condition ambiguity, remedied by a boundary scenario and a named rule owner
    3. Vocabulary ambiguity, remedied by a glossary entry agreed with the case handlers
    4. Interface ambiguity, remedied by a contract test between the two systems
  2. In the Nordvik Region specification record, how is the baseline for returned applications recorded, and why?

    1. As not measured, because the claim can only be tested against a baseline that exists
    2. As an estimate by the assistant, because no telemetry was available for the form
    3. As the figure from the pilot survey, because nine of twelve developers answered it
    4. As confidential, because the public-access rules prevent its disclosure
  3. Where do the Level 4 prohibitions bite on framing, according to the chapter?

    1. An assistant may never draft a user story from a meeting transcript
    2. No agent changes the acceptance criteria its own output is tested against
    3. A product owner may never use a conversational assistant to build a prototype
    4. A specification may never be stored in the same repository as the code it describes

Chapter 6 · 75 minutes

Design: Architecture, Decisions and Constraints with AI

The lesson treats D2 Design as the choice of constraints on the code that follows. It covers the five kinds of constraint, the decision record and the five fields an ADR gains when AI took part, what an assistant is good for as option generator and design reviewer and what it flatters, architectural drift and conformance rules derived from an ADR, and the seam between the developer's decisions and the architect's.

Learning objectives

  • Review a design against the five kinds of constraint: boundary, interface, data, failure and security
  • Draft an ADR that states who decided, what the tool contributed, what the human added, the dissent and the reversibility
  • Explain four mechanisms that weaken an assistant as a design reviewer
  • Classify a design decision as the developer's or the architect's by scope and reversibility

Key concepts

Design as the choice of constraints
A design is a set of constraints on the code that will be written. Five kinds recur (boundary, interface, data, failure and security), and a design review that does not ask about all five has not reviewed the design.
ADR fields when AI took part
Beside the classic fields, the record states who decided (one named developer), what the tool contributed, what the human added or rejected, the dissent, and the reversibility with a review date. Together they apply Name, Understand and Revert to design.
What the assistant flatters
Four mechanisms bear on design review: agreement with the user's framing, homogenisation of the options teams consider, blind spots shared between models whose errors are correlated, and automation bias in the person who reads the advice.
Architectural drift
The gradual divergence of the code from the design intended for it. The mechanism not in doubt is that a tool sees the files it is given, so a constraint that appears in no file cannot be seen by it.
Conformance rule
A machine-checkable rule derived from an ADR that sets a boundary, run in the pipeline and owned by someone other than the generator. No agent may change the rule that checks its own output.

Interactive exercises

  • Sort: The developer's decision or the architect's
  • Scenario: Options first, or the assistant first

Done on the lesson page, with feedback at once.

Discussion

  1. In the Nordvik example the option that changed the discussion came from a person who knows the system, not from the assistant. What does the repository not say in your own codebase?
  2. The practical guide tells the developer to write their own options before asking the tool. What is lost when the order is reversed?
  3. The seam to the architect runs along scope and reversibility, not seniority. Which of your team's recent decisions were one-way without anyone saying so?

Exercise · 25 minutes

An ADR with a stated AI contribution

Choose a design decision your team faces, or the status interface between the citizen portal and the case-management system at Nordvik Region. State the decision as a question with its context and non-negotiable constraints. Write your own options first. Then add the options and objections an assistant offered or would be asked for, and at least one option it did not offer. Hold a short pre-mortem: assume the decision failed in a year and record the likeliest reasons. Decide, give reasons in your own words, record dissent, mark the decision one-way or two-way, set a review date, and derive one rule the pipeline could check, with its owner.

Deliverable: An ADR with named decider, tool contribution, human additions, dissent, reversibility, review date and one derived conformance rule.

Self-test

  1. In the worked decision ADR-NR-0031, which element does the decider mark as one-way?

    1. The status interface behind the gateway, because the vendor controls its schema
    2. The use of the pilot assistant, because its transcript must be archived
    3. The mapping check against closed cases, because it runs only once before release
    4. The public status vocabulary shown to applicants, because residents rely on it
  2. Which ADR field is, according to the chapter, the evidence that the decision was the developer's own and not the tool's?

    1. What the human added or rejected, with reasons
    2. The title and status of the record
    3. The date on which the record was committed
    4. The list of pull requests that implement it
  3. Which statement about drift does the chapter treat as a mechanism that does not depend on the studies?

    1. Copy-pasted lines rise in every codebase where an assistant is in use
    2. More capable models always produce fewer architecture violations
    3. A design constraint that appears in no file cannot be seen by a tool that generates code
    4. A 25 per cent increase in AI adoption always lowers delivery stability by the same estimated share

Chapter 7 · 75 minutes

Build: Writing Code and the Tools of the Craft

The lesson treats D3 Build with assistants. It maps the progression of tools from ambient completion to agents onto the usage modes by what the tool may touch and the unit the developer reviews, reads the controlled studies with their conditions, and sets out prompt and context craft and what stays human: framing, reading and ownership. Participants write a coding-assistant usage profile with acceptance criteria, a measurement plan and a stop rule.

Learning objectives

  • Classify a coding tool by usage mode from what it may touch, the unit of review and the identity it uses
  • Explain how task, experience, codebase and measure account for the differences between the productivity studies
  • Apply the four rules of prompt and context craft to a coding task
  • Draft a coding-assistant usage profile that narrows the delegation profile and never widens it

Key concepts

Unit of review
What the developer must read to accept a tool's output: a few lines for completion, a snippet for chat, a diff and a command log for edit and agent mode. The chapter says risk grows with this unit and with the identity the tool uses, not with the sophistication of the model.
Four variables behind the studies
Task, experience of the person, codebase and measure. Self-contained tasks showed speedups, real issues in familiar mature repositories did not, and measures such as pull requests, commits and acceptance rates count output that a tool can inflate.
Vibe coding
Not a tool but a way of working in which generated code is accepted without being read. The chapter gives it a legitimate place only in a throwaway prototype in a sandbox with no credentials and no data, because it sits outside framing, reading and ownership.
Coding-assistant usage profile
A file that turns the statement that the team uses an assistant into something that can be checked: tool, mode and hosting, ceilings copied from the delegation profile, what may not be given to the tool, merge criteria, measurement plan, evidence age and a stop rule.

Interactive exercises

  • Match: The form of the tool and what the developer reviews
  • Scenario: The prototype that works

Done on the lesson page, with feedback at once.

Discussion

  1. In the trial of 16 experienced developers, completion took 19 per cent longer while the developers believed they had been faster. What does that imply for a survey of time saved in your own organisation?
  2. The chapter calls Mode 0 the most common error: an assistant that arrived in an update and was decided afterwards. How would you find such features in your own tools?
  3. Why does the usage profile measure at team level, and what changes when a tool reports a named developer's acceptance rate to a manager?

Exercise · 25 minutes

A usage profile for one coding assistant

For one assistant your team uses, or for the pilot NR-DEV-001 at Nordvik Region, write a usage profile. Identify the tool, its usage mode and where the model runs. Copy the ceilings per work class from the delegation profile. List what may not be given to the tool. Write acceptance criteria for merging a change that contains generated code, with one criterion each for Name, Understand and Revert and an oracle the generator did not write. Write a measurement plan using outcomes already measured at team level, record the evidence age of every claim relied on, mark unverified claims as asserted, and write the stop rule and who decides.

Deliverable: A usage profile with ceilings, exclusions, merge criteria, measurement plan, evidence ages, a stop rule and a review date.

Self-test

  1. In the study by Peng and colleagues, what was measured and with what result?

    1. Weekly pull requests of 4,867 developers, which rose by about a quarter
    2. Time for 95 freelance programmers to complete one JavaScript task: 71.17 against 160.89 minutes
    3. Time for 16 experienced open-source developers on 246 tasks in mature projects, which was 19 per cent longer
    4. Time for 96 engineers on an enterprise task, about 21 per cent shorter
  2. According to the chapter, what does the risk of a coding tool grow with?

    1. The number of parameters and the benchmark score of the model behind it
    2. The share of the team's developers who hold a licence for it
    3. The price per seat and the length of the supplier contract
    4. The unit the developer must review and the identity the tool uses
  3. How does the usage profile for NR-DEV-001 show the quoted claim that developers are a third faster?

    1. As asserted, beside the measurement plan that would verify it
    2. As verified, because the executive committee has accepted it
    3. As withdrawn, because the pilot ended before the profile was written
    4. As confidential, because it rests on telemetry about named developers

Chapter 8 · 90 minutes

Build with Agents: Delegated Coding, Mandates and Sandboxes

The lesson treats coding agents: a model in a harness that chooses tool calls until a stopping condition. Participants learn the mandate manifest with its never list, the sandbox that makes the mandate true, stop paths outside the agent, the run record, and the one Level 3 Bounded class of patch-level dependency updates at Hansa Mutual. The chapter stages the debate on whether agents should write and merge code, and the lesson rehearses it.

Learning objectives

  • Explain how a mandate, a sandbox and credentials together set the authority of a coding agent
  • Design the sandbox controls for filesystem, network, secrets, tools, untrusted input and budgets
  • Compare the case for concern and the case for calm on agents that write and merge code, and state where they meet
  • Draft a mandate manifest with a never list, budgets, stop holders and a review date

Key concepts

Mandate manifest
The written, versioned statement of what an agent may do, with what, on what, for how long and at what cost, and who can stop it. It is subordinate to the delegation profile, and its never list closes the routes by which an agent could change its own governance.
The sandbox makes the mandate true
An ephemeral container with one repository, egress denied except to the package proxy, no secrets, a one-run identity issued by a service the agent cannot reach, and budgets enforced by the host. It is not a defence against intent, since a model intends nothing.
Untrusted input and the rule of two
Text in issues, comments, documentation or command output can be treated by the model as an instruction. The design check is that no run combines untrusted input, sensitive access and the ability to change state or communicate externally.
Stop path outside the agent
An agent can be stopped inside the agent, at the harness or at the identity. The stop must not run through the pipeline the agent's pull requests trigger, and stopping does not undo what was done: Revert is a separate test.
Writing, merging and deploying
Three acts that are often confused and get different answers. The chapter's verdict is writing at Level 2 Supervised with a reviewer who is not the requester, and a pipeline merge only for a narrow listed class whose gate the change cannot alter.

Interactive exercises

  • Sort: Which sandbox control is this
  • Scenario: Who approves the agent's pull request

Done on the lesson page, with feedback at once.

Discussion

  1. The calm side argues that a human click is not in itself a control. What would make an approval a real control in your team rather than a click?
  2. Review capacity is finite and is a number. How would you establish how many agent pull requests a week your team can review well?
  3. The run record holds what the agent did, not what the engineer typed. Why does the chapter draw the line there, and who should agree to it?

Exercise · 25 minutes

Write the mandate of a coding agent

For an agentic tool your team already uses, or for the platform team of Nordvik Region, write a mandate. Name the task class and the repositories, and exclude the security-critical paths. Set the level per work class under the ceiling of the delegation profile, with the evidence for each level and its age. List what the agent may do and what it may never do, in terms of paths and actions a sandbox can enforce. Specify a one-run identity, numeric budgets and halt rules, who is told when a rule fires, the stop holders with one reachable out of hours, the mechanism outside the pipeline, who writes the run record, and the review date.

Deliverable: A mandate manifest with levels, allowed actions, a never list, identity, budgets, halt rules, stop holders and a review date.

Self-test

  1. Which rule about approval does the Nordvik Region mandate MND-NR-DEV-01 contain?

    1. Two platform engineers must approve every run before it starts
    2. The CIO approves each pull request that an agent opens
    3. The person who starts the run does not approve its pull request
    4. The agent may approve its own pull request when all checks pass
  2. Why must the stop path not run through the pipeline that the agent's pull requests trigger?

    1. Because pipelines are too slow to stop a run within the wall-time budget
    2. Because if a pipeline job stops the agent, a broken pipeline leaves it running
    3. Because the pipeline is owned by the platform team and not by the requester
    4. Because a pipeline stop would delete the run record that the host has written
  3. In the chapter's table of ceilings for a coding agent, what applies to the work class review?

    1. Level 0 Advisory: an AI review comment never counts as an approval
    2. Level 2 Supervised: an agent approves after a developer confirms
    3. Level 3 Bounded: an agent approves patch-level dependency updates
    4. Level 1 Assisted: an agent's approval counts as one of two approvers

Chapter 9 · 90 minutes

Prove: Review, Tests and Verification

The lesson treats D4 Prove: what review is for, which layer of testing answers which question, and why the test oracle must be independent of the generator. Participants learn the three rules of independence (authorship, source and protection), the volume problem that cheap generation creates for review, the design measures that keep review real, the limits of an AI reviewer, and how a verification plan and a review record carry the evidence.

Learning objectives

  • Explain which question each layer of checking answers and who should write it
  • Apply the three rules of an independent oracle: authorship, source and protection
  • Design review so that it stays real under rising volume, using size limits, budgets, queue caps and seeded defects
  • Draft a verification plan with an independent oracle and a named steward

Key concepts

The strength of the oracle
Testing is a set of layers (static analysis, example-based tests, property-based tests, mutation score, formal models, human review), each answering a different question. The strength of any pass is the strength of the oracle behind it.
Authorship, source and protection
The three rules of independence: the oracle is written or approved by someone other than the author of the change; it is derived from a source the implementation was not derived from; and the tool that produces the change has no permission to edit the oracle, review rules or gates.
The volume problem
When generation is cheap, review capacity bounds the merge rate. The chapter's own arithmetic leads to a choice between a visible cap on what is merged and an invisible thinning of the review each change receives.
Seeded defects
Known defects added by the quality function to a sample of changes, to measure how many each check catches. They are how independence and review quality are shown rather than asserted, and they are reported in aggregate.
AI as reviewer
A system that reads a diff and writes comments. Three limits are architectural: blind spots correlated with the generator, context it cannot see, and comments that look like approval. It is a useful additional check when evaluated like one and never counts as the human review.

Interactive exercises

  • Match: Which check answers which question
  • Scenario: Green tests from the same session

Done on the lesson page, with feedback at once.

Discussion

  1. The chapter says the value of review for the stewardship principle is that it creates a second person who can explain the change. How often does your review achieve that?
  2. Between a visible cap on merges and an invisible thinning of review, organisations tend to drift to the second. Who in your organisation would have to agree to the first?
  3. Oversight-quality figures such as approvals within seconds are reported in aggregate and agreed with staff representatives. Why does the chapter insist on both conditions?

Exercise · 30 minutes

A verification plan with an independent oracle

Take one change that AI took part in, or a change to the deductible and cap calculation in the claims core of Hansa Mutual. Name the behaviour that must be true after the change and the behaviour that must not change, both taken from the specification. Choose the layers of checking and, for each, name who writes the check and the source of the expected result. Write two properties from the specification. Set a mutation target for the changed lines and name who may lower it. List the checks the generator can and cannot see. Name the reviewer and what they read first, the steward, and how the change is reverted outside the pipeline.

Deliverable: A verification plan naming layers, oracle authors and sources, properties, mutation target, protected checks, reviewer, steward and revert path.

Self-test

  1. What does the rule of protection require of an independent oracle?

    1. That the oracle is stored in an encrypted repository with restricted read access
    2. That the oracle is rewritten whenever the model behind the tool changes
    3. That the tool producing the change cannot edit the oracle, the review rules or the gates
    4. That the oracle is reviewed by a second AI model from a different provider before each merge
  2. What does the duplicated-settlements incident at Hansa Mutual (INC-HM-2029-0207) show, according to the chapter?

    1. That generated COBOL is less reliable than generated Java in payment paths
    2. That a review without independence fails even when nobody used AI at all
    3. That mutation testing would have been too slow for the quarter-end batch
    4. That two approvers are always sufficient for a security-critical change
  3. In the chapter's division of labour, who should write a property-based test?

    1. A person, working from the specification and not from the code
    2. The assistant that generated the change, in the same session
    3. The platform team, once, as a fixed rule for all repositories
    4. A specialist in formal methods, together with the product owner

Chapter 10 · 90 minutes

Prove Security: Secure Code, Supply Chain and the Toolchain as Attack Surface

The lesson treats the security side of D4 Prove and D5 Steward. Generated code is untrusted input and is proved like any other; the tool's proposals are a new entry point to the supply chain; secrets leave in prompts and enter in code; prompt injection is a property of the architecture, so controls sit outside the model; and the toolchain is a Tier 0 asset. Participants design the controls for a coding agent, entirely as a defensive design exercise.

Learning objectives

  • Explain why the chapter treats generated code as untrusted input and how to measure its effect in one's own code
  • Design the five controls on the path a dependency name must travel
  • Classify the inputs of a coding agent by who can write them and limit what the agent can do after reading them
  • Draft the toolchain controls of a mandate, with separated identities and a stop path

Key concepts

Package hallucination
A coding tool proposes imports, and some of the names it proposes do not exist; one study found a substantial share of suggested packages hallucinated and treats this as a threat to the supply chain. The defence is the path a name must travel, not the tool's accuracy.
A denial that is an event
The fifth dependency control: when the package proxy refuses a name, the refusal is logged with the run that asked and reaches an owner. At Hansa Mutual the proxy held against a non-existent package but the denial had no reader.
Permissions set the cost of being steered
Prompt injection is architectural and not a patchable defect. What an agent can be made to do is what its permissions allow, so the limits are input classification, no unneeded secrets, egress denied by default, reading separated from acting, and gates kept out of reach.
The toolchain as Tier 0
The systems that turn intent into running software are among the most privileged in the estate. Developer, agent, build and release identities are kept separate, and no one identity combines authoring, approving and releasing.
Provenance record
The record PRV of where a piece of software came from. It claims origin only as far as a log supports, says nothing about the share of code a human wrote, and leaves AI comments out of the count of approvals.

Interactive exercises

  • Sort: Four identities in the toolchain
  • Scenario: The proxy said no, three times

Done on the lesson page, with feedback at once.

Discussion

  1. The studies measure code at the moment of generation, not what survives review and scanning. What would you need in order to state a figure for your own merged code?
  2. At Hansa Mutual the proxy refused the package and nobody read the denial. Which refusals in your own toolchain have no reader today?
  3. The chapter says an untested limit is declared, not verified. How would an authorised exercise under rules of engagement test your agent's limits without creating new risk?

Exercise · 30 minutes

Write the controls for a coding agent

For a coding agent in your organisation, or the agent under MND-HM-DEV-02 at Hansa Mutual, design the controls. List what the agent reads and label each source by who can write it: the team, the organisation, a supplier, anyone. List what the agent can do and strike everything the task does not need. Specify a separate identity with task-scoped, short-lived credentials issued outside its runtime. Route packages through the proxy with denied direct egress, a waiting period and a named approver for any new name. Place the secret filter and log at the gateway. Put gates, signing keys, ownership rules and the mandate out of reach. Write the stop path and the date of its drill.

Deliverable: A toolchain-controls section for a mandate: labelled inputs, pruned permissions, identity, package path, gateway filter, protected assets, stop path and drill date.

Self-test

  1. Which of the following is one of the five dependency controls the chapter lists?

    1. A rule that agents may only propose packages written in the team's main language
    2. A monthly manual review of every package in the lock file
    3. A requirement that every new dependency is first forked into the organisation
    4. A waiting period before new versions of existing packages are installed
  2. What happened in the incident INC-NR-2030-0071 at Nordvik Region?

    1. A consultant pasted a test-database connection string into an unapproved public chat assistant
    2. A coding agent proposed a dependency that did not exist and the proxy refused it
    3. A pipeline workflow ran with elevated permissions on the title of an untrusted pull request from outside
    4. A generated change to the citizen portal bypassed the regression pack
  3. What does the provenance record in the chapter say about the share of code written by a human?

    1. It states the share as measured by accepted suggestions in the IDE
    2. It says nothing about it, and claims origin only as far as a log supports
    3. It estimates the share from the agent's run record and the diff size
    4. It records the share as confidential under the works agreement

Chapter 11 · 90 minutes

Steward the Release: CI/CD, Change and Operating What You Build

The lesson treats D5 Steward at the point where a change becomes a release. Its claim is that when AI takes part in a change, the release path must contain at least one gate the change cannot alter and a named owner who can revert from outside the pipeline. Participants cover progressive delivery, the four properties of such a gate, change approval by class, the limits of the delivery metrics, and the Revert test in practice.

Learning objectives

  • Classify the controls on a release path by whether the change can alter them
  • Explain the four properties of a gate the change cannot alter
  • Review how each of the delivery metrics can be distorted by AI-assisted change
  • Design a rehearsed revert with authority, access and time outside the pipeline

Key concepts

A gate the change cannot alter
A gate with four properties: its definition is out of reach of the change, it executes out of band, its oracle is independent of the generator, and it is shown to work by dated seeded faults. A pipeline file in the same repository does not qualify.
Progressive delivery
Exposing a change to a growing share of users or systems while measuring its effect, with the ability to stop and revert at each step: feature flags, canaries and rings, and rollback. A flag is a production change in its own right.
Approve classes, not items
A class that is low in blast radius, reversible and covered by a strong gate can be approved once, with an expiry. Human judgement is reserved for what is irreversible or security-critical, and a model may score a change but not approve it.
Change volume per owner is a budget
The number and size of changes a team can understand and run is finite. You build it, you run it survives rising volume only if the owner is in the ownership record before the change and the generator is never the sole responder to its own failure.
The Revert test in practice
Authority: the owner or deputy may use the stop without asking. Access: the stop works when the pipeline does not. Time: the rehearsed time to restore is shorter than the time in which harm accrues. A revert not exercised in the last 90 days is marked not tested.

Interactive exercises

  • Sort: Can the change alter this control
  • Put in order: Adding a gate and a rehearsed revert

Done on the lesson page, with feedback at once.

Discussion

  1. What cannot be rolled back in your own services, and how is that marked before the change is approved?
  2. Deployment frequency rises when a team ships many small generated changes, whether or not they matter. Which of your reported metrics would move without anything improving?
  3. Nordvik Region has a contract and a small platform team; Hansa Mutual has a platform, a policy repository and an agent mandate. How does each put the same control in place?

Exercise · 30 minutes

A gate the change cannot alter and a rehearsed revert

For one service you know, or the citizen portal of Nordvik Region, draw the release path from commit to production and mark each control as inside or outside the reach of a change. Say where the gate definition should move so that contributors cannot edit it. Name the oracle for the change class and its owner. Choose three faults to seed that the gate must catch: a failing contract, a boundary case and a policy violation. Define the rings and promotion conditions. Write the revert in two forms, through the pipeline and by a stop path outside it, and plan a rehearsal with a target in minutes and an expiry for the evidence.

Deliverable: An annotated release path with gate location, oracle owner, three seeded faults, rings, two revert forms and a rehearsal plan with target and expiry.

Self-test

  1. Which control does Table 11.1 class as one the change can alter?

    1. Required status checks and branch rules set at organisation level
    2. The pipeline definition file in the same repository
    3. Policy as code in a separate repository with its own owners
    4. Synthetic journeys owned by the quality function
  2. How does the chapter say a revert that has not been exercised in the last 90 days should be recorded?

    1. As passed, provided that the pipeline rollback step exists
    2. As failed, which blocks all further releases of the service
    3. As waived, with the approval of the engineering manager
    4. As not tested, a legitimate entry that is not the same as passed
  3. Why does the class approval in CHG-HM-2030-0415 expire on the delegation profile's review date?

    1. So that the class approval does not outlive the evidence behind it
    2. So that the supplier contract can be renegotiated at the same time
    3. So that each update receives an individual approval after that date
    4. So that the agent's credentials are rotated once a year

Chapter 12 · 75 minutes

Steward the Code: Maintenance, Legacy Modernisation, Technical Debt and Documentation

The lesson treats D5 Steward over years: code health, legacy modernisation, technical debt, documentation, deletion and ownership. Participants read the young and mixed evidence on AI-assisted codebases, learn what public reports of AI-assisted migration do and do not describe, and take away the sequence both organisations arrive at: owner first, oracle second, knowledge captured third, translation last. The artefact is the code-ownership record and its yearly review.

Learning objectives

  • Compare what the sources on code health in AI-assisted codebases measured and where each stops
  • Explain the five things a legacy migration needs before any generated translation
  • Classify documentation by its three jobs and say which an assistant can draft
  • Draft a code-ownership record and plan a yearly ownership review

Key concepts

Programming as theory building
Naur's argument that a program is not its source text but a theory the programmers hold of how it relates to the world and why it is built as it is. Documentation derived from code can say what the code does; the reasons are carried by people and decision records.
Five things before a migration
An owner by name, an oracle that does not come from the generator (characterisation tests of the old system's behaviour), a scope in which the tool may act, a way back, and the knowledge captured before it retires. Both profiles keep migrate at Level 0 Advisory.
Debt as a flow
Technical debt is the accumulated cost of choices that made change easier then and harder now. The chapter's rule is to track it as a flow and not a stock, because debt accumulates in the sum of changes and the sum needs an owner and a measure.
Deletion as stewardship
The counterweight to cheap generation. Deletion works when a signal of use, a human reviewer, an exception list and a way back are in place.
Code-ownership record
The artefact OWN: owner and deputy, scope, tests and who owns the oracle, decisions, revert method, and the evidence age of the Understand and Revert tests. It is a tool for the owner and the team, not a means to rank or appraise named developers.

Interactive exercises

  • Match: What each code-health source measured
  • Scenario: The repository whose owner has left

Done on the lesson page, with feedback at once.

Discussion

  1. The public reports describe bounded, mechanical, well-tested migrations. What makes the COBOL estate of Hansa Mutual or the case system of Nordvik Region a different kind of problem?
  2. Why does the chapter ask that the ownership inventory is reported as counts with dates, and what would an undated figure hide?
  3. Adding code is visible and rewarded; deleting it is not. What would have to change in your organisation for deletion to count as work?

Exercise · 25 minutes

An ownership record for one module

Choose the module in your estate whose last explainer you would miss most, or the COBOL settlement module of Hansa Mutual. Write its ownership record: the owner and a deputy by name, what the module is and does, where its tests and decisions are and who owns the oracle, how it is reverted, and the review trigger: a date at most a year ahead and the events that bring it forward, such as the owner leaving or the tool changing. Record when the Understand test was last run, by asking the owner to explain a recent change without the assistant, and when the Revert was last rehearsed. Mark every vacancy as a finding.

Deliverable: A code-ownership record with owner, deputy, scope, oracle owner, revert method, test dates, review triggers and marked findings.

Self-test

  1. What did the randomised trial by Borg and others, in which 75 developers evolved code without AI, find?

    1. Code written with an assistant took significantly longer for the next maintainer to change
    2. Lines added rose three to five times in the first month after adoption
    3. No significant difference for the next maintainer, whether or not an assistant was used
    4. Copy-pasted lines rose from 8.3 to 12.3 per cent of changed lines
  2. What sequence do both organisations arrive at for legacy modernisation?

    1. Owner first, oracle second, knowledge captured third, translation last
    2. Translation first, tests second, owner third, documentation last
    3. Documentation first, translation second, oracle third, owner last
    4. Oracle first, translation second, knowledge third, owner last
  3. What does the practical guide say about using ownership records to count the modules a named developer owns for appraisal?

    1. It recommends it as a fair measure of a senior developer's contribution
    2. It allows it when the engineering manager and the tech lead both agree
    3. It requires it as part of the yearly ownership review
    4. It treats it as a monitoring use that the record is not meant for

Module 3 · Part III · Developer Roles Across the Organisation

Part III follows the transformed role through the people who hold it: the junior and the apprenticeship problem, the senior and the review bottleneck, the tech lead and the engineering manager, the architect, platform engineer and reliability engineer, the tester, product owner and designer, the developer in a public authority, and the citizen developer. Participants leave with an apprenticeship plan, a senior charter, a team working agreement, a golden-path specification, a role-boundary matrix, procurement criteria and a register entry.

Chapter 13 · 90 minutes

The Junior Developer and the Apprenticeship Problem

The lesson treats the apprenticeship problem for D3 Build and D4 Prove: the entry tasks that taught the craft are the tasks assistants perform best, so output is separated from learning. Participants weigh what four groups of studies measured, rehearse the debate on whether junior developers will disappear, and design a first-year route: attempt first, review first, AI-off practice, an owned small change with a revert drill, a mentor and a second assessor.

Learning objectives

  • Explain how the entry tasks of a junior developer separated into an output a tool can supply and a learning it cannot
  • Compare what the studies of early-career employment, novice productivity and learning beside an assistant each measured
  • Compare the case for concern and the case for calm, and state the points on which they meet
  • Design a first-year apprenticeship plan with milestones, tool access by phase and an AI-off share

Key concepts

The apprenticeship problem
The separation of output from learning. A task has an output, which the tool can now supply, and a learning, which the tool supplies only if the junior does the thinking the tool is replacing. The question is where the next senior developers come from.
Attempt first
The junior states what the problem is, what a solution would look like and where in the code it would go, before opening the assistant's draft, and keeps a short log of what the assistant got wrong.
Review first
The junior becomes a reader before a writer by reviewing pull requests as practice. One rule protects the design: the junior's review is practice, not the gate, and it does not count as an approval.
AI-off practice
Tasks done without any assistant, including ambient completion, for a stated time. The plan fixes the share and its reason, and the platform team configures the tools so that completion can be switched off for a named learning period.
Apprenticeship plan
The artefact APR: a first-year route with a named plan, mentor and second assessor, four to six milestones, tool access that starts below the team ceiling and rises, and evidence from work and not from telemetry. No assistant assesses a named junior.

Interactive exercises

  • Match: What each entry task taught
  • Scenario: No apprentices this year

Done on the lesson page, with feedback at once.

Discussion

  1. The chapter says the decline in hiring is a choice, not a law. Who in your organisation makes that choice, and on what figure?
  2. A broker interface team at Hansa Mutual took no apprentices for 2030 on the strength of a figure of 42 per cent AI-assisted lines. What would the claim record of Chapter 4 have required before that decision?
  3. Skill is the measure, not output. How would you know after one year that a junior can own a change, without using telemetry about that person?

Exercise · 30 minutes

A first-quarter apprenticeship plan

Design a first-quarter plan for a junior joining a team you know, or for a junior in the case platform team of Nordvik Region. List the team's entry tasks with what each taught and who performs it now. Choose four to six milestones covering reading code, writing a test from a specification, reviewing a pull request and owning a small change with a revert drill. Set the junior's tool access by phase, starting below the team ceiling. Fix the AI-off share and name the exercises. Name the mentor and a second assessor, budget the mentoring hours, and state what evidence is kept and that representatives see the template before signing.

Deliverable: An apprenticeship plan with milestones, phased tool access, AI-off share, mentor, second assessor, mentoring hours, evidence kept and review dates.

Self-test

  1. What did the study by Humlum and Vestergaard, linking chatbot adoption surveys to Danish administrative records, find?

    1. Precise null effects on earnings and recorded hours two years after the launch
    2. A fall of about a fifth in the employment of the youngest workers in exposed occupations
    3. A 26.08 per cent increase in completed tasks, larger for less experienced workers
    4. A lower score on a comprehension quiz for participants who used an assistant
  2. Which rule does the chapter set for the junior's review of pull requests?

    1. It counts as one of the two required approvals once the mentor has signed it
    2. It replaces the senior's review for changes outside security-critical paths
    3. It is practice and not the gate, and it does not count as a required approval
    4. It is done only with the AI reviewer's comments visible, to save time
  3. How does the verdict label the claim that the junior developer will disappear?

    1. Observable, on the strength of the American payroll data
    2. Expected, because the entry tasks are already delegated
    3. Refuted, because every earlier wave of tools kept juniors
    4. Speculation, since no evidence cited supports the claim

Chapter 14 · 75 minutes

The Senior Developer, Staff and Principal Engineer

The lesson treats the senior developer and the staff and principal engineer across D2 Design, D4 Prove and D5 Steward. The senior's work is four jobs: reviewer, mentor, technical decision-maker and keeper of context. AI makes the first draft of change cheaper without making any of the four cheaper, so review becomes the bottleneck. Participants design a review budget and a professional-judgement clause for a senior developer charter.

Learning objectives

  • Explain what AI makes cheaper and does not make cheaper in each of the senior's four jobs
  • Design controls for the review bottleneck: inflow limits, reviewable changes, tiers, first-view samples and seeded errors
  • Draft a professional-judgement clause with its six parts and its limits
  • Explain the three duties specific to staff and principal engineers

Key concepts

The senior's four jobs
Reviewer, mentor, technical decision-maker and keeper of context. An assistant with retrieval finds text; it does not find reasons that were never written and cannot tell a deliberate oddity from an accident.
Review budget
A named share of the senior's working time for review, with a mentoring share beside it, changed only by recorded decision. It is the lever that keeps review from quietly becoming shallower as inflow rises.
Professional-judgement clause
Six parts in the role charter: the right to hold a change, the right to the explanation without the tool, the right to decline ownership, the right to record dissent, no use target in appraisal, and the right to unassisted work. It is not a veto and not immunity.
A second model is not a second opinion
One of four mechanisms that worsen the bottleneck, beside anchoring on the proposal, vigilance on a mostly correct stream and confidence in the author. Model errors are correlated, so an AI comment is never the human review.
Keeping the hands in
A senior or principal who only reviews may lose the working theory of the system, because the theory is maintained by changing the system. The charter for staff roles therefore includes a build share as well as a review share.

Interactive exercises

  • Sort: What the judgement clause gives and what it does not
  • Match: The senior's four jobs

Done on the lesson page, with feedback at once.

Discussion

  1. Why does the chapter place the right to hold in a role charter rather than in a general policy on AI tools?
  2. The senior is not the default owner of every change they have reviewed. What happens in your team to a change whose reviewer cannot pass the Understand test?
  3. Linnea Sjöberg holds 17 years of history of the case system; Ralf Hauser is one of five maintainers near retirement. What does succession look like before the farewell rather than at it?

Exercise · 25 minutes

A senior charter with judgement clause and review budget

Write a role charter for a senior developer in your team, or for the senior developer on the case platform team of Nordvik Region. List the four jobs and estimate weekly hours for each. Count review demand by tier and set a review budget and a mentoring share as shares of working time, with the date and who may change them. Write the decision rights: what the senior decides alone and what goes to the forum. Write the judgement clause with its six parts, the classes in which a hold applies and when a hold lapses. Remove any acceptance-rate or usage target for a named person, and plan the first-review test of three holds, three recorded disagreements and three declined ownerships.

Deliverable: A role charter with four jobs, review budget, mentoring share, decision rights, six-part judgement clause and a first-review test.

Self-test

  1. Which of the following is one of the six parts of the professional-judgement clause?

    1. The right to veto any generated change permanently, without review by peers
    2. The right to decline ownership of a change that fails the stewardship tests
    3. The right to see each colleague's acceptance rate
    4. The right to approve a change on the strength of an AI review comment
  2. What happens, under the clause, to a hold that is not answered in time?

    1. It lapses to the next decision-maker named in the charter
    2. It becomes permanent until the senior withdraws it
    3. It is overridden automatically by the pipeline after two days
    4. It is escalated to the works council for a ruling
  3. Why does the charter for staff and principal roles include a build share?

    1. Because staff engineers are cheaper than agents for mechanical changes
    2. Because the works agreement forbids roles that consist only of review and mentoring
    3. Because a reviewer who no longer changes the system risks losing its theory
    4. Because acceptance-rate targets require every engineer to generate code

Chapter 15 · 90 minutes

The Tech Lead and the Engineering Manager

The lesson treats the tech lead and the engineering manager, the two roles through which every decision about AI reaches a team, across D1 Frame, D3 Build and D5 Steward. Participants separate what the lead holds (intent, entry rules, the picture of the system, the stop) from what the manager holds (people, outcomes, headcount), build a list of paired measures, hold a headcount conversation on a six-part record and write a team working agreement.

Learning objectives

  • Explain what the tech lead holds and what the engineering manager holds, and the typical failure of each arrangement
  • Design a metrics list in which every measure is paired, dated and held at team level
  • Apply the six-part record to a headcount claim
  • Draft a team working agreement with review rules, protected files and a weekly rhythm

Key concepts

What stays with the tech lead
Four things no tool holds: the intent that precedes generation, the rules under which generated code enters the codebase, the picture of the system that makes the Understand test passable, and the stop. The lead may narrow a ceiling; raising one goes to the profile's owner.
Paired measures
Measures chosen so that no single one can be read alone: lead time with change fail rate, review wait time with a second reviewer re-reading five merged changes. They are held at team level, in groups of five or more, with per-person views switched off.
The figure that must not reach the board
The share of AI-assisted lines or the acceptance rate presented as productivity, as capacity or as the case for fewer developers. What may reach the board is a claim with scope, method, date, result and expiry.
Headcount record
Six parts: the claim as asserted, the scope, the measure and method with an evidence owner independent of the sponsor, the date and expiry, the alternatives for the capacity, and the decision owner with the next look.
Team working agreement
A short, versioned file in ten parts stating how a team works with AI and who is responsible for what. It narrows a delegation profile and never raises one, protects the files that govern the agents, and is reviewed on a date and on triggers.

Interactive exercises

  • Sort: Tech lead or engineering manager
  • Scenario: Can we cut the consultants by a third

Done on the lesson page, with feedback at once.

Discussion

  1. Where one person both approves a developer's code and holds the conversation about that developer's year, how should review and appraisal be kept apart?
  2. The practical guide says to establish what the team uses by asking, not by tooling that detects individuals. What do you gain and lose by asking?
  3. Onboarding is measured by the first change a new colleague can explain and has owned through production, not by time to first merge. How would that change your onboarding?

Exercise · 30 minutes

A team working agreement and weekly rhythm

Write a working agreement for a team you know, or for the claims core delivery team in Hamburg at Hansa Mutual. Put the inherited ceilings at the top and any narrower ones the team sets. Write the scope and ownership clause with a deputy for every owner. Write the review rules, including that an AI review comment never counts as an approval, and the oracle clause. List the protected set of files agents may not edit. Write the data clause, the metrics list with level, pair, expiry and non-use in appraisal, and the weekly rhythm in hours. State who may lower a ceiling, the review date and the triggers.

Deliverable: A working agreement with ceilings, ownership, review rules, oracle clause, protected set, data clause, paired metrics, weekly rhythm and review triggers.

Self-test

  1. According to the chapter's table of responsibilities, who takes a proposal to raise a ceiling to the owner of the delegation profile?

    1. The tech lead alone, who also records the new ceiling in the team working agreement
    2. The senior developer, under the judgement clause
    3. The platform engineer who registers the tool
    4. The engineering manager, after the tech lead proposes it with evidence
  2. What does the Wednesday block in the worked weekly rhythm of the Hamburg team produce?

    1. Acceptance criteria and a named owner for each item of the week
    2. A second reviewer re-reads five merged AI-involved changes and logs what the first missed
    3. A list of owners without deputies and any ceiling lowered this week
    4. A refreshed claim record and answers to any headcount question
  3. In a headcount record, what does the chapter require of the evidence owner?

    1. Independence from the sponsor of the claim
    2. Membership of the executive committee
    3. Access to per-person telemetry from the tool
    4. A background in finance rather than engineering

Chapter 16 · 75 minutes

Architects, Platform Engineers and Site Reliability Engineers

The lesson treats the developer's three neighbours across D2 Design and D5 Steward: the architect, the platform team and the site reliability engineer. The architect keeps the constraints that cross team boundaries; the platform team turns decisions about AI tooling into defaults on the golden path; the reliability engineer holds the error budget, which the book connects to the delegation ladder. Participants write a golden-path specification with AI tooling defaults.

Learning objectives

  • Explain what the architect keeps and what the developer's team keeps, and how a tool's proposal is routed between them
  • Design the four AI tooling defaults a platform team provides: allow-list, route, logging and cost, and supply chain
  • Explain how a spent error budget lowers the level of delegation for AI-originated change
  • Draft a golden-path specification with gates, tools, an exception route and an error-budget rule

Key concepts

A proposal that is an architectural change
A tool that proposes a dependency, an endpoint or a permission has proposed an architectural change. A code-ownership rule on those files routes the proposal to the architect's forum instead of letting it pass as an ordinary diff.
Golden path with AI tooling defaults
The opinionated and supported path to build something. The platform team adds four defaults: an allow-list of assistants and agents, a route through the AI gateway, logging and cost by team, and a supply-chain rule that reports a refusal as well as making it.
Exception route
A golden path made mandatory without an exception route makes teams with a real need leave quietly. An exception therefore has a named approver and an expiry date, and the specification says what happens at expiry.
Error budget connected to the ladder
The book's own conclusion: when a service's error budget is spent, the level of delegation for AI-originated change in that service drops. The rule lowers delegation by class and not by person, so nobody's performance is read from it.

Interactive exercises

  • Match: Who decides what among the neighbours
  • Scenario: A team wants to leave the golden path

Done on the lesson page, with feedback at once.

Discussion

  1. Neither organisation has a rule that says which decisions need the architect. What rule would you write, and how would a tool's proposal trigger it?
  2. The Nordvik specification records the question whether prompts are records as open rather than settling it by default. Why does that matter for what the gateway logs?
  3. The chapter says both organisations can state what the path contains and who owns it, and that this is a smaller claim than saying the platform governs AI tooling. What evidence would support the larger claim?

Exercise · 25 minutes

A golden-path specification with AI tooling defaults

Write a golden-path specification for one kind of service in your organisation, or for the Spring service path of Nordvik Region's platform team. Name the path, its version, its owner, the person accountable for use and the delegation profile that applies. List the pipeline gates and who owns their definitions, and state that no coding agent has write access to them. List each allowed AI tool with usage mode and route. State what the gateway records and what it does not. Write the supply-chain rule, including who is told about an unknown package name. Write the exception route with approver and expiry, the error-budget rule and a review date.

Deliverable: A golden-path specification with owner, gates, allowed tools, gateway logging, supply-chain rule, exception route, error-budget rule and review date.

Self-test

  1. Under the error-budget policy recorded in AIDR-1166 for the customer portal of Hansa Mutual, what happens to the Level 3 Bounded class when the service budget is spent?

    1. It is removed from the delegation profile permanently
    2. It continues unchanged, because patch-level dependency updates are reversible
    3. It drops from Level 3 Bounded to Level 2 Supervised for that service
    4. It rises to Level 4 Autonomous to restore the service faster
  2. What does the chapter's decision table say about the definition of a pipeline gate?

    1. The requesting team defines it for its own service and the platform team is informed
    2. The platform lead decides it, and it is not editable by the change it gates
    3. The architect defines it in the design forum for each service
    4. The coding agent may adjust thresholds within its mandate
  3. Which of these does the chapter list as a common failure of a platform team?

    1. Recording metadata only at the AI gateway
    2. Publishing a version number for the golden path
    3. Reporting a package refusal to the mandate owner
    4. Making the golden path mandatory without an exception route

Chapter 17 · 75 minutes

Testers, Quality Engineers, Product Owners and Designers

The lesson treats the roles on either side of the code, across D1 Frame and D4 Prove: product owners and designers, who say what the software is for, and testers and quality engineers, who find out whether it does it. The boundary around intent and prototype moves outwards because anyone can build a running prototype; the boundary around proof and ownership does not move. Participants build a role-boundary matrix.

Learning objectives

  • Explain how the tester's role shifts in weight from writing test code to owning the verification plan and exploring
  • Apply the four-part test of an oracle's independence: source, author, seeded faults and age
  • Explain the rule that a prototype is a question and not an answer, and its three conditions
  • Draft a role-boundary matrix that marks which boundaries move and which are fixed

Key concepts

Four-part test of independence
Independence has to be shown and not asserted. Source: written from the specification record and independent evidence. Author: someone other than the author of the change, and not the generator. Seeded faults: known faults are injected and caught. Age: the evidence carries a date and expires, by default after 90 days.
A prototype is a question
Product owners and designers can now build running prototypes. The rule the book proposes is that a prototype is a question and not an answer: it is labelled, built on synthetic data and never promoted as code.
Quality as an independent voice
The quality function stays independent only if it has access to evidence, the authority to hold a release at a defined gate, and a measure of success that is not delivery speed. Quality is reported by team, service and oracle, never as a count per named tester.
Role-boundary matrix
A record for one team of who frames, builds, proves and owns each kind of work, what AI may do in it and what is fixed. It is an annex to the role charters and the delegation profile, and carries no Level 4 for any class of work.

Interactive exercises

  • Sort: Which function does the activity belong to
  • Scenario: The prototype looks finished

Done on the lesson page, with feedback at once.

Discussion

  1. In both organisations one person asks, of any proposal to let an assistant write tests, who writes the oracle. Who asks that question in your team, and with what authority?
  2. A product owner builds a running prototype in an afternoon. What stops it from being promoted as code when it already seems to work?
  3. Measurement tied to reward invites distortion. How should the quality function itself be measured if not by delivery speed or defects per tester?

Exercise · 25 minutes

A role-boundary matrix for one team

Build a role-boundary matrix for a team you know, or for the e-services team of Nordvik Region and its citizen portal. List the activities from need to revert, with the developer functions as the spine: state the need and criteria, build a prototype, build the production change, write the oracle, review, check usability and accessibility, accept, and hold or revert. For each, name the accountable role as a person and the roles that may prepare it. Enter the highest degree of delegation the profile allows and its condition. Mark the fixed points: the oracle's independence, the unpromoted prototype, the named steward and the hold authority.

Deliverable: A role-boundary matrix with activities, accountable persons, preparing roles, delegation ceilings, fixed points and a review date.

Self-test

  1. According to the table of where the boundary moves, what must not move for the activity hold or revert a release?

    1. The release manager approves every hold in advance of the release window
    2. The pipeline acts on the basis of canary analysis alone
    3. The product owner signs the specification record
    4. The authority to hold or revert sits outside the pipeline
  2. What default expiry does the book use for verification evidence in the four-part test?

    1. 30 days by the clock, or at the end of the sprint if that is sooner
    2. 90 days by the clock, and earlier when the conditions change
    3. 180 days by the clock, the same default as for value claims
    4. One year, reviewed together with the delegation profile
  3. How does the chapter label the claim that testing as a role will end because models write tests?

    1. Speculation: no study reviewed for the chapter shows it
    2. Observable: test drafting is already in use at Hansa Mutual
    3. Expected: the trend in test generation supports it
    4. Measured: the Meta field report demonstrates it

Chapter 18 · 75 minutes

Developers in the Public Authority: Procurement, Public Code and Legitimacy

The lesson treats developers in a public authority across D1 Frame, D2 Design and D5 Steward, working through Nordvik Region and its tender NR-2030-041 for development assistants. Legality comes before capability, software that mis-encodes the law harms people at scale, and the public pays for the code and may read it. Participants cover procurement criteria, public code, accessibility, archives and the choice between in-house and supplier.

Learning objectives

  • Explain three ways in which a public authority is a different place to develop
  • Draft procurement criteria for an AI coding tool in terms of work classes, usage modes and verifiable evidence
  • Explain what publishing code as public code commits the authority to
  • Classify a component as in-house or supplier using the chapter's six questions

Key concepts

The tender is the first delegation decision
The book's conclusion for procurement: the ceiling of the delegation profile, the agentic switch and the review clause for model, price and feature changes belong in the contract, because a coding tool is not a delivered system and will test the limits on changing a contract.
Evidence in the criteria
Claims about a tool's benefit enter the procurement as statements with population, task, period and method, each criterion with a way to verify it, and the Region measures its own work after award.
Public code as a promise of maintenance
Software developed with public money and published for reuse under an open source licence. Publishing creates an expectation, so a component is a candidate only when it is generic, has no secrets or personal data in its history and has an owner; an unowned repository is not published.
Records on purpose
Specification records and ADRs are certainly records under the public-access and archives rules. What the Region keeps of prompts and runs is decided with the archivist, counsel and the union before the tool is switched on, and requests are answered by the competent official, not by the developer.
In-house or supplier per component
Decided per component and recorded with exit criteria. A component that encodes the Region's own legal interpretation, changes on its timetable and can be tested with an oracle the Region owns tends towards in-house.

Interactive exercises

  • Sort: In-house or supplier
  • Scenario: Publishing a component as public code

Done on the lesson page, with feedback at once.

Discussion

  1. The Region's own pilot figure has the same weakness as a supplier's claim. How should a tender treat evidence from the buyer's own pilot?
  2. Why does the practical guide ask for the criteria sheet to be reviewed with the union's IT representative before publication?
  3. The benefits-triage scoring is in a supplier's hands. Using the six questions, what would have to be true for the Region to judge what it cannot test?

Exercise · 25 minutes

Procurement criteria for an AI coding tool

Write a criteria sheet for buying a coding assistant for a public authority, using Nordvik Region's tender NR-2030-041 as the case. State the function needed in terms of work classes and usage modes, never in terms of a product. List mandatory pass-or-fail requirements such as processing location, no training on the Region's code and export of logs. Choose scored criteria and weights, each linked to the subject matter and each with a way to verify it. Add a review clause for model changes, price changes and new features, tested against the delegation profile. Write the record clause: what is logged, who may read it, how long it is kept and how it is exported.

Deliverable: A criteria sheet with functional need, mandatory requirements, scored criteria with verification, a review clause and a record clause.

Self-test

  1. Why did nothing in the framework agreement NR-2025-102 address the consultant who pasted a test-database connection string into a public assistant?

    1. The agreement covered only suppliers of finished systems
    2. The agreement had expired before the incident occurred
    3. The agreement for about 22 consultant developers had no clause on AI tools
    4. The agreement delegated all tool decisions to the consultants' employer
  2. Which answer to the chapter's six questions tends towards building a component in-house?

    1. The component encodes the Region's own legal interpretation
    2. The rule changes rarely, or on the supplier's timetable
    3. The component is a generic service used by many authorities
    4. The Region has nobody who can own the component
  3. Under the Region's rule, who answers a request for public documents that concerns code or design records?

    1. The developer who wrote the code, since they know it best
    2. The competent official, with the developer's help in finding the material
    3. The supplier of the coding tool, under the record clause
    4. The union's IT representative, after reviewing the logs

Chapter 19 · 75 minutes

Citizen Developers, Low-Code and the Non-Developer Who Builds

The lesson treats the non-developer who builds, across D1 Frame, D3 Build and D5 Steward. AI lowers the barrier of producing a first version without lowering the barrier of knowing whether it is right. Participants learn the risks of shadow IT (data, access, continuity and the legal role), governance without prohibition through a register, templates and sandboxes, four tiers, and promotion criteria that apply Name, Understand and Revert to a citizen-built tool.

Learning objectives

  • Classify a citizen-built tool into Tier A, B, C or D using the four tests
  • Explain why the chapter prefers a register, templates and a sandbox to prohibition
  • Apply promotion criteria based on Name, Understand and Revert to a tool built by a case handler
  • Draft a register entry that records each criterion as met, not met or not tested

Key concepts

Citizen developer
An employee outside the development organisation who builds software for work, with a spreadsheet, a form or workflow builder, a low-code platform or a natural-language app builder.
Shadow IT as a mismatch of visibility
Not a new category of fault but tools the organisation relies on and cannot see. Discovery is by asking and by service, never by watching named individuals, with a time-limited amnesty.
Four tiers
Tier A personal, Tier B team, Tier C business (personal data, money, a record of the organisation, more than one unit or unattended running) and Tier D project. Any doubt moves a tool up one tier, and Tier D is not a citizen build.
Promotion criteria
The stewardship principle applied to the tool: Name an owner and a deputy, Understand with a one-page data flow and test cases the maker did not write, Revert with a tested switch-off and fallback. A pipeline identity promotes, never the maker.
Build-your-own-tool register
The list of tools that exist, with owner, data classes and a sunset date, kept in version control. A criterion is recorded as met, not met or not tested, with a date, and it expires.

Interactive exercises

  • Sort: Which tier is this tool
  • Put in order: From a case handler's tool to a register entry

Done on the lesson page, with feedback at once.

Discussion

  1. The sanctioned route has to be at least as good as the unsanctioned one. What would make your organisation's sanctioned route worse than a consumer tool today?
  2. Both organisations found that the delegation profile written for developers did not cover the people who build most often. Who are those people in your organisation?
  3. Sunset is a decision taken at registration, not at departure. Which tools in your unit have outlived their maker?

Exercise · 25 minutes

A register entry and promotion criteria

Take a tool built by a non-developer in your organisation, or the missing-documents tracker of the benefits unit at Nordvik Region. Describe the task, who uses it and the manual fallback. Classify the tier with the four tests, moving up one tier on any doubt. Name the owner and a deputy, and describe the deputy's drill: find the switch-off and explain the data flow. Record the data classes and any assistants used. Say who writes the independent test cases, who reviews access and data flow, and how the revert is tested. Record each promotion criterion as met, not met or not tested with a date, and set review and sunset dates.

Deliverable: A register entry with tier, owner, deputy, data classes, criteria marked met, not met or not tested, and review and sunset dates.

Self-test

  1. Which tool belongs in Tier D and is therefore not a citizen build?

    1. A macro used only by its maker, with no personal data of others
    2. A workflow tool that ranks or decides about a named person
    3. A form used by colleagues in one unit, with internal data only
    4. A tracker holding personal data of citizens
  2. Who promotes a Tier C tool to production under the chapter's promotion criteria?

    1. The maker, once the unit head has signed the entry
    2. The unit head, using the maker's credentials
    3. The data protection officer, after screening the data
    4. The platform pipeline, with an identity that is not the maker's
  3. What is the highest degree of delegation the chapter's table allows for agentic work tools (Mode 3) in citizen building?

    1. None: reserved to developers and the platform team under a mandate
    2. Level 1 Assisted, for Tier A and Tier B tools only
    3. Level 2 Supervised, when the maker approves each step and runs known cases
    4. Level 3 Bounded, inside the platform sandbox

Module 4 · Part IV · Leading Change and Adoption

Part IV treats leading change: how adoption is measured without mistaking use for value, how team practice and culture decide whether the figures can be believed, what works councils and unions must be told and when, and what to do when AI-involved change breaks. Participants leave with an internal experiment and an adoption and value record, a team practice agreement, a consultation file with a telemetry description, and post-incident review fields for AI involvement.

Chapter 20 · 90 minutes

Measuring and Leading AI Adoption in Development

The lesson treats how an adoption programme in development is measured and led, across D3 Build and D5 Steward. Every claim about adoption, productivity and quality is a claim with scope, method, date, result and expiry. Participants learn the portfolio of use cases, four families of measure with gaming checks, why acceptance rate and lines of code mislead, the productivity J-curve, internal experiments, stop rules and the adoption and value record. The chapter stages the debate on whether AI makes developers more productive.

Learning objectives

  • Classify measures into the four families of use, experience, delivery and outcome, and give each a gaming check
  • Explain why acceptance rate and share of generated lines cannot carry a value claim
  • Design an internal experiment with a comparison, a counting rule, an independent oracle and a stop rule fixed in advance
  • Draft an adoption and value record that files the quoted and the measured figure side by side

Key concepts

Portfolio of use cases
An adoption programme is a portfolio of use cases by work class and usage mode, each with a sponsor, a hypothesis and a stop rule, and an evidence owner who is not the sponsor. A seat is an input, not an outcome.
Four families of measure
Use (reach and willingness to try), experience (how the work feels), delivery (whether one service got faster or less stable) and outcome (whether what shipped stayed shipped). Each measure carries a gaming check: a second measure that does not use the same data.
Acceptance rate
The share of shown suggestions a developer accepts. It measures a reaction to a suggestion and not the fate of the code, and its level depends on the configuration, so it is valid for one configuration and date.
Stop rule
A programme without one has the structure of a ratchet. A stop rule has a condition tied to evidence and not to mood, a stop path outside the tool and the sponsor, and a way to stop part of a use case.
Adoption and value record
The artefact AVR: a short versioned file in which the quoted claim and its basis are written down beside the measured figure, with what is pending and an evidence age. Claims are shown as verified, expired or asserted.

Interactive exercises

  • Sort: Four families of measure
  • Scenario: The stop condition is met and the sponsor disagrees

Done on the lesson page, with feedback at once.

Discussion

  1. With 12 pilot developers and six sprints, Nordvik Region can show a large effect and cannot show a small one. How should a small organisation decide when it cannot resolve the effect it cares about?
  2. Both sides of the debate accept that throughput and stability are read together. Which of your own figures is reported without its counterpart?
  3. The counting rule is agreed with the representatives before any data are collected. What would change if it were agreed afterwards?

Exercise · 30 minutes

Design an internal experiment and its record

Take an adoption claim in your organisation, or Nordvik Region's claim that the pilot made developers a third faster. Write the claim in one sentence, who quotes it and its evidence age. Write the scope: work class, usage mode, service and period. Choose a design, for example a task-level comparison with a recorded coin flip at planning, and state what it cannot control for and the smallest effect it can resolve. State the counting rule: no figure for a named developer and a minimum group size. Fix outcomes in the four families, each with a gaming check and a reading date. Say how the oracle stays independent. Write the stop rule in advance.

Deliverable: An experiment plan and an adoption and value record skeleton with quoted claim, scope, design, counting rule, outcomes, stop rule and expiry.

Self-test

  1. What does the chapter mean by a gaming check?

    1. A second measure, from different data, that would move if the first were gamed
    2. An audit by the works council of each named developer's acceptance rate every quarter
    3. A penalty applied to teams whose figures improve too quickly
    4. A comparison of the tool's dashboard with the supplier's benchmark
  2. Who should own the evidence for a use case in the adoption portfolio?

    1. The sponsor of the use case, who knows it best
    2. The supplier of the tool, under the reporting clause of the contract
    3. An evidence owner who is not the sponsor of the use case
    4. The developer with the highest acceptance rate
  3. What state are the two claims in the Nordvik record AVR-NR-2030-01 in at the start of the year, with an evidence age of five months?

    1. Both the usage claim and the value claim are verified
    2. The usage claim is verified and the value claim has expired
    3. Both claims were withdrawn by the tech lead in October
    4. The usage claim has expired and the value claim is asserted

Chapter 21 · 75 minutes

Team Practice and Culture: Pairing, Review Culture, Trust and Psychological Safety

The lesson treats team practice and culture for D3 Build and D4 Prove: why working with an assistant is not pairing, the review practices that decide whether review finds anything, how trust is calibrated with a trust ledger, what an assistant changes about speaking up (the record, the count and the draft), the stop right, safety to ask, and shadow AI. Participants run a retrospective on AI-assisted work and write a team practice agreement.

Learning objectives

  • Explain why an assistant can be worked with in a pairing-like way but is not a second person
  • Apply five review practices that keep review real when code is generated
  • Design a trust ledger and an open log that never rank a named developer
  • Draft a team practice agreement and run a blameless retrospective on AI-assisted work

Key concepts

An assistant is not a pair
An assistant supplies something like half of a pairing exchange, but it cannot be named, cannot explain a change a month later and cannot help revert it. The difference is the absence of someone who passes Name, Understand and Revert.
Trust ledger
A record kept by the team of outcomes by class of work and origin, with dates, showing where the tool was reliable and where it was not. Trust is calibrated, not maximised, and the ledger never ranks a developer.
The record, the count and the draft
Three points at which an assistant changes what speaking up risks: searchable prompts and run records, usage counts that developers will manage, and drafted defect reports that say less. Each is a rule a named leader sets.
The stop right
Anyone in the team may hold a merge, pause an agent run or ask for a change to be reverted, on a doubt they can state, without penalty if the doubt turns out to be unfounded.
Team practice agreement
The written, one-page form of the team's rules, stricter than the delegation profile and never looser, identified by the decision record that adopts it. It contains no clause a leader could use against a named person.

Interactive exercises

  • Match: Practices of a team that works with assistants
  • Put in order: A retrospective on AI-assisted work

Done on the lesson page, with feedback at once.

Discussion

  1. A reviewer may return a change as too large to understand. What happens today in your team to someone who says I cannot review this?
  2. Disclosure of AI involvement is routine and has one purpose. What would make developers stop disclosing, and how would you notice?
  3. The retrospective closes by asking what the team nearly did not say. Why is that question worth two minutes of silence?

Exercise · 25 minutes

A blameless retrospective on AI-assisted work

In a group of four to six, run the retrospective of the practical guide on a real or invented log of three near misses involving generated code. Open by restating the rule: names are not recorded, nothing said enters an appraisal, and anyone may pause the session. Read each entry without asking who made it. For each, ask what the assistant or agent was given and produced, what the reviewer saw, and what in the path let it through. Update a small trust ledger by class of work. Decide one change to the practice, one owner and a date. Close by asking what the team nearly did not say.

Deliverable: An anonymised log of the entries, an updated trust ledger and one agreed change to the practice with an owner and a date.

Self-test

  1. According to the chapter, what is the one purpose of disclosing in a pull request that an assistant or agent took part?

    1. To let the engineering manager compare how much each named developer uses the tool
    2. To tell the reviewer where to look harder and to feed the provenance record
    3. To reduce the number of approvals a generated change needs
    4. To assign liability to the tool's supplier if the change fails
  2. Which of these is part of the chapter's response to shadow AI?

    1. Monitoring of each named developer's network traffic
    2. A ban on all assistants until a tender has closed
    3. A report route that costs nothing for someone who pasted what they should not have
    4. A ranking of teams by the number of unapproved tools found
  3. How does the team practice agreement relate to the delegation profile?

    1. It is stricter than the profile and never looser
    2. It replaces the profile for the team that adopts it
    3. It may raise a ceiling when the whole team agrees
    4. It applies only to external members of the team

Chapter 22 · 90 minutes

Developers, Works Councils and Employment: Telemetry, Rights and Intellectual Property

The lesson treats developer tooling and employee representation across D3 Build and D5 Steward. A coding assistant brings telemetry, and telemetry is data about people. Participants learn the four degrees of participation and the rights that attach in Germany, Sweden, the Netherlands and the European Union, the five trigger points in the life of a coding tool, naming for stewardship and not for scoring, employment terms, ownership of output, and what a collective agreement on developer tooling contains.

Learning objectives

  • Explain which representation rights a coding assistant reaches and at which trigger points they arise
  • Draft a field-by-field telemetry description with purpose, grain and retention
  • Apply the four rules that name people for stewardship without scoring them
  • Design the outline of an agreement on developer tooling that follows the mandate and the delegation profile

Key concepts

Trigger points
Five moments at which duties to inform or negotiate arise: a licence or pilot, a vendor update, a telemetry switch-on, a mandate change and an evaluative use. A pilot with real developers on real work is use, whatever the label.
Telemetry description
A short, mechanical file that lists each field the tool collects with why it is collected, its grain (event, person or team), its retention and who may read it. It is part of the consultation file sent before anything is switched on.
Naming for stewardship, not for scoring
A record names a person for a change, not for a rate. Reports to managers are by team with a minimum group size of 5, person-level data is read only for the purpose it was collected for, and prompts are not retained unless the agreement says so.
An agreement that follows the mandate
Coding tools change monthly, so an agreement written about a product version is soon out of date. One written about classes of work, the mandate and the delegation profile survives, with a review that has an evidence date and triggers.
The employer's right in the program
Under Directive 2009/24/EC, Article 2(3), where a computer program is created by an employee in the execution of duties, the employer exercises the economic rights unless the contract provides otherwise. The developer's skills and know-how are not the employer's property.

Interactive exercises

  • Sort: Naming for stewardship or scoring people
  • Scenario: Switching on the dashboard

Done on the lesson page, with feedback at once.

Discussion

  1. A coding assistant is normally not a high-risk AI system, yet the same telemetry turned into an appraisal tool would change its position. Where exactly is that line in your tooling?
  2. The chapter says the evidence that agreements improve outcomes is thin, and argues for them from mechanism. Do you find the mechanism convincing, and why?
  3. What should an obligation to use an assistant, or an adoption target for a team, be treated as in your organisation?

Exercise · 30 minutes

A consultation file with a telemetry description

Prepare a consultation file for a coding assistant in your organisation, or for the pilot NR-DEV-001 at Nordvik Region. List who is affected and which body holds which right. Write the telemetry description field by field: for each field the purpose, the grain (event, person or team), the retention and who may read it. Fix the grain of every report before the first collection: by team, with a minimum group size of 5, never by named developer. State what the data may not be used for: rating, pay, promotion, discipline, access to work and ranking. Describe the stop path for the tool and for the telemetry, outside the tool.

Deliverable: A consultation file with affected groups and rights, a field-by-field telemetry description, report grain, excluded uses and a stop path.

Self-test

  1. For the trigger vendor update, in which an IDE update switches on completion by default, when is information due according to the chapter's table?

    1. Within 90 days of the update reaching developers' machines, when the first telemetry is read
    2. At the next annual review of the works agreement
    3. Only if the update also changes the licence price
    4. Before the update enters the managed image, with the default off until a decision
  2. What does the Dutch Works Councils Act give the works council for facilities that observe attendance, conduct or performance?

    1. A right to be informed after the facility is in use
    2. A right of consent under Article 27(1)(k) and (l)
    3. A right to nominate the supplier of the facility
    4. A right to read person-level telemetry on request
  3. Which statement matches the chapter's first rule on naming for stewardship?

    1. A record names a person for a change, not for a rate
    2. A record names a team only, never an individual reviewer
    3. A record names the tool and omits every human name
    4. A record names the developer with the lowest acceptance rate

Chapter 23 · 90 minutes

When It Breaks: Incidents, Outages and AI-Generated Defects

The lesson treats incidents in AI-involved software for D4 Prove and D5 Steward. An incident in which AI took part is analysed by the same method as any other, with a short list of additional questions. Participants learn the four kinds of event, the four stages of post-incident practice, why blameless review and the Name test are complements, five mechanism classes, what the verified public incidents support, the reporting clocks, and the review fields for AI involvement.

Learning objectives

  • Classify an event as a defect in generated code, an agent action beyond intent, a toolchain incident or a provider-side change
  • Explain how blameless review and the Name test answer different questions and work together
  • Classify the mechanism of a failure using the five mechanism classes and name the control that belongs in the process
  • Draft the AI-involvement fields of a post-incident review, including unknown as a value

Key concepts

The additional questions
Who owned the change? What did the tool do, and can anyone say? Was the oracle independent of the generator? Who could stop the change, and how long did it take? They are added to the usual incident method, not substituted for it.
Blameless and named
Blame asks who deserves a sanction; naming asks who owns the change. The record names roles and conditions, not culprits, the three tests become questions about the system, and the review protects the person nearest the system from becoming a moral crumple zone.
The model did it
Not a contributing condition, because a model holds no role in the change process. The review looks for conditions in the path: the oracle, the specification, the release path, the mandate and the toolchain.
Five mechanism classes
Shared blind spot, specification gap, unsafe release path, excess of agency, and toolchain or provider change. The first two concern the organisation's own proof and are the most common in a development organisation.
Unknown as a value
AI involvement is often unknowable, especially for ambient completion. The review field records unknown or unknown_partly with a consequence field, and the register reports the share of reviews with unknown involvement each quarter.

Interactive exercises

  • Match: Mechanism classes and what the review looks for
  • Scenario: The draft review says the model did it

Done on the lesson page, with feedback at once.

Discussion

  1. In both illustrative incidents a gap was known on paper and nothing connected it to an owner and a date. Where do such gaps sit in your own records right now?
  2. CrowdStrike and Knight Capital involved no AI. Why does the chapter give them so much space in a book about developers and AI?
  3. The review record contains names and sometimes traces of individual work. What must be agreed with representatives before the template is adopted?

Exercise · 30 minutes

AI-involvement fields for a post-incident review

Take a past incident from your organisation, or the home-care form change at Nordvik Region. Extend the review template with a block for AI involvement with the values none, suggested, drafted, executed, unknown and unknown_partly, and a consequence for not knowing. List the evidence that exists for each tool and what is not kept. Add the oracle field: who wrote it, from what source, and whether it could see the failing case. Add the three stewardship tests with a result and a time each, and the measured time from decision to revert. Add the mechanism class, a statement that no individual is named as a cause, and the reporting block. Then fill the fields and count the unknowns.

Deliverable: An extended review template filled in for one incident, with the number of unknown fields counted and dated.

Self-test

  1. What did the review PIR-NR-2030-0006 of the Nordvik Region form change find?

    1. A model fault in the lines of the interface written by the Mode 2 pilot
    2. An agent action beyond the intent of its mandate
    3. A specification gap, not a model fault; Understand failed for the mapping
    4. A compromised dependency in the build chain of the citizen portal's gateway client
  2. How long did the revert take from the decision in the Hansa Mutual incident, and what did the steward's result show?

    1. 22 minutes, and the Understand test failed
    2. 38 minutes, and the steward passed Name, Understand and Revert
    3. 47 minutes, and the canary stage had been skipped
    4. Two days, and the module had no owner
  3. Under NIS 2 Article 23(4), as the chapter's table gives it, what are the first two clocks for a significant incident?

    1. Notification within 4 hours and a final report within 7 days
    2. A single report within 30 days of the end of the incident
    3. Notification without undue delay and, where feasible, within 72 hours, with no early warning
    4. Early warning within 24 hours of becoming aware and incident notification within 72 hours

Module 5 · Part V · Regulation, Ethics and Responsibility

Part V sets the constraints around the craft: what the instruments that reach software ask of named parties, where professional judgement must go beyond the law, and who holds rights in and depends on the toolchain. Participants leave able to apply a role test, keep a dated duty register, turn a value into a rule with a check, follow a route for a request they doubt, and record the dependencies of the coding toolchain with a tested exit.

Chapter 24 · 90 minutes

Regulation as Constraint: AI Act, Cyber Resilience Act, Product Liability, NIS 2, DORA, GDPR

The lesson reads the instruments that reach software (the AI Act, the Cyber Resilience Act, the Product Liability Directive, NIS 2, DORA and the GDPR) and asks what each requires of those who write, review, release and keep code. None of the development provisions read distinguishes code written by a person from code written with an assistant. Participants apply a role test and build a dated duty register that ties each article to an addressee, an artefact and a holder. The content is framed as organisational implication, not legal advice.

Learning objectives

  • Apply the role test to decide which instruments address an organisation and in which role
  • Explain how a configuration change can alter an organisation's role under Article 25(1)(c) of the AI Act
  • Compare what the Cyber Resilience Act and the DORA technical standard ask of development and change
  • Draft duty register rows with addressee, artefact, evidence age, holder and ceiling for AI

Key concepts

The role test comes first
An article is a duty only for an addressee, and one team can hold several roles at once: manufacturer of a product on the market, provider or deployer of an AI system, entity under a cybersecurity regime, controller of personal data, publisher of software others integrate.
A quiet change of role
Under AI Act Article 25(1)(c), a deployer or third party that modifies the intended purpose of an AI system so that it becomes high-risk is considered its provider. The book's reading is that prompt, retrieval and tool configuration can amount to such a change, so the event must be visible before merge.
Generated code is the manufacturer's code
Under the Cyber Resilience Act the product is designed, developed and produced to the essential requirements of Annex I, with due diligence on third-party components under Article 13(5) and vulnerability handling for a support period of at least five years. The text does not exempt code an assistant wrote.
Independence of approval
Delegated Regulation (EU) 2024/1774 asks in Article 17(1)(b) for mechanisms that ensure the independence of the functions that approve changes. Reading this as the legal form of the independent oracle is the book's own step.
Duty register
A register in version control read when a decision is taken: instrument and article, addressee, what the text asks, what developers do, the artefact and the function. Each row has a holder and deputy, and the texts are re-read at most six months later and on every announced amendment.

Interactive exercises

  • Match: From article to developer action
  • Scenario: A small change to the system prompt

Done on the lesson page, with feedback at once.

Discussion

  1. The chapter calls a configuration change that turns a general-purpose assistant into an eligibility tool Nordvik Region's sharpest regulatory risk in development. What is the equivalent quiet change in your organisation?
  2. No row of the table of work classes is satisfied by Level 4, because every instrument assigns its duty to a named holder. What does that imply for how you describe agents to a supervisor?
  3. Why does the chapter prefer existing artefacts such as specification records, verification plans and review records as evidence over a separate compliance file?

Exercise · 30 minutes

Read one instrument into the repository

Choose one instrument from the chapter that addresses your organisation, or take Hansa Mutual as a financial entity under DORA. List the products the organisation supplies or publishes and the AI systems it builds or configures, and apply the role test. For three articles, copy the operative words as the chapter gives them and decide who the addressee is. For each, name the artefact in version control that evidences the duty and its age limit, the events that would change the role, a holder and a deputy, the ceiling for AI, and where a Level 4 prohibition applies. Record the date the text was read. Mark anything you could not verify as open.

Deliverable: Three duty register rows with article, addressee, developer action, evidencing artefact, age limit, holder, AI ceiling and reading date.

Self-test

  1. What does the chapter conclude about how the development provisions it read treat code written with an assistant?

    1. None distinguishes it from code written by a person; Article 50(2) may be the exception
    2. All of them place stricter review duties on generated code than on hand-written code
    3. The Cyber Resilience Act exempts generated code from the essential requirements of Annex I
    4. DORA requires that generated code be labelled in every change record
  2. From which date does Directive (EU) 2024/2853 apply to products, and what does its Article 4(1) say about software?

    1. From 11 December 2027; software is excluded unless embedded in hardware
    2. From 11 September 2026; software is a service and not a product
    3. To products placed on the market after 9 December 2026; a product includes software
    4. From 27 July 2026, with the Omnibus; software is a product only when it contains an AI model
  3. How often is the duty register re-read, according to the practical guide?

    1. Once, when the register is approved as a decision record
    2. Every 90 days, with the usage claims
    3. Only when a supervisor asks for it
    4. At most six months after the last reading, and on every announced amendment

Chapter 25 · 75 minutes

Ethics, Professional Responsibility and the Developer's Judgement

The lesson treats what judgement must add where the law ends, across D1 Frame, D2 Design and D5 Steward. Participants work with three values that recur in a developer's day (fairness, access and honesty), the limits of professional codes, the route for refusing to build harm, accessibility as the model of a value that became a rule, honesty about provenance, bias in what is built, and whistle-blowing. The artefact is a values-to-rule mapping with a check and evidence that expires.

Learning objectives

  • Explain why the chapter treats law as a floor and professional codes as insufficient on their own
  • Apply the five-step route of ask, record, escalate, decline and report to a doubtful request
  • Design checkable rules for accessibility and for bias: the gate, person and prototype rules and the proxy, counterfactual and reasons rules
  • Draft a values-to-rule record with a check owner independent of the generator and evidence with an expiry

Key concepts

Fairness, access and honesty
Three working categories. Fairness concerns who is counted, sorted or priced, and whether a person can contest the outcome. Access concerns who can use what is built. Honesty concerns the developer's account of the work to reviewers, colleagues, customers and the executive committee.
The escalation route
Ask what the software is for and whom it affects; record the concern and the answer; escalate to the tech lead and the owner of the delegation profile; decline in writing if the concern stands; report through the protected channel where a breach of law or danger remains.
An agent does not decline
A model generates and executes within a mandate and does not weigh a request against a value. The refusal that a developer might have made must therefore be designed into the mandate, the gate and the named owner, or responsibility lands on the person nearest the system.
Proxy, counterfactual and reasons rules
For every function that sorts, ranks, prices or routes people: the specification states which attributes may be used and which are proxies; the verification plan includes tests that change one protected or proxy attribute; and the code produces a reason in words the person can contest.
Values-to-rule record
A one-page mapping recorded as an AI Decision Record beside the delegation profile: the value and its source, the rule in one sentence a stranger can apply, the work classes constrained, the check and its independent owner, the evidence and its expiry, and the case the rule does not cover.

Interactive exercises

  • Put in order: The route for a request you doubt
  • Sort: Which value does the rule serve

Done on the lesson page, with feedback at once.

Discussion

  1. Nordvik Region declared its first rule in force for new and changed code only, and recorded that for inherited code the value is asserted and not shown. Why does the chapter call that an honest entry?
  2. Disclosure is not a cure: knowing that advice came from a tool does not remove its influence. What follows for how review is organised?
  3. The whistle-blowing instruments protect reports of breaches of listed law and not every ethical concern. What route exists in your organisation for the concerns in between?

Exercise · 25 minutes

Turn a value into an engineering rule and a check

Choose one value your organisation states, or fair treatment of policyholders at Hansa Mutual. Name it in the organisation's own words and cite its source. Name the point in the development loop where it is at stake. Write the rule as one sentence a stranger can apply and a tool can test; if it needs words such as appropriate or reasonable, rewrite it. Name the work classes it constrains and whether it lowers a delegation ceiling. Name the check and an owner independent of the author and the generator. Name the evidence, its record, its expiry and who looks at it. Name the case the rule does not cover and who is asked.

Deliverable: A one-page values-to-rule record with value, source, rule, work classes, check owner, evidence with expiry and the uncovered case.

Self-test

  1. What does the chapter say about the evidence that a professional code changes behaviour?

    1. Several large studies show that codes reliably change decisions
    2. It is thin and not encouraging, so codes must become rules met at the point of work
    3. Codes change behaviour only when they are made legally binding on the employer as well
    4. No one has studied the question, so the chapter makes no statement
  2. Which rule states that a change adding or altering an interaction pattern is tested by a person with a keyboard and a screen reader?

    1. The gate rule
    2. The proxy rule
    3. The prototype rule
    4. The person rule
  3. In the Hansa Mutual case of ranking broker enquiries partly on postcode, who decided whether postcode was a permissible input?

    1. The chief risk officer's delegate, after the proxy rule routed the request to review
    2. The developer who received the request, under the judgement clause
    3. The coding agent, within the limits of its mandate
    4. The Konzernbetriebsrat, under its co-determination right

Chapter 26 · 75 minutes

Intellectual Property, Open Source and Sovereignty in the Toolchain

The lesson treats three questions an organisation inherits when AI enters its toolchain, across D2 Design, D3 Build and D5 Steward: who holds rights in generated code, what the licences of its sources allow, and on whom the organisation depends. Its thesis is that a dependency nobody recorded is one nobody decided, and a right nobody checked is one the organisation only hopes it has. Participants write a toolchain dependency and exit record.

Learning objectives

  • Explain why the human contribution to generated code is the thread on which ownership hangs, as the chapter reads Directive 2009/24/EC
  • Classify the four routes by which licence contamination arises and name the two layers of detection
  • Review what the cited litigation does and does not settle for an organisation using a coding assistant
  • Draft a toolchain dependency and exit record with a tested alternative and an evidence age

Key concepts

Authorship of generated code
Directive 2009/24/EC protects software that is its author's own intellectual creation, so the human contribution is what ownership depends on, and no court in the Union has ruled on the point for code. The practical step is a provenance record where exclusivity matters and contract terms for consultants and suppliers.
Licence contamination
The arrival in a codebase of code whose licence terms the organisation cannot or will not meet. It arises by reproduction by the model, by a dependency an assistant or agent adds, by code pasted in by a person, and by code leaving the organisation.
Litigation as signal
Public cases do not settle what the organisation should do, and a single first-instance judgment is not the law. None of the four cases the chapter reads decides that an organisation using a coding assistant infringes, or that it does not.
Exit tested
An exit route that has never been used is a hypothesis. The test for a coding assistant is small and carries no risk to production: run held-out tasks on the alternative against a gate, record the result with an age, and record a failed test as failed.
Toolchain dependency and exit record
The chapter's artefact: dependencies by layer (editor, assistant and model, agent runtime, gateway, registries and key libraries, compute), each with a named owner, an exit route, a tested alternative and a review date.

Interactive exercises

  • Match: Instruments behind rights and dependence
  • Scenario: The exit test missed its gate

Done on the lesson page, with feedback at once.

Discussion

  1. Nordvik Region's second model scored 0.86 against a gate of 0.90 and the record says so. What does an organisation gain by recording a failed exit test as failed?
  2. Self-hosting changes the dependency and does not remove it: seven engineers own the serving stack. How would you weigh that concentration against a provider's retirement schedule?
  3. The dependency record asks how many maintainers a critical dependency has and what the organisation does to support it. What would an honest answer be for your stack?

Exercise · 25 minutes

A toolchain dependency and exit record

Record the dependencies of the coding toolchain of your team, or of the assistant NR-DEV-001 at Nordvik Region. List them by layer: the editor and its ambient features, the assistant and its model, the agent runtime, the gateway, the package registries and the open-source libraries that matter, and the compute. For each, name an owner, what the contract or licence says about training on your code and notice of model changes, the exit route, and whether an alternative has been tested, with the result, the gate and the date. For one critical library, record the number of maintainers and who reads its security advisories. Mark every exit that has never been tested.

Deliverable: A one-page dependency and exit record by layer, with owners, exit routes, test results with dates, and untested exits marked.

Self-test

  1. Which of the following is one of the four routes of licence contamination the chapter lists?

    1. A developer forgetting to renew a commercial IDE licence
    2. A provider changing the price of a seat during the contract
    3. A dependency that the assistant or agent adds, with its licence
    4. A works agreement that restricts the use of telemetry
  2. What does the chapter conclude from the four cases it reads under litigation as signal?

    1. Together they establish that using a coding assistant is lawful in the Union and the United Kingdom
    2. None decides that an organisation using a coding assistant infringes, or that it does not
    3. They establish that generated code can never be protected by copyright
    4. They show that training on code is always covered by the mining exception
  3. When is the dependency and exit record reviewed, according to the chapter's summary?

    1. Every five years, with the support period of the product
    2. Only when the supplier contract is renegotiated
    3. Whenever a developer leaves the team that owns the record, and otherwise every five years
    4. At the earlier of evidence expiry, a model-retirement notice and a change of terms

Module 6 · Part VI · The Developer as a Person

Part VI turns to the developer as a person: the competences the transformed role demands and how they are evidenced, what studies measured about offloading, flow, identity and wellbeing, and what may become of the role. Participants leave with a competence record and development plan, a personal practice plan with AI-off time, and a horizon register in which every statement about the future carries a label and a trigger.

Chapter 27 · 75 minutes

Competences and Developing the Developer

The lesson treats the competences that all five developer functions demand. Its claim is that a developer's competence is a claim that needs evidence: a record of judgement exercised, separating assisted from unaided performance, assessed by a second assessor outside the line, dated and with an expiry. Participants work with six competence groups, the kinds of evidence, frameworks, career ladders and hiring, and write a competence record and development plan.

Learning objectives

  • Explain the six competence groups and the developer functions each serves
  • Compare kinds of evidence of competence by what each shows, what it cannot show and when it expires
  • Apply the rule that the level is set from the lower of the assisted and the unaided evidence
  • Draft a competence record and development plan with stated purposes, readers and a second assessor

Key concepts

Six competence groups
Frame and specify; design and system thinking; read, review and verify; delegate and bound; steward; and AI literacy for the role. They are the book's own synthesis, and no research-based taxonomy for a workplace that uses AI broadly has been tested against outcomes.
Attendance is not competence
Neither attendance at a course nor tool use shows competence, and confidence is not evidence. Self-assessment, acceptance rate and completion of a module are listed in the evidence table as not evidence.
The lower figure governs
Evidence must separate assisted from unaided performance, and where both figures exist the lower governs. A group whose evidence has lapsed is shown as lapsed, not as the last level reached.
Second assessor
A person outside the line who observes or checks the exercises and writes what was seen. A record assessed by the line manager alone is exposed to the pressures of appraisal, and one assessed by an assistant to the failure the record exists to detect.
Competence record
The artefact CMP: level per group with evidence date and expiry, the developer's own comment and a development plan with one or two gaps and protected time. It is personal data, limited by stated purpose and reader, and it does not rank the developer.

Interactive exercises

  • Match: What each kind of evidence shows
  • Scenario: Two results for one developer

Done on the lesson page, with feedback at once.

Discussion

  1. In the worked example the lower figure came with the assistant's comment in view. What does that say about the condition under which the developer usually works?
  2. A common framework gives comparability and risks a form that does not fit a local post; a grade structure tied to a collective agreement fits and changes slowly. Which trade-off does your organisation face?
  3. The panel does not use an AI system to filter, rank or evaluate candidates. How does that follow from the prohibitions of Chapter 4?

Exercise · 25 minutes

A competence record for a mid-level developer

Write a competence record for a mid-level developer you know (anonymised), or for a developer in the integration and data team of Nordvik Region. State the purposes, the readers and what the record is not used for. Choose the groups the post needs. For each group choose evidence from the chapter's table, for example a seeded-defect review with and without the assistant's comment visible, an unaided explanation of a module and a revert drill. Name the second assessor. Set the level per group from the lower of the assisted and unaided evidence, with evidence date and expiry. Leave space for the developer's comment and set a plan with one or two gaps, the means, the date and protected time.

Deliverable: A competence record with purposes, readers, groups, evidence, second assessor, levels with dates and expiries, and a development plan.

Self-test

  1. Which expiry does the chapter use for competences that decay with disuse, such as reading and verification without the tool?

    1. 30 days
    2. 90 days
    3. One year
    4. Three years
  2. What does a seeded-defect review, done with and without the assistant's comment visible, show?

    1. Whether the developer attended the training on the tool
    2. How many suggestions the developer accepts in a week
    3. Whether the developer finds defects, and whether the assistant's comment changes that
    4. Whether the specification behind the change was a good one
  3. How is a competence group shown when its evidence has passed its expiry?

    1. As lapsed, not as the last level reached
    2. At the last level reached, with a note
    3. One level lower than the last level reached
    4. As Foundation, until the developer is reassessed

Chapter 28 · 60 minutes

The Developer's Own Mind: Craft, Flow, Cognitive Offloading and Identity

The lesson treats the developer's own mind as part of the system the stewardship principle relies on, for D3 Build and D4 Prove. Participants read what studies of cognitive offloading, complacency and learning with an assistant measured, in which populations, and what is not established; consider flow, craft pride, identity and wellbeing on evidence that is qualitative or divided; and agree a small practice plan with AI-off sessions and code-reading time.

Learning objectives

  • Explain cognitive offloading and what the cited studies establish as a pattern and not a rate
  • Compare the populations and methods of the studies before drawing a conclusion about developers
  • Classify the skills worth keeping by hand by the test or check that depends on them
  • Draft a practice plan with an AI-off block, reading time, a partner and an unaided work sample

Key concepts

Cognitive offloading
The use of action to change the information-processing demands of a task so as to reduce cognitive demand. The studies show a conditional pattern: offloading reduces effort and, under stated conditions, later unaided performance. No study has followed practising developers over years, so the rate of skill loss is unknown.
The manner of use changes the outcome
In the studies of learning with an assistant, what participants did with the tool mattered: asking for explanation preserved more than asking for finished code. The chapter draws from this an attempt-first practice that costs nothing.
Skills kept by hand
Those the Name, Understand and Revert tests and the independent oracle depend on: debugging an unfamiliar failure, reading code one did not write, explaining why a module is as it is, writing the oracle, reverting, and designing a small thing from nothing.
Practice plan
A small, reasoned and reviewed plan: what is offloaded and what is kept, an AI-off block that produces a written artefact, code-reading time, a kata or pair, a partner who does not appraise, an unaided work sample each quarter, and an expiry. It is not an input to appraisal.

Interactive exercises

  • Match: A practice for each skill kept by hand
  • Sort: What a practice plan contains and what it excludes

Done on the lesson page, with feedback at once.

Discussion

  1. The chapter refuses to turn a finding about students or knowledge workers into a statement about developers in general. What can you nevertheless take from those studies for your own practice?
  2. Why does the plan exclude tool telemetry on named persons, and what happens to practice when a record can be turned into a score?
  3. Nothing in the evidence fixes the right share of AI-off time. How would you reason your own share, and how would you know it was wrong?

Exercise · 20 minutes

A practice plan for one quarter

Draft your own practice plan for one quarter. List what you offload now and what you keep by hand, using the work classes of Chapter 4. Choose the skills to protect, starting with debugging and reading unfamiliar code. Set an AI-off block: how long, which assistants are off (completion as well as chat), what is done by hand and what written artefact it produces. Set code-reading time and what is read, with a first judgement written before any assistant comment. Choose a kata and its interval. Name a partner who does not appraise you and what they read. Set the unaided work sample for the end of the quarter, the reasoned share of AI-off time and the expiry.

Deliverable: A one-page practice plan with protected skills, AI-off block, reading time, kata, partner, quarterly work sample and expiry.

Self-test

  1. What does the chapter say is established when the studies are read together?

    1. A rate of skill loss of about one fifth per year for developers
    2. That assistants improve unaided performance in every population studied
    3. That offloading has no measurable effect on experienced professionals
    4. A conditional pattern across the studies, and not a rate of skill loss
  2. Why is debugging an unfamiliar failure on the chapter's list of skills to keep by hand?

    1. It had the largest score gap in the programming experiment and Revert needs it
    2. It is the skill on which assistants score worst in the public coding benchmarks
    3. It is required by Article 4 of the AI Act for all developers
    4. It is the only skill that cannot be practised in a kata
  3. What status do the practice-plan schemes at the two organisations have under AIDR-1137 and AIDR-1187?

    1. Final, after approval by the executive bodies
    2. Withdrawn, because the unions objected
    3. Interim, pending the agreements with the employee representatives
    4. Mandatory for all developers from the first quarter

Chapter 29 · 75 minutes

The Future of the Developer: Fewer, More or Different?

The lesson asks whether there will be fewer, more or different developers. It uses a horizon register in which each trend carries a label (observable, expected or speculation), an evidence age and a trigger in the organisation's own data. Participants weigh employment and demand data, agent-heavy teams, the specification as the main artefact and outside forces, rehearse the debate, and examine the author's five projections, each with a threshold that would change it.

Learning objectives

  • Classify statements about the future of the developer role as observable, expected or speculation
  • Compare the case for concern and the case for calm on the number of developers, and state what both accept
  • Explain the author's five projections and the threshold attached to each
  • Draft a horizon register with triggers that are observable in the organisation's own data

Key concepts

Horizon register
A list of trends, not a forecast. Each entry states the trend in one sentence, its label, the developer functions it concerns, the evidence and its age, the trigger that would change the label and the posture the organisation takes. It is kept as HZN in version control and approved by a decision record.
Three labels
Observable means happening now and documented in a cited source; expected means supported by a stated trend or a decided instrument; speculation means plausible and unevidenced. Most quantitative evidence is from the United States and from 2023 to 2026.
Agent-heavy team
A team in which a large share of changes is drafted by agents, with developers who frame, review and answer for them. Each stewardship test has a characteristic failure that more changes make more likely.
Projection with a threshold
Each of the author's five projections is paired with an observation that would make the author change it. The Level 4 prohibitions are not a projection: they are the ceiling the book recommends.
Different, with a qualification
The verdict's best single answer to the title: the work moves towards D1 Frame, D4 Prove and D5 Steward, and the entry route and the named steward are the two things an organisation can influence.

Interactive exercises

  • Sort: Observable, expected or speculation
  • Put in order: Keeping a horizon register

Done on the lesson page, with feedback at once.

Discussion

  1. The concerned side treats the entry-level data as the earliest signal of a larger change, the calm side as a hiring cycle that predated the technology. What observation would move you from one reading to the other?
  2. Projection P5 says the named steward persists because the law names a party. Which of the book's arguments would have to fail for that to be wrong?
  3. Nordvik Region's concern is the number of juniors it can afford to place, Hansa Mutual's the number of maintainers who will be gone. What is the equivalent entry in your own register?

Exercise · 25 minutes

A horizon register for developer roles

Write a horizon register for developer roles in your organisation, or for Hansa Mutual. Choose four or five trends that matter, for example the entry route, agent-authored change, the specification as reviewed artefact, the retirement of legacy maintainers and a dated legal duty. For each, write the trend in one sentence, its label, the developer functions it concerns and the evidence with its age in months. State the scope limit of the evidence: country, period and occupation. Write the trigger as an event observable in the organisation's own data, the posture taken now, the owner and the review date. Require the register before any headcount decision that cites AI.

Deliverable: A horizon register of four or five labelled trends with evidence age, scope limit, trigger, posture, owner and review date.

Self-test

  1. How does the verdict label the statement that total employment in software roles in the EU holds to 2036, with a shift in the content of the work?

    1. Observable
    2. Speculation
    3. Expected
    4. Refuted
  2. Which projection does the author label as speculation?

    1. P1: the work moves towards D1, D4 and D5 and total employment holds
    2. P3: a few named stewards answer for many agent-authored changes in some units
    3. P2: the entry route survives where organisations build it deliberately, and thins elsewhere
    4. P5: the named steward persists because the law names a party
  3. What does the chapter say about the Level 4 prohibitions in relation to the projections?

    1. They are projection P6 and carry their own threshold
    2. They are expected to be lifted once agents double their task length again
    3. They apply only until the Cyber Resilience Act takes effect
    4. They are not a projection but the ceiling the book recommends

Module 7 · Part VII · Experience and Conclusions

Part VII tests the book against experience. It reads public cases from primary records and derives nine anti-patterns, follows the two organisations through a year of records, draws conclusions and a twelve-month plan for each with ten local measures, and judges the five-part thesis against the evidence. Participants leave with an anti-pattern check, a ledger and year read-out, a twelve-month plan and a scorecard that carries the age of each piece of evidence.

Chapter 30 · 90 minutes

Case Studies and Anti-Patterns

The lesson reads six public cases, each described only from a primary record, and draws from them three recurring mechanisms and a catalogue of nine anti-patterns across all five developer functions. Each anti-pattern has the function it concerns, the stewardship test it fails, an early signal and a control. Participants review their own estate against the catalogue and learn why open findings are left open and partial ones are not rounded up. Cases are discussed by mechanism and control, never as instructions.

Learning objectives

  • Explain the three mechanisms that recur across the six records
  • Classify an observed practice as one of the nine anti-patterns and name the stewardship test it fails
  • Compare the failure cases with the one success case and say what the success case did differently
  • Review a team's estate against the catalogue, marking each answer pass, partial, open or not assessed

Key concepts

The gate sat inside what it governed
The first recurring mechanism: a gate or a record that could be altered or bypassed by the thing it was meant to check, as where a release pipeline could be changed by a contributor or a privileged role left no log of its use.
A name was trusted and not checked
The second mechanism: a package name suggested by a model reached a published README, a statement that a system could not do a thing was repeated before anyone tested it, and an update arrived from a trusted source.
A count replaced an outcome
The third mechanism, for which the successful case is the teacher: the Google migration report chose an outcome measure rather than counting suggestions accepted. The acceptance-rate dashboard is its anti-pattern.
Anti-pattern catalogue
Nine entries: acceptance-rate dashboard, unowned agent, generated test that proves nothing, junior hole, review rubber stamp, secret in the prompt, vibe-coded production system, trusted name and open pipeline. Each begins as a step that looked reasonable.
Anti-pattern check
One file per review with findings, owners, dates and an expiry. Each answer is marked pass, partial, open or not assessed from the inputs and not from memory, a partial is not rounded up, and an independent reviewer re-runs two answers against the evidence.

Interactive exercises

  • Match: Anti-patterns and their early signals
  • Sort: Three mechanisms that recur

Done on the lesson page, with feedback at once.

Discussion

  1. No record supports a conclusion that developers were careless. Why does the chapter insist on this, and how does it change what you look for in a review?
  2. Two cases readers expect were dropped because no primary record could be opened. What does that discipline cost the chapter, and what does it buy?
  3. The catalogue is made of failures and has one success case. What would it take for your organisation to write up a success with the same rigour?

Exercise · 30 minutes

Review one team against the anti-pattern catalogue

Fix a scope in one sentence: a team, a product line or a platform, and a period. For each of the nine anti-patterns, write the early-signal question from the catalogue and answer it from records, not from memory: for example, is there a report that counts suggestions accepted and says nothing of delivery, or an agent or repository whose owner has left? Mark each answer pass, partial, open or not assessed, and name the test it fails. For each open or partial finding, assign the control from the catalogue, an owner and a date. Confirm for each agent that none acts at Level 4 on the prohibited work. Name an independent reviewer.

Deliverable: An anti-pattern check with nine answers, marks, failed tests, assigned controls with owners and dates, an independent reviewer and an expiry.

Self-test

  1. Which stewardship test does the catalogue say the unowned agent fails?

    1. Understand, because nobody can explain what the agent changed
    2. Revert, because the agent's credential cannot be revoked
    3. None of the three, since an agent is not a change
    4. Name, because nobody can say who owns it or its permissions
  2. What does the chapter say about the Amazon Q Developer extension case in terms of the tests?

    1. Revert held and a gate failed; the control named is a gate contributors cannot alter
    2. Name failed, because nobody at the vendor owned the extension
    3. Understand failed, because the generated tests shared the assumptions of the generator's code
    4. All three tests passed, and the case is listed as a success
  3. Which is the only success case in the chapter, and what does the chapter note about its figures?

    1. Knight Capital, whose figures come from a regulator's order
    2. The Horizon system, whose figures come from a High Court judgment
    3. AI-assisted migration at Google, whose figures are estimates by the people who did the work
    4. The Nx build tool, whose figures come from a maintainers' advisory

Chapter 31 · 75 minutes

A Year in Development: Nordvik Region and Hansa Mutual

The lesson follows named developers, leads and managers at Nordvik Region and Hansa Mutual from September 2030 to August 2031 and shows where the instruments of the book held, where they did not and what stayed open. The year is illustrative and measures nothing. Participants draw out its four conclusions, compare the two organisations along six lines, and learn to keep a ledger of commitments, run a quarterly drill with the tools off and write a year read-out.

Learning objectives

  • Explain the four conclusions of the year and the events that support each
  • Compare the two organisations by frame of legitimacy, rhythm, route to representatives, ceilings, drills and open items
  • Review how evidence ages and expiries changed levels of delegation during the year
  • Draft a ledger of commitments and plan a quarterly drill with the tools off

Key concepts

The first honest numbers were lower
The 42 per cent became 27 per cent in one sample, and a third faster became an interval that included no difference. Neither says the tools do not work; a dashboard and a survey had answered a different question from the one a senior body asked.
Evidence expired faster than it was re-measured
Claims and rehearsals lapsed on dates that were derivable on the day each record was written. When the rehearsal behind Hansa's class approval lapsed, the Level 3 Bounded class fell to Level 2 Supervised on a date nobody had to decide.
The failures that mattered were quiet
A flag silently ignored, a gap listed without an owner, a build in a repository nobody owned, a package whose name existed. No dashboard showed any of them, and each was found by a person.
Records turned disagreement into text
A senior's dissent stayed in a design record, a quality engineer's right to hold a release was in the role-boundary matrix, and a doubtful ranking went to the chief risk officer's delegate through a rule.
Year read-out
A file in version control that counts commitments as closed or open against their closing records. It reports by team, never by named developer, and contains no acceptance rates, prompt logs or appraisal data.

Interactive exercises

  • Put in order: The year in order
  • Scenario: Reading the ledger at the quarter

Done on the lesson page, with feedback at once.

Discussion

  1. In the dark week at Nordvik Region the revert outside the pipeline missed its target, and at Hansa Mutual one tool could not be switched off. What would a week with the tools off reveal in your team?
  2. The similarity is called the more important finding: in both organisations answerability sat with a named senior person. Who is that person for AI in development where you work?
  3. A requirement recorded as an assumption cost 53 applicants ten days. Which of your current assumptions has neither an acceptance criterion nor an owner and a date?

Exercise · 25 minutes

A ledger of commitments and a drill with the tools off

Open a ledger for your own team in the form of the practical guide. Enter at least five commitments already made about AI in development: what, in which record, by when and who closes it. Enter each quoted figure with its method, its date and its expiry, and derive the date on which each lapses. Mark every entry without a closing record as an open item and not a result. Then plan one drill for the coming quarter with the tools off: an owner explains a change unaided, a revert runs outside the pipeline, and the time is measured against a target. Name who holds the stop and who reads the result.

Deliverable: A ledger of five or more commitments with records, dates, expiries and open items, and a one-paragraph plan for a tools-off drill.

Self-test

  1. What happened to the Level 3 Bounded class of patch-level dependency updates at Hansa Mutual when its revert rehearsal lapsed on 31 December?

    1. It was withdrawn from the delegation profile for the rest of the year
    2. It fell to Level 2 Supervised until the rehearsal was repeated in January
    3. It continued at Level 3 because the class approval was still valid
    4. It was extended to the payment path to make up for lost time
  2. What does the chapter say the illustrative year can and cannot show?

    1. It shows that the instruments raise productivity by a measurable amount
    2. It shows that Hansa Mutual's approach is better than Nordvik Region's
    3. It shows that Level 4 is safe once drills are passed
    4. It can show that the instruments are workable and cannot show that they work
  3. How were the quiet failures of the year found?

    1. Each was found by a person, such as an applicant who telephoned or a claims handler
    2. Each was flagged by the coding tool's own dashboard within an hour of the release
    3. Each was caught by the AI reviewer's comments on the pull request before it was merged
    4. Each was reported by the supplier under the notice clause

Chapter 32 · 90 minutes

Nordvik Region and Hansa Mutual: Conclusions for Two Organisations

The lesson turns the records of the book into conclusions for Nordvik Region and Hansa Mutual: what the records establish, what stayed open, a twelve-month plan from September 2031 to August 2032, the decisions that belong to named leaders, ten measures by which the book's own claims can be judged locally, and the risks with their early signals. Participants learn the three rules that shaped the plans and adapt them to their own organisation.

Learning objectives

  • Explain the three rules that shaped both twelve-month plans
  • Compare the conclusions, first moves and main residual risks of the two organisations
  • Apply the ten measures K1 to K10, each with an owner, an evidence owner, a method and an evidence-age rule
  • Draft a twelve-month plan that closes what has expired before opening anything new

Key concepts

Close before opening
The first rule and the order of work: close what has expired before opening anything new. The rule runs through both plans, and the first act in each organisation is to restate with its age the claim that reached a senior body.
No ceiling rises without a record
The second rule: no ceiling in a delegation profile rises without a decision record and evidence. Both plans raise none; Hansa Mutual's one Level 3 Bounded class is renewed on measured reverts and a current rehearsal, or lowered.
Owners and watchers are separate
The third rule: the person who owns a step is not the person who reads whether it closed. An owner who also reads the result has marked their own work, the same logic as the independent oracle.
Ten measures
K1 to K10 tie the plans to the five parts of the thesis: the three tests on a sample of changes, current profiles, oracle independence, review, claims, ownership, the junior route, exit tests, competence and supply chain. Each says what would count against a claim of the book.
Risk with a watcher
Each risk is listed with an early signal, a watcher who is not the owner of the work and a response: for example, a planning paper that repeats a third faster, or a rehearsal older than 90 days behind the Level 3 class.

Interactive exercises

  • Sort: Whose risk is it
  • Scenario: Who reads whether the step closed

Done on the lesson page, with feedback at once.

Discussion

  1. The chapter concludes that Nordvik Region's ceilings are right for what it has shown and should stay. What would have to be filed before a rise could be considered?
  2. A figure that went to the executive board without its scope cannot be recalled, but it can be restated. Why is the restatement a decision for the group CIO and not a communication task?
  3. If the Understand test passes on every sample in a quarter with no tool-free period, the practice plans should be reduced and not defended. Would your organisation act on a measure that counted against its own programme?

Exercise · 30 minutes

A twelve-month plan with owners and watchers

Draft a twelve-month plan for AI in development in your own organisation, following the three rules. First list what has expired or was never filed: claims without an evidence age, rehearsals older than 90 days, repositories without a living owner, agreements not concluded. Put closing these in the first quarter. State that no ceiling rises without a decision record and evidence. For each step name an owner and a separate watcher. Choose five of the measures K1 to K10 and for each give the baseline with its date, the evidence owner, the method and the evidence-age rule. List three risks with an early signal, a watcher and a response, and the decisions that belong to named leaders.

Deliverable: A twelve-month plan by quarter with owners and watchers, five measures with dated baselines, three risks and a list of leadership decisions.

Self-test

  1. According to the comparison table, which of Name, Understand and Revert is hardest for each organisation?

    1. Revert for Nordvik Region, and Understand for Hansa Mutual
    2. Name for Nordvik Region, and Revert for Hansa Mutual
    3. Understand for Nordvik Region, and Name for the estate at Hansa Mutual
    4. Understand for both, because of ambient completion
  2. What does the plan require before Hansa Mutual's Level 3 Bounded class under MND-HM-DEV-01 is renewed?

    1. Measured reverts and a rehearsal no older than 90 days, or a drop to Level 2
    2. A rise in the acceptance rate of the IDE assistant across the claims product line
    3. The signature of the nearshore partner on the developer annex
    4. A benchmark showing that the agent resolves more issues than a developer
  3. What does the chapter identify as Nordvik Region's least examined exposure?

    1. The two junior developers in their first quarter
    2. The enterprise architect's review of the public status vocabulary for the citizen portal
    3. The published citizen e-service components
    4. The consultant developers and supplier teams, whose tools nothing yet binds

Chapter 33 · 90 minutes

Conclusion: The Developer with AI Judged

The lesson judges the five-part thesis of the book against the evidence the book gathered. For each part it separates what is established, what is expected, what is speculation and where the evidence is thin, and gives a verdict. Participants examine the ten places where the book found no study, what would show the thesis wrong, the author's labelled projections, and five things to do on Monday, one per developer function, and fill a thesis scorecard for their own organisation.

Learning objectives

  • Explain the verdict on each of the five parts of the thesis and the thinnest point of each
  • Classify a claim of the book as established, expected or speculation, using the chapter's meaning of established
  • Review where the book's evidence is thin and what would show the thesis wrong
  • Apply the five Monday actions to one's own organisation and record the results in a scorecard

Key concepts

Established
Used in this chapter only for what is both observable and in force. The book's own conventions, such as the 90-day and 180-day evidence clocks, the starting levels, the review budget and the AI-off share, are design choices and not findings.
Verdicts part by part
Part 1 is expected in direction and speculation in pace. Part 2 is firm where law and documented failure make it firm and recommended elsewhere. Part 3 is conditional. Part 4 is strongest as a design principle. Part 5 holds, because it can be checked against an organisation's own records.
Stronger on records than on outcomes
The thesis is stronger where it asks for records and weaker where it predicts outcomes. The chapter lists ten places where the book found no study, including a designed apprenticeship, review under volume and the developer's own skill over years.
What would show the thesis wrong
Independent multi-year evidence of better outcomes without named owners and independent checks, or evidence that developers who never write or read code by hand verify as well as those who do. Nothing found meets either bar, which the chapter calls a weak form of support.
Thesis scorecard
A record in version control that gathers the verdicts with the age of each piece of evidence. A claim past its expiry is marked expired and not removed, and the field that counts refutation tests seen is zero.

Interactive exercises

  • Match: Five things to do on Monday
  • Sort: Established, expected or speculation

Done on the lesson page, with feedback at once.

Discussion

  1. The thesis has not been refuted, and the chapter says it could not have been by the evidence gathered. How much weight should a design principle carry when its outcomes are untested?
  2. A critic could say that few developers ever passed Understand for a legacy module without the colleague who wrote it. How would you answer that challenge?
  3. Part 5 can be checked in an afternoon against an organisation's own records. What would such an afternoon find in yours?

Exercise · 30 minutes

Five Monday actions and a scorecard

Plan the five Monday actions for your own organisation, one per function. D1 Frame: take the last feature shipped and list every requirement recorded as an assumption, giving each an owner and a date or an acceptance criterion. D2 Design: choose one constraint that exists in no file and write it as a decision record with a checkable rule. D3 Build: write one row of a delegation profile per work class for a tool in use and plan a test of the stop. D4 Prove: plan a seeded-defect review with the assistant's comments hidden. D5 Steward: choose one service, ask its owner to explain the last change without the tool and time a revert. Enter the planned results in a scorecard with evidence ages.

Deliverable: A one-page plan of five actions, each with the record it produces, and a scorecard skeleton with evidence ages and expiries.

Self-test

  1. What verdict does the chapter give on Part 3 of the thesis, that verification becomes the scarce skill and the junior pipeline must be rebuilt?

    1. It holds without qualification, because several long-term studies confirm it
    2. Conditional: pressure on the entry route is observable, the remedy untested
    3. It is refuted by the field experiments that found productivity gains
    4. It is speculation in every respect and should be dropped from planning
  2. Which part of the thesis does the chapter say has the most direct support, and why?

    1. Part 1, because employment data for Europe confirm the transformation
    2. Part 2, because benchmarks show agents fail above Level 3
    3. Part 4, because courts have already applied the three tests
    4. Part 5, because it is partly a method and can be checked against an organisation's own records
  3. Where does the author's projection Q3 expect the ladder to be raised first?

    1. At Level 3 Bounded, in mechanical, reversible classes such as dependency patches
    2. At Level 4 Autonomous, for security-critical code once models improve on the benchmarks
    3. At Level 2 Supervised, for decisions about named developers
    4. Nowhere, because the ceilings are fixed by law for all classes