How to give instructions to a coding AI
An AI follows checkable instructions and ignores vague wishes. “Be rigorous” produces nothing; “show me the plan before changing more than one file” changes its behaviour. Write your instructions as orders you can verify, store them in its startup sheet, and it will follow them in every single session.
The wish-versus-order test
Take an instruction you give it often, and ask yourself a single question: could I verify that it was respected?
“Be careful”, “be rigorous”, “don’t break anything”: unverifiable. Those are wishes. A machine does not know what to do with them, so it does nothing with them.
“Show me the plan before changing more than one file”: verifiable in one second — either the plan came before the changes, or it did not. That, it knows how to execute.
The whole difference between a maddening AI and a reliable one lives in that rewording.
The five instructions that change everything
If you were to write only five, these are the ones:
“Before changing more than one file, show me the plan and wait for my go-ahead.” The most profitable. A five-line plan takes thirty seconds to read and saves you from discovering too late that it understood something else.
“Do what I ask, nothing more. If you see another problem, flag it in one line and carry on.” The one that stops surprise changes in places you never asked about.
“Do not rewrite what works, unless I ask.” The one that protects Friday’s work from Monday’s initiatives.
“Never delete anything without asking me first.” The one that prevents the irreparable.
“Never say it is finished without having checked and shown the result.” The one that kills the false “done!”.
Where to write them so they stick
Said out loud in the conversation, these instructions work… until you close the window. An AI starts from zero at every session: what you said yesterday no longer exists this morning.
The only place an instruction survives is its startup sheet — a file placed in your project folder, which it re-reads automatically at every opening. That is an official mechanism, not a trick: the documentation describes it in plain terms.
Write your instructions there once, and they apply every day, in every conversation, without you repeating them.
The mistake of writing too much
The classic trap, once the principle clicks: writing everything. Forty rules, the project’s history, paragraphs of context.
The measurable result: the longer the sheet, the less closely it is followed. The official documentation recommends staying under 200 lines. An instruction drowned in a wall of text is an instruction lost.
The discipline: every instruction that enters must earn its place. If you have never had the problem it prevents, it waits outside.
How to check that it worked
Close everything. Reopen. Ask for a small change that touches several files.
If it presents a plan before touching anything, your instructions are read and followed. If it charges ahead, the sheet is in the wrong place or has the wrong name — fix that first, before writing a single extra instruction.
Frequently asked questions
- Why does it ignore what I tell it in the conversation?
- It does not ignore it in the moment — it forgets it at close. An instruction said in the conversation lives as long as the conversation. An instruction written in its startup sheet is re-read at every opening, forever.
- How many instructions can I give it?
- Fewer than you think. The official documentation recommends staying under 200 lines in total: the longer the sheet, the less closely it is followed. Ten sharp instructions beat forty soft ones.
- How do I know whether an instruction is well written?
- Ask yourself one question: could I check that it was respected? “Be careful” cannot be checked. “Delete nothing without asking me” checks in one second. If you cannot verify it, it cannot obey it.