Appearance
Chapter 9 - What aiXP Is Not: Anti-Patterns and Traps
The failure modes of AI-assisted development are specific and predictable. This chapter catalogs the most common ones - not as a list of things to avoid in the abstract, but as patterns that show up in practice and are easy to mistake for legitimate workflows.
The undifferentiated swarm
Launching multiple AI sessions at a backlog without defining their roles, scope, or review relationships. This feels productive - many things are in motion simultaneously - and produces a high volume of output that is difficult to integrate safely, because no session has the full context needed to evaluate what the others are doing.
The failure mode is not that the individual sessions produce bad code. It's that the outputs conflict, overlap, or subtly contradict architectural decisions made in a different session that neither was told about. The fix is Agent Role Topology: define the topology before the sessions start, not after the conflicts appear.
Rubber-stamp review
The gradual degradation of diff review from genuine judgment to mechanical approval. It often starts as a legitimate shortcut - this change is small, I can see it's correct, approve - and becomes a habit that extends to changes that aren't small or obviously correct. The dangerous feature of this failure mode is that it's invisible from the inside: you don't feel yourself approving carelessly, you just do it.
This is what Vigilance Budgeting addresses. Session limits and output-volume ceilings are not productivity constraints; they're the mechanism for keeping the review quality above the threshold where "I reviewed this" means something.
Spec avoidance
Generating an implementation before the requirements are clear enough to write down, on the assumption that seeing the generated output will clarify what you actually want. This sometimes works. More often it produces a codebase shaped by whatever the model inferred from an underspecified prompt, which then becomes the de facto spec because it exists and refactoring is work.
Spec-First Prompting exists specifically to close this trap: write the spec first, develop it to the point where an AI could implement it faithfully, and treat any gap in the spec as a signal that the requirements aren't understood yet - not a prompt to generate and figure it out from the output.
Context Abandonment and Historical Hoarding
Repository context fails in two opposite directions: letting it rot through neglect, or letting the AI turn it into an append-only museum.
Context abandonment is treating CLAUDE.md, architecture notes, and specs as something you set up once and never maintain. This works at the start of a project and compounds as the codebase evolves. By the time the mismatch between documented context and actual code causes visible failures, re-establishing accurate context is expensive because the code has diverged in ways that aren't explicitly marked.
Historical hoarding is the AI's native trap when asked to maintain documentation: preserving deprecated rules, old API shapes, and running changelogs inside living context files and specs. Git and GitHub pull requests already hold your project's history; your context files should not. For an attention-based language model, reading "We used to do X, don't do X anymore" is a "try not to think about monkeys" prompt - the obsolete tokens sit directly in the context window, distracting and biasing the agent toward the very patterns you retired.
The discipline is two-fold: update context artifacts in the same commit as the work they document, and ruthlessly delete or overwrite anything that is no longer current truth.
Volume as productivity
Measuring a session's value by how many lines of code it produced, how many tickets it closed, or how fast the diff came back. None of these measure whether the output is correct, whether it was what was actually needed, or whether it can be safely integrated and maintained. The rejection of token-volume-as-productivity-metric is a standing position in aiXP, not a caveat - it's directly at odds with what Vigilance Budgeting and Merge/Integration Authority are trying to protect.
Vibe coding dressed as aiXP
Using the terminology and surface structure of this discipline - specs, review passes, role topology - without the underlying commitment to verification. A spec that isn't specific enough to catch a wrong implementation. A review pass that summarizes rather than reads line by line. An "executive review" that has access to all the context it's supposed to lack. These aren't partial implementations of aiXP; they're the failure modes it was designed to prevent, wearing its vocabulary.
The rejection test from the Manifesto applies: Does the human exercise real judgment at each gate, or approve a decision already effectively made?