Restrições da Goldman Sachs ao Claude Code Afastam Banqueiros da Criação de Suas Próprias Ferramentas

As restrições da Goldman Sachs ao Claude Code teriam removido o acesso a ferramentas de programação para banqueiros e traders, apesar do incentivo anterior para que funcionários criassem seus próprios aplicativos. A Bloomberg informou a mudança em 2 de novembro, citando orientações de outubro. A tensão imediata diz respeito a quem pode transformar um experimento útil em um software do qual colegas passem a depender.

Claude Code é o assistente de programação com IA da Anthropic, que ajuda usuários a criar e modificar software por meio de instruções em linguagem natural. Restringi-lo traça uma linha entre gerar um aplicativo funcional e assumir responsabilidade por seu comportamento. Essa linha agora coloca as equipes de engenharia da Goldman entre usuários de negócio e algumas ferramentas que antes eles próprios operavam.

O Morgan Stanley oferece uma comparação útil com assistentes desenvolvidos especificamente para consultores financeiros. A decisão relatada da Goldman pressiona uma abordagem diferente: permitir que funcionários montem suas próprias soluções antes que engenheiros as aprimorem. A questão em aberto é se um acesso mais restrito melhora a produtividade confiável ou torna mais difícil entregar trabalho útil.

O que as restrições da Goldman Sachs ao Claude Code realmente mudam

A mudança relatada restringe quem pode usar ferramentas de programação; ela não estabelece que a Goldman esteja abandonando a IA em todo o banco.

A Bloomberg afirma que as orientações de outubro limitaram essas ferramentas aos engenheiros, uma mudança noticiada em 2 de novembro. Sua reportagem sobre acesso a ferramentas de programação estabelece a cronologia da política.

Separadamente, a PYMNTS descreveu os produtos afetados como o Claude Code da Anthropic e as ferramentas de programação GitHub da Microsoft. Seu relato inclui especialistas quantitativos entre os usuários técnicos que mantêm o acesso. Essas distinções importam ao avaliar manchetes que sugerem que a Goldman simplesmente retirou a IA de sua força de trabalho.

Um especialista quantitativo desenvolve modelos matemáticos e software para o trabalho financeiro. Essa função pode estar próxima das operações de trading sem ser equivalente às responsabilidades de um trader. Portanto, as categorias de acesso dizem mais aos leitores do que uma simples divisão entre equipe técnica e todos os demais.

Os relatos públicos também exigem cautela em relação aos nomes dos produtos. GitHub é uma plataforma de desenvolvimento de software com vários serviços, e não um único modelo de IA. Os leitores devem evitar presumir que todos os recursos do GitHub ou produtos relacionados estejam sujeitos a restrições idênticas sem consultar as orientações subjacentes.

As datas merecem precisão semelhante. 2 de novembro é a data da reportagem, enquanto outubro foi quando as orientações internas citadas mudaram. Descrever isso como uma política recém-anunciada em novembro fundiria eventos distintos e sugeriria um anúncio público que a reportagem não estabelece.

A mudança prática diz respeito ao caminho de um funcionário, desde identificar um problema até construir uma solução. Com acesso mais amplo, um usuário de negócio pode experimentar diretamente com um assistente de programação. Com acesso mais restrito, a mesma ideia precisa de outra via aprovada ou da ajuda de um colega técnico.

Essa diferença não determina automaticamente se o trabalho final se torna melhor ou pior. Uma restrição pode impedir a disseminação de aplicativos sem suporte. Ela também pode atrasar uma melhoria que um especialista de negócio entende com mais clareza do que a equipe que recebe a solicitação.

A interpretação defensável das restrições da Goldman Sachs ao Claude Code é, portanto, específica. O banco teria alterado o acesso a determinadas ferramentas de desenvolvimento após uma revisão. As evidências públicas não justificam ampliar essa conclusão para uma rejeição de todo o uso de IA por funcionários.

