AI Developer: teacher's guide

All courses / AI Developer / Teacher's guide

How to use this guide

The guide holds everything a teacher needs to run the course on AI Developer: the lecture of each module with a timed outline, the teaching plan of every lesson, the discussion questions, the exercises and the answers to the self-tests. The agendas of the three formats are on the course page; the slides are in the deck of the book.

Executive briefing (90 minutes): A briefing on what leaders must decide when AI is used broadly in development: the ceiling of delegation, who owns a change, which figures may reach the board and what a plan for the next twelve months contains. It uses the two fictional organisations, Nordvik Region and Hansa Mutual, and ends with the decisions that belong to named leaders.
One-day seminar (1 day): A working day that takes one team's use of AI in development from inventory to plan. Participants write a delegation profile, a mandate with a never list, a verification plan with an independent oracle and a release gate with a rehearsed revert, then turn to measures, team practice and what to do on Monday. Each block draws on the worked examples of Nordvik Region and Hansa Mutual.
Full course (7 weeks, one module a week): The full course follows the seven parts of the book, one module a week, with a lecture on the part, a lesson per chapter and an exercise that produces an artefact for the participant's own team. The longer second and third modules can each be spread over two weeks. The course ends with a capstone in which participants assemble their artefacts into a twelve-month plan.

Keynote on the whole book · 45 minutes

AI may draft, generate and execute. It may not own.

For developers, engineering leaders and executives at a conference or an all-hands meeting

When AI writes, reviews, tests and deploys code across an organisation, the developer is not abolished. The translation into code becomes cheap, and the scarce work becomes knowing what to build, showing that it is right and answering for it in production. The keynote sets out the book's five-part thesis, the delegation ladder and its ceiling, and the stewardship principle with its tests Name, Understand and Revert. It is candid about the evidence: productivity studies disagree, claims expire, and the thesis is strongest where it asks for records an organisation can check this week.

6 min	A change nobody can explain Two opening cases: a merged fix with no record of what a suggestion contributed, and an agent whose every step is logged. In neither did an AI system take a decision; in both the missing thing is an owner who can explain the change. The organisation had a decision for the tool and none for the ownership of the change.
8 min	Cheap generation, scarce proof Development has always been partly translation; AI does the translation into code and leaves framing, proving and owning. Three studies, three results: faster on one task, more completed tasks in field experiments, slower for experienced developers in their own codebases. The strain on the role is on the capacity to prove and to own, more than on the capacity to produce.
9 min	A ladder with a ceiling Five functions, D1 Frame to D5 Steward, and ten classes of work, each with its own degree of delegation. The lowest of five answers governs: reversibility, blast radius, who is affected, evidence and the strength of independent checks. Five kinds of work are never Level 4 Autonomous, whatever the evidence or the saving.
9 min	Name, Understand, Revert A named owner who can explain the change without the tool and stop it from outside the pipeline. The test oracle must be independent of the generator: authorship, source and protection, shown by seeded faults. A gate the change cannot alter and a revert rehearsed recently enough to count.
7 min	The people who make the next seniors The entry tasks that taught the craft are the tasks assistants do best; the route must be rebuilt, not assumed. Review capacity is a number; a review budget and a judgement clause keep it from thinning. Measures stay at team level; tool data never rates, pays or ranks a named developer.
6 min	What to do on Monday Write the evidence age at the top of the oldest claim about AI in your development organisation. Run the Understand test on one recent change and time one revert from the decision. Treat the thesis as design rules to test in your own records, and let the result count against it if it does.

What the audience takes away

The developer is transformed, not abolished: from author of code to framer, verifier and steward of software.
Delegation is graded per class of work and has a ceiling; ownership never moves to the tool.
Productivity, quality and competence are claims that need evidence, and evidence expires.

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.

Lecture · 45 minutes

From author of code to framer, verifier and steward

The lecture carries the argument of Part I. Development has always been partly translation, and AI now performs the translation into code cheaply; what stays expensive is knowing what to build, showing that it is right and answering for it in production. The lecture follows that argument through the history of development practice, through five pressures whose evidence is graded as measured, surveyed, vendor or argued, and into the frame of the book: D1 Frame to D5 Steward, the delegation ladder set per class of work, five Level 4 prohibitions, and the stewardship tests Name, Understand and Revert.

7 min	Two changes nobody can explain Nordvik Region: a merged fix to a national-register interface that no record ties to a suggestion and that a second developer cannot explain weeks later. Hansa Mutual: an agent whose every step is recorded opens a pull request against a claims service; the record exists, the owner's understanding does not follow from it. In neither case did an AI system take a decision; the question in both is who owns the change.
8 min	What each practice answered Craft, structured programming, waterfall, agile, DevOps, open source and platform engineering each answered a scarcity, and none replaced its predecessor. Earlier automation, from compilers to completion, made accidental difficulty cheaper; Brooks's essential difficulty stayed where it was. The ownership idea of 'you build it, you run it' is the root of the stewardship principle, and lapsed ownership is visible in both organisations before any AI.
10 min	Five pressures and four grades of evidence Adoption and headcount expectations, backlog and legacy, security and supply-chain demand, regulatory duty, and adversaries with the same tools. Three productivity results (55.8 per cent faster on one task, 26.08 per cent more completed tasks, 19 per cent slower for experienced developers) measure different people and tasks, not one quantity. The duties in law are the firmest ground because they are written down, and they attach to named parties, not to tools. The conclusion of Part I: the strain is on the capacity to prove and to own, more than on the capacity to produce.
12 min	The loop, the ladder and the ceiling Five functions: D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward; ten classes of work from specify to migrate. A level belongs to a work class in a context, not to a tool; the lowest of five answers governs; lowering is immediate and raising is a recorded decision. Five Level 4 prohibitions hold whatever the evidence: the production gate, security-critical paths, the agent's own mandate, irreversible production data, and decisions about a named person.
8 min	Stewardship, the independent oracle and claims with evidence AI may draft, generate, refactor and, within a mandate, execute; it may not own. The tests are Name, Understand and Revert. The test oracle must be independent of the generator, because errors are correlated and a passing suite is not a correct change. A claim carries scope, method, result, date and expiry; both organisations hold an adoption claim that fails this rule.

What the audience takes away

AI makes the translation into code cheap; framing, proving and owning remain the developer's work and become the scarce part.
Delegation is set per class of development work by the lowest of five answers, and five kinds of work are never Level 4 Autonomous.
Every change in production needs a named owner who passes Name, Understand and Revert, checked by an oracle the generator did not write.

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.

Teaching plan

10 min	The teacher tells the two opening cases from Nordvik Region and Hansa Mutual and asks the room what the two have in common despite one having no record and the other a full one.
15 min	Short lecture on the three reasons for the book: development as translation, the mixed and young evidence, and European law that assigns duties to named parties.
15 min	Participants place tools they know in the table of six usage modes and five degrees of delegation, and the teacher corrects cases where mode and degree were confused.
25 min	Exercise: groups draft the inventory of AI in one team's development work, following the five steps of the practical guide.
10 min	Groups report the places where they could not say which lines came from a tool; the teacher closes with what would show the thesis wrong.

Discussion

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?
Which of the five parts of the thesis do you find least convincing, and what evidence would change your view in either direction?
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

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
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
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.

Teaching plan

