The Vibe-Coding Blast-Radius Rule
Vibe-code freely when only you get hurt by bugs; stop and take responsibility the moment others could.
- Difficulty
- Easy
- Time to result
- ~days to results
- Steps
- 4
- Confidence
- 90%
A decision rule for when it is responsible to vibe-code — building software without looking at, understanding, or caring about the code. The line is drawn by blast radius: if you are the only person harmed by bugs, go wild; the moment other people rely on the code and your bugs could harm them, you must step back and apply professional practice. Judging where that line sits is itself an expert-level skill.
Origin
Simon Willison's framing, building on Andrej Karpathy's original definition of vibe coding (going purely on the vibes, not looking at the code). Willison notes Karpathy positioned it for fun and prototyping before it exploded beyond that.
Core principles
- 01Vibe coding = you don't look at the code, don't care about it, and maybe don't understand it
- 02Democratizing automation of tedious tasks for non-programmers is genuinely wonderful
- 03There is a limit on how much you can vibe-code responsibly
- 04Knowing what's responsible is itself an expert-level skill — e.g. knowing that scraping can damage others' sites
- 05Calling professional, reviewed, production-ready AI work 'vibe coding' devalues the term
How to run it
- 1
Ask who gets hurt if it has bugs
Before shipping, identify who is exposed to failures. If the only person harmed is you, you are in safe territory.
- 2
Vibe-code freely for self-only tools
When only you bear the risk, go wild — build little apps and automations without reviewing the code. This is the liberating, democratizing use.
Pro tip Bring a knocked-up prototype to a meeting to illustrate an idea — those throwaway artifacts are genuinely valuable.
- 3
Stop and switch to professional practice when others are exposed
The moment the code is for other people to use and your bugs could harm them, step back — this is no longer a responsible way to use the tools without review.
Watch out Security-adjacent work (e.g. access management) is emphatically not something to vibe-code by most people's understanding.
- 4
Name the professional mode differently
Reserve 'vibe coding' for un-reviewed prototypes; call reviewed, production-ready agent work 'agentic engineering' so the vocabulary stays useful.
In the wild
Willison notes that once you start doing things like scraping people's websites, you might damage their sites by hitting them too hard. Recognizing that risk requires expertise a non-programmer vibe-coder won't have.
→ Illustrates that crossing from self-harm to others-harm can happen invisibly, which is why the responsibility line demands judgment.
Common mistakes
Vibe-coding software others depend on
Shipping un-reviewed, not-understood code that other people use can harm them; that is where you must step back and apply professional review.
Calling all AI-assisted coding 'vibe coding'
If the term means everything that touches AI, it collapses into just meaning 'programming' and loses its useful signal that something is an un-reviewed prototype.
Is it for you?
Best for
Anyone using AI to build software, deciding how much rigor a given project warrants
Not ideal for
Contexts where you cannot honestly assess the blast radius, or security-critical systems that always need review
From the transcript
“if you're vibe coding something for yourself where the only person who gets hurt if it has bugs is you,”
“The moment you're you're vibe coding code for other people to use, where your bugs might actually harm somebody else, that's when you need to…”
“understanding what's responsible and what isn't is in itself a sort of expert-level skill.”
From the episode
An AI state of the union: We’ve passed the inflection point, dark factories are coming, and automation timelines
Simon Willison