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 (7)
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.
Yes, you have a great point - all vibe coded POC (proof of concepts) should have a TTL (time to live). I am saying a vibe coded item like all POCs should have a lifecycle which is time bound and data driven that decides - we kill it, pause, pivot or scale. Each of these have their own paths. A vibe coded item left on its own, is likely unused and costing resources OR it became famous and everyone started using it only to find, it has say poor quality or does not scale and then people abandon.
The lifecycle framing makes sense. One addition to the kill/pause/pivot/scale decision would be to name the people who can no longer complete their work if the tool disappears, even when the usage numbers are small. A weekly report used by one person can still be a critical dependency. For the kill or pause path, I'd make a working replacement or an agreed manual fallback part of the exit criteria. That catches dependence which popularity and infrastructure cost alone won't show.
I am glad the lifecycle framing worked. Usually, dependency wise, I tend to indicate business function, business unit and point of contact (usually business unit head) as contact to show dependency. In my experience when a business function takes a dependency on a software or tool that has not matured or does not have a lifecycle, it hurts the leader's reputation and is career limiting.
The onus of fallback plan is on the leader that took dependency on a system, it’s not on the person or team that vibe coded. Does this make sense? Whoever takes dependency on any tool or software must have a business continuity plan - that’s what leaders do
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.
Exactly right, well said, once people take dependency on it, that's an unwritten contract. And, then the vibe coder has no idea what they signed up for
Calling it a spike gives teams a word they already know how to manage. A spike has a timebox and an expected outcome, which is a decision, not a feature, and that is exactly what most vibe coded tools are good for.
The quadrant that worries me is the one you flag: internal tools. They start with a tiny blast radius, nobody reviews them, and a year later payroll or invoicing depends on them. The lifespan grew while everyone still thought of it as a prototype.
Kent Bodrov's expiry rule is the practical piece. When the TTL passes, block new integrations first, name an owner, and make the retire or harden call on purpose. Your kill, pause, pivot or scale lifecycle with a named business owner fits well with that.
I would add that hardening should be scoped as its own piece of work with a clear finish line, since rewriting a spike is usually cheaper than patching it. Have you seen teams actually enforce the TTL?