15 min	Lecture with the table of seven practices: period, scarcity answered, what was left unanswered and the developer function most affected.
10 min	The teacher presents the two time-use studies and the room discusses why their figures must not be put in one chart.
10 min	Participants read the pre-AI job description for a senior developer at Nordvik Region and mark what in it could be checked.
20 min	Exercise: pairs take a practice inventory for one team and mark the status of each practice.
5 min	Wrap-up: which lapsed practice would matter most if the volume of change doubled.

Discussion

Which practice in your team has outlived the scarcity it answered, and which answers a scarcity that AI is about to make worse?
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?
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

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
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
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.

Teaching plan

10 min	The teacher introduces the four grades and asks participants to grade three claims they have recently heard about AI and developers.
20 min	Lecture on the five pressures, using the chapter's table of studies and the table that places every claim on its rung with its limit.
10 min	Case reading: Nordvik's note to the executive committee and Hansa's figure in the board report, each set against what was actually measured.
25 min	Exercise: each participant draws a work-and-load map for one sprint and marks the hours with and without a tool touchpoint.
10 min	Plenary on the conclusion of Part I: where in the maps the strain on proving and owning shows.

Discussion

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?
Why does the chapter treat the written duties as firmer ground than any of the productivity or security studies?
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

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
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
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.

Teaching plan

15 min	Lecture on the five functions and the ten work classes; participants sort ten example changes into classes and say how each goes wrong with AI.
20 min	The teacher walks through the ladder, the three rules for setting a level and the table of recommended ceilings; the room sets a ceiling for one class with the five questions.
15 min	The five prohibitions and the three stewardship tests, with the standing of Nordvik Region and Hansa Mutual on each test.
30 min	Exercise: groups write a delegation profile for one team by the eight steps of the practical guide.
10 min	Groups exchange profiles and check each other's oracle and revert path; the teacher closes with the six parts of a claim record.

Discussion

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?
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?
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

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
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
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.

Lecture · 50 minutes

Cheap generation, scarce proof: the craft from Frame to Steward

The lecture follows one change through the developer loop and shows where the weight of the craft has moved. Intent is fixed in a specification whose criteria are an oracle the generator does not own. Design is the choice of constraints, recorded with a named decider and turned into rules a pipeline can check. Building is directing tools under a ceiling, a mandate and a sandbox. Proving rests on checks whose failure modes differ from the generator's. Stewardship is a gate the change cannot alter, a rehearsed revert outside the pipeline and an owner by name years later.

8 min	Frame: intent that a test can fail A request arrives as a solution; framing finds the problem and removes ambiguity of vocabulary, scope and condition. A generating tool does not stop at a gap in the specification; it fills it with something plausible. The acceptance criteria are the oracle: owned by a person who is not the generator and committed before code is generated.
8 min	Design: constraints with a named decider Five kinds of constraint, and an ADR that says who decided, what the tool contributed, what the human added, the dissent and the reversibility. An assistant is competent at the textbook list of options and weaker at the option that fits a given codebase; it tends to agree with the framing. A constraint that exists in no file is invisible to the tool, so each boundary derives a conformance rule owned by someone other than the generator.
12 min	Build: assistants, agents, mandates and sandboxes Risk grows with the unit the developer must review and the identity the tool uses, not with the sophistication of the model. The effect on speed depends on task, experience, codebase and measure; a figure that moves from a survey to a board paper changes its meaning on the way. An agent's authority is what the mandate, the sandbox and the credentials give; the never list and the stop path outside the pipeline carry the safety. Writing, merging and deploying are three acts: Level 2 Supervised for writing, a pipeline merge only for a narrow listed class.
12 min	Prove: independence shown, not asserted Three rules for the oracle: authorship, source and protection. Review capacity bounds the merge rate; the choice is a visible cap or an invisible thinning. Generated code is untrusted input; dependency names travel through a proxy, a named approval, a lock file and a waiting period, and a denial reaches an owner. Prompt injection is architectural, so permissions set the cost of being steered and the toolchain is treated as Tier 0.
10 min	Steward: the gate, the revert and the owner by name A gate the change cannot alter is out of reach, runs out of band, has an independent oracle and is shown to work by seeded faults. The Revert test needs authority, access and time, and a rehearsal no older than its expiry. For legacy: owner first, oracle second, knowledge captured third, translation last.

What the audience takes away

A generator is only as trustworthy as the checks it cannot edit, from the acceptance criteria to the pipeline gate.
Each function has an artefact that makes delegation reviewable: SPC, ADR, usage profile and MND, VER and RVW, PRV, CHG and OWN.
Stewardship holds or fails on the release path and in the ownership record, where a named person can explain and revert the change.

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.

Teaching plan

10 min	The teacher presents a request that arrives as a solution, such as a ticket titled add consent checkbox, and the room restates it as a problem for a named group of users.
15 min	Lecture on the three kinds of ambiguity, the four kinds of requirement and the three moves from need to testable statement.
15 min	What AI adds and the six failure modes; participants match each failure mode to the field of the specification record that controls it.
25 min	Exercise: groups turn a need into a specification record following the ten steps of the practical guide.
10 min	Review in plenary: who owns the scope, who owns the oracle, and what the assistant was used for in each record.

Discussion

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?
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?
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

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
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
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.

Teaching plan

15 min	Lecture on design as constraint, with Table 6.1; participants name a past outage that became the design review because a failure constraint was unanswered.
15 min	The teacher walks through the worked decision ADR-NR-0031 at Nordvik Region: three options from the tech lead, what the assistant added, and the fourth option from a senior developer.
10 min	Short input on drift, the evidence table and its limits, and the seam to the architect by scope and reversibility.
25 min	Exercise: pairs write an ADR in which an assistant proposed options and a named developer decided.
10 min	Pairs read each other's ADR as the second human who knows the codebase and name the missing option.

Discussion

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?
The practical guide tells the developer to write their own options before asking the tool. What is lost when the order is reversed?
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

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
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
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.

Teaching plan

10 min	The teacher presents Table 7.1 and participants place their own tools by what they may touch and the unit they must review.
20 min	Lecture on what the studies measured, in whom and with what limit, ending with the METR trial and its redesign as a lesson in measurement.
10 min	Demonstration and discussion of prompt and context craft: a task stated so it can be checked, deliberate context, known failure modes and a small unit of review.
25 min	Exercise: groups write a usage profile for one assistant, using the NR-DEV-001 example as a model.
10 min	Groups read out their stop rule and the claim they marked as asserted.

Discussion

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?
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?
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

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
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
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.

Teaching plan

15 min	Lecture on what a coding agent is, how it differs from an assistant, and what the evidence on agents does and does not show.
20 min	The teacher walks through the mandate MND-HM-DEV-02, the sandbox controls and the run record; participants say which control enforces each line of the never list.
20 min	Structured debate in two groups: the case for concern and the case for calm on whether agents should write and merge, followed by the five points where the positions meet.
25 min	Exercise: groups write a mandate for a coding agent by the eight steps of the practical guide.
10 min	Each group states how its stop would be tested this quarter and who is reachable out of hours.

Discussion

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?
Review capacity is finite and is a number. How would you establish how many agent pull requests a week your team can review well?
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

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
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
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.

Teaching plan

15 min	Lecture on what review is for and on the table of checks: the question each answers, who should write it and its typical blind spot.
15 min	The teacher presents the three rules of independence with the Hansa Mutual records VER-HM-2030-0007 and RVW-HM-2030-0412; participants identify who wrote the oracle and what the assistant could not alter.
15 min	Group work on the volume problem: each group estimates its team's weekly review hours and the number of open changes it can carry, then picks three design measures.
30 min	Exercise: pairs write a verification plan with an independent oracle for one change.
15 min	Plenary on the duplicated settlements of June 2029: what a review without independence looks like when nobody used AI.

