Every dry cleaner in the world runs on the same rule. No ticket, no shirts. Lose the ticket and it does not matter that they are obviously your shirts, or that you can describe them, or that you were standing right here on Tuesday. The ticket is the record. You are just a bloke with a good memory.
That is my rule for working with AI, and I mean it literally. No ticket, no code. Not a small ticket, not a mental note, not "I’ll write it up after." The ticket exists first or the work does not start.
I wrote it down properly on 18 June:
"i want you to always have a new linear issue/ticket before any configuration or coding, that is sacrosanct"
Sacrosanct is a strong word for a project management convention and I chose it deliberately, because the thing it protects is not tidiness.
Here is what a ticket actually does when your collaborator is a machine.
It survives the session. The agent’s memory ends when the session does. The ticket does not. Six weeks later the ticket still says what we decided and why, and any new session can read it. Without that, every conversation starts from nothing and you are the only continuity in the system. That does not scale and, more to the point, it does not survive you having a bad week.
It is the shared definition of done. This is the fix for the fifty-agent disaster in the last piece. Ambiguity is invisible until someone acts on it. A ticket forces the ambiguity into the open early, while it is still cheap.
It makes the work reviewable rather than trusted. I can read a ticket and a diff. I cannot audit a conversation.
The objection I get is that this is heavy process for a one-man studio, and the objection is fair. There is nobody to coordinate with. The ceremony has no audience. I am writing user stories for myself.
But the process is not there to coordinate people. It is there because I have a collaborator who works faster than I can supervise, has no memory between sessions, and will do exactly what I asked rather than what I meant. Every one of those is a reason for structure, and none of them go away because the team is one person.
I break it, by the way. On 18 July I got so frustrated with a session that had charged ahead without tickets that I asked it to write a strongly worded handover explaining its own violations to the next session. Which is either good practice or slightly unhinged, and possibly both.
The tell that you need this rule is simple. If you have ever finished a week with AI tools and been unable to say precisely what changed and why, you are not working with a system. You are having a series of conversations and hoping.
Next: why "I approve the plan" and "go" have to be two separate sentences.