Plan to Throw One Away — Especially If It's Vibe-Coded
If you follow my blog, you already know I believe vibe coding is not software engineering and that you're taking big risks if you directly deploy a primarily vibe-coded system to production.
As a quick refresher, “vibe coding” is the idea that you can express your requirements in natural language and rely on LLM-based AI assistants to generate a working system for some definition of “working”. The selling points are speed, democratization, and empowerment of non-programmers (which is too often translated into replacing trained engineers with anyone who can type a prompt into Replit).
The drawbacks? All the "-ilities" you remember from your software engineering class: maintainability, scalability, security, debuggability, and so on.
The Right Way to Prototype
One of the enduring truths from when I teach software engineering that has become more relevant than ever is the value of prototyping when done well.
Prototypes are powerful tools to validate ideas, reduce development risk, and build stakeholder alignment. But despite how often prototyping is mentioned in Agile processes, design sprints, and whiteboard sessions, it’s rare to see organizations actually use them the right way.
Let’s recap a few fundamentals of prototyping done right:
Start with a purpose. Know exactly what you're trying to learn: feasibility, UX validation, technical integration, etc.
Build fast. Use high-level tools, fake data, mock dependencies, anything to speed up the development and get through the prototype phase ASAP.
Isolate from production. No shared infrastructure, no production data, and definitely no deploying the prototype to end users.
Address system risks. Target the riskiest assumptions first since that’s where prototypes deliver real value.
When you think about it, vibe coding actually aligns with those goals pretty well. In fact, these days you probably should be vibe-coding your prototype. If you’re trying to test an idea, align stakeholders, or explore a new user flow, fire up your favorite LLM coding assistant and go wild.
But what happens next is where things often go off the rails.
Throw One Away
In The Mythical Man-Month, Fred Brooks famously wrote:
“Plan to throw one away; you will, anyhow.”
He said this in 1975. It’s almost like he saw a future where product managers were trying to prompt their way to MVPs. Needless to say, this remains one of the most important principles of prototyping. And too many organizations skip this step. Instead of throwing away the prototype, they "clean it up" and ship it. Or worse, they confuse the prototype with the “MVP”, and in doing so, they treat a messy, single-happy-path, barely-working demo as something ready for customers and scale.
The results are predictable:
Security vulnerabilities.
Systems that don't scale.
Heaps of tech debt.
No tests, no logging, and no observability.
Nobody (including the original author) can explain how it works.
And then to add insult to injury we tell the software engineers tasked with carrying this mess forward to “move fast” because the prototype already proved it works.
You Can Evolve a Prototype, But Do It Intentionally
Don’t get me wrong: It is possible to successfully evolve a prototype into a production system -- but only if you do so intentionally and with an engineering-discipline mindset.
That means:
Defining architectural standards.
Writing meaningful tests.
Replacing throwaway hacks with production-grade implementations.
Managing stakeholder expectations regarding future development velocity.
If you want to evolve a vibe-coded prototype into something real, you have to deliberately transition from “exploration” into “engineering”. And given the current state of LLM-based AI coding tools, if you’ve already let your product manager vibe-code the prototype, then you've probably made that decision in the negative by default whether anyone said it out loud or not.
Vibe Coding Will Make Prototype Abuse Worse
Let’s be honest: “Prototype abuse” didn’t start with vibe coding. Developers have been evolving, deploying, and maintaining proof-of-concept code for years. But LLMs put this problem on steroids. With a few well-worded prompts and some copy-paste, it’s now easier than ever to generate something that looks like a “working” system.
As a result, we’re about to see a flood of “interesting”, insecure, poorly architected, unmaintainable systems land in production while built entirely out of vibes. And here lies a key fallacy behind the idea that product managers + AI assistants will make software developers obsolete:
The prototype is the easy part. The real work begins when it’s time to engineer it.
After the hype fades, there will be plenty of opportunities for disciplined, experienced software engineers to come back and clean up the mess.
Need Help?
If your organization is experimenting with AI-assisted development and wants to do it right — or if you’ve already gone a bit too far down the vibe-coded path and need help sorting it out — I can assist. I work with teams to bridge the gap between prototype and production in a way that respects speed, innovation, and engineering discipline. Get in touch if that’s something your team could use.