Essa distinção prepara a questão central de toda a reportagem. Criar software e autorizar seu uso são decisões separadas, mesmo quando o mesmo funcionário anteriormente cuidava de ambas. A política relatada da Goldman dá maior peso à questão da autorização.

Para leitores que avaliam a adoção empresarial, esse é um sinal mais útil do que saber se uma empresa parece entusiasmada com IA. As decisões de acesso revelam quais atividades uma organização confia que as pessoas executem de forma independente. Elas também revelam onde ela quer que outra pessoa ou processo participe.

Banqueiros perdem um atalho, enquanto engenheiros herdam o trabalho

Restringir uma ferramenta muda quem atende à demanda; não elimina o problema de negócio que levou alguém a construir algo.

Segundo a PYMNTS, alguns traders usavam as ferramentas para monitorar fluxos de clientes, modelar posições e criar material escrito ou gráfico. O porta-voz da Goldman, Nick Carcaterra, citou produtividade e gestão de riscos ao explicar a revisão. Esses detalhes aparecem em seu relato sobre controles de programação bancária, que atribui a reportagem original à Bloomberg.

Esses usos relatados explicam por que perder o acesso seria relevante para os funcionários. Eles dizem respeito ao trabalho analítico cotidiano, e não ao desenvolvimento de software como um hobby desconectado. Uma ferramenta que encurta a distância entre uma pergunta e um resultado utilizável pode se tornar parte da rotina de alguém.

Considere um analista de mesa hipotético que organiza repetidamente dados aprovados em um gráfico familiar. Um assistente de programação poderia ajudar a automatizar a preparação. O aplicativo resultante pode parecer modesto porque seu criador entende tanto a entrada quanto a apresentação desejada.

Agora suponha que colegas comecem a usar esse gráfico sem saber como o aplicativo funciona. Alguém precisa determinar o que acontece quando o formato da entrada muda. Alguém também precisa estabelecer se o gráfico comunica incerteza e se suas premissas continuam apropriadas.

São questões ilustrativas, não evidências de uma falha na Goldman. Elas mostram por que uma conveniência pessoal pode criar responsabilidades que vão além da tarefa original. A pressão aumenta quando um aplicativo se torna útil o bastante para que outros esperem que ele continue funcionando.

Os engenheiros enfrentam o outro lado dessa demanda. Receber um protótipo não significa receber uma especificação completa, que descreve o comportamento e as restrições exigidos. Uma demonstração funcional pode deixar sem resposta questões sobre entradas incomuns, permissões de acesso e manutenção futura.

Usuários de negócio ainda contribuem com conhecimentos de que os engenheiros precisam. Eles entendem quais exceções importam, em quais resultados os colegas confiam e quais atrasos interferem em uma decisão. Retirar sua capacidade de experimentar sem preservar esse conhecimento enfraqueceria o processo de desenvolvimento.

O argumento mais forte a favor de um acesso mais restrito é que ele torna mais fácil atribuir responsabilidades. Equipes profissionais de desenvolvimento podem avaliar um aplicativo proposto antes que colegas passem a depender dele. Essa avaliação pode distinguir uma demonstração útil de algo pronto para uso recorrente.

O argumento mais forte contra uma restrição ampla diz respeito ao tempo de espera. Se as equipes técnicas não conseguirem absorver a demanda, os usuários de negócio perdem um atalho sem receber uma substituição viável. A restrição então transfere esforço para filas de solicitações e trabalho manual.

Nenhum dos dois resultados decorre automaticamente da decisão de acesso. O resultado depende do que acontece com solicitações que os funcionários antes atendiam por conta própria. Um banco precisa de uma forma de preservar ideias úteis enquanto decide quais merecem apoio de engenharia.

Isso também cria pressão sobre gestores, além dos desenvolvedores. Eles precisam escolher quais melhorias receberão atenção e explicar essas escolhas aos funcionários. Sem essa priorização, a equipe de engenharia se torna o obstáculo visível para decisões tomadas em outro lugar.

