Curse of instructions
It is one of the most relevant findings for spec-driven development, and until now it lived as a mere mention within context engineering. As instructions pile up in a prompt, the model's ability to comply with each one drops predictably: it follows the first ones reliably and starts failing to follow the last ones. With ten detailed rules, it may overlook the final ones; with fifty, it will read the spec only partially.
The evidence
The phenomenon has its own body of research. Work on what gets "lost in the middle" showed that models retrieve information placed at the beginning and end of the context better than information in the center. And research on "context rot" has found that retrieval capability declines as the number of tokens grows in all large models, regardless of the nominal size of their window.
From Prompt Engineering to Context Engineering
The industry's response has been to name a discipline. Context engineering differs from prompt engineering because it changes the question: it is no longer how to word the instruction, but what should occupy the window at each moment and what is best evicted, compressed, or delegated. Anthropic's guide frames it as the management of a scarce resource, the model's attention, which is administered like any other budget.
The countermeasure: a slice per task and reusable context
For those who write specs, there are four consequences: a spec that is smarter, not longer; decompose instead of accumulate (five specs of ten instructions each, assigned to the tasks where they are relevant, perform better than one with fifty); prioritize (if it cannot be split any further, the critical items—such as security—go at the beginning); and separate levels (the boundaries system in AGENTS.md creates categories of urgency instead of a flat list).
The operational countermeasure that teams have settled on has two parts:
- Give each task the portion of the spec it needs, instead of loading the full document in every interaction.
- Systematize reusable context (house conventions, deployment procedures, in-house architectural patterns) in dedicated files that the agent loads when it needs them, instead of bloating a single document.
Thus, the constitution contains the few rules that always apply, each task's prompt contains the specific ones, reusable pieces are loaded when needed, and the full spec exists as a reference without being loaded in its entirety in every interaction.
Signs of an overloaded spec: the agent ignores written constraints, follows the instructions at the beginning but not those at the end, improves when the spec is trimmed, or gets isolated tasks right but fails when several are combined. When these signs appear, the problem is not that the agent is bad, but that the spec is asking too much of it at once.
Common mistake
Responding to a failure by adding more instructions. It makes the problem worse: the answer is to divide better, not to write more. Long lists of equally weighted rules are not weighted well (critical items go first and are separated by level), loading the full spec in every interaction saturates the context, and repeating in-house knowledge in every spec is avoided by writing it once in a reusable piece that the spec refers to.
Resources
📊 SDD Teaching GuideResources · Scrum Manager
🏦 SDD in Agile TeamsSkill Arena · Scrum Manager
References
- Anthropic. (2025). "Effective context engineering for AI agents."
- Liu, Nelson F. et al. (2023). "Lost in the Middle: How Language Models Use Long Contexts." arXiv.
- Chroma. (2025). "Context Rot."
See also
Want to advance in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.