Naval Ravikant posted something last week that I haven't been able to stop thinking about. He called vibe coding the new product management. Not a metaphor. Not an analogy. A direct substitution.
My first reaction was that he was oversimplifying. My second reaction, after watching three non-technical founders ship real products this month using nothing but Claude Code and plain English, was that he might be underselling it. If you are new to the tool, the Claude Code tutorial is the fastest way to get your bearings.
Here's what Naval said: the vibe coder's programming language is English. You describe what you want, the AI writes the code, and you iterate by describing what to change. The technical barrier hasn't just lowered. It has evaporated. What remains is the part that was always harder to teach: knowing what to build, for whom, and why it matters.
That's product management. And it just became the most important skill in software.
English Is a Programming Language Now
This sounds like a headline engineered for engagement. It's not. It's a description of what's actually happening in terminals and IDEs across the world right now.
When I use Claude Code, I don't write functions. I describe behavior. "Add a search bar that filters posts by title and shows results as the user types." That sentence, typed into a terminal, produces working React code with debouncing, state management, and keyboard navigation. Not perfect code. Not production-ready code without review. But functional, testable code that would have taken a junior developer half a day.
The gap between describing software and having software has collapsed. English, spoken with enough precision about what you actually want, has become a viable programming language. Not a toy. Not a demo. A real tool that real people use to build real things.
Naval pointed to Claude Code specifically, calling it "arguably the best coding agent there is right now." For a broader look at how it stacks up, the vibe coding tools comparison covers the full landscape. What makes Claude Code different from earlier AI coding tools is that it operates end-to-end. You don't feed it a function signature and get a function body back. You describe a feature, and it reads your codebase, understands the architecture, makes decisions about where to put things, and writes the implementation across multiple files. It's not autocomplete. It's a collaborator that happens to type faster than you.
This changes who can build software. But more importantly, it changes what skills matter when building software.
The Skill Inversion
For decades, the bottleneck in software was implementation. You could have the clearest vision in the world, but if you couldn't code it or couldn't hire someone who could, your vision stayed on a whiteboard. Companies were organized around this bottleneck. Product managers wrote specs. Engineers turned specs into code. The power sat with whoever could execute the translation from idea to working software.
That bottleneck is dissolving. When a founder can sit down with Claude Code and describe their product in plain English, iterating through features in real time, the translation layer shrinks to nearly nothing. The spec and the implementation happen simultaneously. In the same conversation. By the same person.
This is what Naval means when he says vibe coding is product management. The skills that now determine whether software gets built well are the same skills product managers have always needed: understanding user problems deeply, prioritizing ruthlessly, making trade-off decisions with incomplete information, and knowing when a feature is good enough to ship.
The person who can articulate "we need a dashboard that shows weekly active users segmented by acquisition channel, with the ability to drill into cohorts" is no longer dependent on a six-week sprint cycle to see that vision realized. They can have a working version in an afternoon. The constraint has shifted from "can we build it" to "should we build it" and "is this the right version of it."
That's a product management problem, not an engineering problem.
A Tsunami of Apps
Naval predicts a "tsunami of applications" coming. He's right, and the early waves are already hitting shore.
Look at what's happening on Product Hunt, Indie Hackers, and the various AI builder communities. The volume of new software launching weekly has tripled in the past year. Solo founders are shipping products that would have required small teams eighteen months ago. Weekend projects are turning into real businesses, sometimes by accident, because the cost of trying has dropped so close to zero that experimentation has become the default mode. Of course, as we argued in everyone can code, nobody can ship, building fast and shipping something that lasts are two very different things.
But here's the part Naval emphasizes that most people miss: when everyone can build, the best version wins. Not the first version. Not the most technically impressive version. The one that best understands its users.
Think about what happened to photography. When cameras became cheap and accessible, the number of photographers exploded. But the photographers who thrived weren't the ones who could afford cameras. They were the ones with an eye for composition, light, and story. The technical barrier was never what made great photography great. It was just what kept most people from attempting it.
Software is having its camera moment. The technical barrier kept millions of potential builders on the sidelines. Now they're all rushing onto the field. The ones who'll win are the ones who see the game clearly: who understand user needs with enough depth to build something that actually solves a real problem, not just something that looks like it might.
Every Niche Gets Filled
One of Naval's most interesting predictions is that more niches will get filled. Software has always been a winner-take-most market in broad categories. There's one dominant project management tool, one dominant design tool, one dominant CRM. But within each category, there are thousands of specific workflows that the dominant tool handles poorly.
The accountant who needs a very specific reconciliation workflow. The physical therapist who wants a patient tracking system that matches their exact methodology. The property manager who needs maintenance scheduling that integrates with their specific vendor network.
These niches were never big enough to justify the engineering investment required to build dedicated software. A team of five engineers for twelve months to serve a market of 2,000 potential customers? The math never worked.
But a single person with Claude Code for two weeks? That math works fine.
This is where vibe coding as product management becomes most powerful. The people closest to niche problems are the ones best positioned to describe solutions. They don't need to learn React or understand database normalization. Even a complete beginner can get started. They need to clearly articulate what their workflow looks like, what breaks, and what "fixed" means. That's product management. That's the skill.
I've watched a real estate agent build a custom CRM that handles their specific lead qualification process. Not Salesforce with custom fields. A purpose-built tool that mirrors exactly how they think about prospects. They described it in English, iterated over a weekend, and now use it daily. They didn't learn to code. They learned to describe what they needed with enough precision that an AI could build it.
Personal, Bespoke Software
Naval also talks about "personal software" and "bespoke apps," and this might be the most underappreciated part of his argument.
We've been trained to think of software as a product you sell. SaaS, subscriptions, monthly recurring revenue. But what if most of the software created in the next five years is never sold to anyone? What if it's personal?
I built a tool last month that tracks my reading habits, connects highlights to my notes, and generates a weekly summary of themes I've been thinking about. Nobody else would want this exact tool. It's designed around my brain, my workflow, my idiosyncratic habit of tagging notes with single-word emotional descriptors. It would be absurd to productize it.
But it's incredibly valuable to me. It saves me an hour a week and helps me see patterns in my thinking that I'd otherwise miss. In the old world, building this would have cost weeks of development time. In the vibe coding world, it cost an evening and a conversation with Claude Code.
This is software that could never have existed before, not because it was technically impossible, but because it was economically irrational. No one would pay a developer to build a tool for an audience of one. But when the cost of building drops to nearly zero, the calculus changes entirely. Software becomes personal. Like a custom suit versus off-the-rack. You don't sell custom suits to the mass market. You make them for yourself because you can.
Naval sees this clearly. The future isn't just more apps competing for the same users. It's millions of personal apps that never compete with anything because they're built for an audience of one.
What This Means for Product Managers
If vibe coding is the new product management, what happens to actual product managers?
They become more valuable, not less. The skills they've developed, understanding users, prioritizing features, making scope decisions, defining success metrics, these are exactly the skills that matter when anyone can build anything. The product manager who can walk into a room, listen to a customer describe their frustration, and then sit down with an AI coding tool to build a solution in real time? That person is extraordinarily powerful.
But the role changes shape. Product managers who think their job is writing Jira tickets and managing sprint velocity are in trouble. Those activities were always proxies for the real work, which is making good decisions about what to build. The proxies are disappearing. The real work remains.
I think we'll see a new hybrid role emerge. Call it a "builder PM" or a "product engineer" or don't call it anything at all. It's a person who deeply understands a problem space, can articulate solutions in precise English, and uses AI tools to iterate on those solutions at the speed of thought. Not at the speed of a sprint cycle. At the speed of thought.
The Skills That Matter Now
If you're reading this and wondering what to invest in, here's my honest assessment.
Learn to describe software precisely. This sounds trivial. It isn't. The difference between "build me a dashboard" and "build me a dashboard that shows the seven-day rolling average of new signups, grouped by referral source, with the ability to click into any source and see individual user timelines" is the difference between getting something useless and getting something useful. Precision in language is the new precision in code.
Develop product intuition. Talk to users. Watch them work. Understand their frustrations at a granular level. This has always been the hardest skill in software, and it's about to become the most valuable. When anyone can build, the person who knows what's worth building has all the leverage.
Get comfortable with iteration. Vibe coding isn't "describe it once and ship it." It's a conversation. You describe, you review, you refine, you redirect. The quality of the final product depends on the quality of your feedback loops, not the quality of the first prompt. This is exactly how good product management works, through rapid iteration informed by user feedback.
Learn to evaluate code you didn't write. You don't need to be able to write a binary search from scratch. But you need to know when the AI has made an architectural decision that will cause problems at scale. You need to recognize when a solution is brittle, when it's missing error handling for real-world scenarios, when it's technically correct but wrong for your users. This is code review, and it's a skill that transfers perfectly from traditional engineering to vibe coding.
The Real Shift
Naval's observation lands because it names something many of us have felt but hadn't articulated. The center of gravity in software creation is moving. It's moving from "how do we build this" to "what should we build" and "for whom."
This isn't the death of engineering. Karpathy made a similar argument when he said vibe coding is passe and that the real skill is agentic engineering: steering AI with deep system knowledge. Engineers who understand systems deeply, who can evaluate AI-generated code critically, who know where distributed systems break and why, are more valuable than ever. The code is free, but the judgment about code is not.
But it is the death of coding as a gatekeeping function. You no longer need to pass through years of technical training to participate in building software. You need to think clearly about problems, describe solutions precisely, and iterate based on real feedback.
That's product management. It always has been.
Naval is right. Vibe coding is the new product management. And if that makes you nervous, consider this: the best product managers I've known were never the ones with the fanciest tools or the most elaborate processes. They were the ones who talked to users, understood problems deeply, and made good decisions under uncertainty.
Those skills are about to be worth more than they've ever been, and the future of vibe coding careers is being shaped by people who double down on them. The tools just caught up to the people who always had the vision but never had the means to build it.
The tsunami is coming. The question isn't whether you can code. It's whether you know what's worth building.
