Vibe coding works. You describe a feature to Claude Code, Cursor or Lovable and it exists by lunch. The failure is not in the code. It is that you shipped the wrong feature, told nobody, and never checked whether it mattered. This guide gives you the loop that goes around the agent and a weekly rhythm to run it. It also covers what to keep outside the chat, and how a map of your product stops the agent re-breaking what it built last week.
The failure pattern
It goes like this. You have an idea on Monday. You describe it to the agent. By Tuesday it is live. You post about it. Nothing happens. You check analytics on Friday: a handful of visits, no sign-ups that stuck. You conclude the feature needed one more thing, describe that to the agent, and ship it Saturday. Still nothing.
Founders describe the result the same way: "I built it. Why isn't anyone using it?" Or shorter: "shipping to the sound of crickets."
The cause is upstream of the code. Building used to be expensive enough that it forced a question: are we sure anyone wants this? The agent removed the expense and, with it, the question. Now a founder can build the wrong thing faster than they could ever have discovered it was wrong.
Three things usually went missing:
- Nobody asked. The feature came from your head, a competitor's page, or one loud message. Not from a pattern in what your users said.
- Nobody was told. The two people who did ask for something like it never heard it shipped.
- Nobody checked. You never wrote down what you expected to change, so you cannot tell whether it did.
And a fourth, specific to agents: the agent "forgets your database schema" between sessions and "re-breaks what it fixed". Each new feature costs you two old ones.
The loop: learn, decide, build, launch, check
The fix is a loop around the agent. Five steps. The agent lives in the third one.
Learn
Collect what users actually said, in their words, with the source and date. Support emails, reviews, call transcripts, form answers. Sort it into problems, and rank the problems by how many of your own users have them. Public threads and competitor reviews are context, not votes.
Decide, with the why
Pick the problem, write the belief it rests on, and write what you expect to change: "median days-to-paid goes down". Decide what is out of scope and write that down too. A decision with a reason survives the next loud request.
Build, with the why attached
Hand the agent a spec that carries who it is for, why, the metric, the must-haves with acceptance criteria, what is out of scope, what is already broken, and what already exists. Then let it build. The spec-driven development guide covers the document.
Launch, to the people who asked
Before the post, write to each person who asked for this, in their own words: "you said X in March; it's live." You send it. Then post. Interest from strangers is not intent; a reply from someone who asked is.
Check
On the date you set, compare the prediction with what happened, from the source you chose. Mark it worked, didn't, mixed or too early. Write one line about what you learned. That line is the start of the next Learn.
The loop is slower than vibe coding alone by about a day per feature. It is faster than vibe coding alone by every feature you did not build.
A weekly rhythm
The loop fits in a week if you protect a few hours. Here is one shape; move the days to suit you.
| Day | What you do | Time |
|---|---|---|
| Monday | Read the week's feedback and file it. Look at the ranked problems. Pick one thing to build this week, and write the belief and the prediction before you touch the agent. | 1 hour |
| Tuesday | Write the spec from the evidence. Hand it to the agent. Let it plan, read the plan, let it build. | 2 hours plus the agent's time |
| Wednesday | Test what shipped against the acceptance criteria. Ask the agent to report what it changed. Update the map. Check what is now public before you publish. | 1 hour |
| Thursday | Tell the people who asked, one by one, in their words. Then post. Hold one customer call with a script you checked in advance. | 1 hour plus the call |
| Friday | Review the week: what moved, which predictions came due, what you decided. Log the decisions. Write the update you send to whoever follows your progress. | 30 minutes |
Two features a week on this rhythm is plenty for a solo founder. If the agent could build five, the constraint was never the agent.
Notice how little of the week is building. That is the point. The agent made building cheap; the rest of the week is what it cannot do for you.
What to keep outside the agent
A chat session is a copy. Close it and the context is gone; open a new one and the agent starts from zero. Four records belong outside the agent, in one place you can hand back to it.
- What users said. Every piece, in their words, with its source and date. Not your summary. The quote "I chase every invoice by hand" survives a year; "users want payment stuff" does not.
- What you decided and why. Each call with its reason and the evidence as it stood. When the loud request comes back in six weeks, you can see what you knew when you said no.
- What you predicted. The metric, the number, the date, written before the build. An outcome you did not predict cannot be checked.
- What the product is. A map: what it does by area, what is live, in progress or only scoped, and how it is built. This is the one record your agent can write for you, because it already reads your code.
Everything else can live in the chat. These four cannot.
How a product map stops the re-breaking
The agent re-breaks things because it does not know they exist. It rediscovers your codebase every session, guesses at conventions, and fixes the Safari bug a second time in a slightly different way. A product map is the cure.
A map has two layers. What the product does: each area, each capability, and whether it is live, partly live, in progress, scoped or still an idea. How it is built: the parts, the conventions, what never to do. Your coding agent writes both, from the code it already has, and you approve a preview before anything is saved. After each build, it reports what it changed, and the map stays current.
With a map, every spec can carry three short sections: what already exists in this area, where the work fits, and what it touches. The agent reads "this extends the invoice page; it touches the payments service and the email templates; never compute amounts in the browser" and starts without asking. It also stops rebuilding the invoice page.
The map helps you as much as the agent. A non-technical founder can finally see what is built, what is half built and where users are hurting, in plain words rather than in code. That is the view you need on Monday when you pick what to build.
A map is written by your agent, not by a tool reading your repository. Keep it that way. The agent has the code; the tool that keeps the map should never need it.
Related guides: The evidence ladder · Customer interview questions · The Build Pack format
Do this in MindBacklog
The loop, with the agent in the middle. Drop anything: a thread, a transcript, a CSV. Mind shows where it'll go before filing it. Every piece of feedback, sorted into problems ranked by who has them, with the quotes behind each. Under 30 pieces of feedback, Mind says "Not ranked" and why, instead of inventing a ranking.
Your coding agent pulls the Build Pack: why it matters, who it's for, the metric, and the must-haves with acceptance criteria. Ask your coding agent to map your product for MindBacklog. Every Build Pack then says what already exists, where the work fits and what it touches. Your coding agent writes the product map. MindBacklog never reads your code. See your whole product: what it does by area, what's live, in progress or just scoped, and where users are hurting, in plain words.
When it ships, tell the people who asked: Mind drafts a note to each, with their own words. You send it. Did it work? MindBacklog checks your prediction against what happened, from the source you chose. You decide.
The Build Pack · The product map · Problems ranked by your users · Launch and Results
