Le restrizioni di Goldman Sachs su Claude Code riportano i banchieri lontano dalla creazione di strumenti propri

Secondo quanto riferito, le restrizioni di Goldman Sachs su Claude Code eliminano l'accesso agli strumenti di programmazione per banchieri e trader, nonostante il precedente incoraggiamento rivolto ai dipendenti a creare le proprie applicazioni. Bloomberg ha riportato il cambiamento il 2 novembre, citando indicazioni di ottobre. La tensione immediata riguarda chi possa trasformare un esperimento utile in un software da cui i colleghi dipendono.

Claude Code è l'assistente di programmazione AI di Anthropic, che aiuta gli utenti a creare e modificare software attraverso istruzioni in linguaggio naturale. Limitarlo traccia un confine tra la generazione di un'applicazione funzionante e l'assunzione di responsabilità per il suo comportamento. Questo confine colloca ora i team di ingegneria di Goldman tra gli utenti aziendali e alcuni strumenti che in precedenza utilizzavano autonomamente.

Morgan Stanley offre un confronto utile attraverso assistenti progettati appositamente per i consulenti finanziari. La decisione attribuita a Goldman mette sotto pressione un approccio diverso: lasciare che i dipendenti assemblino le proprie soluzioni prima che gli ingegneri le perfezionino. La questione irrisolta è se un accesso più ristretto migliori una produttività affidabile o renda più difficile realizzare un lavoro utile.

Cosa cambiano realmente le restrizioni di Goldman Sachs su Claude Code

Il cambiamento riportato restringe chi può usare gli strumenti di programmazione; non dimostra che Goldman stia abbandonando l'AI in tutta la banca.

Bloomberg afferma che le indicazioni di ottobre hanno limitato questi strumenti agli ingegneri, un cambiamento riportato il 2 novembre. Il suo resoconto sull'accesso agli strumenti di programmazione stabilisce la cronologia della politica.

Separatamente, PYMNTS ha descritto i prodotti interessati come Claude Code di Anthropic e gli strumenti di programmazione GitHub di Microsoft. Il suo resoconto include specialisti quantitativi tra gli utenti tecnici che mantengono l'accesso. Queste distinzioni contano nel valutare titoli che suggeriscono che Goldman abbia semplicemente rimosso l'AI dalla propria forza lavoro.

Uno specialista quantitativo sviluppa modelli matematici e software per il lavoro finanziario. Questo ruolo può essere vicino al trading senza coincidere con le responsabilità di un trader. Le categorie di accesso offrono quindi ai lettori più informazioni di una semplice divisione tra personale tecnico e tutti gli altri.

I resoconti pubblici richiedono cautela anche riguardo ai nomi dei prodotti. GitHub è una piattaforma di sviluppo software con molteplici servizi, non un singolo modello AI. I lettori dovrebbero evitare di presumere che ogni funzionalità GitHub o prodotto correlato rientri in restrizioni identiche senza aver consultato le indicazioni sottostanti.

Le date meritano una precisione analoga. Il 2 novembre è la data del resoconto, mentre ottobre è il momento in cui sono cambiate le indicazioni interne citate. Descrivere la vicenda come una nuova politica annunciata a novembre fonderebbe eventi distinti e suggerirebbe un annuncio pubblico che il resoconto non stabilisce.

Il cambiamento pratico riguarda il percorso di un dipendente dal riconoscimento di un problema alla costruzione di una soluzione. Con un accesso più ampio, un utente aziendale può sperimentare direttamente con un assistente di programmazione. Con un accesso più ristretto, la stessa idea richiede un altro percorso approvato o l'aiuto di un collega tecnico.

Questa differenza non determina automaticamente se il lavoro finale diventi migliore o peggiore. Una restrizione può impedire la diffusione di applicazioni prive di supporto. Può anche ritardare un miglioramento che uno specialista aziendale comprende più chiaramente del team che riceve la richiesta.

La lettura sostenibile delle restrizioni di Goldman Sachs su Claude Code è quindi specifica. Secondo quanto riferito, la banca ha modificato l'accesso a determinati strumenti di sviluppo dopo una revisione. Le prove pubbliche non giustificano l'estensione di questa conclusione a un rifiuto di ogni utilizzo dell'AI da parte dei dipendenti.

