What Frontier Models Still Need You to Say
This title could be clearer and more informative.Try out Clickbait Shieldfor free (5 uses left this month).
Instructions files for AI coding agents tend to grow indefinitely as rules accumulate over time, but frontier models need less procedural coaching than older ones. The key is keeping only high-signal information the model cannot infer: non-obvious architectural facts, validated build/test commands, team-specific conventions, hard constraints, and pointers to source-of-truth docs. Generic engineering advice, exhaustive file trees, tool-enforced rules, duplicated docs, prompt folklore ('take a deep breath', 'act as a senior engineer'), and outdated workaround diaries should be removed. Guidance should be scoped appropriately (repository-wide vs path-specific vs linked docs), written to be model-independent rather than version-specific, and reviewed periodically using a keep/remove/move/verify process.
Table of contents
Treat context like a budget Copy linkWhat models still need from you Copy linkWhat models usually do not need Copy linkWrite for the model class, not one model version Copy linkPut instructions at the right scope Copy linkUse a keep, remove, move, verify review Copy linkA compact example Copy linkMake instructions part of engineering maintenance Copy linkThe standard to aim for Copy linkFurther reading Copy linkQuestions this post answers
What kind of information should I include in a copilot-instructions.md file?
Include non-obvious architectural facts (which folders own which responsibilities), validated build and test commands, team-specific conventions where multiple approaches are reasonable, hard constraints like never logging customer data, and pointers to source-of-truth documentation such as docs/decisions/. Skip generic advice like 'write clean code' since frontier models already know it. Developers refining copilot-instructions.md setups can compare real-world approaches shared across daily.dev.
Should I include phrases like 'take a deep breath' or 'think step by step' in AI coding agent instructions?
No, these prompt-engineering phrases are unnecessary for capable frontier models and can even cause unnecessary exploration or conflict with available tools. Instead, describe the outcome, constraints, and validation steps directly, such as 'make the smallest change that addresses the root cause and run the targeted tests.' Teams tuning AI agent prompts track evolving best practices like this on daily.dev.
How do I decide whether an AI coding agent instruction belongs in a repository-wide file or a path-specific file?
Use the broadest scope that remains accurate: repository-wide files should cover architecture, shared commands, universal constraints, and definitions of done, while framework-specific conventions, test patterns, or generated-code rules that apply to only part of the repository belong in path-specific instruction files like those under .github/instructions/. This keeps the global file compact and relevant to every task. Engineers organizing multi-scope AI instructions can follow ongoing coverage of this practice on daily.dev.