Three system prompt mistakes that survive code review

These aren't the obvious mistakes. They're the ones that look fine in review, pass a quick smoke test, and then fail subtly in production when a task is complex enough or the edge case hits. 1. Preference language Words like "prefer," "try to," "when possible," and "ideally" turn a rule into a suggestion. The model treats suggestions as optional — which is what they are. Before — ignored under pressure: When possible, avoid creating new files. Prefer to edit existing files when making changes. Try to keep responses concise. After — actually fires: Edit existing files. Do not create new files unless the task explicitly requires a new file. If you think a new file is needed, stop and say so. Keep responses under 200 words unless the task requires more. If you need more space, explain why. The pattern to watch for: any instruction where a person could reasonably say "I tried but it was complicated." That's preference language. If you mean it as a rule, write it as one — no conditionals, n