Case Studies and Anti-Patterns

The earlier chapters argued from principles, studies and the two fictional organisations. This chapter checks the argument against public cases, in which a regulator, a court, a vendor or a maintainer has written down what happened. It concerns all five developer functions: D1 Frame, because the cheapest failure to prevent is software nobody specified; D2 Design, because several records turn on a pipeline or access role designed to trust its own inputs; D3 Build, because of what a developer accepts from a tool unchecked; D4 Prove, because the recurring fault is a check that shared the blind spots of the thing it checked; and D5 Steward, because every case ends with the questions of who owned the software, who could explain it and who could revert it.

The method is strict. Every case is described only from a primary record that was opened and read in preparing this chapter: a regulator's order, a High Court judgment, a vendor's bulletin, a maintainers' advisory, a researcher's account of an experiment and an engineers' experience report. A party's statement of its own results is called a claim. A case that could not be verified is not analysed, and the section on method lists them. Interpretation is the book's own and is labelled as such. The cases are observable in the sense of AI Governance, Chapter 22 (162, Nordqvist, 2026).

Figure 30.1: The anti-patterns placed on the developer loop. The controls on the left of the dotted arrows are outside the tool, the agent and the pipeline they check.

What this chapter builds on

The chapter takes five conclusions from the earlier volumes as lenses. Incidents fail through correlated controls: a shared credential, a mirror that was also an egress path, an alert that reached people who did not hold the stop decision (AI Governance, Chapter 19, F28) (162, Nordqvist, 2026). Agents acting beyond their mandate are observable, and the lasting response has been to move controls from the agent's compliance into the environment (AI Threat, Chapters 25 and 35, F67) (165, Nordqvist, 2026). In the first exercise on the defenders' own AI, the action control held while the case store accepted unlabelled text (AI Blue, Chapter 15, F114) (168, Nordqvist, 2026). Loops fail in recognisable ways, each a step that looked reasonable, and the controls are few: independence, evidence age, a stop path outside the system and a testing right (AI Purple, Chapter 26, F140) (169, Nordqvist, 2026). Public cases show a system with owners for its parts and none for the whole, an explanation the user could not give, and an assurance that outran its evidence (AI Leader, Chapter 30, F183) (174, Nordqvist, 2026). This chapter asks the same of the person who owns the software, with the stewardship tests of Chapter 4: Name, Understand, Revert, and a test oracle independent of the generator.

How the cases were chosen and what was dropped

A case enters if its record can be read and says something about a developer function, whether or not it involves AI. Two cases, the trading failure of 2012 and the Horizon litigation, involve no AI; their records are precise about who deployed what, who could see what and who could undo it, and AI makes their mechanisms more frequent. Three concern the toolchain of AI-assisted development in 2024 and 2025, and one is a case in which an AI-assisted migration worked and the record says why.

Two cases that readers will expect are not analysed. The first is the report that an AI agent at Replit deleted a customer's production database in July 2025 during a declared code freeze. The AI Incident Database catalogues it from five press reports and no primary post-incident report (33, AI Incident Database, 2025); a search for a published post-mortem found press coverage and a report that the company's chief executive had promised one, and the original statements were not opened. The second is the reversal of a headcount decision by a Swedish fintech company, reported in 2025 from an interview; it concerns customer service, and only secondary coverage could be opened. No such reversal concerning developers could be verified, and the chapter does not substitute a weaker case.

Cases, by mechanism

The cases are grouped by the mechanism they show, not by date. For each, the record is described first, then read through the function and the test it concerns. The reading is the book's.

A deployment that nobody checked and a rollback that made it worse: Knight Capital

On 1 August 2012 the trading firm Knight Capital Americas sent millions of unintended orders into the US equity markets. The Securities and Exchange Commission's order of 16 October 2013 records that its order router sent millions of orders over about 45 minutes, obtained over four million executions in 154 stocks for more than 397 million shares, and that Knight lost more than $460 million on the resulting positions (29, U.S. Securities and Exchange Commission, 2013).

The order traces the cause to a deployment. From 27 July 2012 Knight placed new code on the eight servers of the router in stages, and one technician did not copy it to one of them. Knight did not have a second technician review the deployment, no one realised the old code had not been removed from the eighth server, and no written procedure required such a review (paragraph 15); Knight had no written code development and deployment procedures for the router at all (paragraph 26). On the day, orders reached the eighth server and triggered the old code. Knight had no supervisory procedures for incident response and, in one attempt to fix the fault, uninstalled the new code from the seven correct servers, which the order says "worsened the problem" because more orders then activated the old code there too (paragraph 27).

Through the stewardship principle the case fails Revert in the plainest way: the attempt to revert made things worse, because nobody had written down the state the system should return to. It fails Understand, since no person could say which server ran which code. The functions are D5 Steward and D2 Design, since a deployment in which one person copies code to eight servers by hand is a design. No AI was involved. The case matters because every failure in it is one that an agent with a deploy permission could repeat faster, which is why the delegation ladder prohibits Level 4 for a production change without a gate the change cannot alter (Chapter 4).

