Improve v0 quality with strategic forking

When you submit a message in the chat, v0 sends all of these

  • Your message and any attachments
  • Any project sources relevant to your message
  • Your entire chat history

It also includes all of the files in your codebase, in this order

  • Filenames relevant to your current message
  • Files changed by previous messages, sorted from most recent to last
  • All remaining files

The problem is that AI models have context limits, so sometimes this is too much information for v0 to use, and it needs to eliminate some.

The v0 large model has about 4x the context window compared to the small or medium models. When the context window is full, the data sent to v0 is truncated from the end, excluding the least relevant files.

From this, we can infer several best practices

Use a new fork for every task

If you’re familiar with Cursor or ChatGPT, consider the Fork button to be like “New Chat”

After completing each task, click fork to create a new chat with a clear message history and your most up-to-date code. I like to do this at the end (rather than the start) so the chat at the top of “Recents” is always clean and ready to code.

While v0 filters to the most relevant files, it always includes the most recent messages, so this is the fastest way to ensure your message history doesn’t include anything that may distract the model.

I create forks

  • every time I deploy
  • after finishing a feature
  • after solving any bug that took more than a few messages
  • when sharing my chats
  • to keep my version numbers as low as possible, usually no more than v20

Ask questions to fill it with relevant context

Get v0 to go into detail in the area you’re about to work before making your request

This is especially important in completely fresh chats, as there’s no message history to guide it.

To improve how it implements a feature, get it to dive into an existing similar feature

  1. Explain how the users chart works, including how we display it and where we get its data from
  2. Add a new chart showing posts created over time, following the same patterns as the users chart

To select which parts of the app should be modified, get it to list them first

  1. List the typography components available in the text editor
  2. Add font weight controls to all except for the paragraph text component

If v0 makes a big error, fork the chat

Scroll up in the chat to the last good version, click “View” to make it appear in the preview, and then hit Fork to create a new chat with a fresh message history

Sometimes when you make a request, instead of editing the file v0 will entirely rewrite it. This usually happens when the context window did not have enough room for the file you wanted to edit, so the model thinks it needs to make a new one

A long conversation can bury the original file, and if the filename isn’t descriptive enough to be marked as relevant (which especially happens with big generic files) then it won’t be at the top of the context window

Once this happens, attempting to re-roll the generation or to roll back and try again usually doesn’t work for two reasons

  • Whether v0 can detect a relevant file is fairly deterministic, so if it’s not included in recent context once, trying again is unlikely to fix that
  • Rolling back (which creates a new version with the old file contents) adds an additional message to the chat but doesn’t change the original circumstances

Worse yet, if you don’t roll back and simply ask it again and again, you are now moving forward with the overwritten version of the file

  • v0 no longer sees the original and can only hallucinate the original contents based on message history
  • you are now filling up the message history with debugging knowledge, which will push more files from from your app off the back end of the context window

So any time v0 makes a big error that suggests it no longer properly understands your codebase, it’s time to fork. If you get this with a fresh fork, you’ll need to improve your prompt to specifically mention the files you intend to work on.

Use small files with descriptive filenames

In order for v0 to properly edit a file, it MUST include it in the initial context, otherwise it will attempt to rewrite it. Your files should be structured so it can easily tell at a glance whether something is relevant.

Small files with descriptive filenames will be selected much more accurately

Big files that do many things are less likely to be selected, and when they are it will be the entire file which consumes a large chunk of the context window.

On the other hand, if a lot of your development happens in that file, it will often be one of the most recently edited files and included for that reason, so problems with big files usually happen when you have been working on different files for a while. In that case, mentioning the file by name is a good way to remind v0 where to look.

You can also consider breaking it down into smaller pieces. Sometimes you can just ask v0 to do this, but it’s a difficult high context task for AI models to do without errors. Targeted requests like “move the theme code to its own file” or “extract the fetching into a custom hook” will have better results

Do not abuse the robot

LLMs respond very differently depending on the emotional tone of the language you use. If you berate or act angrily toward v0, it will consume thinking tokens on thoughts like “the user is frustrated because…” and it will fill the message history apologizing.

If you do this multiple times it may even start suggesting what “should” have happened, which makes its context further diverge from the actual state of the application and make errors more likely in the future.

Remember that AI models are tools and there are ways to use them that give good results and ways to use them that give bad results.

3 Likes

you can also work on multiple features at the same time in different windows as long as you’re not changing the same files.

no more sitting around doing nothing waiting for the response to come back.

Hey, great advice! Actually both advises. I wanted to clarify something: If features are being refined in separate forks, how do you merge them afterward? Do you merge them manually via GitHub, or is there a more interesting and elegant way to do it? Thanks!

You can merge manually in Github, but if your v0 chat is synced to a branch, it will give you an option in the top right to create a PR directly from v0

Then after merging, your “main” chat should sync and update, and you can fork that into a new branch for the next feature

2 Likes

So the full cycle can be:

  1. Fork the main chat into two new GitHub branches: feature1 and feature2.
  2. Develop feature1.
  3. Develop feature2.
  4. Open PR for both feature1 and feature2 into main.
  5. Repeat.

What would you say about my next idea of working in a 2-phase cycle?
Phase 1: Drafting a PRD describing, say, 3 new components with 10 features in total. You can do the prompt-writing work in a suitable markdown editor (Cursor, Obsidian). As an output, you get 3 well-structured markdown files.
Phase 2: Processing these files with v0 — 3 chats in parallel, one chat per component (3–4 features each). It helps avoid both downtime and overlapping code changes. When the work is done, you enrich your PRD with any details that were understood in Phase 2. Finally, you upload them as source files to Project Knowledge.

It looks like Phase 1 is real vibe coding, and Phase 2 is more about testing and bug fixing (pain coding). Thanks to v0 for helping make this phase less painful and faster.