What the Living Plan Is For
There are two ways people build software with AI right now, and both of them assume you already know something you probably do not.
On one side is vibe coding. You describe the idea, you say “let’s build a thin slice,” and you prompt your way forward. It is genuinely great when the project has one job. It falls apart when the project has four pieces that all have to agree on the same data shape, because it optimizes for seeing where you end up rather than ending up in the right place. My first attempt at this project was pure vibe, and it veered off target around week two and produced a behemoth that did a third of what I wanted in a way that made the other two-thirds impossible.
On the other side is spec-driven development. You work out what you are building in advance, you write it down properly, and the agent builds to the spec. This is the right answer when you actually know. My second attempt used spec-kit, and I drowned in paperwork before any code ran, because I was writing specifications for decisions I had not made yet and could not make without building something first.
The gap between those is where most of my projects actually live. I only half-way know what I want it to do. Not nothing, which is why vibe coding wastes the part I do know. Not enough to specify, which is why the spec becomes fiction I have to maintain. The thing I am building is a prototype that I intend to turn into the real tool, and I will not find out whether the idea works until some of it exists.
The living plan is for that. You plan and you build in the same flow, and the planning doc stays alive the whole time instead of being a thing you wrote once at the start. It records what you have decided so far, the agent reads it and implements against it, and when building teaches you something the plan is wrong about, you change the plan. The doc is not a prediction of the project. It is the current state of the project’s thinking.
The trick is dumber than I want to admit, which is most of why it works.
What it costs is maintenance. A doc that stays alive gets fat, and a task file fills up with finished work, and neither of those announces itself. Most of this series is that: the problems that showed up once the method was actually running, and what I changed to fix them.
The skill is open source. The living-plan skill that owns both docs is in my agent-skills repo, along with the rest of them. Each one is standalone, so you can take just that folder and nothing else. It used to be called plan-rebalance, and one of the posts below is why it isn’t.
These are in reading order, oldest first, because they build on each other.
