Vibe Coding: The New UDAs, But Faster

Why democratized AI development risks repeating the spreadsheet governance failures of the past

Eight PCs and sixteen screens

I once watched a warrant market maker in Sydney run eight PCs with sixteen screens.

Not because the trading was complex. Because he was running a spreadsheet.

A Frankfurt desk had built it years earlier to price European warrants. It worked well enough. It was sent to the Sydney desk when they were starting a similar warrants business. Then they added more warrants, everything on the PC slowed down. So they bought more hardware. Eight PCs. Sixteen screens. Diminishing returns masquerading as a solution.

The original developer? Gone. No documentation. No handoff. No governance.

When the spreadsheet went wrong due to a discrepancy in the data feed for the underlying equity prices caused the trader to get picked off in the market there was no one to call. The original trader-developer had left the bank and the knowledge walked out the door with him.

This is the User Developed Application (UDA) problem. It could be about to get a lot worse.

The promise of vibe coding

Enter “vibe coding.”

The pitch is seductive: describe what you want in plain English, let AI generate the application. No developers. No sprints. No months of procurement. Just ideas, executed.

“Build me a tool that prices Asian warrants using Bloomberg data, applies our house volatility surface, and outputs to Excel.”

Minutes later, you have code. It runs, it works. I’ve done it myself recently, refer to my recent post on my website rebuild.

And for some use cases? This is genuinely transformational. Quick automation scripts. Internal tools. Prototypes. Proof-of-concepts. The kind of things where “good enough today” beats “perfect next quarter.”

The democratisation of development is real. The barrier to building has never been lower.

But.

The governance gap

Here’s what I worry about.

That warrant spreadsheet wasn’t built by someone who hated governance. It was built by someone who needed to solve a problem quickly. Who had market-making responsibilities and insufficient tooling. Who found a way to keep the desk running.

That’s the same psychology driving vibe coding.

The difference is speed. The Frankfurt desk at least had to understand Excel. They had to build formulas, structure sheets, think through cell dependencies and circular references. It took days or weeks. That friction was actually protective — it gave time for questions to be asked.

Vibe coding removes the friction. A trading desk can describe a pricing model in plain English and have a “working” application in minutes. Not weeks. Minutes.

Which means the governance gap, the time between “someone built something” and “someone noticed it needs governance” shrinks from months to hours.

By the time a technology risk team discovers the tool, it’s already critical. Already has data flowing through it. Already has traders whose workflows depend on it. Already has compliance exposure.

This is how you end up with the spreadsheet problem, but faster and more distributed.

What went wrong (and keeps going wrong)

The compliance failure with the Frankfurt spreadsheet wasn’t the tool itself. It was that nobody asked:

• Who owns this application?
• What’s the handoff process when the builder leaves?
• How do we support it when original knowledge is gone?
• What happens when market conditions change and the logic needs updating?
• Where’s the documentation, the audit trail, the data lineage?
• How do we retire it?

These are boring questions. They’re bureaucratic questions. They’re also the questions that prevent panicked calls about broken pricing tools and difficult to explain P&L hits.

The same questions apply to vibe coding. But now you’re asking them after the application is already in production. After the trader has already built his workflow around it. After replacing it means disrupting live trading and explaining to management why something that “worked fine yesterday” needs to be rebuilt by actual developers.

A framework for moving fast without breaking things

I’m not arguing against vibe coding. The genie is out of the bottle. Business users will build applications with AI because they can, and because often they should.

I’m arguing for governance frameworks that move at the same speed.

If your organisation lets business users build applications with AI (and increasingly, they will) you need four things.

Visibility: know what’s being built

This doesn’t mean a committee approving every prototype. It means a registry. A lightweight system that tracks what’s being built, by whom, for what business purpose, using what data, and with what outputs.

Not for blocking, for knowing. So, when something breaks or when audit asks you have context.

Ownership: define who supports it

The biggest failure mode for UDAs was always the knowledge vacuum. Someone builds something, leaves, and now no one knows how it works.

Vibe coding needs explicit ownership rules. Who is responsible when the AI-generated code breaks? Who understands the business logic enough to debug it? Who approves changes?

If the answer is “the person who built it,” you have a single point of failure. And in markets, single points of failure eventually fail.

Standards: set guardrails, not roadblocks

Not every vibe-coded app needs enterprise architecture review. But some things should be automatic:

• No production data in unapproved environments
• No external connectivity without security review
• No market data team without onboarding and approval
• No handling of PII or MNPI without compliance sign-off
• No deployment to shared infrastructure without basic testing

These aren’t heavy processes. They’re guardrails. They’re the difference between “move fast” and “move fast and break regulatory compliance.”

Sunsetting: plan for retirement

Most UDAs didn’t fail. They faded. They became obsolete but kept running because no one knew if they were still needed. They accumulated. They became technical debt.

Vibe coding will accelerate this. More applications, shorter lifespans, faster obsolescence.

You need a retirement strategy. How applications get turned off, not just turned on. How you know when something that was critical six months ago can be safely deprecated today.

The real question

The Sydney warrant trader with eight PCs wasn’t foolish. He was resourceful. He found a way to keep trading despite his tool, not because of it. He kept the desk operational through ingenuity and hardware.

Vibe coding will create thousands of similar situations. Clever people solving real problems quickly. Applications that work until they don’t. Knowledge that walks out the door when the user moves on.

The question isn’t whether to allow vibe coding. The question is whether your governance can keep up.

If someone on your desk vibe-coded a pricing tool this morning, how would you find out?

If you’re not sure, that’s where to start.