Vibe Coding Is a Spike, Not a User Story
The vibe coding argument has been running for over a year and has settled nothing, because it's a boundary dispute being fought as an identity war.
One side hears "AI writes my app" and sees the end of engineering. The other side hears "real developers don't vibe code" and sees gatekeeping. Neither side is arguing about the actual question, which is smaller and much more useful: what is this code for, and who wakes up if it breaks?
The survey data says most developers already drew the line quietly. In the 2025 Stack Overflow survey of roughly 49,000 developers, 84% use or plan to use AI tools, and 72% say vibe coding is not part of their professional work. Same people, both answers honest. They use AI constantly, and they don't ship unbounded prompts. Which means the interesting thing was never whether to vibe code. It's where.
Agile answered this decades ago, and the answer is worth stealing back.
The Spike Already Solved This
If you worked through the XP era, you know the spike. A spike is a timeboxed exploration you build to learn something, with every intention of throwing it away. The output of a spike is knowledge, not software. Nobody reviews a spike for maintainability. Nobody pages anyone when a spike falls over, because a spike falling over is the spike doing its job.
Vibe coding is a spike with a much faster engine. That is not an insult. Spikes are a legitimate, disciplined engineering practice and always have been. The discipline was never in the code quality. It's in the label.
The problem is that most teams have no word for "throwaway" that survives contact with a deadline.
Four Quadrants, One Test 🗺️
Two variables decide whether vibe coding is a spike or a liability: how long the code lives, and who feels it when it breaks.
blast radius: none blast radius: real
lifespan: days vibe freely guard the data, not the code
lifespan: years harden before it matters this is engineering, act like it
Top left: prototypes, demos, weekend experiments. Vibe away. This quadrant is what the tooling was built for.
Top right: throwaway code that touches real things. A demo pulling production data, a PoC that emails real customers. The code can still be garbage. The data and the blast radius cannot. You guard what's real and let the code rot.
Bottom left: internal tools, personal scripts, dashboards for your own team. This is the dangerous quadrant, because "internal" is where standards go to die and everything drifts toward permanent. Vibe the v1 if you want, but schedule the hardening before the tool gets fans.
Bottom right: anything with a pager attached. Production paths, money, auth, user data. Generated code can absolutely live here, but it arrives with gates, tests, and review. Not because AI code is bad. Because this quadrant was never about trusting the author, human or machine.
Then there's the shortcut that replaces the whole matrix: if this breaks at 2 AM, who gets called?
💡 Pro-tip: the fastest architecture review of your life is asking who gets paged. The org chart does the rest.
If the answer is "nobody, we delete it," you're holding a spike. Enjoy it. If the answer is a name, you're holding a user story, and user stories have a definition of done whether a model wrote them or not.
The Escape Hatch Problem
Every experienced developer knows the failure mode the chart can't fix: prototypes escape.
The temporary script from 2019 is still running the nightly report. The demo the sales team loved became the product. Nobody chose that. It happened because nothing in the toolchain marks the difference between a learning artifact and a load-bearing wall.
We already have a cultural template for things that expire: certificates. ⏰ So treat the prototype like one. When you ship a spike, it gets an expiry date, and when the date passes it stops working until someone consciously renews it. If that sounds heavy, notice what it replaces: the current system, which is pretending the prototype will be rewritten later, forever.
That part is opinion. The quadrant test isn't. The test is bookkeeping about who absorbs the risk, and the survey numbers say most of you already do that bookkeeping in your heads.
Where the Matrix Fails
Two things this framework won't do.
It won't stop a founder from shipping the vibe-coded MVP on Friday, and sometimes that's the right bet. The matrix doesn't tell you what to risk. It tells you what risk you're carrying, which is the minimum a team deserves to know.
And it won't fix the word. "Vibe coding" got coined as a joke, got weaponized as an insult, and now carries baggage neither side can put down. The useful move is boring: retire the argument, keep the practice, label the artifact.
So, which quadrant did you learn the hard way? And be honest: what's the oldest "temporary" script still running in your company?
References
- Stack Overflow 2025 Developer Survey, AI section (49,000+ respondents; 84% use or plan to use AI tools, 72% say vibe coding is not part of their professional work): survey.stackoverflow.co/2025/ai
Top comments (2)
The internal tools part is so real. Nobody worries about them because it’s just for the team, and then a year later half the company depends on it and nobody remembers how it works.
The expiry idea needs a transition rule once a supposedly disposable tool has users. If the old nightly report silently became load-bearing, switching it off on the expiry date discovers that dependency through an outage. I'd have expiry block new integrations or write privileges first, notify a named owner, and require a decision to retire or harden it. The useful acceptance test is whether an expired spike can acquire a new real dependency without anyone acknowledging the change.