How GSD's Context Engineering Keeps Your AI Coding Assistant Sharp Throughout Long Projects

Apr 21, 2026

I’ve noticed something frustrating when working with AI coding assistants on long projects. The quality starts great, then slowly degrades. By hour two or three, the AI that was sharp and precise becomes fuzzy and generic. What happened?

This phenomenon has a name: context rot. And I found a framework that solves it elegantly.

The Context Rot Problem

When you have long conversations with an AI assistant, the context window fills up with everything you’ve discussed. The model’s training data gets buried under session artifacts, code snippets, and tangential discussions. Responses become less precise. The AI starts making mistakes it wouldn’t make in a fresh session.

This is why vibecoding—those casual AI coding sessions without structure—produces garbage at scale. The longer you go, the worse it gets.

I searched for solutions and found GSD (Get Shit Done), a framework that tackles this problem head-on with context engineering.

Fresh Context Per Agent

The first mechanism GSD uses is simple but powerful: every agent spawned by an orchestrator gets a fresh context window.

When I work with GSD, my main session stays lean—at around 30-40% capacity. The heavy lifting happens in specialized subagents. Each planner, executor, researcher, and verifier agent gets its own clean 200k-token context window.

Orchestrator (main session)
├── Spawns Planner Agent (fresh 200k context)
├── Spawns Executor Agent (fresh 200k context)
├── Spawns Researcher Agent (fresh 200k context)
└── Spawns Verifier Agent (fresh 200k context)

This means context rot never accumulates. Each specialized agent starts fresh, does its work, and returns results to the orchestrator.

Structured Artifacts Load Only What’s Needed

The second mechanism: GSD doesn’t load your entire project history into context. Instead, it uses structured artifacts that load only relevant context per task.

Each phase of work has specific files it reads:

Planning Phase reads:
├── PROJECT.md (project vision)
├── REQUIREMENTS.md (scoped requirements)
├── CONTEXT.md (current context)
└── RESEARCH.md (ecosystem knowledge)

Execution Phase reads:
├── PLAN.md (atomic task)
├── Project context
└── Skill rules

Verification Phase reads:
├── Deliverables
└── Goals

This selective loading keeps context focused. The planning agent doesn’t need to see execution details. The verifier doesn’t need planning artifacts. Each agent sees only what it needs.

State That Survives Context Resets

The third mechanism: all state lives in files, not in conversation history.

GSD stores everything in a .planning/ directory as Markdown and JSON files:

.planning/
├── PROJECT.md      # Project vision, always loaded
├── RESEARCH.md     # Ecosystem knowledge
├── REQUIREMENTS.md # Scoped requirements
├── ROADMAP.md      # Where you're going
├── STATE.md        # Decisions, blockers, memory across sessions
└── PLAN.md         # Atomic task with XML structure

This file-based approach means I can run /clear in my AI assistant and lose nothing. My project state persists. It’s inspectable by humans, trackable in git, and readable by both humans and agents.

No more frantically copying important context into a notes file before clearing a conversation.

XML Prompt Formatting for Precision

GSD also uses structured XML prompts optimized for AI understanding:

<plan>
  <context>
    What we're building and why
  </context>

  <requirements>
    Specific acceptance criteria
  </requirements>

  <steps>
    Atomic, verifiable tasks
  </steps>

  <verification>
    How to confirm success
  </verification>
</plan>

This structure removes ambiguity. The AI doesn’t have to guess what matters. Verification steps are built into the plan, not afterthoughts.

Why Thin Orchestrators Matter

The orchestrator workflow files in GSD follow a specific pattern: they never do heavy lifting themselves.

Instead, orchestrators:

Load relevant context
Spawn specialized agents
Collect results
Route to next step

This keeps the orchestrator context clean. The main session coordinates work rather than doing it. Heavy computational work happens in fresh agent contexts that get discarded after use.

In This Post

In this post, I explained why AI coding assistants degrade over long sessions and how GSD’s context engineering solves this problem. GSD maintains quality through three mechanisms: fresh 200k-token context windows for each spawned agent, structured artifacts that load only relevant context per task, and file-based state that survives context resets. Your orchestrator stays lean while specialized agents do the heavy lifting. If you’ve experienced quality degradation in long AI coding sessions, GSD’s approach offers a structured solution.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!