RPLCED
Client loginBook a call
Menu
← All posts

Goldman Sachs pulled Claude Code from its bankers - what it means for automations built by non-engineers

Goldman limited Claude Code and GitHub coding tools to engineers. The real lesson is about who owns the automations staff build.

Goldman Sachs has taken Claude Code and Microsoft's GitHub coding tools away from its bankers and traders. Bloomberg reported on 2 November that, under internal guidance issued in October, the tools are now for the bank's engineers only.

For months before that, non-technical staff had been using them at work. According to Bloomberg, traders used them to monitor client trading flows and to produce written and graphic material. Some of them are reportedly unhappy about losing access.

What Goldman actually said

Not much. A Goldman spokesperson, Nick Carcaterra, told Bloomberg the tools were made available to find the best use cases across the firm, and that after an experimentation period, weighing factors including productivity and risk management, they go to the people best placed to use them over the long term. No incident was disclosed. No numbers on what the experiment produced were published.

The reversal is the interesting part. In July, Goldman's CIO Marco Argenti praised "vibe coding" by non-technical staff in an interview. His model was simple: a trader or someone in asset management builds a quick prototype with AI, then hands it to one of the firm's roughly 12,000 engineers to make it production-grade. The Decoder, which covered the restriction, says that is no longer the plan.

Goldman is not alone in tightening up. PYMNTS notes that JPMorgan has said outside AI agents will not be allowed inside the bank, Citigroup has taken the same line, and Bank of America is limiting what agents can touch while it works out who is liable for AI-authorised payments.

Why the handoff model breaks

Read the July plan again. A non-engineer builds something, then an engineer turns it into something real. That sounds efficient. In practice it tends to fail in a predictable way.

The prototype works on the builder's laptop, with their login, on last week's data. It does one useful thing, so people start relying on it. Then the handoff never happens, because the engineers have a queue and the prototype already "works". Now the business depends on a script nobody reviewed, running under one person's credentials, with no log of what it did and no one who can fix it when the data changes shape.

Multiply that across a few thousand eager staff and you have hundreds of small, unowned automations. At a regulated bank, each one is a question an auditor can ask and nobody can answer. That is a reasonable thing to get nervous about, whatever Goldman's private reasons were.

What it means for a smaller business

You are not Goldman, and you probably do not have 12,000 engineers to hand prototypes to. That makes the problem sharper, not smaller. If an ops manager builds a workflow with an AI coding tool and it becomes load-bearing, there is often no one else in the building who can maintain it.

That does not mean non-technical staff should be kept away from these tools. They are often the people who know exactly which task is worth automating, and a rough prototype is the fastest way to prove it. The mistake is letting the prototype quietly become the production system.

A workable rule looks like this:

  • Anyone can prototype, on copies of data, with their own access.
  • Nothing touches customer data, money or another system on a schedule until someone accountable has reviewed it.
  • Every automation that runs unattended has a named owner, logs what it did, and runs under a service account, not a person's login.
  • If no one can be named as owner, it stays a prototype.

The honest caveat

We do not know why Goldman really did this. "Productivity and risk management" could mean a security scare, a compliance finding, or simply that the experiment did not produce enough to justify the licences and the review burden. Reading it as proof that non-engineers cannot build useful things with AI would be overreach. Reading it as proof that the tools are unsafe would be too.

It is also one bank. Highly regulated firms carry audit and liability costs that most businesses do not. If you run a ten-person company, your bar for review can be lighter. It cannot be zero.

What to do this week

Make a list of every automation, script or AI workflow currently running in your business, including the ones someone built on a Friday afternoon. For each, write down who owns it, whose credentials it runs under, and where its logs are. Anything with a blank in those columns is the thing to deal with first, either by giving it a proper owner and a review, or by switching it off before it fails on its own schedule.

Want this kind of system in your business? Book a free scoping call.