Para fornecedores de IA, a mesma questão afeta a promessa de vender ferramentas de programação para além dos desenvolvedores profissionais. Um público mais amplo traz expectativas adicionais quanto à revisão e à responsabilidade. Gerar um aplicativo é apenas parte do que o comprador empresarial precisa.

A lacuna entre um protótipo funcional e um software aprovado

A programação em linguagem natural reduz o esforço necessário para criar software, enquanto mantém seu responsável encarregado do que o software faz.

A PYMNTS informa que o CIO da Goldman, Marco Argenti, elogiou o “vibe coding” em julho, referindo-se a funcionários que direcionam a criação de software por meio de instruções conversacionais. Sua abordagem descrita envolvia profissionais não técnicos criando protótipos que engenheiros aprimorariam. As restrições de outubro complicam essa visão anterior.

A atração dessa abordagem é fácil de entender. Um protótipo permite que um especialista de negócio mostre o que quer dizer, em vez de descrever cada interação em uma solicitação. Ele pode revelar um requisito ignorado antes que uma equipe de desenvolvimento comprometa esforço substancial.

No entanto, uma demonstração responde a uma pergunta mais limitada do que um aplicativo aprovado. Ela mostra que uma sequência específica produziu um resultado útil sob condições específicas. Ela não estabelece como o mesmo software se comporta quando essas condições mudam.

Um aplicativo hipotético pode processar corretamente um arquivo familiar, mas lidar mal com um campo vazio. Outro pode exibir um resultado plausível após ler uma entrada desatualizada. Essas possibilidades explicam a necessidade de validação sem estabelecer que qualquer uma delas tenha ocorrido na Goldman.

A distinção se torna especialmente importante quando os resultados parecem refinados. Um gráfico claro ou uma explicação fluente pode tornar um aplicativo mais fácil de usar. A qualidade da apresentação não informa ao público se as premissas subjacentes correspondem à tarefa.

A revisão humana também tem significados diferentes em etapas distintas. Aprovar uma saída significa verificar um resultado específico. Revisar o aplicativo significa examinar o processo que gera resultados, incluindo comportamentos que o criador original talvez nunca encontre.

Portanto, uma equipe de engenharia que assume um protótipo precisa reconstruir mais do que seus recursos visíveis. Ela precisa entender os usuários pretendidos, as entradas aceitáveis e as consequências dos erros. Também precisa de uma pessoa capaz de resolver divergências sobre o significado de negócio do aplicativo.

Essa pessoa frequentemente continuará sendo um especialista de domínio. A expertise técnica não estabelece automaticamente se uma premissa financeira se adequa a um uso específico. Uma supervisão eficaz requer tanto discernimento sobre software quanto conhecimento do trabalho que está sendo apoiado.

É por isso que o principal conflito é entre software criado por funcionários e supervisão de engenharia responsável. Não é uma disputa sobre qual grupo entende melhor o negócio. O desafio diz respeito a como suas responsabilidades se conectam quando criar software se torna mais fácil.

As restrições da Goldman Sachs ao Claude Code colocam essa conexão em foco. Uma restrição pode reduzir o número de pessoas que criam aplicativos diretamente. Ela não pode, por si só, definir as responsabilidades de todos que os propõem, revisam, aprovam ou mantêm.

Um ambiente governado para protótipos oferece uma possível resposta. Esse ambiente limita onde os experimentos são executados e quais informações podem utilizar. Ele pode preservar a exploração enquanto exige outra decisão antes que um aplicativo alcance um público mais amplo.

Essa é uma possibilidade analítica, não uma descrição de uma substituição anunciada pela Goldman. As reportagens disponíveis não estabelecem o conjunto completo de alternativas recebidas pelos funcionários. Os leitores devem evitar tratar uma proposta de design sensata como uma política implementada.

