Back to all posts
· 6 min read

Your AI Doesn't Need Better Prompts. It Needs a Sprint Planning Session.

I was vibe coding with Claude for months. Then I started treating it like a real teammate — with PRDs, scoped tasks, and standing context. Everything changed.

Your AI Doesn't Need Better Prompts. It Needs a Sprint Planning Session.

But I’m more of a Kanban guy 😆

I haven’t been in a formal sprint in years… Story points feel like astrology for project managers. Stand-ups are status theater.

I was vibe coding with Claude for months and it worked great — until it didn’t.

Longer sessions. More complex features. The AI would lose track of what we were building. I’d spend more time re-explaining context than actually shipping. The magic was wearing off.

Then I tried plan mode. Claude Code has this feature where you can force it to plan before executing. Stop. Think. Write down what we’re going to do. Get my approval. Then build.

At first I thought it was a speed bump. Turned out it was the missing piece.

Because planning before building? That’s not new. We’ve been doing it for humans for years. We just call it sprint planning. Or backlog refinement. Or Epic/PRD writing.

The ceremony doesn’t matter. The function does.


The Thing We Already Knew

Every ceremony we complain about in software development exists to solve one problem.

Context transfer.

Sprint planning? Scoping work so everyone knows what we’re building before code gets written. Backlog refinement? Breaking big ideas into chunks a human can hold in their head. PRDs? Getting the picture out of one person’s brain and into a format others can execute against.

These aren’t meetings. They’re bandwidth. Context from one brain to another.

I don’t run sprints. But I scope work before I start. I break features into tasks. I write down what I’m building before I build it. That’s the function. The ceremony is optional.

And once I started treating Claude like a real teammate instead of a magic autocomplete, I realized: AI needs the same thing.


From Vibe Coding to Context Engineering

You know what vibe coding looks like: you open Claude, you describe what you want, you iterate in conversation until something works. It’s fast. It’s fun. It feels like pair programming.

It also falls apart at scale.

The longer the session, the worse the output. (Context rot is real.) The more complex the feature, the more you’re fighting the AI instead of directing it. The magic autocomplete starts suggesting things you already rejected. Starts building abstractions you didn’t ask for. Starts solving the wrong problem.

Ralph Wiggum taught me that fresh context beats extended context. Spin up a new worker, give it scoped instructions, let it execute clean.

But “scoped instructions” is doing a lot of work in that sentence. What does scoped even mean?

That’s where ceremonies come in.


PRDs Aren’t Bureaucracy. They’re Briefings.

A month ago, I started writing PRDs for everything.

Not because I love documentation. Because I was tired of re-explaining context to Claude every session.

A PRD is just structured context. What are we building? Why? What are the constraints? How do we know when it’s done?

When plan mode forces Claude to stop and think, it’s doing the same thing a PRD does - externalizing the picture before execution. I just started capturing that thinking in files instead of letting it disappear into chat history.

Now every repo I work on has a /prd folder. The blog migration. reactiveSWR. context-kit. shopify-backup. FlowSpec. All of them.

A real /prd folder with numbered PRDs Numbered PRDs in a real project. Each one is a briefing doc for Claude.

Each PRD is a briefing doc. When I spin up a fresh Claude session or a subagent, I hand it the PRD. “Here’s what we’re building. Here’s why. Here are the boundaries. Go.”

No more re-explaining. No more “wait, I thought we decided…” No more fighting the AI because it lost context three turns ago.


Break It Down or Watch It Drown

PRDs handle the big picture. But a PRD for a whole feature is still too much context for one session.

This is backlog refinement. Breaking the PRD into stories small enough that one worker can hold the whole thing in its head.

For complex features, I break the PRD into numbered work items (think JIRA tickets). Each one is scoped. Clear boundaries. One task.

Then I hand each work item to a subagent. The subagent gets:

  • The PRD for background (what and why)
  • Its specific work item (what to do right now)
  • Nothing else

Story 1 can’t scope creep into story 3. Story 2 can’t get confused by implementation details from story 1. Fresh context, clean execution, results passed back to the orchestrator.

Backlog refinement isn’t a meeting. It’s chunking. And AI needs chunking more than humans do.


Standing Context: Sprint Planning on Autopilot

The PRD handles new work. But what about the stuff that’s always true?

Every developer walking into a new codebase needs baseline context. How does this project work? What are the patterns? What are the landmines?

For humans, this is onboarding and docs. For AI, it’s CLAUDE.md.

I keep a CLAUDE.md at the root of every project. Here’s what this is. Here’s how we work. Here’s what matters. Claude reads it automatically before every session.

The CLAUDE.md file for this blog The actual CLAUDE.md for this blog. Commands, architecture, patterns, contracts. Claude reads this before every session.

For subfolders with their own rules, I add AGENTS.md files. “This area handles payments. Here are the patterns. Here’s what not to touch.”

It’s sprint planning that runs itself. The AI walks into the room already briefed, every time.


The Pattern

Every ceremony is structured context transfer:

  • PRD = what and why (big picture briefing)
  • Story breakdown = one task, clear boundaries (scoped execution)
  • Standing docs = how we work here (operational context)

Call it Scrum. Call it Kanban. Call it “just how I work.” The label doesn’t matter. The function is the same: get context out of your head and into a format your teammate can use.

The AI is the teammate now.

We didn’t need to invent anything new. We needed to point twenty years of process engineering at a new kind of worker.

Once you get good at this, you start capturing workflows as reusable skills. /write-prd. /code-review. /deploy. Ceremonies you define once, then replay forever. More on that soon.


Where This Is Going

This is where puzzle pieces starting falling in place for me…

Context rot told me the problem: AI degrades over long sessions.

Ralph Wiggum showed me the mechanism: fresh workers beat extended sessions.

Ceremonies gave me the structure: PRDs for briefing, story breakdown for scoping, standing docs for baseline.

But I wanted to go further.

What if I wired all of this into an actual workflow? A planner that writes the PRD. A builder that executes stories one at a time. A reviewer that checks the work. A QA engineer that verifies it.

Not one AI doing everything. A team.

That’s what I built. More soon.


This is part of a series on AI-assisted development. Start with I Built a Life OS in Markdown, then Context Rot and Ralph Wiggum. Next up: the full system.

// RELATED POSTS