Discussion

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?
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?
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

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
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
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.

Teaching plan

15 min	Lecture on what the studies of generated code measured and their three shared limits, and on how to measure one's own merged changes within a quarter.
15 min	The teacher tells the two lessons: the connection string pasted into an unapproved chat assistant at Nordvik Region, and the package that did not exist at Hansa Mutual. The room names the control that held and the one that was missing.
15 min	Whiteboard: draw the toolchain trust boundary with the four identities and mark where signing keys, gate configuration and the stop path sit.
30 min	Exercise: groups write the controls for a coding agent following the eight steps of the practical guide.
15 min	Tabletop: each group explains how its stop path works when the pipeline does not, and when the limits would be re-tested.

Discussion

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?
At Hansa Mutual the proxy refused the package and nobody read the denial. Which refusals in your own toolchain have no reader today?
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

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
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
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.

Teaching plan

15 min	Lecture on what AI changes in the volume and size of changes, and on progressive delivery with the Knight Capital and CrowdStrike cases as the chapter reports them.
15 min	Participants sort the controls of Table 11.1 into those a change can and cannot alter, then compare with the chapter's reasons.
15 min	The teacher walks through the two change records CHG-NR-2030-0212 and CHG-HM-2030-0415, reading each as a checklist.
30 min	Exercise: groups add a generator-independent gate and a rollback rehearsal to the release path of one service.
15 min	Discussion of the delivery metrics and the measures the book suggests beside them, with evidence ages.

Discussion

What cannot be rolled back in your own services, and how is that marked before the change is approved?
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?
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

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
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
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.

Teaching plan

15 min	Lecture on Table 12.1 and the three statements that survive the limits of the evidence on code health.
15 min	The teacher presents the public migration reports and their shared pattern (bounded, mechanical, repeated work), then the five things a migration needs first.
10 min	Reading of the two ownership records OWN-NR-2030-04 and OWN-HM-2030-07: why a vacant deputy is a finding and why the deputy for the oracle differs from the deputy for the code.
25 min	Exercise: participants write an ownership record for the module whose loss of its last explainer would hurt most.
10 min	Plenary: each participant names the first recorded conversation with an explainer they would put in the calendar.

Discussion

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?
Why does the chapter ask that the ownership inventory is reported as counts with dates, and what would an undated figure hide?
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

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
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
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.

Lecture · 45 minutes

Who holds the loop: roles when generation is cheap

The lecture argues that cheap generation moves every role towards the parts of the loop that cannot be generated: the junior's learning, the senior's review and context, the lead's intent and stop, the platform's gates, the quality engineer's oracle and the public authority's legality. More people can build, including product owners, designers and case handlers, so the boundary around prototypes moves outwards while the boundary around proof and ownership stays put. Each role gets an artefact that says what it holds, and the lecture shows how they fit: plan, charter, agreement, golden path, matrix, tender and register.

10 min	The pipeline of people: junior and senior The entry tasks that taught the craft are the tasks assistants do best; the output moves to the tool and the learning moves only if the junior does the thinking. The designed route: attempt first, review first, AI-off practice, an owned small change, a mentor and a second assessor. The senior's four jobs do not get cheaper; a review budget and a professional-judgement clause keep review from thinning.
9 min	The team: lead, manager and the figures that travel The lead holds intent, entry rules, the picture of the system and the stop; the manager holds people, outcomes and the headcount case. Measures are paired, dated and kept at team level; the share of AI-assisted lines presented as productivity must not reach the board. A headcount conversation is held on a six-part record, with the evidence in place before the decision.
8 min	The neighbours: architecture, platform and reliability A tool that proposes a dependency, an endpoint or a permission has proposed an architectural change. The platform turns AI tooling decisions into defaults: allow-list, gateway route, logging by team and a supply-chain rule that reports refusals. A spent error budget lowers the level of delegation for AI-originated change, by class and not by person.
8 min	Intent, prototype and proof A prototype is a question, not an answer: labelled, on synthetic data, never promoted as code. The oracle's independence is shown by source, author, seeded faults and age. Quality needs evidence, a hold authority outside the pipeline and a measure that is not delivery speed.
10 min	Beyond the development organisation In a public authority the tender is the first delegation decision, and records, public code and accessibility add duties at every stage. Citizen builders are governed by a register, tiers and promotion criteria rather than a ban; Tier D is never a citizen build. In every setting the same three tests return: Name, Understand and Revert.

What the audience takes away

The junior pipeline and the senior's review capacity are design decisions with artefacts, not side effects of a tool rollout.
Team-level, paired and dated measures protect both the people and the decision; a usage figure is never the case for fewer developers.
Who may build has widened; who owns the oracle and who can stop a change has not.

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.

Teaching plan

15 min	The teacher lists the six activities through which juniors learned and the table of who performs each entry task now; participants add what each task taught them.
15 min	Lecture on the four groups of evidence and on what none of the studies measured: a cohort of juniors followed over years with and without a designed route.
20 min	Staged debate in four steps: the case for concern, the case for calm, where the positions meet and what each role can do, followed by the chapter's verdict.
30 min	Exercise: groups design a first-quarter apprenticeship plan using APR-HM-2030-01 as a model.
10 min	Groups present their AI-off share and its reason, and how the junior intake will be reviewed.

Discussion

The chapter says the decline in hiring is a choice, not a law. Who in your organisation makes that choice, and on what figure?
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?
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

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
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
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.

Teaching plan

15 min	Lecture on the four jobs with the table of what AI makes cheaper, what it does not, and the risk if unmanaged.
15 min	Participants count their own review demand: weekly changes needing senior review multiplied by average review time, set against the hours actually available.
10 min	The teacher reads the six parts of the judgement clause from ROLE-NR-DEV-01 and explains why a hold lapses to the next decision-maker if unanswered.
25 min	Exercise: pairs write a senior developer charter with a review budget and a judgement clause.
10 min	Plenary on the pipeline of seniors: teaching through review, practising without the aid, and succession through named deputies.

Discussion

Why does the chapter place the right to hold in a role charter rather than in a general policy on AI tools?
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?
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

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
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
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.

Teaching plan

15 min	Lecture on the two jobs and the table of who holds which question; participants mark where one person holds both in their own organisation.
15 min	Group work: for each measure a team reports upward, name how it misleads and what to pair it with.
15 min	Role play of a headcount conversation at Nordvik Region: the executive committee asks whether consultant volume can be cut by a third; the lead and manager answer on the six-part record.
30 min	Exercise: groups write a team working agreement and put its rhythm into a week.
15 min	Groups test each review rule against their last incident, and name the files in their protected set.

Discussion

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?
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?
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

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
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
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.

Teaching plan

15 min	Lecture on the three neighbours and their shared problem, with the table of decisions: who decides, who builds, who runs or stops, and under what constraint.
15 min	The teacher walks through the golden-path specification of Nordvik Region (AIDR-1116) and the error-budget rule of Hansa Mutual (AIDR-1166), stressing what neither claims.
10 min	Participants identify, for their own organisation, who can disable a tool's route and who owns the definition of a pipeline gate.
25 min	Exercise: groups write a golden-path specification with AI tooling defaults by the eight steps of the practical guide.
10 min	Plenary on concentration risk: what a team of seven that writes the gates, reviews agent-drafted code and runs the gateway can do about it.

