Plan Your Dive and Dive Your Plan

The thing stopping most people from using these tools is not that they do not understand them. It is the edge of the dock, and the only method I have ever found for it is staying.

The night I handed over the backlog, four hours after watching the pipeline run end to end for the first time. When the path from idea to production gets that short, a bad idea reaches production just as fast as a good one.

Fifty agents went out. Nothing crashed, nothing errored, and the site came back unrecognisable. The failure mode nobody writes about, because it does not look like failure while it is happening.

Every dry cleaner in the world runs on the same rule. No ticket, no shirts. That is my rule for working with AI, and I mean it literally.

Plan your dive and dive your plan is two instructions, not one. Accepting the plan and saying go are separate gates, and the space between them is the only place where changing my mind is free.

One very capable, very expensive thinker was doing two jobs that are not the same job. So the expensive model plans, twice, and the cheap model builds.

Ninety percent of an answer is a dead stop, and it costs you forty minutes fifteen times a day. So I made it a law: the whole command, copy-pasteable, every time.

Every session begins as a stranger who happens to be very good at their job. The ticket tracker is not admin overhead. It is the memory.

The acceptance criteria tell you what to build. The comments tell you why, and the why is the part you will need in six months.

One ticket, one branch, one pull request, merged promptly. The boring part is the point, and uncommitted changes are a small lie the project tells you.

The anxious question used to be whether a product person should learn to code. The answer is now no. What replaced it is understanding the path your code takes after you stop looking at it.

If a new session started right now with no memory, could it find this by looking at the repository and the tracker? If no, it is not documentation. It is a note you wrote to yourself.

AI has changed the mechanics of the design handover completely and has not fixed it at all. What works, what does not, and why the design has to be in the repository.

Nine pull requests shipped one after another. Only three had a real dependency. A list records the order things occurred to me; a graph records the order they actually depend on each other.

Every workflow chart ends with an arrow pointing at deployment, as though shipping were the terminus. It is not. It is the point at which the product starts telling you things you did not know.