Privileged access with no record: the Horizon judgment

The High Court's judgment of 16 December 2019 in Bates and Others v Post Office Limited (No 6: Horizon Issues) is the most thoroughly tested public record of software that decides about people's money being trusted beyond what could be explained. Mr Justice Fraser considered the Horizon system used in post office branches over its life from 2000; the judgment concerns the accounts of subpostmasters, who were held responsible for shortfalls the system showed (259, Fraser, 2019).

Two findings concern developers. On robustness, the judge found that "Legacy Horizon was not remotely robust", given the number, extent and type of impact of the bugs, errors and defects he had found, and that the first online version's robustness "was questionable and did not justify the confidence routinely stated by the Post Office" (paragraphs 975 and 976). On access, he found as a fact that Fujitsu could insert transactions into branch accounts remotely, without this being visible to the subpostmaster at the time or later, and so without the subpostmaster's knowledge or consent (paragraph 540). Earlier statements by senior Fujitsu witnesses that this was not possible were, in his words, "simply untrue in that important respect" (paragraph 539). He took into account "the lack of records or logs at Fujitsu over time over the use and controls of the powerful access roles permitted to Fujitsu personnel", a deficiency that "seems to have been corrected in about 2017" (paragraph 976), and called remote access a central element of the dispute for many years (paragraph 544).

The mechanism is a privileged way of changing production data with no record of its use, in an organisation that could not say what its own people could do. Name failed, since no record said who used the powerful roles; Understand failed, since statements about what the system could not do were wrong; Revert failed for the people affected, who could not see, and so could not contest, what had been done. The functions are D5 Steward and D4 Prove. The case predates generative AI and the book draws no conclusion about AI from it. It supplies the finding a book on agents needs: a powerful role acting on production data without a record is a hazard whoever or whatever holds it, and an agent with write access to production data is such a role unless its runs are recorded outside it (Chapter 8).

The assistant's own release pipeline: Amazon Q Developer, version 1.84.0

On 23 July 2025 Amazon Web Services published a security bulletin, updated on 25 July and recorded as CVE-2025-8217, about the Amazon Q Developer extension for Visual Studio Code. It states that malicious code had been committed to the extension's open-source repository and automatically included in version 1.84.0, and that the code was distributed with the extension but was unsuccessful in executing because of a syntax error, which prevented it from making changes to any services or customer environments. The root cause given is an inappropriately scoped GitHub token in the build configuration, with which an actor could push code that the release process then picked up. AWS revoked and replaced the credentials, removed the code, withdrew 1.84.0, released 1.85.0 and asked customers to remove every 1.84.0 installation, forks and derivative copies included (32, AWS, 2025).

The bulletin does not say what the code was written to do, and this chapter says no more. It gives the shape of the failure: the release took whatever the repository held, with no gate that the contributor of a change could not alter, and the credential that wrote to the repository was wider than its job. The assistant is the victim here, not the cause. It belongs in the chapter because an extension sits inside the developer's boundary with the developer's permissions and arrives by update; the toolchain is Tier 0 (Chapter 10). The failure is in D5 Steward (the release) and D2 Design (the pipeline). The test that held is Revert: AWS could withdraw the version, rotate credentials and publish a replacement. The tests that failed are the ones before release.

The package that ran on the developer's machine: Nx

On 26 August 2025 malicious versions of the Nx build tool and some plugins were published to the npm registry between 6:32 pm and 8:37 pm Eastern time and removed at 10:44 pm. The maintainers' advisory of 27 August describes a chain. A workflow that ran with elevated permissions on pull requests had been merged on 21 August and reverted the next day, but remained in older branches. On 24 August a malicious commit appeared that changed the publishing workflow to send the npm token to an external address, and a pull request whose title carried injected shell commands ran in the privileged validation workflow minutes later; the maintainers' audit-log analysis links the two and they believe this is how the actor obtained the token. The malicious versions carried a post-install script that scanned the user's file system for text files, collected paths and credentials, and posted them as an encoded string to a repository created under the user's own GitHub account. The Nx Console extension for Visual Studio Code installed the latest version to check its version, so opening the editor in the window could trigger the payload (31, Nx project (nrwl), 2025).

Two details bear on AI-assisted development. The advisory lists "AI agents" among the less obvious ways a post-install script can be triggered, and its appendix reproduces a script whose embedded prompt sets up a file-search agent that inventories text and configuration files without reading their contents. It does not say which AI tool the script called, and this chapter does not either; security vendors' write-ups name specific assistants and none was opened here. The maintainers' remediation is a list of controls: remove versions and clear caches, rotate npm, GitHub and other credentials, enforce two-factor authentication and trusted publishing, remove old tokens, and require approval for workflows from external contributors.