Questa distinzione prepara la questione centrale dell'intera storia. Creare software e autorizzarne l'uso sono decisioni separate, anche quando in precedenza lo stesso dipendente gestiva entrambe. La politica attribuita a Goldman assegna maggiore peso alla questione dell'autorizzazione.

Per i lettori che valutano l'adozione aziendale, questo è un segnale più utile dell'entusiasmo apparente di un'azienda per l'AI. Le decisioni di accesso rivelano quali attività un'organizzazione ritiene che le persone possano svolgere in autonomia. Rivelano anche dove desidera il coinvolgimento di un'altra persona o di un processo.

I banchieri perdono una scorciatoia, mentre gli ingegneri ereditano il lavoro

Limitare uno strumento cambia chi gestisce la domanda; non elimina il problema aziendale che ha spinto qualcuno a creare una soluzione.

Secondo PYMNTS, alcuni trader usavano gli strumenti per monitorare i flussi dei clienti, modellare posizioni e creare materiale scritto o grafico. Il portavoce di Goldman Nick Carcaterra ha citato produttività e gestione del rischio nello spiegare la revisione. Questi dettagli compaiono nel suo resoconto sui controlli di programmazione della banca, che attribuisce il reporting sottostante a Bloomberg.

Questi usi riportati spiegano perché la perdita di accesso sarebbe importante per i dipendenti. Riguardano il lavoro analitico quotidiano, piuttosto che lo sviluppo software perseguito come hobby non correlato. Uno strumento che accorcia la distanza tra una domanda e un risultato utilizzabile può diventare parte della routine di qualcuno.

Si consideri un ipotetico analista di desk che organizza ripetutamente dati approvati in un grafico familiare. Un assistente di programmazione potrebbe aiutare ad automatizzare la preparazione. L'applicazione risultante può sembrare modesta perché il suo creatore comprende sia l'input sia la presentazione desiderata.

Ora si supponga che i colleghi inizino a usare quel grafico senza sapere come funziona l'applicazione. Qualcuno deve stabilire cosa accade quando cambia il formato dell'input. Qualcuno deve anche determinare se il grafico comunica l'incertezza e se le sue ipotesi restano appropriate.

Queste sono domande illustrative, non prove di un fallimento presso Goldman. Mostrano perché una comodità personale possa creare responsabilità oltre il compito originario. La pressione cresce quando un'applicazione diventa abbastanza utile da far sì che altri si aspettino che continui a funzionare.

Gli ingegneri affrontano l'altro lato di questa domanda. Ricevere un prototipo non significa ricevere una specifica completa, che descrive il comportamento e i vincoli richiesti. Una dimostrazione funzionante può lasciare senza risposta domande su input insoliti, autorizzazioni di accesso e manutenzione futura.

Gli utenti aziendali continuano a contribuire con conoscenze di cui gli ingegneri hanno bisogno. Comprendono quali eccezioni contano, quali risultati i colleghi ritengono affidabili e quali ritardi interferiscono con una decisione. Rimuovere la loro capacità di sperimentare senza preservare questa conoscenza indebolirebbe il processo di sviluppo.

L'argomento più forte a favore di un accesso più ristretto è che rende più semplice assegnare le responsabilità. I team di sviluppo professionali possono valutare un'applicazione proposta prima che i colleghi vi facciano affidamento. Questa valutazione può distinguere una dimostrazione utile da qualcosa pronto per un uso ricorrente.

L'argomento più forte contro una restrizione ampia riguarda i tempi di attesa. Se i team tecnici non riescono ad assorbire la domanda, gli utenti aziendali perdono una scorciatoia senza ricevere un'alternativa praticabile. La restrizione sposta quindi lo sforzo nelle code di richiesta e nel lavoro manuale.

Nessuno dei due esiti deriva automaticamente dalla decisione di accesso. Il risultato dipende da ciò che accade alle richieste che i dipendenti in precedenza gestivano da soli. Una banca ha bisogno di un modo per preservare le idee utili decidendo al contempo quali meritino il supporto dell'ingegneria.

Questo crea pressione sui manager oltre che sugli sviluppatori. Devono scegliere quali miglioramenti ricevano attenzione e spiegare tali scelte ai dipendenti. Senza questa definizione delle priorità, il team di ingegneria diventa l'ostacolo visibile per decisioni prese altrove.

