How business leaders should think about 'Vibe coding'. Code Was Never the Bottleneck
I keep hearing the same complaint, in two different decades.
Five years ago it sounded like this: “I built this model in Excel in under an hour. Why does my engineering team need two weeks to put it into our stack?” The 2026 version is barely altered: “I can just prompt Claude Code and get what I want instantly. Why can’t my engineers do that?”
I’ve been in the rooms where both versions get said. Often the same rooms, often the same people. The misunderstanding hasn’t gone away. If anything, it has compounded.
Let me concede what the vibe-coding crowd is right about, because they are right about something. A regional sales operations manager who wants to track which competitors got mentioned in last week’s discovery calls can now build the tool herself in an afternoon, ship it that evening, and iterate through the week. If she’d filed that request with IT, nothing would have happened in any time horizon she cared about. It would have entered a backlog that doesn’t clear for one-team, six-month-half-life utilities, because nobody can justify staffing engineers against them. The category of work that used to be impossible to get built and is now buildable in a weekend is real. It’s also bigger than the previous no-code wave delivered. Lovable, Bolt, Replit and the rest do, on this narrow dimension, what they say they do.
That’s where my agreement with the proponents ends, and almost everything else in the discourse is wrong, including most of what engineers are saying back to it.
The vibe coding side over extrapolates from the salesops dashboard to the customer onboarding workflow. The skeptics argues against that. It pretends the dashboard category doesn’t exist, or doesn’t matter. Both miss the actual question, which is what kind of work is getting created and where it’s accumulating.
The version of this I see most often is in the corner office. I sit with business leaders across industries, and many of them now show me something they built over the weekend on their phone. They built it because their software vendor strung them along on a feature for two quarters, or because their IT team has been quoting them nine months and $400,000 for things that visibly look easier than that. The frustration is legitimate. I’d be frustrated too. The response is wrong, and it’s wrong in a way they don’t want to hear.
A business leader who builds her own customer cohort dashboard on a Saturday is not solving a tooling problem. She is concealing a vendor management problem and an IT leadership problem under three weekends of her own time, which is the most expensive labor in the company. Worse, the dashboard is now the workaround. The vendor and IT failures aren’t generating enough pain anymore to make anyone fix them. She has bought herself relief at the price of postponing the structural fix indefinitely and becoming their ‘assisstant’ over holding them accountable. The opportunity cost is the work she was actually hired to do: replacing the underperforming CIO, renegotiating the vendor contract, fixing the team that was supposed to deliver this. None of that work is happening while she’s in her prompt window.
When I look at what the data says at the tool level, the picture is much quieter than the marketing.
Bubble’s late-2025 survey of 793 builders who had used both visual development and vibe coding tools found that nine percent had deployed vibe coding for the majority of their production applications. Roughly two-thirds had it running 0–25 percent of business-critical workloads. Only 32.5 percent of experienced builders felt confident shipping vibe-coded software for mission-critical use, against 71.5 percent for the older visual-development tools they were comparing against.
Veracode’s October 2025 audit added a quieter finding. Current models had become substantially better at writing functional code over the previous three years. They had not become better at writing secure code. The security gap held even for the new reasoning models that had improved everything else. A separate review of 1,645 Lovable-generated applications found that 170 of them, roughly one in ten, exposed personal information to anyone who asked.
None of this is fatal to the technology. The tools’ job is the dashboard category, not the production app. The trouble starts when the dashboard category gets handed to the head of operations who then decides she has built the production app.
The Excel comparison isn’t a metaphor. It’s the same situation, replayed with a worse blast radius. JP Morgan lost roughly $6.2 billion in the London Whale episode in 2012 because a value-at-risk model lived in a spreadsheet whose author had divided by a sum where he should have divided by an average. The error survived for months because the spreadsheet was the model and nobody else could read it. Public Health England misplaced 16,000 Covid test results in October 2020 because a workflow stitched together from XLS files truncated rows past the 65,536-row limit nobody had thought to look for. Neither was a failure of the tool. Both were failures of the institutions that allowed the tool to become a system of record without anyone noticing the transition.
The vibe-coded equivalent has different physics. A spreadsheet at least sits in a recognizable file format that an auditor knows to ask for, on a shared drive someone owns. A vibe-coded application is a URL nobody catalogued. It runs on infrastructure the company doesn’t control. It talks to APIs the company never approved. It holds data the company hasn’t classified. It is governed by prompts that were not version-controlled.
Replit’s chief executive had to publicly apologize in July 2025 after the company’s coding agent deleted a customer’s production database during a code-freeze window, despite explicit written instructions to make no changes. The detail that stuck with me was that the customer was a non-technical founder who had no separate backup. The agent had been both the development team and the operations team. There was no second pair of eyes in the loop to insist on one.
This is the failure mode the deployment surveys don’t capture. The surveys count launches. They don’t measure whether anyone could put the application back together after it broke, or whether anyone would notice if it began silently returning the wrong answer.
Two years from now I expect a non-trivial number of companies will discover that the operational reporting their CFO had been relying on was being computed by an application built by a manager who has since left. It will be hosted on an account whose credentials were tied to her personal email. It will be drawing from a Postgres instance whose schema had drifted three migrations past what the application expected. The application will continue to return numbers. The numbers will be wrong. Nobody will know they are wrong until an auditor asks how they were computed.
The conventional engineering response to all of this is some version of “this is why you still need real engineers.” I think the conclusion is right. The reasoning around it is wrong, in a way that doesn’t help the engineers making the case.
Engineers don’t earn their keep anymore by typing code better than the model. The model types code better than most of them, and that gap will widen. What engineers still do better is the unsexy stuff. Versioning. Blast-radius reasoning. Knowing the difference between the system that records what happened and the system that displays it. Building things that can be debugged by someone else in three years. Vibe coding as a workflow strips all of that out by design. That is part of the appeal, and it’s also why the engineering function is becoming more valuable, not less.
There is a symmetric implication here that mid-market executives don’t want to hear, so let me say it directly. The domain expert’s value has also moved. It used to be that knowing how the work flowed, where the exceptions lived, and which trade-offs the business could accept was a scarce input that engineers couldn’t generate themselves. The same models that have collapsed the cost of writing code have collapsed the cost of the inverse. A capable engineer with three afternoons in the warehouse, a transcription tool, and a Claude session can now extract a draft of the operator’s mental model that is sometimes better than what the operator can articulate. She can produce more usable domain knowledge in a week than a non-technical operator can encode in a quarter of vibe coding. Mid-market non-technical operators have been monetizing one advantage for two decades. They understood their business better than the consultants and engineers parachuted in to help them. That advantage is eroding faster than they realize, and the vibe-coding tools are accelerating the erosion rather than insuring against it.
So what do you actually do, given that your employees are already vibe coding whether you sanctioned it or not? The first thing to fix connects to the second.
The company that buys Claude or OpenAI licenses for everyone and lets the teams figure it out hasn’t deployed AI. It has deployed access to AI. They are different things. Most mid-market AI rollouts I see now are the second one. Procurement signs the contract. Comms announces it. Training is a one-hour webinar. Three months later the CEO asks me why nothing has visibly changed in the metrics he cares about. The answer is that nothing was set up to change. There was no decision about which workflows the tools were allowed to touch. No designated owner for the rollout in each function. No feedback loop into the engineering and product organization. No mechanism to harvest the prototypes that did get built into something the company actually owns. The tools were distributed in the same unstructured way Excel was distributed in 1995 and Slack in 2015. The fragmentation that resulted from those rollouts is the reason this one looks so familiar.
Governance of the proliferating applications matters, and the answer is roughly the same answer to the spreadsheet problem in 2010 that most companies still haven’t implemented. A register of which tools exist. What they touch. Who owns them. What happens when the owner leaves. The deeper question is harder. Which of your current employees are creating durable value by understanding the domain, and which are creating temporary value an engineering team with the right tooling can now extract in a fortnight? The answer for most operating roles in most mid-market companies is uncomfortable. The right response isn’t to encourage everyone to learn to vibe code. That’s the equivalent of telling people in 2003 to learn Excel, and the consequences of that earlier campaign are why I’m writing this. The right response is to invest in the function that turns domain understanding into systems the institution can own, govern, and hand off. That function used to be called product management married to engineering. Most mid-market companies never built it because the consulting industry promised to provide it as a service and didn’t, and most are now compounding the gap by mistaking weekend prototypes for the system the consulting industry was supposed to deliver.
The market narrative says AI is collapsing the cost of software. It’s collapsing the cost of producing one specific category of artifact within software, and that category turns out to be the part that was already cheapest. Knowing what to build. Knowing what not to build. Building it so someone other than the original author can keep it running. Noticing when it’s started returning the wrong answer. None of that has gotten cheaper. It has gotten rarer in proportion to how easy it is now to skip.
That’s the story I expect we’ll spend the next three years discovering, mostly by losing money in places where the discovery happens behind closed doors.
Five things to do this quarter
1. Inventory before you govern. Build a register of every internally-built tool that touches customer, financial, regulated, or operational-of-record data. Note what each one does, what it depends on, who owns it, and what happens when the owner leaves. The list will be embarrassing. That’s part of the point. Doing this now is cheaper than doing it after the auditor asks.
2. Stop treating AI licenses as a procurement decision and start treating them as a deployment program. A blanket Claude or OpenAI license, distributed without designated owners per function, without scoping decisions about which workflows the tools can touch, and without a feedback loop into engineering and product, produces fragmentation rather than productivity. Most rollouts I see now are this version, and most of them will return zero or negative measurable improvement on the metrics the CEO cares about. The fix is structural: a named owner per function, a list of in-scope and out-of-scope workflows, a recurring review of what got built, and a path for promoting useful prototypes into systems the company actually owns.
3. If you’re a senior leader vibe coding around your own organization, name the actual problem. The problem isn’t that you can’t get the tool. The problem is a vendor management failure or an IT leadership failure, and the cost of your time coding around it is roughly an order of magnitude higher than the cost of fixing it. The opportunity cost is the work you were hired to do. Fix the underlying problem, and have someone whose time costs less build the tool.
4. Treat every weekend prototype as a specification, not as the production system. A vibe-coded application that demonstrates a workflow is genuinely useful. It tells your engineering function exactly what the operator needed, with a fidelity no requirements document achieves. The distinction between treating it as evidence and treating it as the production deployment is what separates a $25 dashboard from a $500,000 rebuild.
5. Build the function that turns domain understanding into durable systems. This used to be called product management married to engineering. Most mid-market companies never built it because the consulting industry promised to deliver it as a service and didn’t. Until that function exists in-house, or is genuinely contracted as an ongoing capability rather than as a project, every other action on this list will degrade over time.