The case is a failure of D5 Steward and D2 Design at the maintainers, and of the consumer's D4 Prove where a build tool resolved to its latest version. For a developer the lesson is the target: the payload sought credentials on a developer's machine, and a machine that hosts coding agents holds the same credentials. The book's recommendation, not a finding of the advisory, is short-lived task-scoped credentials and agents under identities of their own (Chapter 8).

A name that a model suggested: huggingface-cli

Spracklen and colleagues generated 576,000 code samples in two programming languages and report that at least 5.2 per cent of the packages recommended by commercial models and 21.7 per cent of those recommended by open-source models did not exist, with 205,474 unique hallucinated names across the study (234, Spracklen et al., 2025). That measures model output under the authors' prompts, not what developers installed.

The in-the-wild record is a researcher's experiment. Bar Lanyado of Lasso Security reported on 28 March 2024 that models repeatedly suggested a Python package named huggingface-cli, which was not the real installation route. He registered an empty package under that name and a dummy package to estimate scanner traffic, and counted over three months. He reports more than 30,000 authentic downloads and found that the README of an Alibaba research repository carried installation instructions for the empty package. The package was empty and the post reports no malicious use (241, Lanyado, 2024).

The limits matter. The download count does not say how many people installed the package because a model suggested it and how many because a README said so, and it rests on the author's method of separating scanners from people. The evidence is that a name was trusted and nobody checked it, that the trust reached a published README, and that a registry serves whatever is registered under a name. It is a D3 Build and D4 Prove case. The control is the fifth of Chapter 10: a package proxy that refuses names outside an approved set, and a route from each refusal to an owner who reads them.

A case in which it worked: AI-assisted migration at Google

Seven Google engineers wrote an experience report on LLM-assisted code migrations in Google's monorepo, which they describe as an experience report and not a controlled study. For the migration of identifiers from 32-bit to 64-bit integers in advertising systems they report that 80 per cent of the code modifications in the landed changelists were fully AI-authored, measured by comparing the first generated version with the committed version, and that total time was reduced by an estimated 50 per cent "as reported by the engineers doing the migration", counting review and landing. For a later time-library migration they report an estimated saving of about 89 per cent in small clusters, calculated from team leads comparing their experience with the manual approach (267, Nikolov et al., 2025).

The figures are estimates by the people who did the work; the reasoning is the useful part. It defined success as saving at least 50 per cent of the end-to-end time, including finding the places to change, review and rollout, and says this differs from the measure usually reported for code completion, such as the share of code written by AI or the acceptance rate. Generated changes pass unit tests, the engineer checks each change, and it goes to reviewers who own the affected code: "humans review the LLM-generated code the same way as any other code". In most cases the human had to revert at least some of the model's changes, which led to investment in LLM-driven verification, and whether there is a long-term effect on quality "remains to be seen".

Through the tests: a named engineer drives each migration (Name), owners read each change (Understand), and humans reverted what was wrong (Revert). The work class is migrate, kept at low ceilings by default, and the case is a bounded, mechanical change with tests, in a company with existing infrastructure for large-scale changes. The report does not show that the result transfers to an estate without it. What transfers is the discipline: an outcome measure, review by the owner, and verification the model does not control.

What recurs

Three mechanisms recur across the six records; they are the book's reading of them.

The first is the gate or the record sat inside what it governed. Knight's deployment had no second reviewer and no written state. Amazon Q's release took whatever the repository held, with a credential wider than its job. Nx's publishing workflow could be influenced by an outsider's pull request. Horizon's powerful roles used production data with no log. The ladder's prohibition on an agent changing its own mandate, permissions, review rules or pipeline gates is the same rule written for agents (Chapter 4).

The second is a name was trusted and not checked: a package name suggested by a model reached a published README, a statement that the system could not do a thing was repeated before anyone tested it, and an update arrived from a trusted extension. The control is always a lookup against something the actor cannot edit.

The third is a count replaced an outcome, and the successful case is the teacher: Google's engineers chose an end-to-end time measure on purpose.

No record supports a conclusion that developers were careless. Each shows a process that depended on one person's attention, on a control inside the system it governed, or on a figure easier to collect than the thing it stood for, which agrees with the finding of AI Leader, Chapter 30, that the verified cases show no lazy leader (174, Nordqvist, 2026).

Anti-patterns

The catalogue has nine entries. Seven come from the brief of this chapter and two were added because the cases above showed them. Each is a pattern in which every step looks reasonable, which is why it recurs. Each is anchored in a record where one exists; where the only anchor is one of the book's fictional organisations or the book's own reasoning, the entry says so, and where a public anchor was sought and not found, it says that too.

