Appearance
Chapter 1 - The Manifesto: Pillars and Rejection Criteria
aiXP is organized around four pillars. Each pillar is paired with a rejection criterion - a test for whether a proposed practice, tool, or workflow belongs in the discipline or contradicts it.
Pillar 1 - Verification is the work
Generation is not the bottleneck. Writing code, producing output, shipping diffs - these are now cheap. The constrained resource is the human capacity to verify that what was generated is correct, safe, and intentional. Every practice in aiXP either protects or expands that capacity.
What aiXP is not: a way to generate more code faster. Volume of output is not a success metric.
Rejection test: Does this practice increase the rate of unverified change, or decrease it? If a proposed workflow produces more output without a corresponding increase in verification rigor, it fails this test.
XP as a Trust Factory
In Trust Factory, Kent Beck explains that classic Extreme Programming's practices (TDD, pairing, CI, small releases) were never just workflow habits; they were engineered as a "trust factory" to produce confidence between developers, code, and customers. In aiXP, Pillar 1 re-aims that trust factory: verification is not an afterthought or a gatekeeping tax, but the primary work of development.
Pillar 2 - Judgment is not delegatable
AI tools can implement, refactor, review, test, and document. They cannot decide what the software should do, judge whether it does it well enough, or be accountable for the result. The human's role is not to review the AI's work as a formality - it is to exercise the judgment the AI cannot. Practices that reduce the quality of that judgment (vigilance fatigue, rubber-stamp review, context collapse) are failure modes, not efficiencies.
What aiXP is not: a methodology for removing humans from the loop. The loop is the point.
Rejection test: Does this practice require the human to exercise real judgment, or does it require them to approve a decision already effectively made? A practice that consistently produces the second outcome has broken this pillar.
Pillar 3 - The discipline scales with the tools
As AI tools become more capable, the temptation is to loosen the discipline - if the model is better, surely the review can be lighter? The argument runs the wrong direction. More capable tools produce more output at higher speed; the discipline has to keep pace with what's being produced, not relax because the producer is impressive. An error generated at high speed and low scrutiny is not less wrong than one written slowly and reviewed carefully.
What aiXP is not: a fixed checklist that becomes optional once the AI gets good enough.
Rejection test: Would this practice hold up if the AI were twice as fast and twice as confident? If the answer is "we'd probably skip it at that point," the practice is already being treated as a concession to current AI limitations rather than a genuine engineering principle.
Pillar 4 - Context is infrastructure
A stateless collaborator that reads context every session is only as good as the context it reads. Architecture notes, decision records, coding standards, and maintained CLAUDE.md-equivalents are not documentation overhead - they are the mechanism by which a session with no memory behaves like a team member with institutional knowledge. Letting this infrastructure decay is equivalent to letting the test suite decay: the system still runs, but it becomes increasingly unsafe to change.
What aiXP is not: a workflow where context is rebuilt from scratch each session by re-explaining what the project is.
Rejection test: Could a fresh session, reading only the maintained context artifacts, make a reasonable implementation decision without asking? If the answer is consistently no, the context infrastructure has failed this pillar.