Vibe Coding Has Two Jobs. Most Companies Give It Neither.

Vibe coding, the practice of building working software through conversation with AI rather than writing it line by line, has a positioning problem inside most companies. Executives either dismiss it as a toy or panic about it as shadow IT, and both reactions miss the point. Having built a vibe-coding practice inside a large enterprise and spent years before that leading product teams that could never get enough engineering capacity, I have come to a simple conclusion: vibe coding earns its keep in exactly two jobs, and most organizations are giving it neither.

Job one: letting product teams find truth cheaply, before engineering gets expensive. Job two: solving the enormous long tail of real business problems that will never, under any honest prioritization, justify engineering resources at all.

These two jobs have different economics, different risks, and different definitions of success. Treating them as one thing is why so many vibe-coding efforts drift into either chaos or irrelevance.

Job one: cheap truth before expensive code

Here is a moment every product leader knows. The team believes in a feature. The deck is persuasive, the customer quotes are encouraging, and the estimate comes back at three engineers for a quarter. You fund it, because the alternative is another round of research that answers nothing. Two quarters later the feature ships, adoption is a rounding error, and the retro concludes, as retros do, that “we learned a lot.”

That is the most expensive way to learn there is. The dirty secret of product development has always been that our riskiest assumptions are usually testable for a fraction of the build cost, but the testing itself required engineering time, which meant the test competed against the build in the same backlog. So teams skipped the test and built the bet. I ran product organizations under exactly that constraint, and I made exactly that mistake.

Vibe coding breaks the constraint. A product manager or designer can now stand up a working prototype, real enough for a customer to click through, react to, and misuse in instructive ways, in days and without touching the engineering backlog. Not a Figma flow where every path is scripted, but a live artifact with behavior, which surfaces a category of learning static prototypes never reach: what people actually do when the tool pushes back.

The discipline that makes job one work is refusing to let the prototype pretend to be the product. Its purpose is to kill or sharpen an idea before real money gets spent. That means every prototype starts with a named assumption and a decision it will inform: if fewer than half the pilot customers complete the workflow unprompted, we do not fund the build. The prototype is an instrument in a decision process, and when the decision is made, the instrument has done its job. Most should then be retired, and retiring them should feel like success, because each one either saved you an expensive miss or bought conviction for an expensive yes. A killed prototype that cost four days and prevented a wasted quarter is one of the best trades available in product management right now.

Job two: the long tail engineering will never reach

Now the second job, which almost nobody talks about because it is unglamorous, and which I suspect creates more total value.

Every organization carries an invisible inventory of workflow pain: the finance analyst reconciling two systems through a weekly spreadsheet ritual, the operations team routing requests through an inbox and tribal knowledge, the manager assembling the same report by hand every Monday. Each problem is real. Each has a constituency of five to fifty people who feel it every week. And each fails the business case test for engineering investment, forever, because no rational company assigns scarce engineers to a tool for eight people when the roadmap is full of work for thousands of customers.

For decades the honest answer to these people was “live with it.” The pain was real but sub-economic. Vibe coding changes the denominator. When a capable internal user can build the tool themselves in an afternoon, with guardrails, problems that could never justify engineering suddenly justify solving. I have watched people who had hated a manual process for years replace it in a day, and the effect goes beyond the hours saved. Something shifts in a person the first time they fix their own workflow instead of filing a request into a backlog they will never see again. They stop treating software as weather and start treating it as material. Then they find the next problem, and show a colleague, and the practice spreads through credibility no central IT program can manufacture.

Job two needs different guardrails than job one. These tools are not experiments to be killed; they are meant to persist, which is precisely what makes them risky. The failure mode is the afternoon build that quietly becomes load-bearing: real data, real process, no owner, no review. So the rule I coach is a graduation line, drawn before you need it. A job-two tool that touches sensitive data, crosses team boundaries, or becomes something a process depends on gets a lightweight review and a named owner, or it gets retired. The point is not bureaucracy. The point is that “small internal tool” is a category an organization must be able to see, not a shadow it pretends not to notice.

Why naming the two jobs matters

Run both jobs through one policy and you get the worst of each. Judge job one by production conversion and you will strangle experimentation, because its best outcomes are killed prototypes. Govern job two like disposable experiments and you will wake up with ungoverned tools holding up real processes. One practice, two jobs, two scorecards.

If you are a product leader, start with job one this quarter: pick the riskiest assumption on your roadmap and prototype it before you estimate it. If you run a function drowning in manual work, start with job two: find one willing builder and one hated workflow. Either way, the technology is ready. The question is whether your organization has decided what job to give it.

Dave Mathias helps organizations build product capability and practical AI fluency. Standing up a vibe-coding practice, or trying to govern one that grew on its own? Let’s talk.