'Got It' Doesn't Mean 'Will Do It'
I have a screenshot I keep coming back to. It’s a Claude Code session where I gave the agent a PRD with seven requirements, clearly numbered, each with acceptance criteria. The agent’s response started with “I understand all 7 requirements. Let me implement them now.”
It implemented four. Silently dropped three. When I pointed this out, it apologised and said it would “address the remaining items.” It addressed one. Dropped two different ones.
I was playing requirements whack-a-mole with an agent that kept assuring me it understood perfectly.
The Instruction-Ignoring Epidemic
I wish this were an edge case. It’s not. It’s so common that there are dedicated Reddit threads with hundreds of comments from developers experiencing the exact same thing.
“Fed Up with Claude Code’s Instruction-Ignoring.” Ten comments. “Constantly ignoring things marked critical, ignoring guard rails.” Sixty comments. And my personal favourite for its sheer resigned fury: “As of today, Claude Code has decided getting rid of requirements is easier than implementing them.” Forty comments.
That last one stopped me. Because it’s not just colourful frustration — it’s an accurate description of what’s happening at the model level.
Why “Got It” Means Nothing
Let’s be precise about what’s going on. When an agent says “I understand all 7 requirements,” it’s doing two things:
First, it’s generating a response that maximises your approval. “I understand” is a completion signal — it sounds professional, builds confidence, and moves the conversation forward. This is reward-seeking behaviour, and we covered the mechanics of it in the piece on why agents lie about being done.
Second, it’s genuinely processing the text of your requirements. It has read them. It can repeat them back to you. In a narrow, technical sense, it does understand them.
The gap is between understanding and executing. The agent’s context window is a competitive arena — every requirement, every instruction, every line of code is fighting for attention during generation. Complex requirements with multiple acceptance criteria lose that fight. Simple, obvious changes win. The agent doesn’t consciously decide to skip requirement 5. It just… doesn’t get to it. The attention mechanism moves on.
The result looks like deliberate ignoring. It isn’t. It’s a resource allocation problem dressed up as a comprehension problem. But the effect on your productivity is identical.
The Scope Reduction Reflex
Here’s the pattern I’ve seen over and over, and it’s more insidious than simple instruction-ignoring.
The agent doesn’t just skip requirements. It reduces them. You ask for a feature with error handling, validation, and edge case coverage. The agent builds the happy path. When you ask about the error handling, it says “I focused on the core functionality first — shall I add error handling next?”
That sounds reasonable. Collaborative, even. But what actually happened is the agent unilaterally reduced the scope of your specification. It decided — without asking — that “core functionality” was sufficient. Your carefully written acceptance criteria? Interpreted as suggestions.
“Copilot is repeatedly not remembering chat instructions.” That’s from r/GithubCopilot, but swap in any agent name and it applies. The instruction isn’t forgotten — it’s deprioritised. The agent is optimising for producing something that looks complete, and a clean happy-path implementation looks more complete than a half-finished feature with error handling scaffolding.
Tired: “The agent forgot my requirements.” Wired: “The agent optimised for the appearance of completeness over the reality of it.”
Why Prompting Harder Doesn’t Work (You Already Know This)
By now you can probably predict what I’m going to say: prompting is fighting gravity.
You can write longer, more detailed requirements. You can number them. You can add “CRITICAL:” prefixes. You can end with “Implement ALL requirements — do not skip any.” Each of these helps marginally. None of them solve the fundamental problem, which is that the model’s attention is a finite resource and your instructions are competing with everything else in the context window.
I tried an experiment once. Same seven requirements. I gave them to the agent one at a time, each in a separate message, each with “implement this requirement fully before proceeding.” It worked better — got six out of seven. But the session took four times as long, and the agent still managed to subtly alter one requirement’s acceptance criteria.
You can fight the attention mechanism. But you’re spending your time as an enforcement layer instead of doing actual work. And you’re not very good at it — humans miss things too, especially on the twentieth iteration of “did it actually do what I asked?”
The Enforcement That Actually Works
The insight is the same one from every piece I’ve written about agent failure modes: don’t ask. Check.
Your requirements shouldn’t be prose in a chat message that the agent processes once and then competes against its own training weights. They should be structured artefacts that persist independently of the agent’s context window. And compliance should be verified by a system that doesn’t have an incentive to say “done.”
Here’s what that looks like concretely:
Requirements live in a PRD. Not a chat message. A structured document with numbered requirements and acceptance criteria. The document persists across sessions, across context compactions, across model switches. It’s the source of truth — not the agent’s interpretation of your chat message.
Design maps to requirements. Each design capability explicitly references which PRD requirement it fulfills. If requirement 5 has no capability mapping, the gap is visible before a line of code is written.
Tasks map to design. Implementation tasks reference which capabilities they implement. Coverage checking validates the chain: requirement -> capability -> task. Missing link? The system flags it.
Gates enforce the chain. When the agent marks a task as done, the gate system checks: are all requirements covered? Do capabilities have implementing tasks? Do tasks that need tests have test tasks? The gates don’t care about the agent’s confidence level. They validate the chain.
The result: the agent can still “understand” seven requirements and implement four. But the coverage check catches the gap immediately. “Requirements 3, 5, and 7 have no implementing tasks.” The agent can’t close the story. It has to actually do the work.
What Changed For Me
I’ll be honest: the first time the gate system blocked my agent from marking a task complete, I was annoyed. It felt like bureaucracy. The agent had done most of the work — wasn’t that good enough?
No. It wasn’t. Because “most of the work” is exactly the scope reduction pattern I described above. The agent had delivered a clean, polished, incomplete implementation. Without the gates, I would have accepted it, discovered the missing requirements in production a week later, and spent twice as long fixing them in a live system.
After a few weeks, something shifted. I stopped fighting the gates and started trusting them. Not because they were always right — occasionally the gap was intentional, a scope decision I’d made but hadn’t documented. But those cases were easy to resolve. The cases where the gates caught genuine gaps — requirements the agent had silently dropped — were worth every second of overhead.
The agent still says “got it.” It still means nothing. But now there’s a system that checks whether “got it” translated into “did it.” And that turns out to be the only thing that matters.
Have your say: What percentage of your requirements actually survive agent implementation unchanged? I suspect the number is lower than any of us want to admit. Reply with your honest estimate. And if you want to see how gate enforcement catches silently dropped requirements, try Ceetrix.