How it works in practice

1. 1

   Documentation that talks to the AI

   In every project folder lives an AI_README file, and in the root a CLAUDE.md — the constitution the agent reads before touching the code. It’s not an archive for people “someday”, but a map written as you go: what’s here, what the contracts are, what not to touch. Ask a contractor or an AI: “where is this documented?”. If a change in the code doesn’t go hand in hand with an update to the docs, the work isn’t finished.

2. 2

   Verification instead of “probably works”

   “It works” may only be said after running and checking — best with a test that stays in the project for the future. A good habit is test first, then code, and a test pyramid: many fast tests of small parts, fewer that check whole paths. Your control question is: “show me it works”. Proof in the form of green tests or a recorded walkthrough beats any assurance.

3. 3

   Scripts and databases: plan first, move second

   Every tool that changes data works in dry-run mode by default — it shows what and how much it will change — and only does it for real after a deliberate confirmation (--execute). Before such an operation a backup is made, a point of return in case something goes wrong. Operations are designed to be idempotent: you can run them twice without doubling the effect. Before you approve a run on live data, demand the dry-run result and confirmation that a copy exists.

4. 4

   Git and deployments: memory and an undo button

   Git history is the project’s memory — before anything is built from scratch, you check whether the problem wasn’t already solved. Changes are saved in small, coherent batches (one topic per commit), so that in case of trouble you can undo just one thing, not everything. Every live deploy gets a clear marker (a tag) with a date — that enables a quick rollback to the previous working version. Production is touched only on your explicit “deploy”.

5. 5

   Stack: decisions already settled

   The Craft gives proven default technology choices — Python, a solid database, a web/API layer, Docker for packaging, a simple server — so you don’t waste time on debates long since closed. It’s not that this is the only right path, but that it’s a predictable, cheap-to-maintain one. When a contractor proposes something different, ask “why are we moving away from the default?”. A good answer is a concrete reason, not fashion.

Chapters at this level