AI Developer · Module 7 · Experience and Conclusions

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.

Lesson 30 of 33Chapter 3090 minutes

Read the chapterThe whitepaperThe slides

All courses / AI Developer / Module 7 / Chapter 30

Learning objectives

After the lesson the participant can:

Key concepts

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

Interactive exercises

Do them here and get feedback at once. Choose a card and then where it belongs, or drag it.

Interactive exercise 1 · Match

Anti-patterns and their early signals

Match each anti-pattern to the early signal the catalogue gives for it.

Interactive exercise 2 · Sort

Three mechanisms that recur

Sort each observation from the cases and the catalogue under the recurring mechanism the chapter reads in it.

Teaching plan

20 minLecture 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 minGroup 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 minThe teacher walks through the nine anti-patterns, stressing for each the step that looked reasonable and the early signal.
30 minExercise: groups review one team's estate against the catalogue, using the Nordvik Region check of February 2031 as a model.
10 minEach group names one finding it marked not assessed and explains why that is a finding in itself.

Discussion

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

Written exercise

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

Choose an answer to see whether it is right, or open the answer below each question.

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

    Show the answer

    D. Name, because nobody can say who owns it or its permissions
    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. What does the chapter say about the Amazon Q Developer extension case in terms of the tests?

    Show the answer

    A. Revert held and a gate failed; the control named is a gate contributors cannot alter
    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. Which is the only success case in the chapter, and what does the chapter note about its figures?

    Show the answer

    C. AI-assisted migration at Google, whose figures are estimates by the people who did the work
    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.