👋 Hi! It's Alex again.
I was 30 minutes into a coding session with Claude Code. Things were going great.
Then at turn 40, the agent started fixing a bug it introduced three turns ago. It imported a module I deleted. It referenced a file path I renamed ten messages back.
I'd hit the death loop. And I blamed my prompts. So I rewrote them. Twice.
Same result. The agent kept drifting.
That's when I realized: session length is the variable that matters. Not prompt quality.
I've since rebuilt how I use coding agents from the ground up. And I've distilled it into a starter kit with spec templates, task planner prompts, agent scoping formats, and worktree scripts; ready to drop into any repo.
I'll give you my core strategies below, but click here to grab the full starter kit.
Now, let's get into it.
Why agents break (it's not your prompt)
The Anthropic Claude Code docs say it directly: when the context window fills up, Claude starts forgetting earlier instructions and making more mistakes.
A 10-turn session is fine. At 50, things drift. At 80, you're spending more time correcting than building.
Birgitta Böckeler, writing in the Martin Fowler engineering series, confirmed this after months of daily agentic coding: the longer a session gets, the more hit-and-miss it becomes, regardless of prompting rigor.
Most people try to fix this with better prompts. That doesn't work. You fix it with shorter sessions, clearer scope, and isolation.
Here's the 3-stage loop that does it.
Stage 0: Write a spec before you prompt
Harper Reed published his workflow in February 2025. His first move isn't coding. It's a 15-minute spec session where an LLM asks him one question at a time until the idea is clear. Output goes to spec.md.
The Doozy founders do it differently. They built a /discussion command that runs before any code is written. Subagents explore the codebase and produce a summary of decisions. No code edits. Just context.
Your spec doesn't need to be elaborate. It needs four things:
Problem: what you're building, one sentence
Constraints: what the agent should NOT touch
Files: the specific files it needs to read
Done signal: a command that passes when it's complete
150-300 words. That's it.
One test: if you can't describe what the feature should not do, keep writing.
Watch out for CLAUDE.md files that balloon. The Claude Code docs are explicit: bloated CLAUDE.md files cause Claude to ignore your actual instructions. Treat it like code. Prune it.
Stage 1: Break the spec into agent-sized tasks
This is where most people skip straight to prompting. Don't.
Feed your spec to a reasoning model and ask it to decompose the work into bounded tasks. Anthropic calls this the orchestrator-workers pattern.
A task is agent-sized if it fits in one context window, lists specific files, and has a binary done/not-done signal.
These will send your agent spiraling:
❌ "Refactor the authentication system"
❌ "Add tests"
❌ "Improve performance"
These work:
✅ "Add a useAuth hook to src/hooks/auth.ts that wraps authService. Update LoginButton.tsx to use it. Done when: npm run typecheck passes."
✅ "Add a POST /api/users/:id/preferences endpoint. Validate with UserPreferencesSchema. Done when: the route test passes."
See the difference? One is an aspiration. The other is an instruction with a finish line.
The Pane team scores every plan 1-10 on confidence for one-pass success. Below 8, break it down further.
Stage 2: Isolate agents with git worktrees
Once your tasks are ordered, tasks that don't share files can run in parallel. The thing that used to block this was filesystem collisions: two agents writing to the same directory, committing each other's half-finished work.
The fix has been sitting in git since 2015. Almost nobody used it until this year.
git worktree add .worktrees/feature-auth -b session/feature-auth
One command. Sub-second. The new directory is a fully independent working tree on its own branch, sharing the same .git object store. Each agent gets a clean branch, zero visibility into other agents' uncommitted changes, and full ability to run tests independently.
This primitive now underpins several tools: amux (runs up to 30 parallel agents via SQLite task claiming), Emdash (YC W26, supports 20+ CLI providers), and Pane (open-source, from the Doozy founders).
None of them are required. A terminal per worktree gets it done.
The key: scope each agent explicitly. Task description, specific files, constraints, done signal. The agent can't drift into adjacent work because adjacent work isn't in its context.
Ten 20-turn sessions instead of one 200-turn session.
What this still doesn't fix
Agents still hallucinate library APIs. They'll write syntactically correct code against an API that changed two major versions ago.
The spec quality ceiling is you. If you don't understand your codebase well enough to write a clear spec, the agent won't either.
And entropy compounds. Incomplete refactors, mixed conventions, dead code; all of it degrades agent performance on the next feature.
This workflow doesn't fix those. But it fixes the death loop.
Where to start this week
Don't adopt all three stages at once.
Your challenge this week isn't to set up parallel agents with worktrees.
It's to write one task plan before your next AI coding session. 10 minutes. Three things:
• Which files this touches (name them)
• What it should NOT do (scope the blast radius)
• The done signal (what command passes when it's complete?)
That's it. Write it down before you prompt.
Once that's a habit, add the spec. Harper Reed's 15-minute planning session regularly saves 2+ hours of correction.
For parallel execution: git worktree add before you open a second tab. One command, isolated branch, no collisions.
I packaged everything into a starter kit: the spec template, the task planner prompt, the agent scoping format, a worktree setup script, and a lean CLAUDE.md — ready to drop into any repo.
👉 Grab the Agentic Coding Starter Kit here for free
You got this!
If you found this helpful, join 50,000+ engineers in my free weekly newsletter and follow my daily posts on LinkedIn.
Until next time, thank you!
