I’ve been spending more time thinking about vibe coding, not because I believe it is going to replace software engineering, but because I think it changes something much more practical: how quickly people can turn an idea into something real enough to learn from.

That distinction matters.

A lot of the discussion around vibe coding has gone to one of two extremes. On one side, there is the idea that anyone can now build software and engineering as we know it is about to disappear. On the other, there is the view that vibe coding is mostly a toy, useful for demos and weekend projects but not serious product work.

I don’t think either view is particularly helpful.

What I find interesting is what happens in the middle.

For a product manager, designer, founder, or even someone inside a business team, the gap between having an idea and being able to interact with that idea has suddenly become much smaller. That has consequences for product development that are easy to underestimate.

A few years ago, if I wanted to explore a new workflow, I could write it down, sketch it, create a prototype in Figma, or ask an engineer to build something. All of those approaches are useful, but they still require some amount of imagination. A static design can show me what a screen looks like, but it doesn’t always tell me what it feels like to use. A PRD can describe behavior in great detail and still leave five people with five different interpretations.

Now I can often build a rough version myself.

It may not be pretty. The code may not be something I would ever want in production. But I can click through it, change it, give it to someone else, watch them struggle with it, and learn something that I would not have learned from a document.

That is the part of vibe coding I think product teams should pay attention to.

The value is not really that AI writes code. The value is that experimentation becomes cheaper.

And when experimentation becomes cheaper, good product teams should probably experiment more.

I care much more about the learning loop than the code

There is a habit in product development that I think most of us recognize. An idea starts simple, but before anyone has really validated it, it begins accumulating process.

We discuss requirements. We refine the requirements. We create designs. We review the designs. We debate edge cases. Engineering estimates the work. It goes through prioritization.

Sometimes all of that is necessary.

But sometimes we spend a surprising amount of time debating something that could have been answered by building a rough version and putting it in front of a few people.

This is where vibe coding becomes useful to me.

If I have three ideas for how a workflow might work, I don’t necessarily need to pick one based on which sounds most convincing in a meeting. I may be able to build all three badly, quickly, and learn which direction is worth taking seriously.

That is a very different use of AI than asking it to produce production code.

It is closer to using code as a thinking tool.

I think product people will increasingly do this.

Not because every PM needs to become a developer, but because product managers have always needed ways to make ideas tangible. We use diagrams, prototypes, spreadsheets, SQL, mockups, presentations and whatever else helps us understand a problem.

Code is becoming another one of those tools.

A working prototype changes the conversation

There is also something powerful about being able to show rather than describe.

Consider a conversation about onboarding.

Someone says the onboarding process needs to be simpler. Another person thinks the product should ask more questions upfront. Someone else wants AI to recommend a configuration. Another person wants to remove onboarding completely and let the system infer what the user needs.

You can spend a long time discussing those ideas abstractly.

Or you can build rough versions and try them.

Once something exists, even imperfectly, the conversation usually gets better.

People stop reacting to the idea they have in their own head and start reacting to the same thing.

You notice that the flow is too long.

You realize the recommendation feels premature.

You discover that a screen you thought was obvious is confusing.

You see that one idea is far better in practice than it sounded in a document.

That is useful product work.

In some cases, I think a functioning prototype may become more valuable than a very detailed PRD at the early stage of a project.

Not because documentation no longer matters. It does.

But a document is usually an explanation of an experience. A prototype lets you experience it.

Those are not interchangeable.

Where I think people get into trouble

The problem starts when the prototype stops being treated like a prototype.

This is the part of vibe coding that deserves more caution.

It is very easy to build something that appears finished.

The screens look polished. Authentication seems to work. Data is being stored somewhere. The AI tool has generated APIs, database calls and deployment configuration. A few people test it and everything appears fine.

At that point, there is a natural temptation to say, “Why don’t we just use this?”

That is where I would become much more careful.

A product appearing to work is not the same as a product being ready to operate.

Production software carries responsibilities that are largely invisible in a demo: security, authorization, data protection, accessibility, observability, performance, failure recovery, dependency management, testing, maintainability and ownership.

