13 prompting techniques for better vibe coding.

small changes that yield massive performance improvements 🧵👇

1. if you're using anthropic models, you can use hard-coded "magic words" in your prompt to increase the token budget.

> think
> think hard
> think harder
> ultrathink

2. when role assigning, spell out responsibilities, tasks, and expected output.

don’t rely on titles the way most do with writing tasks.

ex:

❌ “you are a senior UI engineer that builds world-class, award-winning front-ends.”

✅ “you are a UI engineer responsible for designing, building and organizing reusable UI components. your job is to document all user stories and only build or refactor components to satisfy the user stories.”

3. add context dumps and information about the situation to the beginning of a prompt, and the task request at the end.

research shows LLMs attend most to tokens near the start (and end) of long prompts.

add details about the app, the end‑user, the problem your product is solving, your lack of technical skills, etc.

the model provider is more likely to “save” this information and reference it in follow‑up requests, and the agent is more likely to stick to the directive.

4. not every directive needs a thorough prompt.

when you get stuck (or lazy), sometimes “make it better” yields unexpected wins over a 1 000‑word context dump.

when in doubt, use the socratic method with reasoning models—start with a question (i.e. "how would you approach this?", "what do you think?").

or ask it to ask you questions (i.e. "what do you need from me to feel 100% confident you can build this?").

research shows iterative Q‑and‑A elicits more precise output and reduces hallucinations.

5. if you're cost-sensitive, you can turn a cheaper non-reasoning model (i.e. gpt 4o, sonnet 3.5) into a reasoning model by ending your prompt with "think step by step..."

6.  when something goes wrong, revert your changes and update the original prompt with additional context addressing the issue you observed.

it’s always cheaper (time and money) to restart than brute force prompting.

but if you insist on trying to fix an error, always ask it to determine the underlying root cause:

"trace the full user flow and identify where the issue originates. think deeply about the **root cause** and treat the symptom as a clue, not the target."

7. fill the gaps by asking the model to reflect on its work. after a task is completed, ask it to criticize itself.

here's a great prompt i stole from @shawmakesmagic:

"Please write a SCATHING review of my codebase -- everything that's wrong with it, in what ways it is badly implemented, larp code, stubs, demo and not production ready, etc. Catalog every weakness and explain why it's bad. Then write a detailed technical implementation plan on how to fix it."

and then ask it to implement its solution.

it's best to do this no more than once or twice before it starts inventing critiques.

8. know every model's strengths.

here's where i've personally found the most success:

> o3 = planning, task breakdowns and debugging
> sonnet 4 = specific, precise execution tasks
> gemini 2.5 pro = when you have wireframes or mockups, also for specific execution tasks
> opus 4 = large tasks or refactors

don't be afraid to switch models or ask different models attempt the same task.

9. know every platform's strengths.

every vibe coding platform has a highly researched, battle-tested system prompt that shapes the models behavior more than your own prompts.

here's where i've personally found the most success:

> lovable/v0 = reliable, consistent front-ends
> replit = python apps and backends fast (also the best vibe coding mobile app)
> cursor/windsurf = good for everything, but best for using MCPs and tool calling
> claude code = when i'm starting with or refactoring an existing codebase

you can also push a project to github and switch from one platform to another depending on what your current task is (i.e. create a working prototype in lovable and refine the back-end in claude code).

10. before asking the model to do anything, present your task and ask it to decompose it.

if you ask for a task outright, it's more likely to start working and lose track of the directive. instead, try this:

"before starting this task, break it down into it's smallest components and list out the sub-tasks."

the list it outputs will give it a to-do list that it can refer back to as it progresses and lowers the cost.

11. if you know what you want, you're guaranteed a performance lift by giving it examples or code snippets (or asking it to find examples before starting).

research shows examples boost performance more than fine-tuning.

whether its API documentation, component functionality, code structure and style, response formats, etc.

one example is good. many examples is better.

12. when giving context, references or examples, you should speak the language of LLMs.

most coding models are most comfortable using the formats they're trained on.

you can boost the model's understanding by providing documentation in markdown and presenting codebases in xml.

use tools like gitingest to convert github repositories into markdown or repomix to convert to xml. always look for llms.txt from api providers.

13. give the same prompt to every model to find the "majority vote" for a solution.

once you have multiple code outputs from each model, find where the most overlap is and commit to that direction.

this could be reviewing file diffs, a visual vibe check for UI output, asking different reasoning models how they would fix a bug, etc.

TL;DR:

1. “think" to boost Claude's token budget
2. avoid “you are a X”
3. context at beginning, request at end
4. iterative Q&A
5. "think step by step" for cheaper models
6. revert changes, update prompt
7. ask model to self-critique
8. match tasks to model strengths
9. match tasks to platform strengths
10. break tasks into sub-tasks
11. provide examples
12. use markdown/XML for context
13. compare outputs from multiple mode

*if you can’t evaluate the code it writes yourself

I see engineers write the worst prompts and then they just edit the crappy code themselves