Our usual advice is to give a model more of the relevant context, not less. We found an exception while debugging why a series of implementations kept converging on the same wrong shortcut.
The pattern we noticed
Tickets that included, as background, a description of a previous approach we had rejected — kept in for the human reader's benefit, to explain why we were doing it differently this time — kept producing implementations that drifted back towards the rejected approach. The model was treating background context as a suggestion with equal weight to the actual instruction.
Why this happens
A model does not reliably distinguish "here is what we are not doing and why" from "here is relevant prior art" unless the framing is extremely explicit, and even then the rejected approach, once present in the context, exerts a pull simply by being described in detail alongside the current instruction. Anything vividly described competes for influence with anything else vividly described, regardless of the label put on it.
What we changed
- Rejected approaches are now summarised in one flat sentence, not described in enough detail to be reimplementable, specifically to reduce how much weight they can exert.
- The actual instruction is repeated at the end of the ticket, after any background, so it is the most recent and most emphasised thing in the context rather than competing evenly with everything before it.
- For anything where the rejected approach is a strong attractor, we omit it from what the model sees entirely and keep it only in the human-facing ticket history, accepting the small loss of shared understanding for the larger gain of not reproducing a mistake.
Context that explains what not to do is not neutral information. Describing a wrong approach in enough detail to explain why it's wrong is also, incidentally, describing it in enough detail to reproduce it.
Where this generalises
We now apply the same caution to any content in a prompt that describes something undesirable in detail — a bug being fixed, an anti-pattern being removed, an insecure approach being replaced. All of these need the same treatment: enough detail for a human to follow the reasoning, deliberately less than that for what the model actually receives, with the current instruction stated last and stated plainly.
The cost of getting this wrong
On the project where we first noticed it, this cost about a week of implementations quietly regressing towards an approach we had specifically ruled out three months earlier, none of it caught until someone reviewing a diff recognised the pattern by name.