Vibe Code the Prototype, Not the Product

Part 2 of a series on the dos, don'ts, and dangers of vibe coding.

Years ago, a developer who worked for me said something I've never forgotten: "Alex, every prototype has a danger of going into production." She was prophetic in a rather specific way — yes, the prototype I was asking her for at the time did make it into production.

I want to hold that warning in one hand while I say something with the other that might surprise you, given how much of this series has been me pointing at vibe-coded wreckage: vibe coding is a genuinely great way to build prototypes and product requirements. It might be the best thing to happen to the most neglected part of software development. You just have to know which part that is — and where the prototype has to stop.

Software development is mostly not developing software

Even the term "software development" misleads people. They hear it and think about how much time it takes to write the software. They forget all the work that goes along with it — except it isn't ancillary work. It's the majority of the time, often. Gathering requirements. Validating that those requirements make sense. Validating that they were even implemented as written. Testing them. Documenting what was built and delivered.

This is the part of custom software that surprises people most: the minority of the time is writing code. The majority is deciphering what the customer actually wants — in direct conversation, in internally interpreting those conversations, in building something to check the interpretation against. Saying "we deliver software" is like saying a restaurant delivers salt. Technically true. The salt does arrive. It comes with the rest of the meal, which is where the work was.

And here's the uncomfortable part we don't like to own up to: when deadlines arrive and the requirements aren't really done, we start throwing things overboard and calling it good enough. That's the dangerous moment, because it isn't good enough. The difference between good and great might not look like much on a demo day, but it's the difference between a product people use for years and a product that gets thrown away.

What ignoring the requirements costs

If you think skipping definition is a small-stakes sin, let me offer some history.

Austin opened its convention center on July 4, 1992 — without the parking to go with it. The garage was supposed to be built by the hotel next door; that deal fell through, and a decade after opening day the garage was still famously "in limbo," the fix kicked around politically for years. A need so obvious it's unfathomable anyone could miss it, attached to a project people had spent twenty years fighting over. And yet.

Around the same era, Motorola shipped the StarTAC — a beautiful phone, and at launch an analog phone — while the carriers were rolling out digital PCS networks. Building the wrong phone for where the customer was going cost Motorola dearly: in 1994 they held sixty percent of the American mobile market, and by 1998 a company most Americans had never heard of, Nokia, was outselling them on digital handsets — and never looked back.

And in software: early in my career at Novell, there was a system meant to manage backups. In a fast-growing company, the project never got a firm definition, and it started growing like a virus. The code base grew larger than the network operating system it was supposed to serve. It wasn't that the work was bad — a lot of it was good work. It was solutions looking for problems, features answering hypothetical customers, effort that was never reined in by having to fit a specific purpose. A whole lot of talent, spent sitting around making a machine that just looks pretty.

Different decades, different industries, same disease: nobody nailed down what the thing was actually for before building it. Every one of those failures happened with professionals, budgets, and process. Now hand the same skipped step to someone alone at midnight with a vibe coding tool.

The blank sheet is the real enemy

Why can't people just say what they want? Mostly because almost nobody can think from a blank sheet. It's genuinely difficult for most of us. What people can do, easily and honestly, is react: show them something running and they'll tell you "this is how I would change it" all day long.

This is also why traditional sign-off is so often fake. People tell me all the time that they like what we've built. Do I believe them? Very often, no — because I can see how many minutes, not hours, they spent testing it. They looked at it, said "yeah, this is great," and never went hunting for what's missing. The more abstract the thing being approved — a spec document, a description, a slide — the more that buy-in is really just "looks good enough," which is a promissory note that bounces the first week of real use.

Where vibe coding earns its keep

This is exactly the gap vibe coding fills. It's now economical to do the things we honestly should have been doing all along but skipped under deadline pressure.

You can show more prototypes, sooner. It's easy to vibe code something that looks like the thing without it having to do anything yet — and that's not a bug in this phase, it's the point, because people think far better off an example than off a description. On our own platform there are screens that went through six or seven renditions of the same interface, because sometimes you realize you can't tweak your way out — you have to throw it away and start again. Before, each of those throwaways had a painful price. Now iteration is cheap enough that you can afford to be wrong early, which is the only time being wrong is affordable.