A documentação é importante em qualquer arranjo. Um registro do propósito e das premissas de uma aplicação ajuda a próxima pessoa a avaliar mudanças. Uma base de conhecimento pesquisável pode apoiar essa transição, embora a documentação por si só não aprove um software para uso.

A questão mais profunda sobre produtividade envolve toda a transição. Um protótipo que exige pouco esforço para ser gerado ainda pode demandar esclarecimentos consideráveis antes que outra equipe aceite a responsabilidade. Por outro lado, um protótipo bem delimitado pode facilitar esses esclarecimentos.

Medir apenas a etapa de criação deixaria de fora ambos os resultados. As organizações precisam examinar o trabalho necessário para alcançar um resultado confiável e mantê-lo confiável. Essa visão mais ampla explica por que o entusiasmo dos funcionários e a cautela da gestão podem coexistir.

Outros bancos mostram por que a interface importa

Os bancos podem ampliar o acesso à IA enquanto mantêm tarefas, dados e ações disponíveis estritamente definidos.

A própria implementação anterior do Goldman oferece uma comparação importante. A Reuters informou sobre o lançamento em toda a empresa do GS AI Assistant em 23 de junho de 2025, após o uso por cerca de 10.000 funcionários. O assistente de IA corporativo apoiava atividades como resumos de documentos, elaboração inicial de textos e análise de dados.

Esse histórico mostra por que o acesso a um assistente e o acesso a uma ferramenta de desenvolvimento merecem tratamentos distintos. Um assistente pode oferecer recursos por meio de uma interface definida pela organização. Uma ferramenta de programação ajuda o usuário a criar novos comportamentos, que então exigem sua própria avaliação.

Essas categorias podem se sobrepor, portanto o rótulo do produto, por si só, é insuficiente. Um assistente conversacional pode realizar ações relevantes se estiver conectado a outros sistemas. Uma ferramenta de programação também pode operar dentro de um experimento rigidamente limitado.

A comparação útil diz respeito à autoridade concedida pela interface. O sistema pode recuperar informações, modificar arquivos ou iniciar outro processo? Quem decide quais ações exigem aprovação e onde a organização registra essa decisão?

O Morgan Stanley fornece um exemplo concreto de fluxo de trabalho definido. Seu assistente de resumo de reuniões gera notas e destaca itens de ação para consultores financeiros, com consentimento do cliente. A empresa descreveu o Debrief como uma adição ao seu assistente interno de IA já existente.

Esse exemplo não demonstra que a abordagem do Morgan Stanley seja universalmente mais segura ou mais produtiva. Ele ilustra uma unidade diferente de implantação. A organização fornece uma aplicação para uma atividade identificada, em vez de pedir que cada consultor construa uma de forma independente.

Essa escolha torna algumas questões de avaliação mais explícitas. Uma aplicação de reuniões tem uma entrada pretendida, uma saída esperada e um usuário reconhecível. Os revisores podem se concentrar em saber se ela atende adequadamente àquela atividade.

Aplicações desenvolvidas por funcionários oferecem uma vantagem diferente: flexibilidade. Um especialista pode atender a uma necessidade que uma aplicação fornecida centralmente não resolve. A organização então precisa decidir quais experimentos permanecem pessoais e quais merecem apoio mais amplo.

Portanto, a questão competitiva é mais ampla do que decidir se um banco escolhe Claude Code ou outro produto de programação. Mudar de fornecedor não resolve automaticamente questões de propriedade ou aprovação. Recursos semelhantes podem criar exigências organizacionais semelhantes quando oferecidos com permissões similares.

Um banco que compara abordagens deve examinar o trabalho viabilizado por cada modelo de acesso. A ampla disponibilidade pode ajudar funcionários a descobrir aplicações úteis. Aplicações definidas podem tornar o trabalho recorrente mais fácil de supervisionar.