Anti-pattern	Functions	Test that fails	Anchor	Early signal	Control
Acceptance-rate dashboard	D3, D5	Understand	Google chose an outcome measure instead (1204); Hansa Mutual (fictional)	A report that counts suggestions accepted and says nothing of delivery	Outcome measures with method, date and expiry; sample of merged changes
Unowned agent	D5	Name	Horizon roles with no log (3002); Nordvik Region and Hansa Mutual ownership inventories (fictional)	An agent or repository whose owner has left or never existed	OWN-* record, one-run identity, run records written outside the agent
Generated test that proves nothing	D4	Understand	The book's own reasoning (Chapter 9); Hansa Mutual (fictional); no public record verified	Tests written by the generator of the change and green on the first run	Independent oracle, mutation score, seeded faults
Junior hole	D3, D5	Understand	Descriptive employment data (40, 1301)	A year with no apprentices because the tool does the junior tasks	Apprenticeship plan, protected mentoring, unassisted practice
Review rubber stamp	D4	Understand	Knight, no second reviewer (20); INC-HM-2029-0207 (fictional)	Approvals within seconds, one reviewer who shares the author's blind spots	Independence rule for the second approver, review budget, reading record
Secret in the prompt	D4, D5	Revert	Nx payload sought credentials (1007); INC-NR-2030-0071 (fictional)	Long-lived credentials on developer machines; assistants outside the approved list	Gateway, approved list, short-lived task-scoped credentials
Vibe-coded production system	D1, D5	Name	No public record verified; Chapter 19 (fictional organisations)	An application in use whose specification and owner nobody can name	Tiering sweep, promotion rule, owner before data
Trusted name	D3, D4	Understand	huggingface-cli (3001, 1001); FND-HM-2030-0012 (fictional)	A new dependency whose name no one on the team has seen	Package proxy, approved names, denial route to an owner
Open pipeline	D2, D5	Revert	Amazon Q 1.84.0 (2302); Nx (1007); Knight (20)	A workflow that an outsider or the change itself can alter	Gates outside the change's write path, scoped tokens, stop path

The acceptance-rate dashboard. A programme reports the share of suggestions accepted, or of lines that are AI-assisted, as evidence of value. The step that looked reasonable is that the number exists and rises. Goodhart's law, in the variants Manheim and Garrabrant categorise, says a measure used as a target stops measuring what it was chosen for (61, Manheim & Garrabrant, 2019), and the SPACE framework argues that no single activity count captures productivity (62, Forsgren et al., 2021). In a randomised trial that timed experienced open-source developers on their own tasks, 16 developers across 246 tasks expected a 24 per cent reduction in time, believed afterwards that it had fallen by about 20 per cent, and were measured to take 19 per cent longer with AI. The setting is narrow and the tools were those of early 2025, so it is no verdict on other developers; it shows that belief and measurement can diverge in the same people (63, Becker et al., 2025). Google's report is the contrast (267, Nikolov et al., 2025). In the fictional record, Nordvik Region's pilot NR-DEV-001 reported 31 per cent acceptance and a survey in which 9 of 12 developers said "about four hours a week", and the sponsor's slide said "a third faster" with no delivery time measured (AVR-NR-2030-01); Hansa Mutual's telemetry said 42 per cent of committed lines were AI-assisted in February 2030 and a sample of 40 merged pull requests found 27 per cent in August (AVR-HM-2030-01). The control is in Chapter 20: outcome measures, a counting rule agreed in advance, an independent sample and an expiry.

The unowned agent. An agent runs against repositories, tracker or pipeline with an identity and permissions, and nobody can say who owns it. The step that looked reasonable is that a pilot grew. Horizon is the nearest public anchor, by analogy: powerful roles acted on production data and the organisation had no records of their use (259, Fraser, 2019). The fictional anchors are the ownership inventories: 31 per cent of Nordvik Region's 96 repositories name an owner who has left or changed team (OWN-NR-2030-00), and 14 of Hansa Mutual's 410 services have no active owner (OWN-HM-2030-00) (Chapter 12). An agent added to such an estate inherits the gap. The control is the mandate of Chapter 8: a one-run identity, a named owner, stop holders, and a run record written by the sandbox host, not by the agent.

The generated test that proves nothing. An assistant writes the change and its tests, the suite passes, and the pass is reported as evidence. The tests share the generator's reading of the requirement, so they confirm what the code does and not what it should do. No public primary record of this pattern was verified; the entry rests on Chapter 9 and on the fictional Hansa case of Chapter 1, in which a Mode 3 agent opened a pull request, two humans approved it and the passing tests had been written by the same agent. The control is the corollary of the stewardship principle: the oracle is written or approved by someone other than the author, the agent cannot write to it, and the suite is tested for strength. The plan VER-HM-2030-0007 (Chapter 9) reports a mutation score of 0.83 with 22 live mutants and treats the live mutants, not the green run, as the result.

