Vibe Coding With a Backlog: Structure Without Slowing Down

Vibe coding is writing software by telling an AI what you want in plain language, running what it produces, and asking for changes until it works, without writing or closely reading the code yourself. To do it well you keep the loop and add three things: small tasks, one change at a time; a quick review and a saved checkpoint after each working step; and a backlog where everything you notice but do not do right now is written down. That structure costs a few seconds per step and saves the afternoon you would otherwise lose untangling a project that grew past what anyone understands.

Where the term comes from

The AI researcher Andrej Karpathy named it in a post on X in February 2025. He described “a new kind of coding I call vibe coding, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists”. He accepted every change without reading the diffs, pasted error messages back in with no comment, and said it was “not too bad for throwaway weekend projects”.

The phrase spread well beyond programmers. Collins named vibe coding its Word of the Year for 2025↗ (opens in a new tab), defining it as “the use of artificial intelligence prompted by natural language to write computer code”. Notice the drift: Karpathy meant a particular carefree style, and the dictionary meaning covers almost any coding done by prompting.

Two meanings, and why the difference matters

Google Cloud’s explainer on what vibe coding is↗ (opens in a new tab) separates the two. “Pure” vibe coding is the original: you trust the output, forget the code exists, and use it for rapid ideation or throwaway projects. Responsible AI-assisted development uses the same conversation but you review, test and understand what the AI generates, and take ownership of the result.

Both are legitimate. The mistake is doing the first and believing you did the second: building something in pure vibe mode, then deploying it, sharing it with customers or handing it to a colleague as if someone had checked it. Decide at the start which one you are doing, and if the answer changes halfway through, change how you work from that point on.

The basic loop

1. Describe the goal in plain words: “A page with a form that takes a name and an email and lists everyone who signed up.”
2. Let the AI generate the code.
3. Run it and look at the result.
4. Say what is wrong or missing: “The list should show the newest first, and reject an email without an @.”
5. Repeat until it does what you wanted.

Any AI coding tool with a chat will do this: an editor assistant, a terminal agent, or a browser-based app builder. The loop is fast because you never stop to write code. It fails for the same reason: nothing in it asks you to stop and check.

Why pure vibe coding breaks on anything that lasts

• The code outgrows you. Karpathy said as much: the code grew beyond his usual comprehension. That is fine for a weekend; it is a problem the first time something breaks and the AI cannot fix it.
• Fixes pile on fixes. When the AI cannot find a bug, it tries something else, and the failed attempts often stay in the code.
• It invents things. An AI can suggest libraries that do not exist or code that is insecure. The OWASP entry on misinformation and overreliance↗ (opens in a new tab) describes attackers publishing malicious packages under names AIs commonly hallucinate.
• The ideas get lost. Halfway through a session you notice five other things to change. In pure vibe mode you either chase them all at once, which is how a project turns to mush, or forget them.

How to vibe code without losing control

None of this slows the loop down much. It adds a few seconds between turns.

1. One change per prompt. “Add sign-up, a dashboard and email reminders” produces three features’ worth of guesses at once. “Add the sign-up form” produces one thing you can look at.
2. Run it after every change. Not after five. When something breaks, you know which prompt broke it.
3. Save a checkpoint when it works. Use git, or your tool’s checkpoints: commit after each working step, so going back costs one command instead of an argument with the AI about what it changed.
4. Glance at the diff. You do not have to understand every line; you do need to notice that a one-line request changed eleven files. Reading the output of git diff↗ (opens in a new tab) takes seconds.
5. Check anything the AI says it did. “I have added validation” is a claim. Type a bad email in and see.
6. Write down what you notice and move on. This is the backlog, and it is the step people skip.

git add -A
git commit -m "Sign-up form rejects emails without an @"

The backlog is what keeps it fast

A backlog sounds like the opposite of vibe coding, but it is what lets you keep the loop tight. When you notice that the header is misaligned while fixing the form, you have three options: fix it now and lose the thread, ignore it and lose the idea, or write one line and carry on. The third is the only one that keeps both the pace and the idea.

The backlog also stops scope from creeping. At the end of a session, you pick the next thing from the list deliberately, instead of the AI or your last thought picking it for you. And it gives each prompt a natural size: one item on the list, one prompt.

It can be a text file to begin with. Once more than one person, or more than one AI assistant, is working on the project, it needs to be somewhere they can all see. On a fenbs board the flow is four lanes: To Do for ideas you wrote down, Next Up for what you will do next, In Progress for what is being worked on now, Completed for what is done. Each task has a kind, feature, enhancement or bug, which is usually obvious from the one line you wrote while vibe coding.

If your AI tool connects to the board over MCP, it can keep the list for you: file what it notices with fenbs_create_item, write how it intends to do a task in the task’s plan before it starts, and when it finishes, set the testing status, from Tested to Needs owner check, so you can see what it actually verified. Choices you want to stick, such as the database you picked, go on the board’s Decisions page, so the next session does not quietly undo them.

When pure vibe coding is fine

• A throwaway prototype to test an idea, which you will delete afterwards.
• A personal tool that only you run, on data that is not sensitive.
• Learning: seeing how something could be built, then building it properly.

Anything that holds other people’s data, takes payments, or will be maintained by someone else needs the structure above, and a person who has read the code before it goes live.