Vibe-coded applications aren’t a new enterprise risk. They’re the same old problem, now running at AI speed.
In July, Goldman Sachs’s CIO was singing the praises of vibe coding. Traders and bankers were using AI to turn ideas into working prototypes, then handing them to the firm’s roughly 12,000 engineers to refine. By October, the rules had changed. Goldman restricted access to Claude Code and GitHub’s coding tools to engineers, leaving most traders and bankers without access. The bank cited productivity and risk management concerns. That’s all we know about its reasoning. I’m not going to pretend I know what was in that review. I don’t need to. I’ve seen this movie at every enterprise I’ve worked at.
When applications built by business users fail, it’s rarely because their authors lacked the ability to build them. The failure comes when a personal productivity tool quietly becomes something the business depends on, without anyone recognizing that the rules need to change. Engineering’s advantage isn’t simply better developers or better coding practices. It’s the discipline of having controls around change. Every change goes through a gate, every time. And that gate exists for a reason.
From spreadsheet to production
Business users have been building software for as long as enterprises have had PCs. They just never called it software. They called it a spreadsheet. A macro. An Access database on a shared drive.
At one company I worked at, the practice even had an official name: RAD – Rapid Application Development. The pitch was the same one we’re hearing today. The business knows the problem best, so let the business build the solution. I have no problem with individuals building tools that make their day-to-day work easier. The problem isn’t that someone built an application outside engineering. The problem is that the organization started depending on it without recognizing that it had become an application requiring engineering discipline.
RAD ran on a shared Microsoft SQL Server, with Access forms on the front end connected directly to its tables. The business got a quick onboarding solution, and initially, it was a genuine win. Then, as businesses tend to do, things changed. New processes emerged, but the forms couldn’t keep up. The application couldn’t scale to a global user base. There was no automated testing, either. Fixes were quick. So were the regressions. The same bugs kept coming back because nothing checked a change before another user discovered what broke.
Risk and audit have less flattering names for these applications: End-User Computing (EUC) and User-Developed Applications (UDAs). Every enterprise I’ve worked at has tried to rein them in. None has managed to eliminate them. You can’t ban Excel. You can only inventory it and hope. The path from desktop convenience to production dependency rarely changes. Someone builds a tool for themselves. It’s useful, so a colleague borrows it. Then the desk adopts it. A downstream report starts consuming its output. Every step is small and reasonable. None seems significant enough to trigger an engineering review.
Nobody ever makes a formal decision to put the tool into production. One morning, it’s simply there
Nobody publishes reliable data on why user-developed applications fail, and we tend to hear about only the spectacular failures. But in the best-documented examples (e.g., Excel partly to blame for trading loss), the author’s ability to build the application wasn’t necessarily the problem. What was missing was a point at which someone else had to review it. To be fair, enterprises have tried to identify that point. There’s an entire category of software designed to crawl file shares, discover spreadsheets, inventory user-developed applications, and classify them by risk. But these inventory strategies are reactive response. It tells you what exists after the fact, often after the application has become something the business depends on. It identifies risk through discovery, not at the moment the risk is created.
Meanwhile, the regulatory perimeter is changing, and perhaps not in the direction you’d expect. In April 2026, U.S. banking regulators replaced SR 11-7 with SR 26-2, a revised model risk management framework. Among other changes, the new guidance explicitly excludes simple spreadsheet calculations and deterministic software from its definition of a model. The shift toward a more risk-based approach is understandable. Not every spreadsheet deserves the same scrutiny as a complex financial model. But there’s an important distinction between something no longer qualifying as a model and something no longer presenting a business risk. The regulatory definition may be getting narrower just as the number of applications being created is about to get a whole lot bigger.
When the number looks right
That case was the London Whale. If you’ve worked anywhere near a trading floor, you probably know how this ends. In 2012, JPMorgan’s Chief Investment Office lost approximately $6.2 billion on a synthetic credit portfolio. The bank’s own task force report, as excerpted by James Kwak, described a new value-at-risk model built around a series of Excel spreadsheets. Let that sink in, “a series of Excel spreadsheets”. Data was entered by hand, then copied and pasted from one spreadsheet to another. Somewhere along the way, one formula divided by the sum of 2 rates instead of their average. The result understated reported volatility by roughly half, lowering the VaR calculation along with it.
A basic statistics error. Billion-dollar consequences.
I would argue that spreadsheet didn’t cause the trading losses. The Senate investigation found that risk limits had been breached hundreds of times and that the model change was used to make those breaches less visible. People made the trades. The spreadsheet played a different role: it made an increasingly risky position look safer than it was. Sounds familiar? The same danger exists with AI-generated software. A result that looks plausible can be more dangerous than one that obviously fails. It earns trust before anyone has established that it deserves it.
The model wasn’t simply some rogue spreadsheet operating in the shadows. It had been reviewed. JPMorgan’s Model Review Group approved it, while explicitly recommending that the process be automated and another significant flaw be corrected. Neither recommendation was implemented. The manual copy-and-paste process continued, and the underlying problems remained. First, the error worked in the direction everyone wanted. As Kwak pointed out, if the model had doubled volatility instead, the resulting VaR would have likely blocked the trades. Someone would have torn that spreadsheet apart to find the problem. Nobody debugs when something looks plausible. Second, the person who built the model wasn’t an amateur. The task force report described a quantitative expert and mathematician, although someone without prior experience building a VaR model who also lacked sufficient support.
The problem wasn’t an inability to write a formula. It was the absence of enough independent scrutiny, effective controls, and follow-through to catch what the formula was telling the business. Skill wasn’t absent. It just wasn’t enough.
The gate is the discipline
Promotion isn’t a 1-time sign-off. It’s a discipline repeated with every change. Every change has an author, a diff, an independent reviewer, and automated checks before it reaches production. Promotion is deliberate, with a record of who approved what and when. None of this assumes the author is incompetent. It assumes they’re human. And humans need independent checks, not just confidence in their own work.
Before any engineers get too smug, though, this isn’t an engineers-versus-everyone-else argument. Engineering code finds its way into production without discipline, too. Every team has that 1-off script that quietly became a nightly job, or the cron task nobody remembers writing but everybody is afraid to delete. The gate is a practice. Skip it, and engineers create user-developed applications of their own.
In The Shorter Path, I argued that engineers are better positioned to take on the product-engineer role because they bring the judgment to distinguish a working product from a working demo. I still believe that. But judgment and discipline aren’t interchangeable. You need both. An engineering’s advantage is skill combined with a gate. The London Whale is what happens when you have the former without enough of the latter.
Same risk, different name
Vibe-coded applications are the next generation of user-developed applications. Same author: a business user who knows the problem and doesn’t want to wait in the engineering queue. Same path to production: built for one, borrowed by a desk, suddenly running in critical production process. But two things have fundamentally changed.
The speed
A spreadsheet generally needs someone to interpret its output and act on it. A vibe-coded application doesn’t necessarily need that intermediary. It can call APIs, read production data, modify records, write files, and initiate transactions. Excel needed a human to act on its mistakes. An AI-powered application can act on its own.
The reach
A spreadsheet calculates. It only causes damage when someone reads the result and acts on it. A vibe-coded application doesn’t necessarily need that intermediary. It can call APIs, read production data, modify records, write files, and send transactions. Excel needed a human accomplice. AI Agents doesn’t. The most dangerous artifacts are often the ones that fail silently. A UDA rarely crashes. It simply gives you the wrong number with complete confidence. A vibe-coded application can take that same wrong answer and send it straight to an API.
The wrong line to draw
Look at Goldman’s decision again. The restriction is drawn by title: engineers keep the tools; most traders and bankers lose access. As stated earlier, an engineer’s job title isn’t what makes their code safer. It’s the engineering discipline the code goes through. Read that way, a job title is merely a proxy for something harder to capture on an organizational chart: whether the work is reviewed, tested, and deliberately promoted into production by default.
The original arrangement deserves a closer look, too. Traders build prototypes; engineers refine them. On paper, that sounds like a sensible control. In practice, it’s the same handoff model enterprises have relied on for decades with user-developed applications. And the handoff is where things break down. A tool that works on Tuesday can become something the desk depends on by Friday. At that point, nobody sees a prototype that needs handing over. They see a working solution. Why involve engineering? It works. I don’t know if that’s what happened at Goldman. But I’ve seen this pattern often enough to recognize the organizational failure mode.
I’m not going to tell you whether Goldman drew the right line. That depends on information only Goldman has. Restricting access by job title is a proxy for shifting the risk. It sorts people by who they are, when the real risk depends on where their code goes, what it can do, and what controls it passes through.
The test is the gate
Take applications built by business users and sort them into two groups. One goes through an engineering gate on every change: version control, independent review, automated checks, and deliberate promotion. The other follows the traditional UDA path, gradually finding its way into production without those controls. Compare applications of similar complexity and business criticality. Measure not just failures, but their frequency, severity, and how quickly they’re detected. If the gated group performs no better than the ungated one, then we have a reason to question whether the gate is delivering the protection we think it is. I don’t expect that result. But I’d rather test the assumption than restrict access based on someone’s job title.
Vibe-coded applications will follow the same path. The difference is that they’ll get there faster, in greater numbers, and with the ability to act on what they produce.
The risk isn’t who writes the code. It’s what happens after they do.
