Vibe coding 1016 min read

I’ve recently noticed that many vibe coders just hit a wall at one point or another, usually quite deep into their app. This is super frustrating, it feels like you’re so close to finishing your page or app and instead of moving forward, you keep getting errors, problems or it just simply doesn’t do what you want and starts to ignore you…This is usually after quite a lot of prompting, so you have a lot invested already, but you’re stuck in this rabbit hole of errors or just can’t move forward. That’s not the only problem I’ve seen after doing a few sessions with real users. I noted that some simple techniques that were obvious to me were less obvious to others, so let’s dive right in:

(Originally posted on Linkedin)

1. Start with “something” other than a prompt

Most people just start prompting right away, but hold your horses – letting Claude (that’s what’s under the hood for most of the current Vibing platforms) do the UX for you is not always a good idea. If you start with a theme, a color scheme, a brand image, a project (you can get rid of the stuff you don’t care about later) or a template, will start you off much better than just prompting.

2. Pick the technology yourself

If you don’t specify anything, the vibe coding platforms like Bolt/Lovable/V0/Replit will pick their own technology. If you don’t care, they might utilize a framework you’ll be stuck with later on. React+Typescript using ShadCN+Tailwind ensures that you can take your project elsewhere and, it turns out, that LLMs particularly love this combo. This is why we picked it as the default for our Anima AI vibe coding platform.

3. Keep saving and undoing

Each time you get to a point in the vibe coding flow that the LLM got things right, save it. This is super useful if things go wrong. What I noticed many people doing, is trying to move forward or ask the LLM to correct mistakes – leading them to be stuck in a labyrinth (in coder speak – stuck a rabbit hole).

Don’t keep hitting your head running into that wall – if you save often, if something goes wrong just go back to the last working version and try it again. Even if you use the same exact prompt, it will often yield different results as the LLMs have a degree of randomness to them.

If you hit a major milestone, save a copy elsewhere – most vibe coding platforms let you fork or save a copy, so that you can roll back to this version if something goes wrong (and it very likely will, LLMs are unruly that way).

If you find yourself repeated prompting “make it work”, “fix it”, or “that’s not what I meant” – you’re doing it wrong, roll back and try it again instead.

Some vibe coding platforms offer revisions or git-like revision management. This is a bit more sophisticated, so might be complex to users unfamiliar with git, but can be super helpful.

4. Large comprehensive prompt vs. smaller step-by-step prompting

Your focus should be on a single task. Don’t overcomplicate the LLM with multiple requests all at once. Give it one focused task but be as descriptive as you can. if you prompt “make it responsive” or “make it work”, most likely the LLM will interpret it wrong. Be specific, elaborate, but stick to a single piece of functionality.

Don’t try to put an entire PRD for your project or idea in one huge prompt, unless it’s your initial prompt…

So, detailed prompts, but focused on a single, specific task or objective.

5. Use selectors and “change nothing else”

Most vibe coding platforms support selectors, so you can refer to a particular element on a particular screen. Use these when you want to change or refer to an object instead of referring to “the continue button”. When you do, be very specific about what you want to do to that component – don’t write “make it larger” but instead “make it 42px high”.

Oh, and add “change nothing else!” at the end:

Make this 42px high. Change nothing else!

Yes, it is dumb, but this does work… the LLMs are sensitive to this type of thing. If you REALLY want to make it not change anything else, you can yell at the LLM by writing it in all caps:

Make this 42px high. CHANGE NOTHING ELSE!!!

Selectors are useful for navigation as well, you can select a particular component and ask it to navigate to XXX, which will add routing and multiple pages to your landing page or app.

6. All about context – vibing growing dumber

With vibe coding, context is king. Most Vibe coding platforms put all the files in the project in context. You can add a text file with constant instructions to the LLM and call it “special-instructions.rm”, that way, the LLM sees it, but it is not part of the actual project. For example, if you have a PRD or description document of the entire project, just keep it there and the platform will remember your objectives.

There’s a downside to all this context. As your project grows larger and you have more and more prompts and responses, the LLM will slowly grow dumber. Take Anthropic Sonnet 3.7, it has roughly 200K token input limit and that means that above 100K tokens (400KB), is where its intelligence starts deteriorating… Gemini Flash 2.5 has 1M input tokens, that’s more than enough for small or medium size projects, but that means that these platforms do have a clear upper limit. Cursor/Windsurf/Cline/Copilot use more sophisticated (but expensive in time and cost) techniques to bypass these context limits, by letting the LLM “collect” its own context using search and file information, but vibe coding platforms so far are avoiding this.

What can you do?  Some platforms let you “squash” or “clear the chat”, which can dramatically reduce the context size, making the LLM smarter. If you feel the platform growing dumber as the number of prompts grows longer, try to use this functionality.

7. A few safety tips

If you’re not a coder by profession, be careful about interfacing with outside services. Using APIs (payments, LLM usages) typically require API keys or credentials. If the vibe coding platform does not have this integrated directly (Supabase was designed for this, so it’s safe), make sure that your API keys are not visible to end users that may use your product. For example, use Stripe only if your vibing platform supports it…

We’ve already seen quite a few products that were launched and API keys and credentials harvested and utilized elsewhere, so be careful with that. API keys and credentials must be stored securely and only used through backend services and not front end.

That’s it for now, hope this is useful to you. If so, share it and let me know you like it.