And you can put the prototype in front of a broader audience before you're done. I see business owners — in a genuinely well-meaning way — building tools for their employees without involving them, then discovering they answered questions wrong because they didn't have the data, plus a side order of resentment because nobody was asked. Meanwhile, guess what: some of those employees have been quietly vibe coding their own process improvements the whole time. Involve people from the beginning instead. When the real thing arrives, it's a surprise to nobody, training is lighter because they've already handled their future, and — this is the part I care about — you can actually trust their feedback, because they worked the prototype instead of glancing at it.

Magic doesn't exist, so feed it

Vibe coding achieves magical results. I call them that deliberately, because magic doesn't exist — so neither do those results. Dig in and they're general results: you get out more or less what you put in. Put in vague effort and you get off-the-shelf junk, freshly written by an AI just for you.

So there's a step you don't get to skip, and it comes before the first prompt. When someone says "you should build this and that" — great, but that's not the first question. First, the background. Who is this for? What's the operating profile of this company? What's the glossary — because certain words mean certain things to these particular people, and the AI doesn't know that. Write that down first, then feed it into every session as input. It's the difference between a prototype of your business and a prototype of a generic one.

Then capture two things as you go, not one: requirements and intentions. Requirements say what the system does; intentions say why. Intentions are the part that gets skipped constantly when people vibe code without documenting — and without them, nobody later knows why something is configured the way it is. So when changes come, you break things, because neither you nor the AI knows the value of what you're changing. Getting these out of people is honestly the hard part; we do it through structured conversations and extract both from the transcripts. The formatting into documents is the easy part. The talking is the work.

"But my prototype works"

Now the skeptic: "My prototype works. My employees use it every day. Why would I pay anyone to rebuild it?"

I was in a peer group recently where someone spent a few minutes on the virtues of what their vibe-coded tool was doing preparing estimates for their work. The moment they closed their mouth, the very first question from across the table was: "And how do you trust it?"

That's the whole issue in four words. Picture a machine running your backup generator. It appears to run. But it's a Rube Goldberg contraption of parts nobody can account for. Do you keep it because it's currently making noise, or do you start wondering whether you want something mainstream, something solid, something you can inspect?

"It works" answers less than you think, because the follow-up questions are where prototypes go to die. Did you ask it to do things right, or just ask for them? Did you tell it how to provide good security, or just say "make it secure"? When it claimed the security was good, did you test specific access from the outside, or did you ask the system to grade itself? Will it work a year from now — or is there a table quietly filling up, unindexed, that will grind everything down eighteen months in? These are the what-ifs a prototype was never designed to answer, because answering them was never its job. It's also why people who buy custom software insist on receiving the source code: what you can't inspect, you can't trust past the current moment.

Here's the danger in one sentence: unless you know what a prototype is actually doing, your continued use of it gives you a false sense that it's more accurate and more robust than it really is. Every quiet day deepens the impression without adding one ounce of evidence.

The handoff

So the discipline is knowing what you're holding. A prototype is a requirements document that runs — and as that, it's the most valuable artifact in custom software, because it collapses the expensive part: the months of deciphering what you actually want. Someone who arrives with a worked prototype, plus the background and glossary that shaped it, plus the requirements and intentions collected along the way, has done something remarkable. The build that follows is faster, cheaper, and lands on target, because the target finally holds still.

But it's the drawing of the bridge, not the bridge. My developer's prophecy comes true when things get "too good" — the prototype is so useful that it just... stays, and accretes, and one day it's load-bearing. If you read the first article in this series, you know where that ends: as the trunk of your tree, built by a process nobody can inspect.

So vibe code freely. Prototype everything. Iterate until your people stop saying "looks fine" and start saying "that's it." Then stop, hand over the drawing, and build the bridge properly. The prototype's job was to make sure you build the right thing. Building the thing right is a different job — and knowing where one ends and the other begins is the whole trick.