Per i fornitori di AI, la stessa questione incide sulla promessa di vendere strumenti di programmazione oltre la cerchia degli sviluppatori professionisti. Un pubblico più ampio porta ulteriori aspettative in materia di revisione e titolarità. Generare un'applicazione è solo una parte di ciò di cui l'acquirente aziendale ha bisogno.

Il divario tra un prototipo funzionante e software approvato

La programmazione in linguaggio naturale riduce lo sforzo necessario per creare software, lasciando il proprietario responsabile di ciò che il software fa.

PYMNTS riporta che il CIO di Goldman Marco Argenti ha elogiato il “vibe coding” a luglio, intendendo dipendenti che dirigono la creazione di software attraverso istruzioni conversazionali. Il suo approccio descritto prevedeva che personale non tecnico costruisse prototipi poi perfezionati dagli ingegneri. Le restrizioni di ottobre complicano quella visione precedente.

L'attrattiva di questo approccio è facile da comprendere. Un prototipo consente a uno specialista aziendale di mostrare ciò che intende invece di descrivere ogni interazione in una richiesta. Può rivelare un requisito trascurato prima che un team di sviluppo impegni uno sforzo sostanziale.

Tuttavia, una dimostrazione risponde a una domanda più circoscritta di un'applicazione approvata. Mostra che una determinata sequenza ha prodotto un risultato utile in condizioni specifiche. Non stabilisce come lo stesso software si comporti quando tali condizioni cambiano.

Un'applicazione ipotetica potrebbe elaborare correttamente un file familiare ma gestire in modo errato un campo vuoto. Un'altra potrebbe mostrare un risultato plausibile dopo aver letto un input obsoleto. Queste possibilità spiegano la necessità di validazione senza dimostrare che una delle due si sia verificata presso Goldman.

La distinzione diventa particolarmente importante quando gli output appaiono curati. Un grafico chiaro o una spiegazione fluida possono rendere un'applicazione più facile da usare. La qualità della presentazione non dice al suo pubblico se le ipotesi sottostanti corrispondano al compito.

Anche la revisione umana ha significati diversi nelle diverse fasi. Approvare un output significa verificare un risultato particolare. Riesaminare l'applicazione significa esaminare il processo che genera i risultati, incluso un comportamento che il creatore originario potrebbe non incontrare mai.

Un team di ingegneria che prende in carico un prototipo deve quindi ricostruire più delle sue funzionalità visibili. Deve comprendere gli utenti previsti, gli input accettabili e le conseguenze degli errori. Ha inoltre bisogno di una persona in grado di risolvere disaccordi sul significato aziendale dell'applicazione.

Quella persona resterà spesso uno specialista del settore. L'esperienza tecnica non stabilisce automaticamente se un'ipotesi finanziaria sia adatta a un utilizzo specifico. Una supervisione efficace richiede sia giudizio sul software sia conoscenza del lavoro supportato.

Ecco perché il conflitto principale riguarda il software creato dai dipendenti rispetto alla supervisione responsabile dell'ingegneria. Non è una gara su quale gruppo comprenda meglio l'azienda. La sfida riguarda il modo in cui le loro responsabilità si collegano quando la creazione di software diventa più semplice.

Le restrizioni di Goldman Sachs su Claude Code portano questa connessione al centro dell'attenzione. Una restrizione può ridurre il numero di persone che creano direttamente applicazioni. Non può da sola definire le responsabilità di chiunque proponga, riesamini, approvi o mantenga tali applicazioni.

Un ambiente governato per prototipi offre una possibile risposta. Un ambiente simile limita dove si svolgono gli esperimenti e quali informazioni possono utilizzare. Può preservare l'esplorazione richiedendo al contempo un'altra decisione prima che un'applicazione raggiunga un pubblico più ampio.

Questa è una possibilità analitica, non la descrizione di un'alternativa annunciata da Goldman. I resoconti disponibili non stabiliscono l'intera gamma di alternative offerte ai dipendenti. I lettori dovrebbero evitare di trattare una proposta progettuale sensata come una politica già implementata.

