Prompt Engineering Anti-Patterns: What We Stopped Doing
Prompt Engineering Anti-Patterns: What We Stopped Doing
After cutting our system prompts by roughly 60 percent with no eval regression, we started noticing patterns in what we removed. Here are the specific anti-patterns we see most often and what we do instead.
The Redundancy Anti-Pattern
The same instruction in the system prompt, the tool description, and the skill definition. This was necessary with older models that needed guidance repeated across context layers. Claude 5 and GPT-5.6 do not.
Pick the most authoritative location for each instruction and delete the duplicates. Tool descriptions are usually the best place for tool-specific guidance. The system prompt is for cross-cutting constraints that apply everywhere.
OpenAI's guidance is quantitative: "configurations with leaner system prompts improved evaluation scores by roughly 10 to 15 percent while reducing total tokens by 41 to 66 percent and cost by 33 to 67 percent."
The Over-Constraint Anti-Pattern
Compound instructions like "never use X, always use Y, and if you are unsure, ask." This bundles three different behaviors into one line. When eval results are unclear, you cannot tell which part caused the problem.
Break compound instructions into individual, testable constraints. Each constraint maps to specific eval cases. If an eval fails, you know exactly which constraint caused it.
OpenAI recommends using "ALWAYS" and "NEVER" only for true invariants such as safety rules, required fields, or actions that should never happen. For judgment calls, prefer decision rules.
The Vague Tone Anti-Pattern
Broad labels like "friendly" or "empathetic." These are too abstract for consistent results. GPT-5.6 responds far better when you spell out the actual writing behavior you want.
OpenAI's example: instead of "be empathetic," say "name the customer's problem in your first line, give the fix as numbered steps, skip the apology paragraph."
The same applies to personality instructions. Keep personality and task instructions in separate sections. Personality should shape the user experience; task instructions should shape behavior. Neither should replace clear goals, success criteria, tool rules, or stopping conditions.
The Brevity Anti-Pattern
Blanket instructions like "be concise" or "keep it short." GPT-5.6 is more concise by default than GPT-5.5. These instructions can now make responses too short, dropping detail that was actually useful.
If you need specific control over output length, use GPT-5.6's verbosity parameter (low, medium, high) instead of prompt-level brevity rules. Or describe which information to keep and which detail to drop.
The Repeated Rule Anti-Pattern
The same constraint restated at different autonomy boundaries. For example, "ask before writing files" in the safety section, "do not edit without approval" in the workflow section, and "confirm before changes" in the tool description.
Keep the policy in one place and state each rule once. Repeating instructions causes unnecessary approval requests for safe, expected actions and desensitizes the model to important constraints.
The Everything-Is-Hard Anti-Pattern
Treating every instruction as equally important. Safety rules, style preferences, and workflow guidance get the same emphasis. The model cannot distinguish between "this is a hard constraint" and "this is a suggestion."
Use tiered instruction markers: hard constraints (safety, required fields, never-violate rules) get explicit marking. Preferences and style guidance go in a separate section with lower emphasis language. The model prioritizes hard constraints when they conflict with preferences.
Read the full Context Engineering series: orioverse.com/blog/what-is-context-engineering