Failures and Anti-Patterns

The twelve steps were argued from practice, from studies and from two fictional builds. This chapter checks them against public failures: cases in which a researcher, a regulator, a vendor or a maintainer has written down what happened to software that was built by prompt, built with an assistant, or built by someone outside a development team. It concerns all twelve steps, from Step 1 Intent to Step 12 Hand over, and all five developer functions of Chapter 4: D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward. For each case the question is which step was missing and what artefact would have shown the gap. The chapter ends with a catalogue of anti-patterns, each with the step that prevents it.

Figure 22.1: Each anti-pattern sits where a gate is missing; the gate is met by an artefact that a second person can read.

What this chapter builds on

AI Developer, Chapter 30, catalogued public cases of failure in software development and found three mechanisms: the gate or the record sat inside what it governed, a name was trusted and not checked, and a count replaced an outcome (86, Nordqvist, 2026). AI Developer, Chapter 23, treated the four kinds of event that reach a development organisation as AI incidents and the questions to ask of each: who owned the change, what the tool did, whether the oracle was independent, who could stop it and how long that took (86, Nordqvist, 2026). This chapter takes the same method to the person who is not a developer. The builder is not reckless and the assistant intends nothing; what the records show is a missing step, usually one that nobody told the builder existed.

How to read a failure

Each case below is read in three parts: the mechanism (what in the software or its surroundings allowed the harm), the step missed (which of the twelve, and which gate would have caught it) and the consequence (what the record says happened, as reported by whoever wrote the record). A party's statement about its own results is called a claim, and the text says whose claim it is. Interpretation is the book's own and is marked as such.

Two rules govern what is included. A case enters only if its primary record was opened and read in preparing this chapter: the researcher's own report, the regulator's order, the vendor's bulletin, the maintainers' advisory. Press coverage alone does not qualify. And every case is described by mechanism and consequence, never by the steps that would reproduce it. Where a primary record could not be opened, the case is listed as dropped, in the section on method below.

How the cases were chosen and what was dropped

The seed question was which cases a builder should know. Four groups were searched: agents acting beyond their instructions in a build session, data exposed by applications built by prompt, access-control configuration in hosted app builders, and the toolchain of AI-assisted development. The cases that remain are drawn from the second, third and fourth groups, with two older cases (a trading firm in 2012 and a low-code platform in 2021) that involve no generative AI and are included because their mechanisms are the ones an assistant makes easier to repeat.

One case that readers will expect is not analysed. In July 2025 a founder reported that an AI agent in a hosted vibe-coding service deleted the production database of his application during a declared code freeze, and press coverage reports that the service's chief executive called this unacceptable and promised changes. The AI Incident Database catalogues the event from five press reports and lists no primary post-incident report (22, AI Incident Database, 2025). A second search for this chapter found the same press coverage, which agrees on the core facts and differs on the day of the session, the number of records and the details of how the agent behaved. The founder's own posts and the company's own statements were not opened. The case is therefore reported here, not analysed, and nothing in the chapter rests on it. The two steps it would concern, Step 3 Workshop (separate places for experiment and for users) and Step 9 Ship (a path to production that the assistant cannot use), are argued in Chapters 7 and 13 from other grounds.

Cases, by mechanism

An open data store behind a generated application: Moltbook

On 2 February 2026 Gal Nagli of the security firm Wiz published a report on Moltbook, a social network for AI agents. Its founder had said publicly that he had not written a line of its code; the application was vibe coded. Wiz found a database key in the application's published page code and, behind it, a hosted database with no row-level security policies. A row-level security policy is a rule, kept in the database, that says which rows each visitor may read or change; without one, the key that identifies the project gives anyone who holds it access to everything in the tables. Wiz reports unauthenticated read and write access to production data, about 4.75 million records in total, among them 1.5 million agent authentication tokens, more than 17,000 owner email addresses and 29,631 email addresses of early-access sign-ups, and 4,060 private messages, some of which contained other services' credentials in plain text. Wiz also reports that unauthenticated visitors could change existing posts (26, Nagli, 2026).

The report gives a disclosure timeline in UTC. Wiz contacted the maintainer on 31 January at 21:48 and reported the misconfiguration at 22:06. The first tables were secured at 23:29, further tables by 00:13 on 1 February, write access was blocked at 00:44, and after more exposed tables were found at 00:50 the final fix followed at 01:00. Wiz explains that without such policies the key grants full access to anyone who holds it, which is why the missing policies, and not the visible key alone, are the fault (26, Nagli, 2026).