Discussion

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?
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?
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

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
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
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.

Teaching plan

15 min	Lecture on the four kinds of work of a tester, what AI changes in the economics of test drafting, and the four-part test of independence.
10 min	The teacher presents the table of where the boundary moves; participants mark for each activity what must not move.
15 min	Discussion in threes, each taking the product owner, the designer or the quality engineer: what did I gain, and what must I not hand over?
25 min	Exercise: groups build a role-boundary matrix for one team, using the e-services team of Nordvik Region as a model.
10 min	Groups read the matrix through as the people in it would, and set its review date with the delegation profile.

Discussion

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?
A product owner builds a running prototype in an afternoon. What stops it from being promoted as code when it already seems to work?
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

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
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
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.

Teaching plan

15 min	Lecture on why the public authority differs, and on what is being bought when an authority buys a coding tool.
15 min	The teacher walks through the criteria sheet for NR-2030-041 and the framework agreement NR-2025-102 that had no clause on AI tools.
10 min	Short input on public code, accessibility with an oracle the generator did not write, and archives and transparency.
25 min	Exercise: groups write a criteria sheet for an AI coding tool following the seven steps of the practical guide.
10 min	Each group checks its sheet against three clauses: who may change the model and with what notice, what is logged and exportable, and which ceiling the tool can be configured to.

Discussion

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?
Why does the practical guide ask for the criteria sheet to be reviewed with the union's IT representative before publication?
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

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
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
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.

Teaching plan

10 min	The teacher asks who in the room has built a tool outside the development organisation, and introduces the ladder of tools and what AI changes on it.
15 min	Lecture on the risks of data, access and continuity and the legal-role question, and on why bans have the weakest evidence.
15 min	Sorting task: participants place ten described tools into the four tiers and argue the doubtful ones up a tier.
25 min	Exercise: pairs create a register entry and promotion criteria for a tool built by a case handler.
10 min	Plenary on the missing-documents tracker at Nordvik Region: why an entry that is registered and not promoted is an honest state.

Discussion

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?
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?
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

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
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
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.

Lecture · 45 minutes

Evidence, trust and the day it fails

The lecture connects four chapters into one argument about leading adoption. A programme that only buys seats has no way to fail, so every claim gets a scope, a method, a date and an expiry, and every use case a stop rule. Figures are believable only where people can speak: where review is real, trust is calibrated and nobody is ranked by tool data. That requires agreements with employee representatives made before the telemetry is switched on. And the test of the whole arrangement is an incident, analysed blamelessly, with a named owner and a measured time to revert.

12 min	Adoption as a portfolio of claims A seat is an input, not an outcome; a use case has a sponsor, a hypothesis, a stop rule and an evidence owner who is not the sponsor. Four families of measure, each with a gaming check; acceptance rate measures a reaction to a suggestion, not the fate of the code. The studies agree underneath: the effect depends on task, person, codebase and the vintage of the tool, and throughput is read with stability. The only study that tells an organisation whether a tool helps in its own work is one run in it.
10 min	Culture decides whether the figures can be believed An assistant is not a pair: it cannot be named, explain the change a month later or help revert it. Review stays real when the author reads the diff first, disclosure is routine, and a reviewer may return a change as too large. The record, the count and the draft change what speaking up risks; the stop right and the open log give doubts a route.
11 min	Telemetry is data about people Rights of representatives attach early; a pilot is use and a vendor update is a trigger. Names for changes, not scores for people: reports by team with a minimum group of 5, and no tool data in rating, pay or promotion. An agreement follows the mandate and the delegation profile, not the product version.
12 min	When it breaks The usual incident method plus four questions: owner, what the tool did, independence of the oracle, and who could stop it and how fast. Blameless and named are complements; the model did it is not a contributing condition. The verified public incidents are mostly about the release path; both illustrative incidents had a known gap on paper with no owner and no date.

What the audience takes away

File the quoted and the measured figure side by side, with an evidence age and a stop rule fixed in advance.
Settle the grain and the excluded uses of telemetry with employee representatives before the first collection.
Give every assumption and every not covered item an owner and a date, and measure the time from decision to revert in a drill.

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.

Teaching plan

15 min	Lecture on adoption as a portfolio and on the four families of measure; participants sort the figures their organisation reports into the families.
20 min	Staged debate on whether AI is making developers more productive: the case for concern, the case for calm, the table where the positions meet, and the verdict.
15 min	The teacher presents the three experiment designs and what the published trials teach about selection, refusals and the smallest effect a small team can resolve.
30 min	Exercise: groups design an internal experiment and the record that will hold its result.
10 min	Groups read out their stop rule and name who holds the licence, the gateway route and the repository permissions.

Discussion

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?
Both sides of the debate accept that throughput and stability are read together. Which of your own figures is reported without its counterpart?
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

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
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
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.

Teaching plan

10 min	The teacher asks what a human pair gives that an assistant does not, and collects answers under Name, Understand and Revert.
15 min	Lecture on the five review practices and on what a sample of review records should be able to show.
15 min	Input and discussion on trust calibration, the three points of speaking up, safety to ask and the four-part response to shadow AI.
25 min	Exercise: groups run a short retrospective on AI-assisted work in the blameless form and decide one change to practice.
10 min	Each group writes the clause it would add to a team practice agreement and states its limit on data about people.

Discussion

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?
Disclosure of AI involvement is routine and has one purpose. What would make developers stop disclosing, and how would you notice?
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

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
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
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.

Teaching plan

15 min	Lecture on the table of instruments: the strongest right relevant to developer tooling in each and its trigger in the text, framed as organisational implications and not legal advice.
15 min	Participants walk a tool from their own organisation through the five trigger points and mark where information was due and when it was actually given.
15 min	The teacher presents the Hansa Mutual sequence that ran the wrong way round for two of three bodies, and the Nordvik negotiation record MBA-NR-2030-03.
30 min	Exercise: groups prepare a consultation file with a telemetry description for one coding assistant.
15 min	Role play: one group presents its file to another group acting as employee representatives, who ask what the data may not be used for.

Discussion

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?
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?
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

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
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
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.

Teaching plan

15 min	Lecture on the four kinds of event and the four stages of practice: stop first and name early, triggers, accounts before the timeline, and actions that close by evidence.
20 min	Case reading in groups: the form change Nordvik Region rolled back and the item Hansa Mutual had listed as not covered. Each group names the mechanism class and the result of the three tests.
15 min	The teacher presents Table 23.2 of verified public incidents, stressing what each primary source supports and that the agent case is cited only as reported.
30 min	Exercise: groups add AI-involvement fields to a post-incident review template and fill them for a past incident.
10 min	Short input on the reporting clocks and who classifies; the developer supplies facts and does not own the classification.

Discussion

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?
CrowdStrike and Knight Capital involved no AI. Why does the chapter give them so much space in a book about developers and AI?
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

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
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
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.

Lecture · 40 minutes

Duties, values and dependencies: constraint as design input

The lecture treats law, ethics and rights as inputs to engineering, not as a review at the end. The instruments attach duties to products, systems and entities and do not distinguish who or what typed the code, so the first task is a role test and a register that ties each article to an artefact and a holder. Where the law is silent, values become rules only when they have a check and evidence that expires, and a developer needs a route for the case no rule covers. Rights and dependencies are decisions that must be recorded and tested. The lecture describes implications, not legal advice.

