Goldman Sachs and the AI Builder's Paradox

In July 2026, Marco Argenti, Goldman Sachs’s chief information officer, enthusiastically described how traders and bankers were using artificial intelligence to develop their own tools. They identified a problem, built a prototype through vibe coding, then handed it to engineers to refine.

Three months later, the direction changed.

According to Bloomberg, Goldman Sachs revised its internal guidelines in October to limit access to Claude Code and certain GitHub tools to its engineers, with an exception for hybrid specialists known as strats. Employees who had been using these tools to track transaction flows, model positions or produce analyses now find themselves without some of their working tools.

The bank cites an assessment of productivity and risk. It also continues to develop its own artificial intelligence solutions.

This is therefore not a retreat from AI.

But the episode reveals a tension extending far beyond banking: companies want their employees to innovate with artificial intelligence, without necessarily adapting their organisations to what those employees can now do.

A decision that is entirely defensible

It would be too easy to portray Goldman Sachs as a conservative organisation that became frightened of innovation.

An investment bank is not an ordinary experimentation ground. Client data is sensitive, financial transactions are regulated, and certain information must remain strictly separated between different business activities.

Claude Code is not simply a conversational assistant. It is a tool that can read files, generate code and execute operations within the permissions it is granted.

There is a considerable difference between asking AI to summarise a financial report and allowing it to develop and then execute a program handling market data.

An incorrect model, poorly managed access or insufficiently controlled automation can have serious consequences.

Restricting the use of these tools can therefore be an entirely rational decision.

But a decision that is rational from a control perspective can also have undesirable consequences for innovation.

And that is where the case becomes interesting.

Employees have just discovered that they can build

For decades, application development has largely relied on a division of responsibilities.

Business teams expressed their needs. IT teams analysed them, prioritised them and developed solutions. Timelines depended on available resources, technical complexity and organisational trade-offs.

That separation had its reasons. It also had its limitations.

How many useful ideas never progressed beyond a request because they were considered too small, too specific or insufficiently important?

Generative AI changes part of that equation.

A sales manager, financial analyst or operations director can now describe a problem in their own language, explore different approaches and produce an initial prototype without mastering programming languages.

That does not make them a software engineer. Nor does it guarantee the quality or security of what they build.

But it profoundly changes their relationship with technology.

They no longer simply request a solution. They can participate directly in creating it.

This shift is potentially more important than the productivity gains usually associated with AI.

Because the people closest to a problem are often those who best understand its subtleties, exceptions and operational consequences.

They may not know how to build a reliable production-grade system. But they can now demonstrate much more quickly what is worth building.

The risk of governance arriving after innovation

One of the most revealing aspects of the Goldman Sachs case is its chronology.

In July, vibe coding initiatives were presented favourably. In October, access was restricted.

We do not know the details of the internal assessments that led to this decision. There is no basis for claiming that it resulted from a security incident, financial misconduct or a particular failure.

It would also be excessive to conclude that the bank had put no control mechanisms in place.

But this sequence of events raises an essential question: what happens when an organisation encourages experimentation before defining the conditions for scaling it?

Employees discover new uses, invest time, develop working methods and begin to see possibilities they could not have imagined a few months earlier.

Then the rules change.

Even when those rules are justified, the signal they send can be ambiguous.

On one hand, the organisation asks employees to be curious, enterprising and innovative. On the other, it can leave them feeling that their initiatives become problematic as soon as they extend beyond the scope originally envisaged.

The danger is not merely slowing down a few projects.

It is weakening the trust that experimentation requires.

An organisation seeking to develop initiative must be able to explain clearly where the boundaries lie, why they exist and how promising ideas can continue to progress.

There is a third way between unrestricted freedom and prohibition

The debate is often presented as a conflict between innovation and control.

That is the wrong way to frame the problem.

The real question is not whether all employees should have the same tools and permissions.

The question is how to design an organisation in which everyone can contribute to innovation at a level compatible with their skills, responsibilities and the associated risks.

That means distinguishing three stages.

These three stages require neither the same skills nor the same rules.

The role of governance is precisely to enable the transitions between them.

A prototype should not quietly become a critical application. But a worthwhile idea should not be abandoned simply because its creator has no IT training.

Between these two extremes, there is considerable room for new forms of collaboration between business teams and technical teams.

The real change also concerns leadership

This could be seen as a matter exclusively for CIOs, cybersecurity leaders and IT teams.

That would underestimate its significance.

When an employee can design a solution they would previously have had to request from another department, working relationships change.

Responsibilities must be clarified. Approval processes must be adapted. Managers must learn to assess initiatives that do not necessarily fit familiar categories.

And leaders must make trade-offs between objectives that can seem contradictory: accelerating innovation, protecting the company, developing autonomy and maintaining sufficient operational control.

These are not simply technology decisions.

They are leadership decisions.

They require a practical understanding of the tools, but also judgement, trust and a vision of the organisation one wants to build.

A company can distribute AI licences to thousands of employees without fundamentally transforming how it operates.

Conversely, an organisation that learns to surface, assess and develop its employees’ initiatives can transform its operations without endlessly multiplying its tools.

Transformation lies not in the number of people using AI, but in what the organisation learns to make possible through them.

What leaders should examine now

The Goldman Sachs case invites some very practical questions.

Do we know what our employees are already building with artificial intelligence, including outside officially identified projects?

Have we defined the difference between an individual experiment, a shared prototype and an application used in day-to-day operations?

Do business teams have a simple way to have their prototypes reviewed and seek technical support when an idea deserves further development?

Who becomes responsible for a solution once it moves beyond the experimental stage?

And above all, when we decide to restrict a tool, do we take time to understand the problems employees were trying to solve with it?

This last question deserves particular attention.

A restriction may be necessary. But the operational needs that led employees to adopt a tool do not disappear when it is restricted.

They remain.

Effective governance must therefore protect the organisation while preserving the learning generated by experimentation.

The challenge is no longer simply adopting AI

For several years, companies have sought to accelerate the adoption of artificial intelligence. They measure licences deployed, active users, hours saved and productivity gains.

These indicators have their uses.

But they do not answer a more fundamental question: are we building organisations in which individuals can genuinely take more initiative, learn and create value?

Goldman Sachs has not necessarily made a mistake by restricting certain tools. The risks associated with agents capable of writing and executing code justify rigorous governance.

The mistake would be to believe that returning to a strict separation between those who imagine solutions and those who build them is necessarily the definitive answer.

Artificial intelligence opens up a new possibility: bringing business experience closer to the means of creation.

That possibility does not remove the need for rigour. It demands more of it.

But it deserves better than a binary choice between total freedom and prohibition.

The companies that succeed in their transformation will not necessarily be those that give employees the most tools. They will be those that create the conditions for people to become responsible builders.

And that begins with a leadership decision, long before a technology decision.

The facts concerning Goldman Sachs are based primarily on Bloomberg’s reporting. The governance analysis, organisational interpretations and recommendations are those of Aligned in Motion.

Aligned in Motion — Executive Advisory · Leadership · AI

A place where experienced minds become builders.