These things are not optional just because the application was easy to create.

In fact, the easier it becomes to create software, the more disciplined companies may need to become about deciding what software is allowed to exist.

That may sound contradictory, but I think it is one of the most important consequences of vibe coding.

We are lowering the barrier to creation without lowering the cost of mistakes.

This will probably create a lot more small software

One area where I think vibe coding will have a very large impact is software that previously was not worth building at all.

There are thousands of small problems inside companies that are currently solved with spreadsheets, manual work, scripts, copy and paste, or simply tolerated.

A finance team might spend an hour every week cleaning a report.

A support team might manually combine information from several systems.

A product manager might repeatedly transform the same dataset for research.

An operations person might maintain a spreadsheet because getting an internal tool built would never make it onto an engineering roadmap.

Historically, the economics were simple. The problem was annoying, but not annoying enough to justify software development.

AI changes that equation.

If a person can build a small internal tool in an afternoon, use it for six months and save several hours each week, that can be perfectly rational even if the tool would never deserve a formal product team.

I suspect we are going to see a lot more software like this: small internal tools, temporary experiments, team-specific applications, and personal utilities built to solve a particular problem. Some of them will be rough around the edges, while others will become surprisingly useful. Many will never develop into products in the traditional sense, and I actually think that is healthy. Not every piece of software needs to scale, attract users, or become a formal company initiative. Sometimes it only needs to save a team time or make one frustrating process easier.

We have spent years treating software as something that has to be designed for scale. AI may make it reasonable to build software for very small audiences, or even for one person.

There is also a governance problem hiding here

The same trend creates a problem for larger organizations.

If everyone can build software, eventually you have to know what everyone built.

Someone connects a generated application to a customer database.

Someone else creates a tool using an API key stored incorrectly.

A team starts depending on an internal utility that nobody officially owns.

The employee who created it leaves.

Six months later, nobody knows how it works, but the business depends on it.

This is not a reason to ban vibe coding.

Companies tried versions of that approach with spreadsheets, SaaS products and shadow IT, and people generally find ways around restrictions when the tools solve real problems.

I think the more useful response is to create boundaries.

What can employees build freely?

What kind of data can those applications access?

What authentication and authorization patterns are required?

When does a prototype need an engineering review?

When does an internal tool become important enough to need an owner?

What happens to these applications when the person who created them leaves?

Those are product, engineering, security and governance questions that many companies will have to answer sooner than they expect.

I don’t think vibe coding makes engineering less important

If anything, I think it may clarify where engineering expertise matters most.

AI can generate a lot of code.

Generating code was never the entirety of software engineering.

Engineers make decisions about systems that need to keep working when requirements change, traffic grows, people make mistakes, dependencies fail and security assumptions are tested.

That work becomes more important when the amount of software being created increases.

The role may change, though.

I can imagine product teams where PMs and designers build much richer prototypes themselves. Engineers may get involved later in some ideas because less promising directions have already been discarded.

That could be a positive outcome.

Engineering time is expensive. We should spend more of it on ideas that deserve to become real products and less of it answering questions that could have been resolved through cheap experimentation.

The part that excites me most

I don’t find vibe coding particularly interesting because it lets people say they built an app without knowing how to code.

What interests me is that the cost of curiosity is going down.

You can have an idea at 10 a.m. and interact with some version of it before lunch.

You can test something you would previously have dismissed because it wasn’t worth asking an engineering team to build.

You can explore five directions instead of arguing about one.

You can create tools for problems that are too small for a roadmap but still worth solving.

That creates room for more experimentation.

And I think that is where the real opportunity is.

The companies that benefit most from vibe coding probably won’t be the ones that simply generate the most code.

They will be the ones that learn how to use this new speed without confusing speed with quality.

Build quickly when the goal is learning.

Throw things away when they have served their purpose.

Bring engineering discipline in when something becomes important.

And be very clear about the difference.

That, to me, is a much more useful way to think about vibe coding than asking whether everyone is suddenly a software engineer.