Whilst preparing a demo and short talk for my game Music Melee, I compiled some thoughts on vibecoding.
- “Vibe coding is not the same thing as writing code with the help of LLMs!” – Simon Willison
- Vibecoding is “where you fully give in to the vibes, embrace exponentials, and forget that the code even exists”. Where you ‘Accept All’ always, don’t read the diffs anymore, and copy-paste error messages with no comment. – Andrej Karpathy on X
- Vibecoding is for low-stakes, high-speed exploration.
- It’s experimenting with dark magicks, where you sometimes invent powerful new spells and sometimes set your hat on fire. It is not recommended for use in battle.
- Good vibecoding tools support tighter feedback loops by reducing friction.
- Semi-agentic > accept diffs > copy-paste from GUI.
- Slow and deep thinking for planning the architecture, rapid fixes for quick modification.
- Good vibecoding projects enhance the feedback loop.
- Vibecoding a single-player FPS game is great. You can test feature
n
while the LLM works on featuren+1
. You can immediately see if things are working as you expect. The best tests are direct experience. - Vibecoding infrastructure for cloud DB migration is not great. Your feedback loops are bad and your verifiability is almost non-existent. (Also you will be fired)
- Vibecoding a single-player FPS game is great. You can test feature
- Understanding what’s in the code is much less important than understanding what’s in the context.
- Beg for forgiveness (
git reset --hard HEAD~1
) rather than asking for permission. - Vibecoding is nirvana, vibe-debugging is hell.
Behind the Scenes video for Music Melee. Watch at this URL: https://youtu.be/znz3BeIdFlE
Thanks for checking this out! If you’re interested in my writing, projects, or working with me then please do reach out on X, Bluesky, or by email.
If you think other people might enjoy reading this or any of my other posts, shares are always appreciated.