La documentazione è importante in entrambe le configurazioni. Un registro dello scopo e delle ipotesi dell'applicazione aiuta chi subentra a valutare le modifiche. Una base di conoscenza ricercabile può agevolare questo passaggio di consegne, sebbene la sola documentazione non autorizzi l'uso di un software.

La questione più profonda della produttività riguarda l'intero passaggio di consegne. Un prototipo che richiede poco sforzo per essere generato può comunque richiedere chiarimenti sostanziali prima che un altro team accetti di assumerne la responsabilità. Al contrario, un prototipo ben circoscritto può rendere tali chiarimenti più semplici.

Misurare soltanto la fase di creazione non coglierebbe entrambi gli esiti. Le organizzazioni devono esaminare il lavoro necessario per ottenere un risultato affidabile e mantenerlo tale. Questa prospettiva più ampia spiega perché l'entusiasmo dei dipendenti e la prudenza del management possano coesistere.

Altre banche mostrano perché l'interfaccia conta

Le banche possono ampliare l'accesso all'AI mantenendo strettamente definiti compiti, dati e azioni disponibili.

Il precedente rollout di Goldman offre un confronto importante. Reuters ha riferito di un lancio aziendale di GS AI Assistant il 23 giugno 2025, dopo il suo utilizzo da parte di circa 10.000 dipendenti. L'assistente AI aziendale supportava attività tra cui riassunti di documenti, prime bozze e analisi dei dati.

Questa storia mostra perché l'accesso a un assistente e l'accesso a uno strumento di sviluppo meritino un trattamento distinto. Un assistente può offrire funzionalità attraverso un'interfaccia definita dall'organizzazione. Uno strumento di coding aiuta l'utente a creare nuovi comportamenti, che richiedono poi una valutazione propria.

Queste categorie possono sovrapporsi, quindi la sola etichetta del prodotto non basta. Un assistente conversazionale può compiere azioni rilevanti se è collegato ad altri sistemi. Anche uno strumento di coding può operare all'interno di un esperimento rigorosamente limitato.

Il confronto utile riguarda l'autorità concessa attraverso l'interfaccia. Il sistema può recuperare informazioni, modificare file o avviare un altro processo? Chi decide quali azioni richiedono approvazione e dove l'organizzazione registra tale decisione?

Morgan Stanley fornisce un esempio concreto di flusso di lavoro definito. Il suo assistente per i riepiloghi delle riunioni genera note e mette in evidenza le azioni da intraprendere per i consulenti finanziari, con il consenso dei clienti. L'azienda ha descritto Debrief come un'aggiunta al proprio assistente AI interno esistente.

Questo esempio non dimostra che l'approccio di Morgan Stanley sia universalmente più sicuro o più produttivo. Illustra una diversa unità di distribuzione. L'organizzazione fornisce un'applicazione per un'attività identificata, anziché chiedere a ogni consulente di costruirne una in autonomia.

Questa scelta rende più esplicite alcune domande di valutazione. Un'applicazione per le riunioni ha un input previsto, un output atteso e un utente riconoscibile. I revisori possono concentrarsi sul fatto che serva appropriatamente quell'attività.

Le applicazioni create dai dipendenti offrono un vantaggio diverso: flessibilità. Uno specialista può affrontare un'esigenza che un'applicazione fornita centralmente non risolve. L'organizzazione deve quindi decidere quali esperimenti restano personali e quali meritano un sostegno più ampio.

La questione competitiva è dunque più ampia della scelta di una banca tra Claude Code e un altro prodotto di coding. Cambiare fornitore non risolve automaticamente le questioni di responsabilità o approvazione. Capacità simili possono creare richieste organizzative simili quando vengono offerte con autorizzazioni analoghe.

Una banca che confronta gli approcci dovrebbe esaminare il lavoro reso possibile da ciascun modello di accesso. Un'ampia disponibilità può aiutare i dipendenti a scoprire applicazioni utili. Applicazioni definite possono rendere il lavoro ricorrente più facile da supervisionare.

L'esito dipende dal fatto che l'organizzazione colleghi la scoperta alla realizzazione. I dipendenti hanno bisogno di un percorso per proporre miglioramenti che gli strumenti esistenti non supportano. I team tecnici hanno bisogno di un contesto sufficiente per valutare tali proposte senza ricominciare la conversazione da zero.

