I build things. Not as a developer. I have never claimed the title and adding an AI model between me and the code doesn't suddenly make me one. I build things because, as a product manager, I have a problem with ideas that remain ideas for too long.
A browser extension that normalizes some of the signals used for fingerprinting. An Android app that listens for Bluetooth LE signals from nearby wearable devices. A local identity vault built around passkeys and verifiable credentials. None of these started with a business plan. There was no market-size slide, funding strategy or inspired weekend in which I decided to disrupt an industry.
I had a question. Does this actually work the way I think it does?
A few years ago, answering that question would have required considerably more effort. I could write a specification. Draw a prototype. Build a clickable simulation. Then I would need an engineer willing to spend time translating my hypothesis into something executable.
Now I describe what I want, argue with an AI for a few hours, correct what I understand, fail to notice some of what I don't understand, and eventually something runs.
This is an extraordinary change.
It is also where the trouble starts.
Every one of those projects has been wrong at some point in a way I didn't initially notice.
The rare condition that appeared only under a particular sequence of events. A timezone signal leaking through a privacy tool whose entire purpose was to reduce identifying information. An MVP that appeared functional until somebody approached it without knowing how it was supposed to work and found reproducible bugs and documentation gaps in an afternoon.
Weeks of building. An afternoon of looking at it differently.
Nothing unusual happened. This is how software development works.
The unusual part is that AI allows someone like me to get to apparently working software much faster than before. The speed at which I can create has become much greater than the speed at which I can prove that what I created is actually good.
That distinction matters.
What does "working" mean?
Vibe coding has collapsed the distance between an idea and executable software. Describe what you want in normal language. Generate code. Run it. Find a problem. Explain the problem. Generate more code.
Repeat.
For a product manager, this is difficult not to love.
Ten years ago, I could spend several days making a prototype whose main function was to help everybody pretend that the missing parts existed. Click here and imagine the backend did something. Move to the next screen and assume the data arrived. Ignore this part because it is only a prototype.
Now the backend can actually do something. The data can arrive. The API can respond.
Sometimes the damned thing actually works. And "works" is where we should become suspicious.
Working on my laptop is evidence of something. It is not evidence of everything.
Working with my accounts, my permissions, my test data, my browser configuration and my knowledge of exactly which button I am supposed to press next is a very particular definition of working.
It is the definition appropriate for a prototype.
A prototype is supposed to answer questions like:
Can this interaction work?
Can I intercept or change this signal?
Can these credentials remain under the user's control?
Can a phone identify a particular type of nearby device?
Will a user understand this workflow?
The prototype doesn't have to prove that the idea will survive every device, every network condition, every operating-system version or every creative human being determined to use it in a way I never anticipated.
Its purpose is to replace speculation with evidence. Cheaply, quickly, and preferably before we spend serious money building the wrong thing.
This is exactly where vibe coding is useful.
Product managers should build more things
For most of my career, product management has had an interesting limitation.
We are expected to understand the problem deeply enough to decide what should be built, but historically we could rarely build enough of it ourselves to test the assumptions behind that decision.
We researched. Interviewed. Mapped journeys. Created wireframes. Wrote stories and specifications. Presented diagrams containing arrows moving confidently between rectangles. Then engineering entered the picture and reality started correcting us.
AI changes this relationship.
A product manager can now test far more before asking an engineering team to commit production capacity.
I can create five variations of a workflow and put them in front of people.
I can connect to a real API instead of writing "API response here" inside a box.
I can discover that the clever idea I have been carrying around for three weeks is stupid.
This last feature may be the most valuable one.
Good product management is not the art of being right. It is finding inexpensive ways of discovering where you are wrong.
Vibe coding gives us a very powerful new way to do that.
I don't see this as invading engineering territory. Quite the opposite. If I can eliminate weak ideas before asking engineers to build them properly, I am using their time better. A semi-functional prototype built in one afternoon can sometimes produce more useful discovery than another week spent refining a requirements document.
But then something predictable happens.
The prototype becomes good.
Then surprisingly good.
Someone else sees it.
"Can I try it?"
And this is the moment where I think we need a line.
The prototype becomes somebody else's problem
The difference between a prototype and a product is not necessarily architecture.
It is trust.
As long as I am the only person using the software, I know where the bodies are buried. I know that one setting should not be touched. I know that permissions need to be granted in a particular order. I know that the error message really means "restart the application." I know which part the AI implemented elegantly and which part survived only because after the fifth attempt I told it not to touch anything anymore.
Nobody else knows any of this.
The moment I send somebody an APK, publish a browser extension, share a repository or tell another person to depend on something I built, the conditions change.
The software has left the laboratory. Install it on a clean machine. Run. Close it halfway through something. Restart. Deny a permission. Lose network connectivity. Change location. modeChange timezone. Uninstall. Install again.
Use an account that doesn't contain my beautifully curated test data.
Do something the documentation doesn't mention.
Do something stupid.
This is not sophisticated QA.
It is the minimum price of allowing strangers into the experiment.
And for privacy, identity and security products, there is another problem: I am probably the worst possible person to prove that my own assumptions are correct.
I designed the assumptions and I built the tests around them. And I already know what result I expect.
My blind spots and I have been working on the same project.
An adversarial review has a different job. It tries to prove me wrong.
That is much more useful.
AI changed the cost of building, not the meaning of done
There is a temptation here, particularly for product people.
For years we were separated from executable software by a professional boundary. We could describe it in extraordinary detail, but somebody else had to make the machine obey.
Now the machine listens to us directly.
Build this. Change that. Add authentication. Create an API. Make an Android version. Learn Android Studio. And a few seconds later, code appears.
I understand the attraction. I experience it almost every day.
There is a satisfying moment when an idea that existed only inside my head starts moving on a screen.
But the ability to generate functional code doesn't make me an engineer any more than an engineer wrting an excellent requirements document automatically becomes a product manager.
The professions overlap more. The boundary moves. It does not disappear.
AI has given me a much larger implementation surface. I can explore farther before I need specialized engineering help. I can understand technical constraints better because I can actually encounter them instead of reading about them in a Jira comment. I can have a much better conversation with developers because I've already crashed into some of the problems myself.
All good.
But AI didn't give me years of accumulated engineering judgment together with the generated files.
It certainly didn't give my prototype a release process.
My line in the sand is simple
I need rules simple enough that I will actually follow them.
For now, mine is this:
If it is a prototype, it needs a room, not a release.
Show it to people who understand that they are testing an idea. State what you are trying to learn. Let them break it. Use what you learn. Then improve it, rebuild it properly or kill it.
A prototype is allowed to die. We should probably kill more of them.
Don't give experimental software a version number and public download link and then mentally promote it into a product because nobody complained during the first 48 hours.
And:
If it is a product, it needs a release process, regardless of who—or what—wrote the code.
That doesn't necessarily mean a dedicated QA department, six environments and a release committee meeting every Thursday afternoon.
It does mean testing outside the environment in which it was created. It means knowing what remains broken. You need to understand that alpha and beta labels actually mean something. Create documentation someone other than the author can follow. Have another set of eyes looking for the problems I stopped seeing three hundred prompts ago.
It means somebody being deliberately hostile toward my assumptions.
AI can participate in that review too. Different models, fresh contexts and automated tests can be very effective at finding problems.
But asking the same model that built something whether what it built is good has obvious limitations.
Humans have been doing the same thing to ourselves forever.
Faster building requires better brakes
I don't think the problem with vibe coding is that people without traditional development backgrounds are suddenly building software.
I think this is one of the interesting parts.
More people can turn ideas into something testable. Product managers, designers, researchers, entrepreneurs and domain experts can move closer to the implementation. People who understand a problem can experiment without first assembling a small software company around themselves.
We will get good things from this.
We will also get an unbelievable amount of garbage.
The historical friction involved in creating software acted as a filter. Not necessarily a good filter, but a filter nonetheless. Building took time. Engineering capacity cost money. Deployment required effort.
AI removed a large part of that friction.
It did not remove edge cases or security problems. It did not remove bad architecture, dependency problems, privacy leaks or users who click the one button nobody expected them to click.
It did something more interesting.
It made software look finished much earlier in its life.
That is the part I am trying to remember.
I will continue vibe coding. Probably more, not less. It has become one of the most useful product discovery tools I have ever had access to.
I can go from "I wonder if..." to something I can touch.
That is a major change in how I work.
But when the application opens and everything appears to work, I try not to confuse that satisfying moment with the end of the process.
It means I have a prototype. Maybe a very good one. Even one worth turning into a product.
The next question is no longer: Can I build this?
AI has made that question surprisingly easy to answer.
The harder question is the old one:
Should anyone else trust it?
Until I can answer that one properly, it stays a prototype.