The junior hole. An organisation lets the assistant do the tasks that taught juniors, and takes fewer juniors. The step that looked reasonable is a saving. The data are consistent with such a mechanism and do not prove it: payroll data from one provider show employment of workers aged 22 to 25 in AI-exposed occupations 19 per cent below what it would have been had it kept pace with less-exposed occupations, through reduced hiring and not separations, and the authors call the results descriptive (51, Brynjolfsson et al., 2025); résumé data show junior employment at adopting firms about 9 per cent lower relative to non-adopters after six quarters (69, Hosseini & Lichtinger, 2025). Both are American working papers. The fictional anchor links two anti-patterns: the head of Hansa Mutual's broker interface team took no apprentices in the 2030 intake, citing the 42 per cent figure above; the decision is due for review on 30 March 2031 (Chapter 13). The control is an apprenticeship plan with protected mentoring, unassisted practice and a second assessor (APR-NR-2030-01, APR-HM-2030-01).

The review rubber stamp. A change is approved in seconds, or by the only other person who shares the author's blind spots. Knight's order is the public anchor for review that did not happen: no second technician reviewed the deployment (29, U.S. Securities and Exchange Commission, 2013). The fictional anchor is INC-HM-2029-0207 (June 2029), in which one reviewer, also the only other person who knew the module, approved a change that paid 312 claims twice. Nobody used AI; AI does not change the diagnosis, only the volume of diffs. The control is in Chapters 9 and 14: an independent second approver, a review budget in hours, an AI comment never counted as the human approval, and the reviewer's right to decline sole approval in a security-critical or payment path (AIDR-1164).

The secret in the prompt. A credential or customer record is pasted into an assistant outside the boundary, or an agent is given a long-lived token. The step that looked reasonable is that the task needed the context. The Nx payload shows what is sought on a developer's machine: credentials in text files (31, Nx project (nrwl), 2025). A vendor of secret-detection tools reports 23,770,171 new hard-coded secrets detected in public GitHub repositories in 2024 and a leakage rate of 6.4 per cent in public repositories using GitHub Copilot against an average of 4.61 per cent, with no stated method, sample or period for that subset, so the figures show how common leakage is and not that the tool caused it (237, GitGuardian, 2025). The fictional anchor is INC-NR-2030-0071 (March 2030): a consultant pasted a test-database connection string into an unapproved assistant and the platform team rotated it within 40 minutes. That ended well because someone acted within the hour, which is not a control (Chapter 10). The control is short-lived task-scoped credentials, an approved list with a gateway, and a supplier clause.

The vibe-coded production system. Software generated from a prompt, with no specification and no reviewer, becomes something people depend on. The step that looked reasonable is that the prototype worked. The Replit report is the case readers will expect; it is not analysed because no primary record was verified. The entry rests on Chapter 19: Nordvik Region's sweep found 60 FormFlow applications, 11 handling personal data, and Hansa Mutual's found 150 in Flowdesk, 23 touching personal data, and a prototype built outside the platform in an uncontracted tool. The control is the tiering and promotion rule of Chapter 19: an owner and a specification before data, and a review before an application serves anyone but its builder.

The trusted name. A dependency, extension or tool is accepted because its name is plausible or a trusted source suggested it. The public anchor is huggingface-cli (241, Lanyado, 2024), read with the measurement of how often models suggest names that do not exist (234, Spracklen et al., 2025). The fictional anchor is FND-HM-2030-0012: a coding agent proposed a name that did not exist, the proxy refused it, and the review that followed found two further denials nobody had read. The control is a package proxy that denies names outside an approved set, with each denial routed to an owner who counts them (Chapter 10).

The open pipeline. A pipeline or release job can be altered by the thing it releases, or by a contributor who should not hold that power. The step that looked reasonable is that the automation was convenient. The anchors are Amazon Q 1.84.0, where a build token with too wide a scope let code reach a release (32, AWS, 2025), and Nx, where a privileged workflow was influenced by an outsider's pull request title (31, Nx project (nrwl), 2025); Knight's deployment is the manual version. The control is the Level 4 prohibition written as a design rule: gates the change cannot alter, tokens scoped to the job, workflow definitions outside contributors cannot affect, and a stop path outside the pipeline.

Success cases, and why the base is thin

The catalogue is made of failures because failures are what the records describe, and the Google report is the only success case, in the authors' own account. It is observable that the verified cases here come from the United States and the United Kingdom, from vendors and maintainers, and that none is a European public authority's use of an AI coding tool. It is expected, as a trend and not a decided instrument, that European records will follow as supervisors and vendors publish more. Treat the catalogue as a checklist drawn from records, not as a frequency table.

What would have prevented them

The answers below are the book's own conclusions: which control, outside the tool, would have made each failure smaller or impossible.

