It sounds like a business’ worst nightmare, but letting employees code their own solutions to tech issues will solve more problems than it creates.
There is a particular joy known only to those of us who run technology in regulated financial services. It is the joy of receiving an email from a regulator that begins with the words “further to our review” and not immediately requiring a change of underwear.
We operate under the perpetual gaze of people whose entire professional purpose is to ensure we are running a tight ship. Change control, cyber security and data governance are not aspirational posters on our office wall. They are the reason half my team has a mildly haunted expression and flinch at the word “audit.”
We take operational security and stability extremely seriously, because the alternative is a conversation with a regulator that nobody wants to have, followed by a series of headlines that nobody wants to read.
So you can imagine the general mood when the phrase “vibe coding” first drifted into the building.
The backlog of broken dreams
To understand why vibe coding genuinely matters, and isn’t just another Silicon Valley fever dream, you need to understand how things used to work. Actually, scratch that; it’s how things still work in most large organisations.
Someone in operations has a problem. Perhaps they’re wrangling a spreadsheet so monstrous it has its own postcode. Perhaps they need a small dashboard to track something that currently involves copying numbers from three systems into a fourth while silently questioning their life choices. Perfectly reasonable. Easily solved, in theory.
So they raise a request with the technology team. A business analyst is assigned to understand the requirement. Meetings are held. Requirements are documented. The work is then lovingly placed onto the backlog, that great elephant’s graveyard of good intentions, where it takes its place behind 247 other tickets, each one representing someone else’s operational misery.
Months pass. Seasons change. The person who raised the request has either left the company, been promoted, or simply given up and built something horrifying in Excel with nested VLOOKUPs that would make a grown developer weep.
Now, I want to be clear: this is not a damning indictment of technology teams. I run one, so that would be a spectacularly poor career move. Technology is an expensive resource, and it needs to be spent wisely. When you have a choice between helping one person fix a spreadsheet and building a feature that 200 clients are actively requesting, the maths is not complicated.
The person with the spreadsheet isn’t wrong to be frustrated. The technology team isn’t wrong to prioritise elsewhere. It’s just that the economics of bespoke internal tooling have, historically, been brutal.
Until now.
Enter the vibes
Vibe coding, for those mercifully unfamiliar with the term, happens when you tell an AI what you want, and it writes the code. No computer science degree required. No three-month onboarding into the codebase. You explain your problem in plain English, the AI produces something functional, and you iterate from there.
At EXANTE, we’ve made a deliberate decision to encourage our staff to experiment with these tools. All of them. Not just the developers. The operations team, the compliance team, the middle office — anyone with a problem that could be solved with a small, purpose-built utility. We want people building their own tools and dashboards. We want them solving their irritations rather than waiting 18 months for a ticket that may never be called.
This is, of course, the point at which every compliance officer within a three-mile radius develops a nervous twitch. And, frankly, they’re right to.
The guardrails, or why we can’t have nice things (without governance)
Letting over 700 people loose with AI coding tools in a regulated brokerage without guardrails would be catastrophically stupid. So we’re not doing that.
What we are doing is building the infrastructure to make it safe, controlled and (here’s the radical bit), useful.
First: the APIs. If people are going to build tools that interact with our systems, they need proper, governed internal APIs to do it through. Not direct database access. Not CSV exports emailed to a shared mailbox. Controlled, authenticated, authorised access points that know exactly who is requesting what data and, crucially, who is not authorised to see it.
In a regulated business the spectre of data exfiltration, information leaving the building when it absolutely shouldn’t, keeps people like me awake at night. Quality APIs with proper access controls are not a nice-to-have. They are the foundation upon which everything else must be built.
Second: somewhere to put the stuff. Vibe-coded tools need a home. They need to run somewhere sensible, be maintained, and not end up as a rogue process on someone’s laptop that everyone has quietly forgotten about until that person goes on holiday and something important stops working. We are creating managed environments where these small utilities can live, breathe and be looked after.
Third (and this one has been a revelation): Git. We insist that all vibe-coded work goes into version control. “But they’re not developers!” I hear you cry. No, they’re not. And that is precisely why they need it.
Here is what we’ve learned from early experiments: an inexperienced vibe coder starts with a general idea of what they want. They describe it. The AI builds something. They refine it. The AI adjusts. They refine further. And then, somewhere around iteration 15, they find themselves down a blind alley with no idea how they got there and no way back.
So they do what any reasonable person does — they delete the lot and start again, losing everything that was working.
Git solves this. It lets them see every change, understand what happened, and revert to a previous good state before striking out in a new direction. It is, in effect, an unlimited supply of “undo” buttons for people who desperately need them. Getting this right is one of the most important things we’re doing.
Fourth: sharing. Someone builds a brilliant little tool that solves their problem. Lovely. But there’s a very good chance that 15 other people in the organisation have the exact same problem and are each currently solving it on their own with the same grim determination and the same questionable spreadsheet.
We need a way for people to share what they’ve built, discover what others have made and adapt existing projects for their own needs. This is where the real acceleration happens. Not in the initial creation, but in the compounding effect of every tool becoming a starting point for the next one.
The uncomfortable truth
There is a certain breed of technology leader who will tell you, with great confidence, that vibe coding is a fad, that non-developers have no business writing code, and that this will all end in tears. I understand the instinct. I share some of the concerns. But I also know what the alternative looks like, because I’ve been staring at it for years: an ever-growing backlog, an ever-frustrated business, and an ever-widening gap between what people need and what technology can deliver.
Vibe coding doesn’t replace developers. It won’t build your trading platform or your settlement engine. But it might — just might — mean that the person in operations finally gets that dashboard they asked for three years ago. And that the compliance team can stop pretending their thirty-seven-tab spreadsheet constitutes a monitoring solution.
The trick, as with most things in a regulated business, is not to say no. It’s figuring out how to say yes without setting the building on fire.
We’re working on it. The regulators are watching. And I’ve checked — I have clean underwear in my desk drawer. Just in case.
Richard Forss is CTO of EXANTE, a business of over 700 staff, where he leads a technology team of 230 and an ever-expanding collection of governance frameworks.
This article was written by FM Contributors at www.financemagnates.com.
Source link
