Managing the work
How to manage vibe coding sessions without losing the thread
Every new AI coding session starts from nothing. It cannot see the last conversation, so it rebuilds work that was already finished, re-opens decisions you already made, and asks you the same questions again. The fix is to stop keeping the plan in the chat and start keeping it in the project.
Why a new session forgets everything
A chat has no memory of the chat before it. When you close a session and open another — or when the first one runs out of context — the new one begins with only what is written down. If the plan lived in the conversation, it is gone. So the assistant does the reasonable thing with no information: it starts over.
That is where the hours go. Not to hard problems, but to rebuilding what was already done, second-guessing settled choices, and re-explaining the same context on every restart. The problem is not the model. It is that the one thing a session needs — the state of the work — was never put somewhere a session can read.
Keep the state in the project, in three plain files
The Playground can install a small system into your app that does exactly that. It writes the state of the work into the repository, in files any Claude Code session reads before it does anything else:
docs/ROADMAP.md
What is left
One file of outstanding work only. Each item carries a status you can skim — done, partly done, open, blocked on you, or a decision waiting on your yes. Finished work leaves this file, so it stays short enough that a session actually reads all of it.
docs/roadmap-archive.jsonl
What was proved
An append-only history — added to, never rewritten. Every finished item and every passing test run is recorded here, so “we already did that” is a thing a session can check instead of a thing you have to remember.
CLAUDE.md
The rules, read first
The protocol a fresh session loads before it starts: where the roadmap lives, what the statuses mean, and the house rule that a task is only marked done once a test has actually run and passed.
How a fresh session picks up where the last one stopped
Once the system is in place, a new session does not need briefing. It reads the rules, reads the roadmap, and continues:
- You add an app in the Playground and tick “How the work gets managed”. The system is written into your project — you do not set anything up by hand.
- A session opens and reads CLAUDE.md first, so it knows the roadmap exists and what the rules are before it touches a line.
- It reads the roadmap and takes the next open item — not a finished one, because finished work is in the archive and off the list.
- When the work is done and a test has passed, that result is recorded and the item comes off the roadmap. The next session starts from the new, shorter list.
Why several agents at once don’t collide
The reason a plan-in-a-file survives more than one worker is a single rule: no agent edits the roadmap directly. Each one does its piece and hands back a result. One step at the end applies all of those results to the list.
That is what turns “run a few agents in parallel” from a merge conflict waiting to happen into something safe. Nobody is writing to the same file at the same time, because only one writer ever touches it — after everyone else has finished and reported in.
Done means a test ran, not that the code looked right
The most expensive lie in a shared plan is a task marked finished that was never actually checked — the next session trusts it, builds on it, and inherits the bug. So the system draws a hard line: an item is only marked done when a test has run and passed, and a separate check confirms it rather than the same agent that wrote the code signing off on its own work.
It is deliberately strict about this. The safe setting ships with that independent verifier turned on, because the alternative — recording “done” on trust — is how false history gets written into a file every future session believes.
What you need — said plainly
Two honest requirements, both shown before you switch anything on:
- Claude Code and python3. The roadmap engine is a small Python program. Everything else the Playground builds runs without it, so this is the one option that can install and still not start — which is why the wizard tells you before you tick the box, not after.
- Running it overnight is a separate, opt-in layer. Unattended runs are gated on a safety add-on that refuses to start on a failing test, works only the open items, never touches anything that is yours to decide, and hands back anything whose correctness is in doubt.
This is part of what makes the Playground work rather than a bolt-on: the plan for your app lives with your app, so the work gets finished instead of restarted. See where it sits in the rollout.