Goldman Sachs restricts AI coding tools to engineers

Goldman Sachs has reportedly pulled advanced AI coding tools away from most employees, limiting access to engineers after months of wider experimentation. The move matters because it shows how quickly enterprise AI rollouts can shift from open testing to tighter governance when productivity and risk concerns enter the picture.

According to The Decoder, citing a Bloomberg report based on internal guidelines from October, traders and bankers had used tools such as Claude Code and GitHub Copilot to monitor trading flows and create content. Now, only engineers can continue using them.

Goldman moves from experimentation to control

The rollback marks a change in tone from earlier enthusiasm inside the firm. In July, Goldman CIO Marco Argenti spoke positively about “vibe coding” by non-technical staff, according to the report. The idea was that a trader or asset management employee could turn an idea into a quick AI-built prototype, then pass it to an engineer to make it production-ready.

That workflow now appears to be off the table for most non-engineers. The Decoder reports that the decision has caused frustration within Goldman, although the source does not describe the scope of that frustration or name specific teams affected.

Goldman spokesperson Nick Carcaterra told Bloomberg that the change reflected “a variety of factors including productivity and risk management.” He also said the experimentation phase had ended and that the firm is now restricting the tools to employees best positioned to use them over the long term.

For large companies, that is the key signal: AI coding tools may be welcomed during a pilot phase, but access can narrow once leadership decides the tools need clearer ownership, review and accountability.

Why non-engineer coding is harder to govern

The reported Goldman approach highlights a tension many businesses face. AI coding assistants can help non-technical employees sketch ideas, automate small tasks or produce rough prototypes. But the same flexibility can create questions about code quality, oversight and where responsibility sits when something is used in a real business process.

The source does not say whether any specific incident triggered the Goldman change. It does, however, name productivity and risk management as factors cited by the company. That distinction matters: the issue is not simply whether AI coding tools can produce useful work, but whether the organization has a reliable way to manage that work.

For creators, marketers, freelancers and small businesses, the practical lesson is not that non-engineers should avoid AI coding tools. It is that AI-built scripts, dashboards and workflow helpers need a path from experiment to review. If a prototype touches customer data, business-critical processes or regulated information, the person who prompted it may not be the right person to approve it.

A simple policy can help smaller teams avoid the same kind of abrupt reversal:

• Decide who can use AI coding tools for experiments.
• Define what counts as production use.
• Require technical review before AI-generated code affects customers, money or sensitive data.
• Keep a record of what a tool was used to build and who reviewed it.

What this says about enterprise AI rollouts

Goldman’s reported decision fits a broader pattern in enterprise AI adoption: companies often start by encouraging experimentation, then narrow access once real workflows and risk questions emerge. That is especially true for tools that can generate code rather than just draft text.

GitHub Copilot is already a familiar coding assistant for developers, while Claude Code is part of a growing category of AI tools aimed at helping users work with software projects. Emonarc readers comparing developer-focused assistants may also find our Cursor vs GitHub Copilot guide useful for understanding how coding assistants are positioned.

The Goldman case is also a reminder that “AI for everyone” can mean different things inside different companies. A bank may allow broad use of chatbots for general drafting or research while restricting tools that produce executable code. The source does not say what other AI tools Goldman employees can use, so the reported change should be read narrowly: it concerns advanced coding tools and access by non-engineers.

The timing is notable because the earlier workflow described by Argenti depended on collaboration between business staff and engineers. Non-technical employees could prototype, but engineers would handle scaling for production. Goldman’s new guidelines, as reported, appear to move the starting point back toward engineering teams.

What teams should watch next

The immediate question is whether other large enterprises follow a similar path after their own AI coding pilots. The source only addresses Goldman Sachs, so it would be premature to treat this as an industry-wide policy shift. But it gives other organizations a concrete scenario to plan around.

If your team is rolling out AI coding tools, the Goldman report suggests three questions to answer early: who is allowed to build with them, what happens after a prototype works, and who owns risk when generated code is used in a live workflow.

That may feel slower than letting every employee experiment freely. But it is also less disruptive than granting broad access, building habits around it, and then pulling tools back after expectations have already formed.