Cover of AI Developer

Book 12 · Course

AI Developer

Set how far AI may take part in each class of development work, and keep a named owner who can explain and revert every change.

7 modules33 lessons8 lecturesabout 44 hours of teaching

Start with Chapter 1The lecturesRead the book online

All courses / AI Developer

About the course

The course follows AI Developer, Book 12 of The Transformed Architecture. It starts from the question of what a developer is for when AI writes, reviews, tests and deploys code, and defines the developer loop of five functions (D1 Frame, D2 Design, D3 Build, D4 Prove, D5 Steward), the delegation ladder with its Level 4 prohibitions and the stewardship principle with its tests Name, Understand and Revert. It then works through the craft function by function, the roles across the organisation, adoption and culture, regulation and ethics, the developer as a person, and a year in two fictional organisations. Every module ends in artefacts that a team can put in version control, because generation is cheap and proof and ownership are not.

After the course the participant can

  • Explain the five developer functions and how the weight of the role moves from writing code to framing, proving and owning it
  • Write a delegation profile that sets a ceiling per class of development work by the lowest of five answers and applies the five Level 4 prohibitions
  • Apply the stewardship tests Name, Understand and Revert to a change, a repository and a release path
  • Design verification with a test oracle that is independent of the generator, shown by authorship, source, protection and seeded faults
  • Draft the governing artefacts of AI-assisted development: specification record, ADR, mandate, verification plan, change record and ownership record
  • Measure adoption as claims with scope, method, date, result and expiry, at team level and never per named developer
  • Design an apprenticeship route, a senior charter and a practice plan that keep verification skill in the organisation
  • Review an organisation against the anti-pattern catalogue and plan twelve months that close what has expired before opening anything new

Three ways to run it

The same material in three lengths. Each row of an agenda names the lessons it draws on.

Executive briefing90 minutes

For cIOs, heads of development, executive committees and board members who decide on coding tools, delegation and headcount

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.

0:00Two changes nobody can explain, and the five-part thesis of the book Ch. 1
0:15The developer loop, the delegation ladder, the five Level 4 prohibitions and the tests Name, Understand and Revert Ch. 4
0:35The figure that must not reach the board: adoption claims, evidence age and stop rules Ch. 15, Ch. 20
0:50The junior route and the future of the role: fewer, more or different Ch. 13, Ch. 29
1:05Duties that attach to named parties, and what breaks when nobody owns the change Ch. 24, Ch. 23
1:15Decisions for leadership and the first move of a twelve-month plan; questions Ch. 32, Ch. 33
One-day seminar1 day

For tech leads, senior developers, engineering managers, architects, platform and quality engineers, with employee representatives welcome

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.

09:00Opening lecture: from author of code to framer, verifier and steward Ch. 1, Ch. 3
09:45Workshop: a delegation profile for one team, with ceilings, prohibitions and stewards Ch. 4
10:45Frame and design: the specification as oracle and the ADR with a stated AI contribution Ch. 5, Ch. 6
11:30Workshop: a mandate, a sandbox and a stop path for a coding agent Ch. 8, Ch. 10
13:15Prove: the independent oracle, the volume problem and review that stays real Ch. 9
14:00Workshop: a gate the change cannot alter and a rehearsed revert for one service Ch. 11, Ch. 12
15:00People: the apprenticeship route, the senior's review budget and the team working agreement Ch. 13, Ch. 14, Ch. 15
15:45Measures, telemetry and employee representation: what may be counted and what may not Ch. 20, Ch. 22
16:30Anti-pattern check, five things to do on Monday and close Ch. 30, Ch. 33
Full course7 weeks, one module a week

For development teams and their leads, and cohorts drawn from development, platform, quality, architecture and HR in one organisation

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.

Week 1The developer role in question: thesis, history, pressures, and the loop, ladder and stewardship principle Ch. 1, Ch. 2, Ch. 3, Ch. 4
Week 2The craft of developing: frame, design, build, build with agents, prove, prove security, steward the release and the code Ch. 5, Ch. 6, Ch. 7, Ch. 8, Ch. 9, Ch. 10, Ch. 11, Ch. 12
Week 3Developer roles across the organisation: junior, senior, lead and manager, neighbours, quality and product, public authority, citizen developers Ch. 13, Ch. 14, Ch. 15, Ch. 16, Ch. 17, Ch. 18, Ch. 19
Week 4Leading change and adoption: measurement, team practice and culture, works councils and employment, incidents Ch. 20, Ch. 21, Ch. 22, Ch. 23
Week 5Regulation, ethics and responsibility: the role test and duty register, values to rules, rights and dependence in the toolchain Ch. 24, Ch. 25, Ch. 26
Week 6The developer as a person: competences, the developer's own mind and the future of the role Ch. 27, Ch. 28, Ch. 29
Week 7Experience and conclusions: cases and anti-patterns, a year in development, conclusions for two organisations, the thesis judged; capstone presentations Ch. 30, Ch. 31, Ch. 32, Ch. 33

Modules and lessons

One module for each part of the book and one lesson for each chapter. A lesson has learning objectives, key concepts, a teaching plan, discussion questions, an exercise and a self-test.

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: From author of code to framer, verifier and steward

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: Cheap generation, scarce proof: the craft from Frame to Steward

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: Who holds the loop: roles when generation is cheap

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: Evidence, trust and the day it fails

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: Duties, values and dependencies: constraint as design input

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: Competence, practice and the outlook for the role

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: What the records show, and what they cannot

Final assignment

Capstone

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.

Steps

  1. Take the inventory of AI in the team's work by usage mode and work class, and write or update the delegation profile with ceilings, prohibited paths, stewards and a stop path
  2. For one service, assemble a specification record, a verification plan with an independent oracle, a change record with a gate the change cannot alter, and an ownership record
  3. Run the three stewardship tests on one recent AI-involved change: find the owner, ask for an explanation without the tool, and time a rehearsed revert
  4. List every adoption, productivity or competence claim in circulation with its scope, method, date, status and expiry, and mark it verified, expired or asserted
  5. Review the unit against the nine anti-patterns and mark each answer pass, partial, open or not assessed
  6. Write the twelve-month plan by quarter, with five measures, dated baselines, risks with early signals, and the decisions that belong to named leaders

Deliverables

  • A delegation profile for one team with its inventory of AI use
  • An artefact chain for one service: specification record, verification plan, change record and ownership record
  • A claims register with evidence ages and an anti-pattern check with open findings left open
  • A twelve-month plan with owners, watchers, measures, risks and leadership decisions

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