Case	Function	Test failed	What would have prevented or limited it	Record
Knight Capital, 2012	D5, D2	Revert, Understand	A written deployment procedure, a second reviewer of the deployment, a written state to return to, and an incident-response procedure	CHG-*, RBK-* from AI Operations
Horizon judgment, 2019	D5, D4	Name, Understand	A log of every use of a privileged role on production data, held by someone other than the role holder, and a tested statement of what the system can do	Run record RUN-*, OWN-*
Amazon Q 1.84.0, 2025	D5, D2	Revert held; gate failed	A release gate that contributors cannot alter and a token scoped to the job	MND-*, pipeline gate rules
Nx, 2025	D5, D2, D4	Understand	A trigger that outside input cannot reach; pinned versions and a delay for new releases on the consumer side; short-lived credentials	PRV-*, toolchain section of MND-*
huggingface-cli, 2024	D3, D4	Understand	A proxy that denies names outside an approved set	PRV-*
Google migrations, 2025	D3, D4, D5	Passed with human reverts	(a success case)	Verification and review records

Four records do most of the work: the code-ownership record OWN-* that names a team and a lead, the mandate manifest MND-* that bounds an agent and names its stop holders, the run record RUN-* that the sandbox host writes, and the provenance record PRV-* that ties a change to its origin. Together they answer the three tests: whose is it, can the owner explain it, and how is it undone.

Practical guide: Reviewing one's estate against the anti-pattern catalogue

Purpose. To check the development estate of a team, a product line or an organisation against the nine anti-patterns, name the function and test each violates, and leave a dated record with an owner for every finding. The check takes half a day for a team and is repeated at least twice a year.

Roles. The tech lead, who answers for the check; the engineering manager, who owns the capacity to fix findings; an architect or platform engineer from outside the team as independent reviewer; the quality engineer who owns the oracle; the product owner of any application that serves citizens or customers; the works-council or union representative where a finding touches telemetry on named people; in a public authority, the data protection officer.

Inputs. The delegation profile DLG-* and the mandate manifests MND-* in force; the ownership record OWN-* for each repository; the adoption and value record AVR-*; the apprenticeship plans APR-*; the last three verification plans VER-* and review records RVW-*; the list of approved tools and the package proxy's denial log; the application list of the low-code platform.

Steps.

1. Fix the scope in one sentence: a team, a product line or a platform, and the period.
2. For each anti-pattern, ask the early-signal question of the catalogue in writing and answer it from the inputs, not from memory: what is reported beside the acceptance rate; who owns every agent and repository today; who wrote the oracle of the last five AI-assisted changes; how many apprentices started in the last intake; what the median review time was and how many approvals came from the author's only colleague; which tools staff can reach outside the approved list and how long credentials live; which applications serve others without a specification or owner; how many package denials were counted last month and who read them; whether the change, or an outside contributor, can alter the workflow that releases it.
3. Mark each answer pass, partial, open or not assessed. Do not round a partial up. Name the test it fails (Name, Understand or Revert) and the function.
4. For each open or partial finding, assign the control from the catalogue, an owner and a date.
5. Check the Level 4 prohibitions: for each agent, confirm that none acts at Level 4 on production without a gate, on security-critical code without a named reviewer, on its own mandate or gates, on irreversible production data or on a decision about a named person.
6. Have the independent reviewer read the answers and re-run two of them against the evidence.
7. Store the record in version control next to the delegation profile, and record the decision to adopt the actions as an AI Decision Record. The record expires after 180 days or on a change of tool, model or pipeline.

Artefact. An anti-pattern check, one file per review, with findings, owners, dates and an expiry.

A worked example for Nordvik Region

The check below is illustrative. It applies the guide to the integration and data team at Nordvik Region, whose tech lead is Anders Falk, in February 2031. It draws on facts established in earlier chapters: the pilot NR-DEV-001 and the value record AVR-NR-2030-01, the ownership inventory OWN-NR-2030-00, the incident INC-NR-2030-0071 and the decision to route the pilot through the AI gateway (AIDR-1116), and the apprenticeship plan APR-NR-2030-01. No identifier family was coined for the check; it is named by its file.

# governance/anti-pattern-check-2031-02.yaml  (illustrative)
scope: integration-and-data-team
period: 2030-09-01/2031-01-31
date: 2031-02-10
tech_lead: {name: Anders Falk, role: ROLE-NR-TCL-01}
independent_reviewer: {name: Maja Lindqvist, office: platform team lead}
findings:
  acceptance_rate_dashboard:
    result: partial
    test: Understand
    basis: "AVR-NR-2030-01 restated: 31 per cent acceptance reported beside delivery time from the tracker; 'a third faster' withdrawn"
    action: "measure lead time per change for two quarters; owner Gunilla Roos"
    due: 2031-06-30
  unowned_agent:
    result: open
    test: Name
    basis: "OWN-NR-2030-00: 31 per cent of 96 repositories name a departed owner; 7 in this team's area"   # illustrative count
    action: "assign owners before any Mode 3 extension; owner Anders Falk"
    due: 2031-04-30
  generated_test_proves_nothing:
    result: partial
    test: Understand
    basis: "portal changes use an oracle approved by the quality engineer; inherited national-register interfaces have none"
    action: "keep inherited interfaces at Level 0 Advisory for generate; second reviewer who knows the system"
  secret_in_prompt:
    result: partial
    test: Revert
    basis: "AIDR-1116 routes NR-DEV-001 through the AI gateway; consultants under NR-2025-102 not yet covered by a clause"
    action: "AI-tools clause in the next call-off; owner CIO office"
    due: 2031-05-31
  review_rubber_stamp: {result: open, test: Understand, basis: "one same-team reviewer, no rule for generated code"}
  junior_hole: {result: pass, basis: "APR-NR-2030-01: mentor with 2 protected hours a week; second assessor"}
  vibe_coded_system: {result: not-assessed, note: "FormFlow sweep belongs to the e-services team"}
  trusted_name: {result: not-assessed, note: "no coding agent in this team; proxy denials not yet counted"}
  open_pipeline: {result: partial, test: Revert, basis: "release job token not yet scoped per job", owner: platform team}
