A spec file doesn't end context rot by itself
You wrote the spec. You reviewed it. The agent implements task one exactly as written, task two mostly as written, and by task six it's inventing a field name you never mentioned. The spec didn't stop existing. The agent just stopped reading it as if it mattered.
Amazon bet the whole product on the spec coming first
In 2026, AWS did not patch Amazon Q Developer. It announced the end of it. Kiro launched internationally on May 7 as a ground-up replacement built around one rule: you describe a feature, the tool writes a structured spec, and only then does it write code. New signups to the old product were blocked eight days later, with support for existing ones running out in April 2027.
That is the industry's biggest single bet yet that spec-first is the correct default, not an optional discipline layered on top of chat-first coding. It is also, on its own, an incomplete fix.
Why the spec stops being read
A spec file is a document. An agent's context window is where that document actually lives during a session, alongside everything else: the codebase it's read, the errors it's hit, the fixes it's already tried. As that window fills, the model's attention to any one part of it, including the spec, is not guaranteed to hold constant.
This is the mechanism behind what practitioners call context rot: the spec doesn't get deleted, it gets outcompeted by everything accumulated since you wrote it. A rule stated once at task one has to compete for attention against thirty tasks' worth of code by task thirty-one.
What a spec alone doesn't provide
A spec answers "what should get built." It does not answer "which task is next," "is the last task actually done," or "should this session's context get cleared before it starts task seven." Those are orchestration questions, and a static markdown file has no mechanism for enforcing them.
| Question | Answered by the spec | Answered by orchestration |
|---|---|---|
| What are we building? | Yes | No |
| What is explicitly out of scope? | Yes | No |
| Which task runs next? | No | Yes |
| Is the previous task actually finished? | No | Yes |
| Does this task start from a clean context? | No | Yes |
| What does the agent no longer need loaded? | No | Yes |
That gap is why GSD, an open-source layer that sits on top of Claude Code and eleven other coding tools, reached 48,400 GitHub stars by April 7, 2026, a month before Kiro's relaunch. It doesn't replace the spec. It adds the missing layer: a planner that breaks the spec into tasks, a fresh context per task, and a check before the next one starts.
The fix costs one habit change, not a new tool
You don't need GSD specifically, and you don't need to switch to Kiro, to get most of this. The fix is a habit: stop letting one session run the whole spec.
Before your next multi-step build, split the spec into tasks small enough to finish in one sitting, and start a fresh session for each one, pasting in only the spec section that task needs. This is the whole ritual, run once per task:
You are implementing exactly one task from a larger spec. Do not start any
other task, and do not refactor anything the task does not name.
SPEC SECTION (the only requirements that apply):
[PASTE ONLY THIS TASK'S SECTION]
OUT OF SCOPE for this task, even if you notice it is wrong:
[LIST]
DONE means: [ONE TESTABLE SENTENCE].
Before writing code, restate the requirement in your own words and list what
you are choosing not to touch. If the spec section is ambiguous, ask instead
of picking.
Then close the session. Starting the next task in the same window is the exact thing that reintroduces the problem, because everything above is still competing for attention.
It costs you a few minutes of splitting up front. What it buys back is a context window that never has to compete with thirty tasks' worth of accumulated noise to remember what you actually asked for.
The spec was never the part that failed. The session that outlived its usefulness was.