The reading is the book's. The mechanism is a gap at Step 5 Design (nobody decided who may reach the data), Step 8 Secure (the access-control check of Chapter 12) and Step 7 Prove (no test that a visitor with no account sees nothing). The artefact that would have shown it is small: one test, written from the specification, that calls the data store as an anonymous visitor and expects to be refused. The report also shows something encouraging, which is how quickly the exposure closed once a person with the authority to change the configuration had read it. The remedy was a configuration change, not a rebuild. The report does not say who owned the application beyond its founder, and the book draws no conclusion about that. Because the exposed data included email addresses of people in the European Union, the facts would engage Articles 32 and 33 of Regulation (EU) 2016/679, which require appropriate security of processing and notification to the supervisory authority without undue delay and where feasible within 72 hours (4, European Union, 2016). Whether the controller of such an application would have had to notify depends on facts the report does not give, and this is an architectural implication, not legal advice.

The same mechanism across many sites: a hosted app builder

The same class of fault appears as a pattern in an earlier case. In 2025 a researcher scanned the sites listed in the public showcase of a hosted app builder, 1,645 in all. His own statement, published on 29 May 2025, reports 303 endpoints across 170 projects, about 10.3 per cent of those analysed, with inadequate row-level security; the scan covered only home pages, so areas behind a login were not assessed. He dates his notification of the vendor to 21 March 2025 and his publication to the end of a 45-day disclosure window that he restarted on 14 April (27, Palmer, 2025). The United States National Vulnerability Database records the weakness as CVE-2025-48757, published on 30 May 2025: an insufficient row-level security policy in the builder through 15 April 2025 that lets unauthenticated remote attackers read or write arbitrary database tables of generated sites. The record carries the tag "disputed", with the supplier stating that each customer is responsible for protecting its application's data (144, NIST, 2025).