level_4_check: "no step at Level 4; people class not delegated (DLG-NR-DEV-01)"
decision: AIDR-1130
expires: 2031-08-10

The record does not round up: two patterns are listed as not assessed, which is a finding in itself. The count of seven repositories is illustrative, not a figure from the profile. AIDR-1130 adopts the check as a standing step before any extension of the pilot; Gunilla Roos answers for it.

Across the usage modes

The anti-patterns attach to usage modes unevenly. The table shows where each is most likely to arise and the highest degree of delegation the default ceilings of Chapter 4 allow at that mode, which is also where the control applies.

Usage mode	Anti-patterns most likely	Highest degree of delegation in the default ceilings	What to check
Mode 0 Ambient AI	Acceptance-rate dashboard, trusted name, unowned (supplier tooling invisible)	Level 1 Assisted	Whether anyone chose it; origin recorded or "not asserted"
Mode 1 Conversational assistants	Secret in the prompt	Level 0 Advisory to Level 1	What left the boundary; approved list
Mode 2 Embedded workplace assistants	Acceptance-rate dashboard, review rubber stamp, junior hole	Level 1 Assisted	Can the developer explain the accepted code without the tool
Mode 3 Agentic work tools	Unowned agent, open pipeline, trusted name, generated test	Level 2 Supervised outside security-critical paths, Level 1 inside	Whose identity acted; who approved; oracle write-denied
Mode 4 Built AI applications	Generated test, unowned agent	Level 1 Assisted	Seeded faults and mutation evidence with a date
Mode 5 Autonomous production agents	Open pipeline, unowned agent	Level 3 Bounded within a codified policy; never Level 4 for the prohibited work	Where is the stop and who holds it

No case in this chapter would have been improved by granting Level 4 for the work the prohibitions name.

Nordvik Region and Hansa Mutual

Both organisations check themselves against the catalogue. Nordvik's capacity is limited (18 developers, four testers and a platform team of seven), so findings are phased, and the check is repeated before any extension of the Mode 2 pilot beyond the interim protocol (AIDR-1122). Its public-law setting gives the check a second purpose: the Region must be able to give reasons for decisions its software supports, and an ownership gap is a gap in that duty. Whether run records and prompts are records is still open with the archivist and counsel, and MBA-NR-2030-03 decides whether the telemetry behind the check may be reported by team.

Hansa Mutual runs the same check in the quarterly review of DLG-HM-DEV-01. In the check of 17 February 2031 (illustrative) the group CIO Rainer Lehmann answers for the record and Dr. Annette Krämer, the chief risk officer, is the independent reviewer. The acceptance-rate dashboard is remedied, since AVR-HM-2030-01 keeps the quoted 42 per cent and the sampled 27 per cent side by side and AIDR-1172 keeps acceptance rates out of appraisal and pay. The generated test passes for the claims core, where Ewelina Maj owns the oracle and the replay of recorded settlement runs is independent of the agent. The trusted name passes: proxy denials are counted monthly and routed to Stefan Brückner, who owns MND-HM-DEV-02. The unowned agent is open for the 14 services without an active owner and the COBOL estate, the junior hole is open in the broker interface team until the review of 30 March 2031, and the vibe-coded system is open for the prototype found outside Flowdesk. The decision is AIDR-1180. The Konzernbetriebsrat co-determines under BetrVG §87(1) no. 6 on measures suited to monitor behaviour or performance, so the check reports by team, never by named developer, with a minimum group size of five (KBV-IT-2024-DEV-01, Chapter 22).

Summary

The chapter read six public records: a regulator's order, a High Court judgment, a vendor's security bulletin, a maintainers' advisory, a researcher's account of an experiment and an engineers' experience report. It dropped two cases whose primary records could not be opened or did not exist. It concerns all five developer functions: D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward. The cases are observable; their interpretation is the book's own.

Three mechanisms recur: the gate or the record sat inside what it governed; a name was trusted and not checked; a count replaced an outcome. The one success case, Google's migrations, shows the opposite practice. No record supports a claim that developers were careless, and none shows an AI system intending anything.

