Vibe Coding Changed How Products Get Built — Here's What That Means for PMs

There is a new term floating around engineering circles that sounds like an absolute joke to anyone outside the tech bubble: Vibe Coding.

It’s essentially the practice of an engineer writing very little manual syntax, and instead acting as a prompt-conductor. They sit in Cursor or Copilot Workspace, describe the physics of the feature, adjust the parameters, hit accept, and watch hundreds of files cascade with new, perfectly formatted logic. They are coding by feel. They are managing the "vibe" of the architecture rather than the semicolons.

When I first saw a senior engineer build a fully functional real-time multiplayer cursor system in 45 minutes using this method, I had two distinct reactions:

1. This is beautiful.
2. The traditional PM sprint cycle is entirely broken.

Here is what vibe coding actually means for the physics of product management.

The Collapse of the Sprint Cycle

If you are still running rigid two-week sprints based on two-week estimation cycles, you are fighting the new laws of physics.

Vibe coding makes estimation essentially impossible, but in the opposite direction. A ticket that a PM estimates as an "8" (meaning it should take a full sprint to complete) might get solved in 12 minutes because the AI agent had the perfect training data for that specific integration pattern.

Conversely, a ticket estimated as a "2" might take four days because the LLM keeps hallucinating an edge-case logic loop that the engineer has to manually untangle.

You cannot use Fibonacci sequences to estimate AI-assisted output velocity.

Instead of rigid sprints, PMs need to move to Continuous Flow (Kanban) with hard WIP limits. The backlog simply exists as a prioritized queue of truth. When the vibe coder finishes a monolithic feature in three hours, they pull the next one. You stop managing time, and you start exclusively managing priority.

Thinner PRDs, Fatter Context

Vibe coders do not want your 12-page PRD.

If they are prompting an AI to write the components, the AI needs constraints and context, not rigid step-by-step procedural instructions. If you lock down the design too strictly, you prevent the engineer from using the generative serendipity of the AI to find a better, faster architectural solution.

You have to write "Fat Context" tickets.

• What is the goal? (e.g., Let users export this report as a PDF).
• What are the data laws? (e.g., Do not expose column C, it contains PII).
• What is the fail state? (e.g., If the PDF library crashes, default to CSV and show a toast error).

You give them the box. You let them vibe inside the box.

The QA Crisis

The biggest danger of vibe coding is the volume of "Dark Code" it generates.

Dark code is code that works perfectly on the happy path, was generated entirely by AI, and is fully understood by absolutely no human being on the payroll.

When a PM tests a vibe-coded feature, it will look flawless. But when a weird edge case hits it in production, the system might fail spectacularly. And because the engineer didn't manually write the DOM logic, debugging it takes longer than building it did.

The PM's role in QA shifts from basic acceptance testing to adversarial testing.

You cannot just verify that the "Submit" button works. You have to attack the feature. You have to submit null values, you have to disconnect your wifi mid-request, you have to try to break the prompt injection boundaries if it's an LLM feature. You must become deeply, aggressively adversarial before you let it hit production.

Respect the Velocity

Some PMs feel threatened by vibe coders. If the engineer is moving at lightspeed, the PM feels like they are losing control of the process.

Do not try to slow them down with bureaucracy. If you try to force a developer who is functioning on pure dopamine and AI momentum to go update a Jira ticket, they will despise you.

Your job is to stay ahead of the snowplow. Clear the corporate roadblocks. Feed them high-context user problems. Then get out of the way.

---

FAQ

Does vibe coding mean we don't need designers anymore?

No, it actually makes designers more crucial. AI can vibe code a functional UI, but it defaults to generic, bootstrap-looking components. Deep, brand-specific UI/UX requires a designer to define the visual "vibe" that the engineer then prompts the AI to adhere to. Design becomes the constraint framework for the code.

What if an engineer is generating code that isn't secure?

This is the primary risk. The PM must formally partner with the lead architect or security officer to define constraints. You add explicit "Security Acceptance Criteria" to the tickets that require automated static analysis tools to run against any AI-generated pull request before it can be merged.

How do I manage a team where half the engineers use AI and half refuse to?

You cannot force old-school engineers to adopt vibe coding, but the momentum will eventually force them out or force them to adapt. Measure them by the same outcomes. If the AI-assisted engineer is shipping high-quality features 3x faster, the traditional engineers will naturally adapt to survive. Your job is just to reward the outcome, not the method.