13 min	The role test and the duty register An article is a duty only for an addressee; one team can be manufacturer, provider, deployer, controller and regulated entity at once. A change of intended purpose can change the role under Article 25(1)(c) of the AI Act, so the event is gated before merge. The Cyber Resilience Act, Directive (EU) 2024/2853 and the DORA technical standard ask for what the book's artefacts already hold: review, independent approval, fall-back, records. The register is dated, held by named people and re-read at most every six months.
13 min	Where the law ends: judgement with a route Law is a floor; professional codes say what the profession says of itself and need to become rules met at the point of work. Ask, record, escalate, decline and report; an agent does not decline, so the refusal is designed into mandate, gate and owner. Accessibility is the model of a value that became a rule; bias is checked by proxy, counterfactual and reasons rules with an independent oracle.
14 min	Rights and dependence in the toolchain The human contribution is the thread on which ownership of generated code hangs; contracts with consultants and suppliers settle the rest. Contamination has four routes; detection needs a similarity check, a bill of materials and a policy with a named owner. Providers retire models on their own schedule and few maintainers carry the open source; an untested exit is a hypothesis. A failed exit test is recorded as failed, with a date for the re-test.

What the audience takes away

Start from the role test: which instruments address the organisation, in which role, and which event would change that role.
A value is enforceable when it has a rule a stranger can apply, a check owned independently of the generator, and evidence that expires.
A dependency nobody recorded is one nobody decided; list the toolchain by layer and test one 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.

Teaching plan

15 min	The teacher introduces the role test with the table for Nordvik Region and Hansa Mutual; participants answer the five questions for their own organisation.
25 min	Lecture by instrument: the four routes of the AI Act into development, the Cyber Resilience Act and its reporting, software as a product under Directive (EU) 2024/2853, NIS 2, DORA and the GDPR in the repository.
10 min	Reading of Nordvik's pipeline rule intended-purpose-change and of four rows of Hansa's register DRR-HM-001-LEG.
30 min	Exercise: groups read one instrument into the repository by writing duty register rows.
10 min	Plenary on what the chapter says was not verified and is therefore not claimed, and why the register carries the date each text was read.

Discussion

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?
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?
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

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
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
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.

Teaching plan

10 min	The teacher asks for a request each participant once hesitated to build, and sorts the answers under fairness, access and honesty.
20 min	Lecture on the professional codes and their limits, the case from the record, the five-step route and what changes when an agent is in the loop.
10 min	Case discussion: the request at Hansa Mutual to rank broker enquiries by a derived likelihood of claim built partly on postcode, and how the proxy rule routed it.
25 min	Exercise: pairs turn one value of their organisation into an engineering rule and a check.
10 min	Pairs read out the case their rule does not cover and who would be asked.

Discussion

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?
Disclosure is not a cure: knowing that advice came from a tool does not remove its influence. What follows for how review is organised?
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

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
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
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.

Teaching plan

15 min	Lecture on copyright in generated code and on who owns what the team commissions from consultants and suppliers, framed as the book's reading and not a ruling.
15 min	The teacher presents the four routes of contamination and the illustrative licence policy LIC-HM-DEV-01, then the four cases as signal.
10 min	Short input on maintainers' load and on providers that retire models on their own schedule; participants name their most critical dependency with the fewest maintainers.
25 min	Exercise: groups record the dependencies of their coding toolchain with an exit route and a tested alternative.
10 min	Comparison of the two worked examples: Nordvik's exit test that failed its gate and Hansa's that passed within stated limits.

Discussion

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?
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?
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

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
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
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.

Lecture · 40 minutes

Competence, practice and the outlook for the role

The lecture argues that the stewardship principle rests on people who can still read, debug, write an oracle and revert without the tool, and that an organisation should treat this as something to evidence and to practise. Competence is a claim with a date: assessed on work, by a second assessor, with the lower of the assisted and unaided figures governing. The studies of offloading show a pattern and not a rate, so the practice plan is small and reasoned. The outlook is labelled: the best single answer to fewer, more or different is different, with the entry route and the named steward as what an organisation can influence.

13 min	Competence is a claim that needs evidence Six groups: frame and specify; design and system thinking; read, review and verify; delegate and bound; steward; AI literacy for the role. Attendance, tool use and confidence are not evidence; seeded-defect reviews, unaided explanations and revert drills are. The lower of assisted and unaided performance governs, a second assessor checks, and evidence expires. The record is personal data with stated purposes and readers, and it does not rank.
13 min	The developer's own mind Studies from several fields show that offloading can reduce later unaided performance under stated conditions; the rate for practising developers is unknown. The manner of use changes the outcome, so attempt first and ask for explanation. A practice plan protects AI-off time that produces a written artefact, reading time and a partner who does not appraise.
14 min	Fewer, more or different Observable: lower hiring of the youngest in exposed occupations in American data, broad adoption with limited trust, and dated legal duties. Expected: employment in software roles in the EU holds, and the work shifts towards D1 Frame, D4 Prove and D5 Steward. Speculation: the size of a development organisation in 2036 and specifications replacing code. A horizon register gives each trend a trigger in the organisation's own data; the Level 4 prohibitions are a ceiling, not a projection.

What the audience takes away

Evidence competence on real work, with and without the assistant, and let the lower figure and its date stand in the record.
Keep by hand the skills that Understand, Revert and the independent oracle depend on, with a plan that is never an input to appraisal.
Label every statement about the future and give it a trigger; the entry route and the named steward are within the organisation's control.

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.

Teaching plan

15 min	Lecture on the six groups and on AI literacy under Article 4 of the AI Act as the floor, with the competence record as the instrument.
15 min	Participants take the evidence table and choose, for one post, which evidence would serve each group and which familiar measures are not evidence.
10 min	The teacher walks through CMP-NR-2030-DEV-01 for a mid-level developer and the three-part interview with its rules that protect candidates.
25 min	Exercise: pairs write a competence record and development plan for a mid-level developer.
10 min	Plenary on ladders: what changes when the gate moves from tenure to evidence, and where a second assessor is found in a small team.

Discussion

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?
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?
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

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
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
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.

Teaching plan

15 min	Lecture on what the studies measured, naming for each the population, the method and whether it is a preprint, a survey or a small experiment.
10 min	Conversation in pairs about flow, craft pride and identity: where interruptions and absorption fall now compared with before assistants.
10 min	The teacher presents the table of skills to keep by hand and the two worked plans, for Linnea Sjöberg and for Jörg Albers.
20 min	Exercise: each participant drafts a personal practice plan for one quarter and agrees it with a partner.
5 min	Close: each participant names the one skill they will test without the tool at the end of the quarter.

Discussion

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?
Why does the plan exclude tool telemetry on named persons, and what happens to practice when a record can be turned into a score?
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

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
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
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.

Teaching plan

10 min	The teacher collects predictions about developers from the room and has participants label each as observable, expected or speculation.
15 min	Lecture on what the employment data show and do not show, on agent-heavy teams and on the specification as the main artefact.
15 min	Staged debate in four steps on fewer, more or different, ending with the verdict and the five projections with their thresholds.
25 min	Exercise: groups write a horizon register of four or five trends for their organisation.
10 min	Groups exchange registers and test whether each trigger could actually be observed in the organisation's own data.

Discussion

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?
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?
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

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
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
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.

Lecture · 45 minutes

What the records show, and what they cannot