Per gli acquirenti aziendali, questo rende la progettazione dei flussi di lavoro parte della selezione del prodotto. Una dimostrazione impressionante dice loro cosa può produrre uno strumento. La decisione di implementazione richiede anche di sapere come la loro organizzazione valuterà, supporterà e modificherà quell'output.

La limitazione riportata di Goldman rientra in questo dibattito operativo. Non dimostra che le banche concorrenti abbiano risolto il problema. Mostra un'istituzione di primo piano che modifica il punto in cui traccia un confine che anche altre istituzioni devono definire.

La policy non dimostra che Claude Code abbia fallito

Una limitazione dell'accesso è la prova di una decisione gestionale, non un test controllato dell'utilità di un prodotto.

Il resoconto di The Decoder sulla revisione di produttività e rischio afferma che la spiegazione di Goldman è rimasta generica. Le informazioni disponibili non identificano un incidente specifico né forniscono un confronto quantificato della produttività prima e dopo il cambiamento.

Ciò lascia irrisolte spiegazioni importanti. I lettori non possono classificare con sicurezza le preoccupazioni di manutenzione, la capacità di revisione, le considerazioni sulla sicurezza o la spesa come fattore decisivo. Ciascuno è una possibile preoccupazione aziendale, ma la possibilità non stabilisce il ragionamento interno di Goldman.

La distinzione limita anche ciò che si può concludere sulle prestazioni dei dipendenti. Una limitazione non dimostra che i banchieri abbiano prodotto applicazioni di scarsa qualità o che i trader abbiano frainteso gli strumenti. Stabilisce che il management ha modificato chi poteva usarli nell'ambito della policy riportata.

Allo stesso modo, la frustrazione dei dipendenti non dimostra che la precedente configurazione abbia generato benefici netti. Un'applicazione può essere utile al suo creatore pur creando lavoro altrove. Valutare il risultato complessivo richiede di guardare oltre la persona che sperimenta la convenienza più immediata.

Le limitazioni di Goldman Sachs su Claude Code lasciano dunque un problema di misurazione. La produttività dovrebbe includere lo sforzo necessario per verificare gli output, risolvere gli errori e mantenere le applicazioni. Dovrebbe includere anche il lavoro manuale o i ritardi che ritornano quando l'accesso scompare.

Una misura ristretta può favorire ingiustamente entrambe le parti. Contare solo l'output generato fa apparire la sperimentazione economica. Contare solo il lavoro di revisione può trascurare applicazioni utili che evitano sforzi ripetitivi.

Un confronto più solido seguirebbe attività simili lungo l'intero processo di lavoro. Esaminerebbe se i dipendenti raggiungono risultati affidabili, quanto intervento richiedono e chi svolge tale intervento. Le informazioni pubbliche non hanno fornito questo confronto per la decisione in questione.

Anche lo status di ingegnere è un sostituto imperfetto di una valutazione completa del rischio. Gli sviluppatori apportano competenze rilevanti, ma necessitano comunque di autorizzazioni e revisioni appropriate. Una categoria professionale semplifica l'amministrazione degli accessi senza risolvere ogni questione relativa a un'attività specifica.

Al contrario, uno specialista aziendale potrebbe proporre un esperimento limitato con conseguenze minori rispetto a una modifica più ampia del sistema da parte di un ingegnere. Ciò non invalida i controlli basati sui ruoli, che assegnano autorizzazioni in base alla funzione professionale. Spiega perché siano importanti eccezioni e confini specifici per attività.

Rendere troppo difficili i percorsi approvati comporta anche un possibile costo. I dipendenti potrebbero abbandonare miglioramenti utili o cercare alternative al di fuori del processo previsto. Si tratta di un rischio generale di implementazione, non della prova che i dipendenti di Goldman abbiano agito in questo modo.

Una valutazione credibile deve mantenere aperte entrambe le possibilità. Un accesso più ristretto può migliorare il controllo e la sua implementazione può creare attrito. L'esito dipende dal fatto che l'istituzione preservi un percorso pratico dalla domanda legittima a un software supportato.

