Vibe Code as Specs?
I’ve heard this sentiment a few times now: “Vibe coding might not be good for production code. But as a product manager, I can use it to quickly throw together a prototype that I can then hand off to the engineers as a sort of specification.”
I’m not thrilled about that use case, and here’s why: It constrains the engineers and reduces them from engineers to mere coders, in stark contrast to the push for more responsibility and autonomy (in the form of product engineers) that is happening in the industry.
We’ve seen similar developments before: It used to be that a product manager would hand off a very rough sketch of how they envisioned a feature. If you picture a drawing on a napkin, you’re not far off. Wireframing tools like Balsamiq embrace that minimalist aesthetic so that the focus is on what’s important: “Okay so we’ll have a navigation menu at the top and an info panel at the bottom right and…”
Then along comes Figma, with its design and developer modes, so that the product team can articulate down to the individual pixel how they want everything to look like. The problem is that now, the developer doesn’t see the forest for the trees or, in Figma’s case, the overarching design principles for the individual properties listed for each page element. Of course we want the developers to stay true to the intended design. The way to achieve that, though, is via upfront work in deciding on a good design system. In another sense, using high-fidelity tools for low-fidelity prototyping leads to a massive duplication of information. No longer do you have a single source of truth for what the desired outcome is. Instead, it’s spread out all over the place.
Back to the vibe “spec” example: It’ll be extremely hard to take such an artifact and reverse-engineer which parts of its behaviour were intended and which are overlooked or misunderstood edge cases. It’s safe to assume that the product manager hasn’t worked out a proper, detailed, specification yet. Because otherwise, they should have just given that spec to the developers instead of a vibe coding tool. So, lacking a proper spec, the vibe AI will fill in the gaps with its own assumptions, until the PM decided it was “good enough” and shipped it to the devs.
A better way
There’s nothing wrong with using AI to flesh out an underspecified problem. It’s actually a great use. Find the missing pieces, clarify the edge cases (”When you say the dashboard should show entries form the last year, do you mean the last calendar year or do you mean from the last 365 days, and how should leap years be handled?”) The outcome of such an exercise though should be a document, not a bunch of poorly written AI code that the poor devs now have to parse through so they can reverse-engineer the spec. (Even better than a detailed spec is a high-level spec together with the actual outcome a user wants to achieve. Heck, that’s what the original concept of user stories in Agile was meant to be…)
No vibes, no fun?
There is a place for vibe-coding a prototype, and that’s for discussions among non-technical folks, if there’s really no way to convey the idea other than “you have to see it to know what I mean.” And even there, I’d remain cautious. Does it need to be an actual software artifact? Does a low-fidelity prototype, meant to demonstrate an idea, need a backend, database connectivity, and all the bells and whistles? Or could it be just a bunch of napkin drawings connected with arrows?
