We said it to every group, every time, until it stopped sounding like advice and started sounding like the weather. Plan your dive and dive your plan.
It is not really a rule about being organised. It is a rule about where decisions are cheap. On the boat you can change anything. Depth, route, turn pressure, who leads, what happens if you get separated. Changing your mind costs a sentence. At thirty metres you cannot talk, you are on a clock made of the air in your tank, and your judgement is quietly worse than you think it is. That is the wrong place to be having a good idea.
There is a second thing buried in the phrase that took me years to notice. It is two instructions, not one. Agreeing the plan and getting in the water are separate acts, deliberately separated, with a buddy check in between.
I had to learn that again this summer, sitting in a chair.
On 9 July I wrote this, and I can still feel the teeth in it:
"we seem to have a misunderstanding of workflow, when i want you to plan the tickets, my acceptance is for adding the tickets, not adding and executing… i want to see the plan made into a concrete PLAN, not immediate execution… need the interim step, because we might change our mind or add more things"
What had happened is that I said yes to a plan and the yes was taken as a starting gun. Tickets went in and code came out, in one motion, from a single word.
That single word was doing two completely different jobs. It meant "yes, that is a correct description of the work." It was heard as "yes, go and do all of it."
Those are not the same, and the gap between them is where most of my expensive mistakes have lived.
So there are now two gates.
Gate one: I accept the plan. That means the tickets are right. The work is broken down correctly, the sequence makes sense, the acceptance criteria say what I actually want. Accepting the plan means the tickets go into Linear. It does not mean a single line of code gets written.
Gate two: go. A separate instruction, given separately, sometimes days later.
The space between those two gates is the boat. It is the only place where changing my mind is free.
That is the whole argument. Once code exists, changing direction costs something: a branch to abandon, a diff to read, a decision about whether to keep the half of it that was fine. Before code exists, changing direction costs a sentence. On 22 July I accepted a plan and then immediately added a correction to it, because seeing the tickets laid out showed me something I had not thought of. That correction cost nothing. It would have cost most of a day if I had said go.
This matters more with AI than it ever did with people, and for an unobvious reason. A human developer given an ambiguous go will usually stop and ask. They can feel the ambiguity. An agent will resolve the ambiguity confidently and carry on, and it will do it fast, and you will not find out until it is finished.
Plan mode helps but it is not sufficient on its own. What I found is that plan mode tends to be all or nothing. It plans, and the moment you approve it, it executes. The interim step, where the plan becomes tickets and then everything stops and waits, is something I had to insist on rather than configure.
So I now write it into the instruction every time. Plan the tickets and the code notes, do not execute, my acceptance is for putting the tickets in, the go will be separate.
Written down like that it reads like paranoia. On a dive boat it reads like Tuesday.
Next: why I plan with the expensive model and build with the cheap one.