O resultado depende de a organização conectar descoberta e entrega. Os funcionários precisam de um caminho para propor melhorias que as ferramentas existentes não suportam. As equipes técnicas precisam de contexto suficiente para avaliar essas propostas sem reiniciar a conversa do zero.

Para compradores corporativos, isso torna o desenho do fluxo de trabalho parte da seleção de produtos. Uma demonstração impressionante mostra o que uma ferramenta pode produzir. A decisão de implantação também exige saber como a organização avaliará, apoiará e modificará essa produção.

A restrição relatada do Goldman se insere nesse debate operacional. Ela não estabelece que bancos concorrentes tenham resolvido o problema. Mostra uma instituição importante alterando onde coloca um limite que outras instituições também precisam definir.

A política não prova que Claude Code falhou

Uma restrição de acesso é evidência de uma decisão gerencial, não de um teste controlado da utilidade de um produto.

O relato do The Decoder sobre a revisão de produtividade e risco afirma que a explicação do Goldman permaneceu ampla. As reportagens disponíveis não identificam um incidente específico nem fornecem uma comparação quantificada de produtividade antes e depois da mudança.

Isso deixa explicações importantes sem solução. Os leitores não podem classificar com segurança preocupações de manutenção, capacidade de revisão, considerações de segurança ou gastos como o fator decisivo. Cada um é uma possível preocupação corporativa, mas a possibilidade não estabelece o raciocínio interno do Goldman.

A distinção também limita o que se pode concluir sobre o desempenho dos funcionários. Uma restrição não mostra que banqueiros produziram aplicações ruins ou que traders entenderam mal as ferramentas. Ela estabelece que a gestão alterou quem podia usá-las sob a política relatada.

Da mesma forma, a frustração dos funcionários não prova que o arranjo anterior gerava benefícios líquidos. Uma aplicação pode ser útil para quem a cria e, ao mesmo tempo, gerar trabalho em outro lugar. Avaliar o resultado geral exige olhar além da pessoa que vivencia a conveniência mais imediata.

As restrições do Goldman Sachs ao Claude Code, portanto, deixam um problema de medição. A produtividade deve incluir o esforço necessário para verificar resultados, corrigir erros e manter aplicações. Também deve incluir o trabalho manual ou os atrasos que retornam quando o acesso desaparece.

Uma medida restrita pode favorecer injustamente qualquer um dos lados. Contar apenas a produção gerada faz a experimentação parecer barata. Contar apenas o trabalho de revisão pode ignorar aplicações úteis que evitam esforço repetitivo.

Uma comparação mais robusta acompanharia tarefas semelhantes por todo o seu processo de trabalho. Ela examinaria se os funcionários chegam a resultados confiáveis, quanto de intervenção precisam e quem realiza essa intervenção. As reportagens públicas não forneceram essa comparação para essa decisão.

O status de engenharia também é um substituto imperfeito para uma avaliação completa de risco. Desenvolvedores possuem habilidades relevantes, mas ainda precisam de permissões e revisão adequadas. Uma categoria profissional simplifica a administração de acesso sem resolver todas as questões relativas a uma tarefa específica.

Por outro lado, um especialista de negócios pode propor um experimento limitado que tenha menos consequências do que uma mudança mais ampla de sistema feita por um engenheiro. Isso não invalida controles baseados em funções, que atribuem permissões por função profissional. Explica por que exceções e limites específicos por tarefa importam.

Também há um possível custo em tornar os caminhos aprovados excessivamente difíceis. Os funcionários podem abandonar melhorias úteis ou buscar alternativas fora do processo pretendido. Trata-se de um risco geral de implementação, não de evidência de que funcionários do Goldman tenham feito isso.

Uma avaliação confiável deve manter ambas as possibilidades em aberto. Um acesso mais restrito pode melhorar o controle, e sua implementação pode criar atrito. O resultado depende de a instituição preservar um caminho prático da demanda legítima até um software com suporte.

