↑ j4ck 🥶 icebreaker.xyz ↑
@j4ck.eth
2677 Following
71488 Followers
10 replies
18 recasts
97 reactions
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. 20 replies
20 recasts
108 reactions
0 reply
0 recast
0 reaction
4 replies
0 recast
39 reactions
1 reply
0 recast
0 reaction
20 replies
5 recasts
59 reactions
1 reply
3 recasts
9 reactions
2 replies
0 recast
16 reactions
1 reply
0 recast
1 reaction
0 reply
0 recast
1 reaction
0 reply
0 recast
1 reaction
0 reply
1 recast
1 reaction
Designer Of The Week - @jordanisgreen.eth
Each week, the Design Channel highlights one of the most influential designers in web3 and the Farcaster network. This week and also our first week, we’re enjoying the company of Jordanisgreen.eth.
Jordan is a graphic designer, creative director, and self-proclaimed professional lurker. Currently freelancing and working quietly with a few teams, Jordan stays curious and inspired. Most recently, Operating System has captured her love and attention. 💙
1. What’s your creative superpower?
My personal mantra has always been “creative, with the chance of what the fuck.” I naturally push myself to create something different and unexpected. I really don’t like when my work feels expected or obvious — I want things that feel like you never would have seen them coming, like a totally new approach for a given category. I love collaging ideas across industries, seeing what works in beauty or wellness and asking how that would work in tech or DeFi.
2. Tell us about a project you really enjoyed — what made it special?
Running Times Newᵀᴺ was really special because I got to develop new ways of working that moved away from the typical agency approach of “we (the agency) have all the taste and all the answers, you (the client) must listen and do what I say.” I created collaborative strategies that felt more fun and joyful, especially discovery “games” for founders and core teams. This was particularly important when working with technical founders who felt uncomfortable giving visual opinions or being creative in ways they weren’t used to. Using my studio to help other people get comfortable making visual decisions about their brand was my favorite part of that experience.
...
Read the full interview and more on @paragraph!
https://paragraph.com/@designchannel/designer-of-the-week-jordanisgreeneth 14 replies
19 recasts
62 reactions
0 reply
0 recast
1 reaction
1 reply
0 recast
1 reaction
1 reply
0 recast
0 reaction
1 reply
0 recast
1 reaction
7 replies
1 recast
29 reactions
1 reply
0 recast
4 reactions
0 reply
0 recast
3 reactions