Requirements for LLM Coding Agents: State the Obvious
Requirements for a large language model (LLM) coding agent need to be much more explicit than requirements for a human developer. The repeated requirements can go in one shared file, such as a Kiro steering file. Agents still miss some requirements that are written down.
Why do LLM coding agents miss requirements?
In November 2026, SemiAnalysis released GDPx, a benchmark that puts frontier models in simulated work environments. Tech Times reports that it tested 13 models on 206 tasks across 11 domains. Datacurve supplied the software engineering tasks, and open-source maintainers wrote them for their own repositories. The SemiAnalysis report breaks down the failed software runs as follows:
| Failure type | Share of failures |
|---|---|
| Involved requirements around the primary request (existing repository behavior, integration, edge cases) | 76% |
| Model never attempted the requirement | 24% |
| Model misinterpreted the intent | 23% |
| Model recognized the requirement and didn't complete it | 17% |
Datacurve wrote the tasks to match how developers prompt today. As models improved, developers moved to short prompts that describe the bug or the feature. The developer expects the model to understand the codebase context, the repository conventions, and software engineering best practices. A human developer on the team already has that context. The GDPx results show that an agent often doesn't.
Put the repeated requirements in a steering file
Codebase context, repository conventions, and best practices are the same from one task to the next. They don't need to go in every prompt. Put them in a file that the agent reads on every task, such as a Kiro steering file or an AGENTS.md file. Each prompt then needs only the requirements that are specific to that task. My guide to agentic AI across the software development lifecycle shows where steering files fit next to Kiro's other tools, such as hooks and Powers.
Agents still ignore written requirements
A written requirement doesn't guarantee that the agent follows it. The public GDPx example is a Git LFS task. The task states that each command must behave "identically in both a partial clone and full clone of the same repository," and that Git LFS may fetch at most once per command. No run passed in 25 runs from five models.
The agents could check the first requirement themselves by running each command on both clones, and they still didn't test it completely. Three of five Claude Opus 5.5 runs broke the second requirement because they kept a git show -s call in an existing helper, and that call caused a second fetch. The report also says that models write self-confirming tests more often than tests of the behavior that the prompt asked for.
Datacurve's summary is that every requirement is within reach, and no model passes them all at the same time.