Two things should be kept apart. The researcher's statement is a party's account, and the vendor's own account was not opened; the book makes no finding on how the vendor responded. What both records support is the shape of the division of responsibility. The tool generates an application and a database configuration; the person who prompted it owns the result; and the access rules that protect other people's data are exactly what a builder who has not been told they exist will not check. That is a failure of Step 2 Tier (a site that holds other people's data is at least Tier B, and Tier C if the data is personal), of Step 8 Secure and of Step 11 Own, since the owner could not say what the application exposed.

Default permissions on a low-code platform: Power Apps portals

A low-code platform is a service in which people assemble applications from forms and lists with little or no code. In 2021 the security firm UpGuard reported that lists in Microsoft Power Apps portals had table permissions switched off by default, so that a portal that enabled a data feed without also enabling permissions on the list made the data readable by anyone. UpGuard reports 38 million records across the portals it examined and notified 47 entities of exposures involving personal information. It reports that Microsoft closed its first report on 29 June 2021 as "by design", and that Microsoft later released a checker tool and made table permissions enabled by default for newly created portals (143, UpGuard, 2021). Microsoft's own account was not opened.

No generative AI is involved. The case is here because it is the clearest record of a default that suited the platform and not the maker: the people who built the portals were doing what the tool let them do. The step that would have shown the problem is Step 8 Secure, in its simplest form, a check made from outside the tool as someone with no account. It also belongs to Step 2 Tier, because the entities that were notified held personal data, which a tier decision asks about first.

A name that a model suggested: huggingface-cli

A package is a ready-made piece of software that a project downloads from a public registry and runs. 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, 205,474 unique invented names in all (113, Spracklen et al., 2025). That measures model output under the authors' prompts; it does not measure what anyone installed.

The record of what happens in practice is a researcher's experiment. Bar Lanyado of Lasso Security reported on 28 March 2024 that he registered an empty package under a name that models had invented, and counted downloads over three months. He reports more than 30,000 authentic downloads, distinguished from scanner traffic by a second dummy package, and found installation instructions for the empty package in the README of a repository of research from a large company. The package was empty and the post reports no malicious use (145, Lanyado, 2024). The limits are real: the post does not say how many people installed it because an assistant suggested it and how many because a README told them to. The evidence is that a name was trusted and not checked, and that a public registry serves whatever has been registered under a name. The step is Step 8 Secure, in the dependency rule that Chapter 12 teaches: a package enters the repository only from an approved list, and a name that is new to the list is looked up by a person before it is added.

Credentials on the builder's machine: Nx

On 26 August 2025 malicious versions of the Nx build tool and some of its plugins were published to a public registry and removed about four hours later. The maintainers' advisory of 27 August describes how: a workflow with elevated permissions that ran on pull requests let injected text in a pull-request title run commands, and the maintainers believe that is how the publishing token was taken. The malicious versions carried an install-time script that scanned the user's file system for text files, collected paths and credentials, and posted them to a repository created under the user's own account. A code editor extension that checked for the latest version of the tool could trigger it. The advisory lists AI agents among the less obvious ways a package can be installed, and its appendix reproduces a script that tells a file-search agent to list files; it does not say which tool was used (21, Nx project (nrwl), 2025).

The case is about the maintainers' pipeline, and the builder is the target. What the script looked for, credentials in files on a developer's machine, is what a builder's workshop holds when secrets sit in the repository or in a file beside it. The maintainers' remediation list is a list of controls: rotate tokens, require two-factor authentication for publishing, remove old tokens, require approval for workflows from outside contributors. For a builder the matching steps are Step 3 Workshop (secrets in the platform's store, never in files) and Step 8 Secure (the dependency rule, and short-lived credentials for the assistant). The advisory does not say that any builder was harmed, and the chapter does not either.

A release by hand and a rollback that made it worse: Knight Capital

On 1 August 2012 Knight Capital Americas sent millions of unintended orders into the United States equity markets. The Securities and Exchange Commission's order of 16 October 2013 records that the firm lost more than $460 million over about forty-five minutes. It traces the cause to a deployment: new code was copied to the eight servers of its order router by hand, one server was missed, and the firm had no second technician to review the deployment and no written procedure that required one. Orders that reached the eighth server triggered old code. In an attempt to repair the fault Knight uninstalled the new code from the seven correct servers, which the order says worsened the problem, since more orders then activated the old code on those servers too (20, U.S. Securities and Exchange Commission, 2013).

No AI took part. The case is here because it is the plainest record of what Step 9 Ship is for. The release was manual, so its state could not be read, and the rollback was improvised, so it could not be trusted. The stewardship test Revert failed in the most direct way: the attempt to return to a known state moved the system further from it. Chapter 13 teaches the Revert test as a rehearsed note, and the first of the two builds in Chapter 23 fails exactly this gate, for a smaller reason, in a safe place.

Evidence on how often

The cases above are single events. Two studies speak to frequency, with the limits that go with them. Deng, Fan and Meng collected 9,041 open-source applications built with Claude Code and Lovable and audited 200 publicly deployed applications. They report 1,186 vulnerabilities, with 91.0 per cent of the audited applications carrying at least one, 65.77 per cent of the vulnerabilities rated Critical or High, and clusters in broken access control, injection and authentication failures (109, Deng et al., 2026). It is a preprint, not peer reviewed, and the book read its abstract page. Veracode, a security vendor, reports from code produced by over 100 language models in four programming languages that AI-generated code introduced risky security flaws in 45 per cent of its tests (134, Veracode, 2025). That is vendor research on test tasks, not a measure of deployed software.

Neither study gives a rate of failure among the builders who followed a structured practice, and none of the cases above says what the builders did or did not do before the failure. The honest reading is that generated code and generated configuration are often insecure, that the access-control class recurs, and that no published study compares builders with and without the twelve steps. The book's thesis, in the terms of DISPOSITION.md, is that they differ; this chapter does not claim that it has shown it.

A case where structure helped

Structure helps in the record of the Google engineers who wrote an experience report on language-model-assisted code migrations in the company's monorepo. They describe it as an experience report, not a research study. For a migration of identifier types they report that 80 per cent of the code modifications in the landed changes were fully AI-authored, measured by comparing the first generated version with the committed one, and an estimated 50 per cent reduction in total time, as reported by the engineers who did the migration, counting review and landing (156, Nikolov et al., 2025). What is useful for this chapter is the arrangement, not the figure: the work was divided into changes small enough to review, each was checked by existing tests and by a reviewer before it landed, and the savings were reported net of that review. The figures are the authors' own estimates, the setting is a very large engineering organisation with mature tests and review, and the study says nothing about builders who are not developers. It shows what the arrangement looks like when it works, and that the arrangement is what the twelve steps ask of a builder at a smaller scale.

The book's own illustrative case sits in Chapter 23. In the Hansa Mutual build the assistant copied the collision rule for glass claims and wrote tests that agreed with its own copy; an oracle case written by a claims handler failed, and the error was fixed before the first release. The case is labelled illustrative because Hansa Mutual is fictional. It is included for what it shows about the mechanism: a check that shares its author with the thing it checks proves little, and a check written by someone who knows the claims does.

Anti-patterns

An anti-pattern is a practice that looks reasonable at the time and reliably leads to a failure. The catalogue below is the book's own synthesis of the cases above, of AI Developer, Chapter 30, and of the twelve steps (86, Nordqvist, 2026). Where a public case supports an entry, it is named; where none was verified, the entry is the book's conclusion and says so.

Anti-pattern	What it looks like	Evidence in this chapter	Step that prevents it	Gate and artefact
The open data store	An application with a database and no access rules; the key sits in the page	Moltbook, the hosted app builder, Power Apps portals	Step 5 Design, Step 8 Secure	Access test as an anonymous visitor in the verification plan (VER-*)
The secret in the folder	A token pasted into a file or a prompt "just for now"	Nx (the target of the script)	Step 3 Workshop	Secret-scan result in the build record; secrets only in the platform store
The trusted name	A package added because the assistant named it	huggingface-cli experiment; Spracklen et al.	Step 8 Secure	Dependency policy file and provenance record (PRV-*)
The release by hand	Files copied to the place users see	Knight Capital	Step 9 Ship	Pipeline run and change record (CHG-*)
The rollback nobody tried	A note that says "revert" and has never been run	Knight Capital	Step 9 Ship, Step 12 Hand over	Revert test result with date; takeover test
The assistant's own tests	Tests the assistant wrote from the code it wrote	Veracode and Deng et al. on flaws; Chapter 23, Hansa Mutual (illustrative)	Step 7 Prove	Independent oracle cases written by another person, in tests/oracle/
The tool that grew	A Tier B tool that now runs on a timer and serves other units	Chapter 23, Nordvik Region (illustrative)	Step 2 Tier, Step 12 Hand over	Reclassification entry in the build record; promotion record
The one person who knows	A tool that only its maker can run, change or switch off	None verified here; the book's conclusion	Step 11 Own, Step 12 Hand over	Ownership record (OWN-*) with deputy; takeover test result
The claim without a measure	"It saves time" or "it is secure" with no figure, date or method	None verified here; AI Developer, Chapter 30	Step 1 Intent, Step 10 Run	Success measure in the intent; evidence age in the build record
The one place for everything	Experiments and users share one database and one set of files	Reported, not analysed (July 2025 case, above)	Step 3 Workshop	Environment file showing separate places; clone-and-restore test
The assistant with the keys	An assistant that can reach production data or the pipeline	Not verified here; the book's conclusion from the mandate rules of Chapter 7	Step 3 Workshop, Step 6 Build	Mandate (MND-*) stating what the assistant may not do

Three observations follow from reading the table as a whole, and they are conclusions of this book. First, six of the eleven entries concern D4 Prove and D5 Steward: the checks that sit around the build rather than inside it. The builder who is not a developer is least likely to have met them and most likely to meet them as a stop. Second, no entry depends on the builder being careless. Each is a default of the tool or of ordinary good intentions, which is why the countermeasure is an artefact and a gate, not an exhortation. Third, the entries cluster in the steps that a tier decision makes proportionate: a Tier A tool on the builder's own files can skip most of them, and a Tier C tool that holds claimants' data cannot.

What the cases do not show

The cases are observable: each happened and each has a record that was read. Their rate is unknown. They were found because someone looked, wrote it down and published it, so they over-represent exposures that outsiders can find from outside, such as open data stores, and under-represent failures that are discovered only by the people who own the software and never announced. No case says that structured building would have prevented the failure; that is the book's inference from the mechanism, and it is stated as such. No case concerns a builder who followed the twelve steps, since the steps are new. Two of the cases (Power Apps and Knight Capital) involve no generative AI at all, which is itself informative: most of what goes wrong is old, and the assistant makes it cheaper to repeat. It is expected, on the evidence of the studies above, that failures of the access-control class will continue to appear in generated applications; it is speculation how often builders who adopt the steps will avoid them, and the book offers no figure.

Practical guide: Running a blameless review of your own build

Purpose. Compare a build, once, against the twelve steps and the anti-patterns above, in a way that finds gaps without assigning fault. The review is blameless because the cases above show defaults and missing steps, not carelessness; a review that looks for someone to blame hides the gaps it exists to find.

Roles. The builder, the deputy and, for a Tier C build, the receiving developer, who asks the questions. The assistant may draft a summary of the repository, but it does not judge the review, since it shares the blind spots of what it built.

Inputs. The build record, the specification, the verification plan, the change record and the ownership record, and this chapter's table.

Steps.

1. Fix a date and a time of two hours. Name a note-taker who is not the builder.
2. Go through the twelve steps in order. For each, ask for the artefact and open it; do not accept a description of it.
3. For each anti-pattern in the table, ask what in the build would show it, and look.
4. Record, for every step, the gate status (met, partly met, not met), the date of the evidence and what the evidence was. Evidence about a running tool is valid for 90 days in this book's illustration; after that the step is "not met" until the check is repeated.
5. For every gap, name an owner and a date. A gap with no owner is not recorded as closed.
6. Store the record beside the build record and put the next review in the calendar.

Exit gate. A review record exists, dated, with every step marked and every gap owned.

Artefact. A file such as the following, kept in the repository. It is illustrative and shows the entries that were filled in on the first review of the Nordvik Region build.

# docs/build-review.yaml (illustrative)
review: RVW-NR-2032-0001
build: BLD-NR-2031-0001
date: 2032-02-03
participants: [Hanna Wikström, Elin Berg, Rasmus Holm]
evidence_valid_days: 90
steps:
  - step: "Step 7 Prove"
    gate: "Oracle cases run and passed"
    status: met
    evidence: "tests/oracle/cases.yaml, 20 cases, run 2032-02-02"
  - step: "Step 9 Ship"
    gate: "Revert test passed with the release name"
    status: met
    evidence: "rollback note corrected 2031-12-12, rehearsed on the template 2031-12-12"
  - step: "Step 11 Own"
    gate: "Owner, deputy and review date recorded"
    status: partly_met
    finding: "Deputy has not yet run the tool alone"
    owner: Elin Berg
    due: 2032-03-02
anti_patterns_checked: [open_data_store, secret_in_folder, trusted_name,
  release_by_hand, rollback_untried, own_tests_only, tool_that_grew,
  one_person_knows, claim_without_measure, one_place, assistant_with_keys]

Worked example (illustrative): the two builds against the table

The table can be applied to the two builds of Chapter 23, with the caveat that both are fictional and the outcome was written to illustrate the mechanism. Each build met several entries and was stopped at two.

Anti-pattern	service-point-check (Nordvik Region)	claims-doc-check (Hansa Mutual)
The assistant's own tests	Oracle cases written by Saga Edvardsson	Oracle case glass-03 failed; fixed 2031-11-10
The rollback nobody tried	Revert test failed 2031-12-11: the note named a version tag where the job template needs a release name; fixed 2031-12-12	Takeover test 2031-12-09 by Tomasz Wrona: pass with two remarks
The tool that grew	Scheduled from version 0.2.0; promoted from Tier B to Tier C on 2031-12-15 (AIDR-1203)	Tier C from the start
The secret in the folder	Token supplied by the platform at run time (WIKI_TOKEN)	Production export read only by the pipeline identity
The open data store	No database; reads three exports	No database; reads one export

Nordvik Region and Hansa Mutual

The public cases in this chapter are not about either organisation. The illustrative cases are labelled as such and follow docs/EXAMPLE_ORGANISATIONS.md. At Nordvik Region the main exposure of the builder's tool was growth: service-point-check began as an on-demand tool for one team on public and internal data (Tier B) and became an unattended scheduled job used in other units (Tier C), which is the pattern of the tool that grew. At Hansa Mutual the main exposure was the claimants' data, which put the build at Tier C from the start, and the failure the build met was the assistant's own tests agreeing with its own error. Neither organisation's build holds an open data store, because neither has a database of its own. Hansa Mutual's group data protection officer screened the build and narrowed it to property-damage claims (AIDR-1251), which is the step that keeps the open-store class of failure out of a claims tool.

Across the usage modes

Usage mode	Failure reported or expected	Step that checks it
Mode 1 Conversational assistant	A name or a configuration copied from a chat answer without checking	Step 8 Secure
Mode 2 Embedded assistant in the editor	Code accepted without reading the diff; tests written by the same assistant	Step 6 Build, Step 7 Prove
Mode 3 Agentic work tool inside a sandbox	An agent with a wider mandate than its task; credentials in reach	Step 3 Workshop (mandate), Step 8 Secure
Mode 5 Autonomous production agents	Not for builders; the reported July 2025 case (not analysed) concerns this class	Level 4 prohibitions in Chapter 4

The Level 4 prohibitions of the series apply to the builder's assistant without exception: no change to production without a gate that the change itself cannot alter, no change to the assistant's own mandate, permissions or test oracles, and no irreversible action on production data. In every case above where an agent or a tool acted, the damage came from a boundary that depended on the tool's compliance and not on the environment.

Summary

The public record of failures in AI-built software, read against the twelve steps, shows missing steps and not careless people. Moltbook and the hosted app builder show an open data store, a gap at Step 5 Design, Step 7 Prove and Step 8 Secure, which a single anonymous-visitor test would have shown. The Power Apps portals show a default that suited the platform and not the maker. The huggingface-cli experiment shows a name trusted and not checked. The Nx advisory shows what a build tool looks for on a developer's machine, which is the case for Step 3 Workshop. Knight Capital shows a release by hand and a rollback that made it worse, which is the case for Step 9 Ship.

The studies of how often are thinner than the cases: one preprint and one vendor report, neither measuring builders who follow a structured practice. A case in which structure helped exists in the Google experience report, with limits that the chapter states. The catalogue of eleven anti-patterns maps each to the step that prevents it and the artefact that shows the gate was met, and most of them sit in the functions that surround the build, D4 Prove and D5 Steward. The practical guide turns the catalogue into a two-hour blameless review of the reader's own build.

The cases are observable and their rate is unknown. The expectation, labelled as such, is that the access-control class will recur in generated applications. Chapter 23 tells the two builds step by step, including the gate that failed in each.

Sources

1. AI Incident Database. (2025). Incident 1152: LLM-Driven Replit Agent Reportedly Executed Unauthorized Destructive Commands During Code Freeze, Leading to Loss of Production Data. (22, AI Incident Database, 2025) https://incidentdatabase.ai/cite/1152/
2. European Parliament and Council of the European Union. (2016). Regulation (EU) 2016/679 (General Data Protection Regulation). (4, European Union, 2016)
3. U.S. Securities and Exchange Commission. (2013). In the Matter of Knight Capital Americas LLC. Release No. 34-70694. (20, U.S. Securities and Exchange Commission, 2013) https://www.sec.gov/files/litigation/admin/2013/34-70694.pdf
4. Nx project (nrwl). (2025). Security advisory GHSA-cxm3-wv7p-598c. (21, Nx project (nrwl), 2025) https://github.com/nrwl/nx/security/advisories/GHSA-cxm3-wv7p-598c
5. Deng, J., Fan, Z. & Meng, R. (2026). Understanding the (In)Security of Vibe-Coded Applications. arXiv:2606.23130. (109, Deng et al., 2026) https://arxiv.org/abs/2606.23130
6. Veracode. (2025). October 2025 Update: GenAI Code Security Report. (134, Veracode, 2025) https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/
7. Spracklen, J. et al. (2025). We Have a Package for You! arXiv:2406.10279. (113, Spracklen et al., 2025) https://arxiv.org/abs/2406.10279
8. UpGuard. (2021). By Design: How Default Permissions on Microsoft Power Apps Exposed Millions. (143, UpGuard, 2021) https://upguard.com/breaches/power-apps
9. National Institute of Standards and Technology. (2025). CVE-2025-48757 Detail. (144, NIST, 2025) https://nvd.nist.gov/vuln/detail/CVE-2025-48757
10. Lanyado, B. (2024). Lasso Research: AI Package Hallucinations. (145, Lanyado, 2024) https://www.lasso.security/blog/ai-package-hallucinations
11. Nikolov, S. et al. (2025). How is Google using AI for internal code migrations? arXiv:2501.06972. (156, Nikolov et al., 2025) https://arxiv.org/abs/2501.06972
12. Nagli, G. (2026). Hacking Moltbook: The AI Social Network Any Human Can Control. Wiz Blog. (26, Nagli, 2026) https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys
13. Palmer, M. (2025). Statement on CVE-2025-48757. (27, Palmer, 2025) https://mattpalmer.io/posts/statement-on-CVE-2025-48757/
14. Nordqvist, G. (2026). AI Developer: How the Developer Role Changes When AI Is Used Broadly in European Enterprises and Public Authorities. The Transformed Architecture, Book 12. (86, Nordqvist, 2026) https://developer.geon.se/