Should you tell an AI what not to do?
Telling an AI what not to do feels like setting a fence. In practice, a long list of prohibitions often produces an assistant that refuses too much, hedges constantly, or misreads the edge case you forgot to name. Describing the behaviour you want — with a note on what to do in the exception — usually works better. Hard rules belong somewhere else entirely.
Why do negative instructions cause problems?
A prohibition is a gap in a map. You write 'never send a formal tone' and the assistant now has to decide what counts as formal every time it composes a sentence. If your definition and its definition diverge — and they often do — you get outputs that feel wrong without a clear reason why.
Negative instructions also stack badly. Each new 'never' narrows the space the assistant can work in, but the boundaries interact in ways you did not plan. Two reasonable prohibitions can combine to rule out the only sensible answer to a third situation. The assistant then either freezes, hedges, or picks the least-bad option silently. None of those outcomes is what you wanted.
- Prohibition
- An instruction that names what the assistant must not do. Useful in small numbers; brittle when stacked.
- Positive framing
- An instruction that names the behaviour you want, including what to do in edge cases. Leaves less to interpretation.
- Hard rule
- A constraint enforced by a mechanism — an approval step, a confirmation screen, a spending cap — rather than by a sentence in a prompt.
- Exception clause
- A note inside a positive instruction that handles the predictable deviation: 'do X, and if Y, do Z instead'.
What does positive framing look like in practice?
Instead of 'never use jargon', try 'write for someone who understands the industry but has not read our internal documentation — if a technical term is unavoidable, define it in the same sentence'. That gives the assistant a target and a fallback. It can act confidently on the instruction rather than guessing where the jargon line sits.
The exception clause does the work that a second prohibition would otherwise do. 'Summarise the email thread and reply with the next action — if the thread is ambiguous about who owns the next step, ask before replying' is one instruction with a built-in decision rule. Compare that to 'summarise threads' plus 'never assume ownership' plus 'always ask when unclear': three rules that may conflict the moment a thread is only slightly ambiguous.
| Intent | Negative framing | Positive framing |
|---|---|---|
| Tone | Never sound too casual | Match the register of the person you are replying to; default to direct and plain |
| Scope | Don't go off-topic | Answer the question asked; if related context is useful, add it after a line break |
| Ambiguity | Never assume | When the instruction is unclear, state your reading of it and ask one question to confirm |
| Length | Don't write too much | Aim for the shortest answer that covers the point; add a section break if a second point is needed |
Where is a hard rule actually the right call?
There is a category of action where no instruction — positive or negative — is the right control: anything that is difficult or impossible to reverse. Sending a message, posting publicly, moving money, deleting a file, deploying code to production. For these, the right mechanism is an approval step, not a sentence.
An approval step works because it does not rely on the assistant interpreting your intent correctly under every possible circumstance. It creates a moment where a human sees what is about to happen and decides. The instruction 'never send without my approval' is weaker than a system that literally cannot send without your approval, because the instruction can be misread or forgotten in a long session; the mechanism cannot.
This is also why spending caps and confirmation screens exist in tools that handle real transactions. The cap is not a reminder — it is a structural limit. If you are working with any AI tool that touches money, publishing or irreversible data changes, look for the mechanism first and treat the instruction as a backup, not the other way around.
How should you decide which approach to use?
A useful test: if the assistant got this wrong once in twenty tries, what would happen? If the answer is 'an awkward email' or 'a slightly off-brand paragraph', a positive instruction with an exception clause is probably enough. If the answer is 'money leaves my account' or 'a post goes live before I have seen it', you need a mechanism, not a better sentence.
For everything in between, start with one positive instruction that includes the most predictable exception. Run it for a while. Add a second instruction only when you find a real gap — a situation the first instruction genuinely did not cover — rather than pre-emptively listing every scenario you can imagine. A short, coherent set of instructions is easier for an assistant to apply consistently than a long list of edge cases that may never arise.
GROX, for instance, separates the two concerns structurally: routines and autopilot modes handle the 'what to do' side, while spending limits, confirmation steps and a daily loss cap handle the irreversible-action side. That separation means you can write clear, positive instructions for the work without also trying to use those instructions as a safety net for money or sending.
Common questions
Does telling an AI 'never do X' actually stop it from doing X?
It reduces the likelihood, but it is not a guarantee. The assistant interprets the instruction every time it acts, and interpretation can drift in edge cases or long sessions. For actions where 'never' genuinely must mean never — sending, spending, deleting — a structural control such as an approval step or a hard cap is more reliable than a sentence in a prompt.
How many instructions is too many?
There is no fixed number, but the risk rises when instructions start to contradict each other or when the assistant has to resolve conflicts between them silently. A practical sign that you have too many: the assistant hedges on straightforward requests, or you find yourself adding new rules to fix the side-effects of old ones. At that point, rewriting from scratch with positive framing usually helps more than adding another prohibition.
What is an exception clause and how do I write one?
An exception clause is a 'and if this happens, do that instead' added to a positive instruction. It handles the predictable deviation without needing a separate rule. For example: 'Reply in the same language as the message — if the message mixes two languages, use the one that appears in the subject line.' The clause gives the assistant a decision rule rather than leaving it to guess.
Should I use negative instructions at all?
Yes, in small numbers and for genuinely binary situations where there is no positive equivalent. 'Do not include the client's account number in outgoing emails' is clear, bounded and hard to reframe positively without losing precision. The problem is not negative instructions themselves but relying on them as the primary way to shape behaviour, especially when stacked in large numbers or used as a substitute for a proper approval mechanism.
If you want to see how structural controls — spending caps, confirmation steps, autopilot limits — sit alongside plain-language instructions in practice, GROX is free to try with no card required.