Para os leitores, a principal disciplina é separar a ação relatada de alegações sobre seu sucesso. O Goldman teria tomado uma decisão de acesso. As evidências necessárias para julgar os resultados operacionais dessa decisão continuam incompletas.

O que observar depois que o Goldman redesenha o limite

As próximas evidências úteis dirão respeito a fluxos de trabalho substitutos, trabalho concluído e se bancos comparáveis ajustam suas próprias regras de acesso.

Primeiro, observe se surge uma explicação mais clara sobre o caminho do Goldman para a experimentação por não engenheiros. Um ambiente aprovado para protótipos, um processo definido de solicitação ou acesso supervisionado esclareceria como as ideias dos funcionários chegam à implementação. São sinais a observar, não substituições anunciadas estabelecidas pelas reportagens atuais.

Uma substituição prática reforçaria a interpretação de que o Goldman está reorganizando o desenvolvimento em torno de responsabilidades mais claras. Uma restrição sem um caminho utilizável reforçaria preocupações sobre perda de flexibilidade. A evidência relevante é se usuários de negócios ainda conseguem receber melhorias adequadas.

Segundo, observe medidas que incluam todo o processo de trabalho. Alegações sobre elaboração mais rápida ou maior criação de aplicações continuariam incompletas sem informações sobre verificação e manutenção. Medidas de conclusão confiável ofereceriam uma base mais sólida para julgar a política.

Evidências de que menos aplicações exigem reparos sustentariam uma supervisão mais rígida, particularmente se trabalhos úteis continuarem chegando aos funcionários. Evidências de atrasos crescentes ou de retorno do trabalho manual enfraqueceriam o argumento de produtividade. Nenhum dos resultados deve ser presumido apenas a partir da mudança de acesso.

Terceiro, observe como instituições comparáveis definem permissões para funcionários fora da engenharia. O sinal relevante é uma mudança no que as pessoas podem criar ou operar. Outro anúncio de entusiasmo com IA revelaria pouco sobre como a responsabilidade funciona na prática.

Se pares ampliarem com sucesso a criação supervisionada, uma restrição ampla ficará mais difícil de defender como a única abordagem viável. Se impuserem limites semelhantes, a decisão do Goldman parecerá mais compatível com uma restrição operacional compartilhada. As comparações ainda precisam levar em conta diferenças nas tarefas e no acesso.

Esses sinais devem ser avaliados em conjunto. Um fluxo de trabalho substituto pode parecer promissor enquanto produz pouco trabalho útil. Uma alegação de produtividade pode parecer favorável enquanto exclui o esforço transferido para outra equipe.

Para desenvolvedores, a história levanta uma pergunta concreta sobre o que chega depois de uma demonstração gerada por IA. Para usuários de negócios, levanta outra: como podem manter influência sobre as ferramentas quando a criação direta se torna restrita?

Compradores corporativos devem levar essas perguntas para as avaliações antes de uma implantação ampla. Eles precisam identificar quem aprova uma aplicação, quem verifica suas premissas e quem a apoia depois que seu criador segue em frente. Essas respostas moldam se uma criação mais fácil se transforma em um benefício duradouro.

Acompanhe as restrições do Goldman Sachs ao Claude Code pelo trabalho que substitui o acesso direto. Observe como os funcionários enviam ideias, como engenheiros assumem a responsabilidade e se aplicações aprovadas chegam às pessoas que precisam delas. Compare esses resultados com alegações sobre criação mais rápida de software. Uma narrativa convincente de adoção deve explicar tanto o ganho inicial quanto o trabalho contínuo necessário para preservá-lo. Quando o próximo banco anunciar um acesso mais amplo à IA, pergunte o que os funcionários realmente podem fazer, quais permissões acompanham a ferramenta e quem é responsável pelo resultado. Essas são as evidências de que os leitores precisam para julgar se uma organização tornou a IA mais útil no trabalho diário.