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 · 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.
Module 2 · Part II · The Craft of Developing · 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.
Module 3 · Part III · Developer Roles Across the Organisation · 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.
Module 4 · Part IV · Leading Change and Adoption · 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.
Module 5 · Part V · Regulation, Ethics and Responsibility · 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.
Module 6 · Part VI · The Developer as a Person · 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.
Module 7 · Part VII · Experience and Conclusions · 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.