The lecture closes the course by asking what experience adds to the argument. Six public cases, read only from primary records, show three mechanisms: a gate that sat inside what it governed, a name trusted and not checked, and a count that replaced an outcome. A year in two fictional organisations shows that the first honest numbers are lower than the first dashboards and that evidence expires faster than it is re-measured. The plans that follow close what has expired before opening anything new. The final judgement is candid: the thesis holds as design rules and is weakest where it predicts outcomes.

11 min	Cases and anti-patterns Six records: a regulator's order, a court ruling, a vendor bulletin, a maintainers' advisory, a researcher's experiment and an engineers' experience report. Three recurring mechanisms, and nine anti-patterns that each begin as a step that looked reasonable. No record supports a claim that developers were careless, and none shows an AI system intending anything.
11 min	A year of records The 42 per cent became 27 per cent in a sample; a third faster became an interval that included no difference. A lapsed rehearsal lowered a Level 3 Bounded class to Level 2 on a date nobody had to decide. The failures that mattered were quiet and were found by people; records turned disagreement into text. The year shows the instruments are workable, not that they work.
11 min	Conclusions and plans for two organisations Three rules: close what has expired first, raise no ceiling without a record and evidence, and separate owners from watchers. Nordvik's exposure is a platform team of seven, unbound consultants and untestable inherited systems; Hansa's is reviewer hours, a board figure without its age and a retiring mainframe estate. Ten measures let each organisation judge the book's claims locally, and they are allowed to count against it.
12 min	The thesis judged Part by part: expected in direction, firm where law and failure make it firm, conditional, strongest as design, and holding as a method. Ten places where the book found no study; nothing found meets the bar for refutation, which is a weak form of support. Five things to do on Monday, one per function from D1 Frame to D5 Steward, each producing a record with an evidence age.

What the audience takes away

Read cases from primary records and look for the mechanism and the control, not for a culprit.
Write the evidence age at the top of the oldest claim, close what has expired, and only then open something new.
Treat the thesis as design rules to be tested in your own records, and let your measures be able to count against it.

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.

Teaching plan

20 min	Lecture on how the cases were chosen and what was dropped, then the six cases by mechanism, each with the source read and what it does and does not support.
15 min	Group task: for each case, name the function concerned, the test that failed and the control outside the tool that would have limited it, then compare with the chapter's table.
15 min	The teacher walks through the nine anti-patterns, stressing for each the step that looked reasonable and the early signal.
30 min	Exercise: groups review one team's estate against the catalogue, using the Nordvik Region check of February 2031 as a model.
10 min	Each group names one finding it marked not assessed and explains why that is a finding in itself.

Discussion

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?
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?
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

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
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
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.

Teaching plan

15 min	The teacher tells the year quarter by quarter, with the people and the records through which each appears.
15 min	Groups each take one of the four conclusions and collect the events of the year that support it.
10 min	Plenary on the comparison table of the two organisations and on the two cautions: the year shows the instruments are workable, not that they work.
25 min	Exercise: participants open a ledger for their own team and plan one drill with the tools off.
10 min	Each participant states the oldest claim in their team, its evidence age and who holds the stop.

Discussion

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?
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?
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

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
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
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.

Teaching plan

15 min	Lecture on the three rules and on what the records establish for each organisation: Nordvik's failures where a resident would meet them, Hansa's where a supervisor would look.
20 min	Two groups each take one organisation and present its open items, its four conclusions and the eight decisions for leadership, with the reason each decision belongs to its decider.
15 min	The teacher presents the ten measures and the three possible readings at month 12, including how a measure could show a claim of the book wrong.
30 min	Exercise: groups draft a twelve-month plan for their own organisation with measures, owners and watchers.
10 min	Each group names its main residual risk, the early signal and who watches it.

Discussion

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?
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?
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

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
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
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.

Teaching plan

20 min	Lecture through the five parts of the thesis: for each, what is established, expected and speculation, the thinnest point and the verdict.
15 min	Groups take the list of ten places where the evidence is thin and choose the one that matters most to their own organisation, saying what study or internal record would fill it.
15 min	The teacher presents what would show the thesis wrong, the challenge from inside the book about legacy modules, and the author's five projections with their labels.
30 min	Exercise: participants plan the five Monday actions for their own organisation and draft the scorecard fields they would fill.
10 min	Closing round: each participant names the first action they will take and the record it will produce.

Discussion

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?
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?
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

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
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
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

Answers to the self-tests

