I wrote a spec last year for a feature that seemed obvious. Three paragraphs, a few acceptance criteria, a rough sketch. The engineer read it, nodded, and built exactly what I asked for. It was wrong. Not wrong in the details — wrong in the shape. The thing I described made sense as a sentence and made no sense as a screen.
That mistake cost about a week. A month later I hit a similar fork and did something different: I spent forty minutes getting an AI to build me a fake, non-functional version of the screen. I looked at it for ten seconds and immediately knew it was wrong. Same discovery, fifty times cheaper.
That is the entire argument for product managers vibe coding. Not that we should write production code. That being specific has become cheap, and being vague is now a choice.
What I mean and what I don't
By vibe coding I mean describing what you want in plain language, letting a model produce something runnable, and iterating by reaction rather than by engineering. You are not reviewing the code. You often cannot review the code. You are reacting to the output.
What I do not mean: PMs opening PRs against the production repo. I will come back to this, because it is the part that determines whether your team finds this useful or infuriating.
1. It moves the moment of discovery earlier
Specs fail silently. Everyone reads the same document, everyone believes they agree, and the disagreement surfaces in code review three weeks later. A prototype fails loudly and immediately. You put it on the screen and someone says "wait, why does it do that," and now you are having the real conversation at the point where changing your mind is free.
This is the same principle behind every cheap-experiment method product people already believe in. Vibe coding just lowered the price of the artifact from days to an afternoon.
2. It turns your opinions into questions engineers can answer
There is a specific kind of meeting where a PM says "it should feel instant" and an engineer says "what does instant mean" and neither person can close the gap because the PM is describing a feeling and the engineer needs a number.
A rough prototype collapses that. Instead of arguing about the word, you put a clickable thing on the table and ask: this, or not this? Engineers are extremely good at answering concrete questions about a concrete artifact. They are understandably tired of answering vague ones about a paragraph.
The prototype is not a proposal for how to build it. It is a question about what we are building, phrased in a way that can be answered.
3. It rebuilds technical intuition that the PM role erodes
The longer you sit in product, the more your technical understanding turns into vocabulary. You learn to say "rate limit" and "webhook" and "idempotent" correctly and you slowly stop knowing what any of it feels like.
Building small throwaway things fights that. When I wired up something against our own API to mock a flow, I finally understood what our onboarding actually asks of a developer, because I had to do it myself with no internal knowledge to shortcut the confusing parts. Reading the documentation had never given me that. Being annoyed by the documentation did.
For anyone working on developer tools this is close to mandatory. You cannot have good judgment about a product you have never used in the way your users use it.
4. The unglamorous stuff is where it actually saves time
Prototypes get the attention, but most of my use is duller: a script to pull and reshape data for a release report, generating realistic test fixtures for QA, a quick tool to diff two API specs, throwaway parsing of a customer's messy export. Small, boring, self-contained, and previously either an engineer's interruption or my two hours of copy-paste.
This category has almost no downside. Nobody depends on it, it runs once, and if it is wrong you find out immediately because the output is nonsense.
Where it goes wrong
I want to be honest about the failure modes, because the version of this post without them is the reason developers roll their eyes at PMs discovering AI.
Confusing a demo with a build. The prototype works because it has no auth, no error states, no concurrency, no migrations, and four rows of fake data. If you then tell your team "it only took me an afternoon," you have damaged something real, and you deserve the reaction you get. The prototype tells you nothing about effort. Never use it as an estimate.
Unearned confidence. Getting something on screen feels like understanding. It is not the same thing. I have been wrong about feasibility more often since I started prototyping, because the working demo makes the hard parts invisible rather than visible.
Security and data. Do not put customer data, credentials, or anything from a private repo into a prototype. This is the fastest way to turn a productivity habit into an incident.
Scope creep into the engineer's job. If your prototype starts accumulating features and you start defending your implementation choices, you have crossed from asking a question to doing someone's job badly.
The rule
One rule makes all of this safe, and it is short:
My code is a question, not an answer. It never ships.
Everything I build this way is disposable by default. It exists to be looked at, reacted to, and thrown away. The engineers on my team know that when I bring something in, I am not proposing an implementation, I am showing them what I could not explain in words. That framing is the whole difference between a PM who prototypes and a PM who is now a liability in the codebase.
Worth trying
If you are a PM who has never done this, the lowest-risk starting point is not a feature. It is one boring internal script that only you will use. You get the reps, nobody is affected if it is bad, and you find out quickly whether this fits how you think.
The skill being unlocked here is not programming. It is specificity. The cost of showing instead of telling dropped by an order of magnitude, and product management is a job that is mostly about being precise in the face of ambiguity.
Curious where other people land on this, especially engineers who have worked with a PM doing it. Where did it help and where did it get in the way?
Top comments (0)