Goldman Sachs took Claude Code away from most of its bankers and traders. That is what Bloomberg reported, and I think the decision is defensible. What interests me is what the restriction does not fix: the code those people already wrote, and the need that led them to write it.

If you have pulled an AI tool from a team, or you are about to, this is the part that tends to get skipped.

What Bloomberg reported

On November 2, Todd Gillespie reported for Bloomberg News (here in the version FA Magazine republished) that Goldman barred most bankers and traders from advanced AI coding tools after reviewing productivity and risk concerns. They had been allowed to use Anthropic’s Claude Code and Microsoft’s GitHub. Under internal guidance updated in October and seen by Bloomberg, that use is now limited to engineers.

Some traders had used the tools to follow client trading flows, model market changes and positions, and produce written and graphic content. The move irritated some staff. It does not apply to strats, who work where trading, quantitative research and software engineering meet.

Spokesperson Nick Carcaterra said the firm tests AI tools and then gives them to the people best placed to use them, and cited productivity and risk management. He did not say more, and in what I could read of the report there is no specific incident behind the change.

There is a contrast worth keeping. In July, CIO Marco Argenti praised vibe coding (describing software to an AI in plain language and letting it write the code) by non-technical staff. According to Bloomberg, what they made was passed to one of Goldman’s 12,000 engineers to improve. So the bank had a path with an owner at the end. What changed in October, as I read it, is who is allowed to start down that path.

What is still standing after you switch the tool off

Two things. The guidance fixes neither.

The first is the code. A trader who built something to follow client flows left it running somewhere. It does not vanish because its author can no longer open Claude Code. Somebody has to know it exists, what data it reads, and what happens when it breaks on a Monday morning.

The second is the need. Nobody builds a flow monitor for fun. They built it because the job asked for it. Switch the tool off, leave the need in place, and people solve it another way, for instance with a personal account nobody approved. I wrote about that pattern in the piece on shadow AI, employees using AI without permission.

I don’t know what Goldman did about either. Bloomberg doesn’t say, and I won’t guess. I’m describing what happens to any company in this position, whether it’s a very large bank or a hundred-person firm.

What I would do before switching anything off

I’ve been programming for 36 years, since 1990, and I use Claude Code every day. What follows is opinion.

Start with a record of uses. Before you withdraw the tool, ask each person what they used it for and what they built. Knowing what each tool does and how many people lean on it gets you most of the way; the data it touches is the next thing to find out. Do it afterward and you’ve lost half the answers, because the person who knew has moved on or forgotten.

Then a named engineer for every non-engineer build. Not “the IT team”. One person who can explain it and who decides whether it’s kept, rewritten or retired. It’s the same issue as code nobody can explain: whether the code is good matters less here than whether anyone answers for it.

Then a route for the need. If traders and bankers needed to watch flows or model positions, that demand goes into a backlog someone prioritizes, with a date. Otherwise the ban just moves the problem somewhere you can’t see it.

And one change underneath all this: cost no longer slows anyone down. A person with no approved budget can stand up an agent in an afternoon, as I argued in the piece on cost as a guardrail. Restricting by role is a sensible answer. On its own it falls short.

What IQ Source does

Our Technology Partner service puts a named engineer in charge of whatever the business builds with AI, including what people who don’t code put together. The first thing we do at the start is the record of uses: which tools exist and who made them.

Then comes the decision that sometimes stings: some get kept and hardened, and some get switched off. With that in hand, the rule about who can use which tool is far easier to write, and it holds up better.

If your company already has tools built with AI by people outside engineering, start with the list. How many there are, who uses them today, and who each one belongs to. I would do it this week, before next quarter makes it longer.