Per i lettori, la disciplina fondamentale consiste nel separare l'azione riportata dalle affermazioni sul suo successo. Secondo quanto riportato, Goldman ha preso una decisione sull'accesso. Le prove necessarie per giudicare i risultati operativi di tale decisione restano incomplete.

Cosa osservare dopo che Goldman ridefinisce il confine

Le prossime prove utili riguarderanno i flussi di lavoro sostitutivi, il lavoro completato e l'eventuale adeguamento delle regole di accesso da parte di banche comparabili.

Innanzitutto, occorre cercare una spiegazione più chiara del percorso di Goldman per la sperimentazione da parte dei non ingegneri. Un ambiente di prototipazione approvato, un processo di richiesta definito o un accesso supervisionato chiarirebbero come le idee dei dipendenti arrivano all'implementazione. Sono segnali da osservare, non sostituzioni annunciate e stabilite dalle attuali informazioni.

Una sostituzione pratica rafforzerebbe l'interpretazione secondo cui Goldman sta riorganizzando lo sviluppo attorno a responsabilità più chiare. Una limitazione senza un percorso utilizzabile rafforzerebbe le preoccupazioni per la perdita di flessibilità. La prova rilevante è se gli utenti aziendali riescano ancora a ottenere miglioramenti appropriati.

In secondo luogo, occorre cercare misure che includano l'intero processo di lavoro. Le affermazioni su bozze più rapide o sulla maggiore creazione di applicazioni resterebbero incomplete senza informazioni su verifica e manutenzione. Misure del completamento affidabile offrirebbero una base più solida per giudicare la policy.

La prova che meno applicazioni richiedono riparazioni sosterrebbe una supervisione più rigorosa, in particolare se il lavoro utile continua a raggiungere i dipendenti. La prova di ritardi crescenti o del ritorno di lavoro manuale indebolirebbe l'argomento della produttività. Nessuno dei due risultati dovrebbe essere presunto dal solo cambiamento di accesso.

In terzo luogo, occorre osservare come istituzioni comparabili definiscono le autorizzazioni per i dipendenti al di fuori dell'ingegneria. Il segnale significativo è un cambiamento in ciò che le persone possono costruire o gestire. Un altro annuncio sull'entusiasmo per l'AI rivelerebbe poco su come la responsabilità funzioni nella pratica.

Se i concorrenti ampliano con successo la creazione supervisionata, una limitazione ampia diventa più difficile da difendere come unico approccio praticabile. Se impongono confini simili, la decisione di Goldman apparirebbe più coerente con un vincolo operativo condiviso. I confronti devono comunque tenere conto delle differenze nelle attività e nell'accesso.

Questi segnali dovrebbero essere valutati insieme. Un flusso di lavoro sostitutivo può apparire promettente pur producendo poco lavoro utile. Un'affermazione sulla produttività può sembrare favorevole pur escludendo lo sforzo trasferito a un altro team.

Per gli sviluppatori, la storia solleva una domanda concreta su ciò che arriva dopo una dimostrazione generata dall'AI. Per gli utenti aziendali, ne solleva un'altra: come possono mantenere influenza sugli strumenti quando la creazione diretta diventa limitata?

Gli acquirenti aziendali dovrebbero integrare queste domande nelle valutazioni prima di un'implementazione estesa. Devono identificare chi approva un'applicazione, chi ne verifica le ipotesi e chi la supporta dopo che il suo creatore passa ad altro. Queste risposte determinano se una creazione più semplice diventa un beneficio duraturo.

Seguite le limitazioni di Goldman Sachs su Claude Code attraverso il lavoro che sostituisce l'accesso diretto. Cercate come i dipendenti presentano idee, come gli ingegneri assumono la responsabilità e se le applicazioni approvate raggiungono le persone che ne hanno bisogno. Confrontate questi esiti con le affermazioni sulla creazione più rapida di software. Una storia di adozione convincente dovrebbe spiegare sia il guadagno iniziale sia il lavoro continuo necessario per preservarlo. Quando la prossima banca annuncerà un accesso AI più ampio, chiedete cosa i dipendenti possano effettivamente fare, quali autorizzazioni accompagnino lo strumento e chi sia responsabile del risultato. Sono queste le prove di cui i lettori hanno bisogno per giudicare se un'organizzazione abbia reso l'AI più utile nel lavoro quotidiano.