The catalogue has nine anti-patterns, each with the function it concerns and the test it fails. The controls are those of the series: an independent oracle, a named owner, evidence with an age, and a stop path outside the system it stops. It is expected that the patterns will recur, because each begins as a reasonable step. Run the practical guide on one team this quarter and leave open findings open. Chapter 31 follows the two organisations through a year of this work.

Sources

1. U.S. Securities and Exchange Commission (2013). In the Matter of Knight Capital Americas LLC. Order Instituting Administrative and Cease-and-Desist Proceedings, Release No. 34-70694, 16 October 2013. (29, U.S. Securities and Exchange Commission, 2013) https://www.sec.gov/files/litigation/admin/2013/34-70694.pdf
2. AI Incident Database (2025). Incident 1152: LLM-Driven Replit Agent Reportedly Executed Unauthorized Destructive Commands During Code Freeze, Leading to Loss of Production Data. Cited only as the record of a case that was not analysed. (33, AI Incident Database, 2025) https://incidentdatabase.ai/cite/1152/
3. Fraser, J. (2019). Bates and Others v Post Office Limited (No 6: Horizon Issues) [2019] EWHC 3408 (QB). High Court of Justice, Queen's Bench Division, 16 December 2019. (259, Fraser, 2019) https://www.benthamsgaze.org/wp-content/uploads/2021/07/Bates-and-Ors-v-the-Post-Office-Ltd-2019-EWHC-3408-QB.pdf
4. Amazon Web Services (2025). Security Update for Amazon Q Developer Extension for Visual Studio Code (Version #1.84). AWS Security Bulletin, 23 July 2025, updated 25 July 2025. (32, AWS, 2025) https://aws.amazon.com/security/security-bulletins/AWS-2025-015/
5. Nx project (nrwl) (2025). Security advisory GHSA-cxm3-wv7p-598c: malicious versions of Nx and some supporting plugins were published. GitHub Security Advisory, 27 August 2025. (31, Nx project (nrwl), 2025) https://github.com/nrwl/nx/security/advisories/GHSA-cxm3-wv7p-598c
6. Spracklen, J., Wijewickrama, R., Sakib, A. H. M. N., Maiti, A., Viswanath, B. & Jadliwala, M. (2025). We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs. arXiv:2406.10279. (234, Spracklen et al., 2025) https://arxiv.org/abs/2406.10279
7. Lanyado, B. (2024). Lasso Research: AI Package Hallucinations. Lasso Security blog, 28 March 2024. (241, Lanyado, 2024) https://www.lasso.security/blog/ai-package-hallucinations
8. Nikolov, S., Codecasa, D., Sjovall, A., Tabachnyk, M., Chandra, S., Taneja, S. & Ziftci, C. (2025). How is Google using AI for internal code migrations? arXiv:2501.06972. (267, Nikolov et al., 2025) https://arxiv.org/abs/2501.06972
9. Manheim, D. & Garrabrant, S. (2019). Categorizing Variants of Goodhart's Law. arXiv:1803.04585. (61, Manheim & Garrabrant, 2019) https://arxiv.org/abs/1803.04585
10. Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B. & Butler, J. (2021). The SPACE of Developer Productivity: There's more to it than you think. ACM Queue 19(1), 20-48. (62, Forsgren et al., 2021) https://queue.acm.org/detail.cfm?id=3454124
11. Becker, J., Rush, N., Barnes, E. & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089. (63, Becker et al., 2025) https://arxiv.org/abs/2507.09089
12. Brynjolfsson, E., Chandar, B. & Chen, R. (2025, revised 12 August 2026). Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence. Stanford Digital Economy Lab. (51, Brynjolfsson et al., 2025) https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/
13. Hosseini, S. M. & Lichtinger, G. (2025). Generative AI as Seniority-Biased Technological Change: Evidence from U.S. Résumé and Job Posting Data. SSRN 5425555. (69, Hosseini & Lichtinger, 2025) https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5425555
14. GitGuardian (2025). The State of Secrets Sprawl 2025. (237, GitGuardian, 2025) https://www.gitguardian.com/state-of-secrets-sprawl-report-2025
15. Nordqvist, G. (2026). AI Governance. The Architecture as Code Series, Book 2. (162, Nordqvist, 2026) https://aig.geon.se/
16. Nordqvist, G. (2026). AI Threat. The Architecture as Code Series, Book 5. (165, Nordqvist, 2026) https://aithreat.geon.se/
17. Nordqvist, G. (2026). AI Blue. The Architecture as Code Series, Book 8. (168, Nordqvist, 2026) https://aiblue.geon.se/
18. Nordqvist, G. (2026). AI Purple. The Architecture as Code Series, Book 9. (169, Nordqvist, 2026) https://aipurple.geon.se/
19. Nordqvist, G. (2026). AI Leader. The Architecture as Code Series, Book 11. (174, Nordqvist, 2026) https://leader.geon.se/