Chapter 1	1B · 2D · 3A (1) The chapter says the three do not contradict each other because they measure different people, tasks, codebases and outcomes. What carries over is that the result depends on the task and on the developer's experience of the codebase. (2) The chapter names independent, multi-year evidence of better quality, security, delivery and learning without named, reachable owners and generator-independent checks. It labels as speculation that no such evidence exists today. (3) The table across the usage modes places Mode 3 at Level 2 Supervised: Nordvik's platform engineers draft and never apply change, and Hansa's agents work in a sandbox, open pull requests and never merge.
Chapter 2	1C · 2A · 3D (1) The chapter says agile answered feedback and tolerance of change and left durability unanswered: documentation valued below working software is missing later, and shared ownership can become ownership by no one. (2) The study reports coding at 21.0 per cent, email at 14.5 per cent and work-related browsing at 11.4 per cent. The 58 per cent figure is from the other study and concerns program comprehension. (3) The chapter names two differences: the same input no longer guarantees the same code, and the reach is wider, since it can draft requirements, tests, reviews and documentation as well as code.
Chapter 3	1C · 2B · 3A (1) Both come from companies that sell a tool or service in the area. The chapter reads such work as a claim by an interested party: useful as a hypothesis, weak as a finding. (2) The note rested on an acceptance rate and a survey of 9 of the 12 pilot developers; nobody had measured delivery time. The sample of 40 pull requests belongs to Hansa Mutual. (3) The chapter argues that a faster generator moves the limit to review and ownership: the pressures strain the capacity to prove and to own, not the capacity to produce.
Chapter 4	1D · 2B · 3C (1) The table of ceilings sets review at Level 1 Assisted: AI comments are input to a human reviewer, and an AI comment never counts as a human approval. (2) Tests from the same assistant in the same session restate the code's assumptions, so a wrong reading of the requirement is in both. The other three are independent in method, authorship or time. (3) The chapter says a repository whose owner has left, or whose owner is a department such as Policy Systems, does not pass: the owner must be identifiable by name or as a named team with a reachable lead.
Chapter 5	1C · 2A · 3B (1) The chapter's table gives this as the example of vocabulary ambiguity, with a glossary entry in the specification agreed with the case handlers as the remedy. (2) The chapter calls this a deliberate detail: the baseline is recorded as not measured rather than estimated, since a claim of fewer returned applications needs a real baseline to be tested against. (3) The chapter treats the criteria as the oracle: changing a criterion changes what counts as correct, which falls under the prohibition on a system changing its own test oracles, so a named person makes the change.
Chapter 6	1D · 2A · 3C (1) Anders Falk marks the public status vocabulary as one-way because residents rely on it, and the interface itself as two-way. The enterprise architect is consulted on the vocabulary because it crosses to the citizen channel. (2) The field lists the options the tool did not offer and those the developer set aside, with reasons. The chapter calls this the evidence that the decision was not the tool's first answer accepted. (3) The evidence on drift is young and partly from vendors. The mechanism the chapter relies on is that a tool sees only the files it is given, which is why each boundary-setting ADR derives a checkable rule.
Chapter 7	1B · 2D · 3A (1) Peng and colleagues recruited 95 freelance programmers for one synthetic HTTP server task; the treated group took 71.17 minutes against 160.89, reported as 55.8 per cent faster. Code quality was not examined. (2) The chapter's first observation on Table 7.1 is that risk grows with the unit of review and with the identity the tool uses, not with the sophistication of the model. (3) The worked example marks the quoted claim as asserted next to the plan that would verify it; nobody had measured delivery time, and the unit of measurement is the team.
Chapter 8	1C · 2B · 3A (1) The mandate sets Level 1 Assisted for drafting, a one-run identity, egress only to the package proxy, no secrets, a branch limit and the rule that whoever starts the run does not approve its pull request. (2) The chapter's reason is that if the agent is stopped by a pipeline job, a broken pipeline leaves it running. The mandate therefore names two mechanisms outside the pipeline: revoking the run's identity and disabling the runner pool. (3) For a coding agent the table sets review at Level 0 Advisory, with two human approvers where the change policy requires them. An AI review comment never counts as an approval.
Chapter 9	1C · 2B · 3A (1) Protection is the third rule after authorship and source: the generator of the change cannot edit what checks it. The rules make the oracle's errors different from the generator's, which is what independence means. (2) The reviewer was the only other person who knew the module, so reviewer and author shared the same knowledge and the same gaps. The review passed and 312 claims were paid twice, with no AI involved. (3) The table assigns property-based tests to a person who derives the rule from the specification, not from the code. The platform team writes static analysis rules, and a specialist writes formal models.
Chapter 10	1D · 2A · 3B (1) The five controls are an approved-registry proxy, a human approval for every new dependency, a lock file with hashes, a waiting period for new versions, and a denial that is an event. (2) In March 2030 a consultant on the case platform pasted a connection string into an unapproved public assistant while asking for help with a SQL view. The secret in the prompt is the Region's lesson. (3) The chapter stresses that the record makes a claim about origin only as far as a log supports, says nothing about the share a human wrote, and does not count AI comments as approvals.
Chapter 11	1B · 2D · 3A (1) A change can edit the file that defines its own checks when the pipeline definition sits in the same repository. The other three lie outside the change's write permissions or are owned by someone else. (2) Rehearsal is the evidence for the Revert test. A revert not exercised within the period the book recommends is marked not tested, which is honest and distinct from passed. (3) The class approval for patch-level dependency updates is valid until 2031-03-30, the profile's review date. The chapter gives the reason directly: the class should not outlive its evidence.
Chapter 12	1C · 2A · 3D (1) The trial asked whether code written with an assistant costs the next maintainer more, and found no significant difference in a small task. The other figures come from the Cursor study and the GitClear report. (2) The chapter concludes that Nordvik Region and Hansa Mutual reach the same sequence from different directions: owner, then oracle, then captured knowledge, and translation only after those. (3) The record is a tool for the owner and the team. The guide says that using it to rank or appraise named developers is a monitoring use, which belongs to the agreements treated elsewhere in the book.
Chapter 13	1A · 2C · 3D (1) The chapter cites it as the study that points the other way from the American payroll data: no measurable effect on earnings or hours in Danish records, which is why the evidence is called young and conditional. (2) Review-first learning turns the junior into a reader before a writer, and one rule protects it: the junior's review is practice and not the gate through which the change passes. (3) The verdict calls lower hiring in some datasets observable, a thin supply of developers able to supervise generated code expected where no route is designed, and the disappearance of the junior speculation.
Chapter 14	1B · 2A · 3C (1) The clause gives the rights to hold, to the explanation, to decline ownership, to record dissent and to unassisted work, and bars use targets in appraisal. It is explicitly not a veto and not immunity. (2) The clause is time-limited and reviewed by peers. A hold that is not answered in time lapses to the next decision-maker in the charter, which is why the chapter says it is not a veto. (3) The chapter warns that a principal who has not changed the system in two years risks becoming a reviewer who has lost the theory Naur described, so the charter includes a build share beside the review share.
Chapter 15	1D · 2B · 3A (1) The lead may narrow a ceiling and records it; for raising one the lead proposes with evidence and the engineering manager takes it to the owner of the delegation profile. (2) Wednesday's 45 minutes is the sample of AI-involved changes. The framing check is on Monday, the ownership and stop check on Friday, and the claim record belongs to the quarterly agreement review. (3) The third part of the record is the measure and the method: what was measured, how and by whom, with an evidence owner who is independent of the sponsor of the claim.
Chapter 16	1C · 2B · 3D (1) The table across the degrees of delegation shows patch-level dependency updates at Level 3 Bounded under MND-HM-DEV-01 and Level 2 Supervised when the service budget is spent: delegation is lowered by class, not by person. (2) The platform lead decides, the platform team builds and runs the gate, and the constraint is that the definition is not editable by the change it gates and no agent has write access. (3) The first of three common failures is a mandatory path with no exception route, so that teams with a real need leave quietly, which is the situation the golden path was meant to prevent.
Chapter 17	1D · 2B · 3A (1) For hold or revert under D5 Steward, the quality engineer may hold and the owner reverts; the fixed point is that the authority sits outside the pipeline. (2) The age part of the test says the evidence carries a date and expires: by clock, with 90 days as the book's default for verification evidence, and by event such as a change of generator model, module or specification. (3) The outlook calls it speculation: no study reviewed shows it, and the chapter instead expects independent quality functions to grow in importance where much code is generated.
Chapter 18	1C · 2A · 3B (1) The chapter notes that the Region buys more than tools: its framework agreement for consultant developers had no clause on AI tools, so the contract did not cover the case. (2) Where a component encodes the Region's own legal interpretation, the Region must be able to explain and change it, which tends towards in-house. The other answers tend towards a supplier. (3) Withholding is decided case by case on grounds fixed in law. The Region's rule is that the competent official answers, with the developer helping to find the material, and not the developer.
Chapter 19	1B · 2D · 3A (1) Tier D covers tools that rank or decide about a named person, are or feed a high-risk AI system, or touch a security-critical path. The chapter calls it the Level 4 prohibitions applied to a different builder. (2) The promoting identity is not the maker. When every criterion is met, the platform pipeline promotes the tool, which is the same gate that Chapter 11 requires of a release. (3) The table gives no level for citizen builders at Mode 3. Agents that edit many components and run actions are reserved to developers and the platform team under a mandate manifest.
Chapter 20	1A · 2C · 3D (1) Each measure in the four families carries a gaming check, a second measure drawn from different data that would move if the first were being gamed, because Goodhart's law applies when a measure becomes a target. (2) Each use case has a sponsor, a hypothesis and a stop rule, and an evidence owner who is not the sponsor, so that the person who wants the use case to continue does not also judge whether it works. (3) With the 90-day default for usage, a five-month-old usage figure has expired. The value claim of a third faster was never measured against delivery, so the record shows it as asserted.
Chapter 21	1B · 2C · 3A (1) Disclosure is routine and has one purpose: it tells the reviewer where to look harder and feeds the provenance record. It is not a mark against the author, and the count of disclosures per person is never reported to anyone. (2) The four parts are an approved route that does the job, a plain rule on what is never pasted, a conversation before any enforcement, and a report route that costs nothing. None is surveillance of individuals. (3) The agreement writes the team's rules on one page, is stricter than the delegation profile and never looser, and is identified by its decision record: AIDR-1121 at Nordvik Region and AIDR-1171 at Hansa Mutual.
Chapter 22	1D · 2B · 3A (1) The platform team holds the sequence by configuration: information is due before the update is accepted into the managed image, and the default is set off until the decision is taken. (2) The table gives consent of the works council under WOR Article 27(1)(k) and (l). At Hansa Mutual this made the remedy a matter of obtaining consent for something already in use. (3) Stewardship needs names: the review record says who read a pull request. But it names a person for a change and never for a rate, and reports upward are by team.
Chapter 23	1C · 2B · 3D (1) The interface ignored a new flag that the specification had recorded as an assumption with no acceptance criterion. Nobody could say which lines were generated and it did not matter; the owner could explain the form change but not the mapping. (2) Stefan Brückner was named in the verification plan, restated the rule from the wording, and the rule was reverted in 38 minutes with authority held outside the pipeline. The 22 minutes belong to the Nordvik incident. (3) The table gives an early warning within 24 hours of becoming aware and an incident notification within 72 hours for essential and important entities. The clocks run from awareness, not from the end of the analysis.
Chapter 24	1A · 2C · 3D (1) The thread of the chapter is that the instruments attach to products, systems, processing and entities; none of the development provisions read distinguishes authorship by a person from use of an assistant, and the position of code under Article 50(2) is left open. (2) The chapter cites Article 2(1) for products placed on the market or put into service after 9 December 2026 and Article 4(1) for the definition of a product as including software. (3) Step six of the guide: record the date each text was read and re-read at most six months later and on every announced amendment, because texts change and entries expire.
Chapter 25	1B · 2D · 3A (1) The chapter observes that a code binds members and not employers, that the evidence it changes behaviour is thin, and that the one replication found suggests a code read once does not change decisions. (2) Three accessibility rules follow from the instruments: the gate rule (automated checks on every citizen-facing change), the person rule (a person tests new interaction patterns) and the prototype rule for prototypes built by non-developers. (3) The developer neither refused nor built it: they asked what it was for and recorded the answer, and the proxy rule routed it to review. The decision went to the chief risk officer's delegate, not to the developer or the agent.
Chapter 26	1C · 2B · 3D (1) The four routes are reproduction by the model, a dependency the assistant or agent adds, code pasted in by a person with unknown origin, and the organisation's own code leaving. (2) The chapter warns against presenting a single first-instance judgment as the law. The decisions diverge and do not settle the user's position, which is least settled where generated code enters distributed software. (3) The record has a named owner, a tested exit with an age and a review date at the earlier of evidence expiry, a model-retirement notice and a change of terms.
Chapter 27	1B · 2C · 3A (1) The chapter uses 90 days for competences that decay with disuse and 180 days for the revert drill, because a record true in January says little about a developer in July who has not done the task since. (2) The evidence table lists it as the check on verification: a change with a known number of defects reviewed in both conditions. It is also the first part of the interview the chapter proposes. (3) Step seven of the practical guide: review at expiry, and show a group whose evidence has lapsed as lapsed. Evidence expires, and the record should not carry forward a level nobody has recently seen.
Chapter 28	1D · 2A · 3C (1) Read together the studies establish a conditional pattern: offloading reduces effort and later unaided performance under stated conditions. No study has followed practising developers over years, so the rate is unknown. (2) The table gives two reasons: debugging showed the largest score gap in the programming experiment by Shen and Tamkin, and the Revert test depends on it. The practice is an AI-off block tracing a defect by hand. (3) Both schemes are interim: Nordvik's until the negotiation MBA-NR-2030-03 concludes and Hansa's pending the developer annex KBV-IT-2024-DEV-01, because a practice record touches the rights of representatives.
Chapter 29	1C · 2B · 3D (1) The summary lists it under expected. Lower employment of the youngest workers in exposed occupations in the United States is observable, and the size of a development organisation in 2036 is speculation. (2) P1, P2 and P5 are labelled expected. P3, on a small number of stewards for many agent-authored changes, and P4, on specifications and oracles as the primary reviewed artefacts, are labelled speculation. (3) The chapter states that the prohibitions are not a projection, and that no threshold above would lift them without a change in what can be verified and stopped from outside the system.
Chapter 30	1D · 2A · 3C (1) An agent with an identity and permissions whose owner nobody can state fails the Name test. The control is the ownership record together with the mandate that names stop holders. (2) The table of what would have prevented the cases records Revert held and the gate failed, with the control being a release gate that contributors cannot alter and a token scoped to the job. (3) Seven Google engineers wrote an experience report, not a controlled study. The figures are their own estimates; the useful part is the reasoning, with a named engineer, owners reading each change and humans reverting what was wrong.
Chapter 31	1B · 2D · 3A (1) The rehearsal of 2 October lapsed under the 90-day rule. The class ran at Level 2 Supervised while it had lapsed and returned to Level 3 Bounded when Hansa Forge repeated the rehearsal on 8 January. (2) The first caution: the year is two fictional organisations over twelve months, built from the book's records. It measures nothing, so it shows the instruments are workable and not that they work. (3) The third conclusion: a silently ignored flag, a gap without an owner and a package whose name existed were shown by no dashboard. Each was found by a person and handled by an owner who could explain and revert.
Chapter 32	1C · 2A · 3D (1) At Nordvik the interface mapping and the inherited systems fail Understand; at Hansa a department, not a person, owns the mainframe platform, so Name is hardest for the estate. (2) The decision for the group CIO is to renew the class on measured reverts and a rehearsal no older than 90 days, or lower it to Level 2. The class approval lapses on a stated date so that it cannot outlive its evidence. (3) The fourth conclusion: about 22 consultants work in the Region's repositories under a framework that was silent on AI tools, and supplier teams write code the Region does not review, while the Region's own developers have a profile, a gateway and a protocol.
Chapter 33	1B · 2D · 3A (1) The chapter calls this the part with the most inference between evidence and claim. The pressure on the route is observable, the case for a designed route stands, and no study of a designed apprenticeship was found. (2) Claims with evidence holds because it is partly a method: gaps between perceived and measured effects and between dashboards and samples are documented, and it can be checked in an afternoon. (3) Q3, labelled expected, names Level 3 Bounded in classes such as dependency patches, formatting, generated documentation and test-data maintenance, each with a gate the change cannot alter.

Final assignment

A twelve-month plan for AI in one development organisation. Assemble the artefacts you produced during the course into a plan for one real team or unit, in the manner of Chapter 32. Start from an inventory of where AI already takes part in the work and a delegation profile for the ten classes of development work. Show, for one service, the chain from specification record through verification plan and change record to ownership record, and say where the stewardship tests Name, Understand and Revert pass or fail today. State the adoption claims in circulation with their evidence age. Then write a twelve-month plan that closes what has expired before opening anything new, raises no ceiling without a decision record and evidence, and names owners and watchers separately. Use no data about named developers.

Assessment criteria

Fidelity to the frame: the five functions, the ten work classes, the levels and the five Level 4 prohibitions are used exactly and no class is placed at Level 4 for prohibited work
Independence: the oracle, the gate and the watcher of each step are demonstrably separate from the generator, the change and the owner
Evidence discipline: every claim and test result carries scope, method, date and expiry, and missing results are recorded as not measured or not tested
Respect for people: measures are at team level, no tool data rates a named developer, and the route to employee representatives is stated
Feasibility: the plan closes expired items first, fits the unit's capacity and assigns each decision to the person or body it belongs to