In July, Goldman Sachs' CIO was publicly championing vibe coding for non-technical staff. By October, Claude Code and GitHub Copilot were for engineers only. That is not a bank stepping back from AI. It is what happens when experimentation meets production, and every regulated firm will meet the same line.
Key takeaways
- Goldman has drawn a line, not left the field. AI coding tools now sit with engineers; the business keeps AI, but not the job of building its own software with it.
- Vibe coding in a bank creates six problems at once: wasted expert time, ungoverned builds, no audit trail a regulator would accept, no view of ROI, single-vendor risk and data exposure.
- The answer is a governed layer between the business and the models. Workflows configured once and run the same way every time, with an audit trail, metering and a choice of model behind every step.
- If the largest banks need that layer, smaller firms need it more. They have a fraction of the engineering capacity to clean up after a thousand personal scripts.
What is vibe coding?
Vibe coding is building software by describing what you want to an AI coding tool in plain language and accepting the code it writes, often without reading or testing it line by line. It lets someone with no engineering background produce a working script or app in an afternoon. In a bank, that script then runs alongside regulated processes, usually with nobody responsible for it once it works.
What did Goldman Sachs change?
In October, Goldman Sachs restricted Anthropic's Claude Code and Microsoft's GitHub Copilot to its engineers, and most other staff, including traders and bankers, lost access. Bloomberg reported the change on November 2, citing internal guidelines. A Goldman spokesperson pointed to "a variety of factors including productivity and risk management," said the tools would go to the people "best suited to leverage them for the long term," and signaled that the experimentation phase was over.
Four months earlier the message had been different. In a July interview, Goldman's CIO Marco Argenti praised vibe coding by non-technical staff: a trader or portfolio manager would prototype a tool with AI and hand it to an engineer to take into production. That model no longer applies.
This is not Goldman stepping back from AI. It is one of the most technically capable banks in the world deciding where AI-assisted building belongs. A coding tool in everyone's hands turns out to create six problems at once.
What are the risks of vibe coding in a bank?
Vibe coding in a regulated firm turns every user into the unreviewed developer, tester and owner of their own system, and the firm inherits the risk of every one of them. Six problems arrive together.
1. Wasted time
Highly valued people end up debugging scripts instead of doing the work they were hired for. A trader, an analyst or an operations lead who spends an afternoon fixing a broken prototype has not saved time; they have moved it from their job to an engineer's job, without an engineer's tools.
2. Ungoverned implementations
Every build is a system with no review, no testing and no owner once its author moves on. In most firms this is already a known risk under another name: end-user computing. AI coding tools make it faster to create and harder to see.
3. No audit trail a regulator would accept
Regulators expect a bank to show how any output behind a decision was produced: the data, the logic and the checks. A personal script cannot show that, and the exposure sits with the bank, not with the person who wrote it.
4. No line of sight on ROI
Thousands of small builds, and nobody can say what any of them cost or returned. A firm cannot scale what it cannot measure, and it cannot defend a budget line it cannot read.
5. Single-vendor risk
In April, Goldman cut off access to Anthropic's Claude for its staff in Hong Kong. Any process that depends on one provider can be switched off with it. We set out why that dependency is a risk finance has not yet priced in AI third-party risk in finance: the counterparty risk nobody has priced: when one model provider holds a firm's data and runs its workflows, it is a counterparty, and it deserves the same discipline as any other.
6. Data exposure
Firm and client data end up spread across thousands of sessions and scripts, with no central view of where it went, which model saw it, or under what terms.
Why did we build Romina Day for this moment?
Two years ago, we set Romina Day up on a simple bet: institutions would not let their operations people become part-time developers for long, but they would still need a governed way to put AI to work. We have been making that case ever since, piloting, deploying and prototyping with some of the world's largest banks, asset managers, foundations and regulators.
We are now seeing it play out. Firms that handed AI tools to the business are coming back to us for something governed. One of them is a global bank with thousands of engineers of its own, which has leaned on us to help with NAV oversight. Engineering capacity was never the constraint. Governance was.
What does governed AI look like in practice?
Governed AI is a layer between the business and the models in which workflows are configured once, run the same way every time, and leave a record of what was done, by which model, at what cost. At Romina Day that layer is MATES, our multi-agent teams: a MATE is a configured team of AI agents that runs one workflow to the firm's own method.
- Configured once, centrally. Workflows are built around how the operations team already works, and run the same way every time, whoever starts them.
- An audit trail built for regulatory scrutiny. Every run records the inputs, each step, the model used and the output, all traceable to source.
- Metered. Every run is counted, so the firm sees what each workflow costs and what it gives back.
- Model-agnostic. The firm decides which models and endpoints see its data, and can change provider without reconfiguring a process. See why the model is not the product.
- Called from the tools people already use. People can call MATES from the AI tools they already have, while execution, governance and reporting stay on the platform, under ISO 27001 and SOC 2 Type II controls.
Personal scripts versus governed workflows
| Vibe-coded personal script | Governed workflow (MATE) | |
|---|---|---|
| Who does the work | The person who built it, debugging between their real work | The operations team runs a workflow configured once, centrally |
| Review and ownership | No review, no testing, no owner once the author moves on | Reviewed and tested before go-live, owned by the firm |
| Audit trail | None a regulator would accept | Inputs, each step, the model used and the output, traceable to source |
| Cost and return | Unknown, spread across thousands of builds | Every run metered: cost and return per workflow |
| Model dependency | Wired to one provider; switched off with it | Model-agnostic; provider changed in configuration |
| Data | Copied into sessions and scripts, no central view | The firm decides which models and endpoints see it |
What does this mean for firms smaller than Goldman?
If the largest banks need that layer, firms with a fraction of their engineering capacity need it even more. A bank with thousands of engineers can absorb the cleanup of a few thousand personal scripts. An endowment, an asset manager or a wealth platform with a handful of technologists cannot, and its regulators and auditors will ask the same questions.
The answer is not taking AI away from the business. It is giving the business AI that has already been through the controls.
Common objections
"Our engineers can take the best prototypes into production."
That was the July plan, and it is the part Goldman has now set aside. Engineers inherit code written to a different standard, with no specification, no tests and an author who has moved on to the next idea. A governed layer starts from the operations team's process instead, so there is nothing to rescue.
"We already govern Claude and Copilot centrally."
Governing access is not governing output. A central license tells you who can use a tool. It does not tell you which scripts it produced, what data they touch, what they cost or how their last result was reached.
"Isn't this selling against the AI labs?"
No. MATES run on models from the leading labs every day, and the business keeps calling AI from the tools it already uses. The question is where execution and evidence live: with the firm, or in a personal session with one provider.
Where should a firm start?
Start with the scripts and prototypes the business has already built. Pick the one that matters most, usually a review, reconciliation or reporting task that runs every month, and ask four questions: who owns it, what data it touches, which model it depends on, and whether you could show a regulator how its last output was produced. If any answer is "nobody knows," that is the first workflow to put on a governed footing.
If that sounds like your firm, it is worth thirty minutes on one workflow. Nothing to prepare, nothing to sign.
Are you seeing the same line drawn inside your own firm?
