Claude guida il 26% della R&S di Anthropic. Chi verifica?

Anthropic afferma che Claude guidava il 26% del proprio lavoro interno di ricerca e sviluppo in IA in una rilevazione di agosto 2026, sotto supervisione umana. Il rapporto del 17 settembre non rileva attività pienamente autonome tra quelle misurate. Ne ricavo che dirigere una ricerca e verificarne i risultati vanno misurati separatamente. [1]

Cosa significa che Claude guida il 26% della ricerca?

Nella classificazione di Anthropic, Claude guida il lavoro mentre una persona lo supervisiona. È diverso dal fare ricerca senza intervento umano. Un sistema può decidere come svolgere un compito e dipendere comunque da qualcun altro per stabilire se il risultato è utile. [1]

La discussione del 17 settembre su r/singularity ha ripreso il dato del 26%. Per me è un buon motivo per leggere il rapporto originale, soprattutto perché «guidare» suggerisce un’interpretazione più ampia di quella richiesta dalla misurazione. Uno sviluppatore potrebbe immaginare un’IA che sceglie un programma di ricerca, esegue gli esperimenti e decide cosa pubblicare. Sono responsabilità distinte. [2]

Ecco come le separerei per valutare un agente nel mio lavoro. È uno schema di revisione che propongo, non la tabella ufficiale di Anthropic.

Delegare la riga centrale non risolve le altre due. È anche la distinzione alla base della mia analisi dei problemi di programmazione e supervisione di Opus 5: produrre un risultato consistente e renderlo facile da verificare sono qualità diverse.

Come è stata misurata la percentuale?

Anthropic descrive una stima interna basata sulle registrazioni del lavoro e su una classificazione assistita da modelli. La ponderazione usa il tempo delle persone come approssimazione, distribuendo il peso settimanale di ciascuna persona tra i suoi compiti. Serve a seguire i cambiamenti nel modo di lavorare, non a misurare direttamente le ore risparmiate. [1]

Quel denominatore cambia il modo in cui leggo il titolo. «L’IA guida una parte del lavoro» non può diventare automaticamente «ci serve una quota equivalente di persone in meno». Per sostenere la seconda affermazione vorrei sapere cosa fanno le persone dopo aver delegato, quanto tempo dedicano alle verifiche e se la qualità o il volume dei risultati accettati sono cambiati.

Immaginiamo un ingegnere che delega un esperimento e poi passa il pomeriggio a controllare se il metodo di prova era valido. L’agente può aver guidato l’esecuzione mentre l’ingegnere continua a dedicare molto tempo al progetto. Oppure lo stesso ingegnere potrebbe verificare diversi esperimenti utili nel tempo prima necessario per uno solo. La classificazione dei compiti, da sola, non distingue queste situazioni.

Userei il rapporto per individuare le domande di una valutazione più precisa, come uso i confronti tra benchmark di IA per decidere cosa merita una prova. Il passo successivo utile è collegare la delega ai risultati accettati e all’impegno richiesto dalla revisione. Altrimenti un team può misurare più attività dell’IA senza capire se il proprio lavoro è migliorato.

Significa che l’IA si migliora autonomamente?

In un altro saggio, When AI builds itself, Anthropic afferma che l’auto-miglioramento ricorsivo non è ancora stato raggiunto e non è inevitabile. Indica inoltre la scelta degli obiettivi di ricerca e la valutazione dei risultati come ambiti in cui l’esperienza umana resta importante. Il rapporto descrive quindi l’organizzazione della ricerca, non un ciclo di sviluppo che procede interamente da solo. [3]

L’auto-miglioramento ricorsivo richiederebbe più del contributo di codice al modello successivo. L’affermazione interessante è che i miglioramenti permettano al sistema di realizzarne altri dipendendo meno dalle persone. Una singola contribuzione utile non dimostra l’esistenza di quel processo continuo. Esamino la stessa distinzione nel resoconto di Z.ai sull’uso di GLM per ottimizzare il software di inferenza.

La mia lettura è che la pressione immediata ricada sulla verifica. Se proporre un esperimento diventa più facile, qualcuno deve comunque decidere se risponde alla domanda. Una spiegazione ben scritta di una prova mal progettata può rendere il controllo più difficile, perché aggiunge materiale plausibile da verificare.

Per questo separerei il meccanismo che produce una risposta dalle prove usate per accettarla. Nello sviluppo software potrebbe significare verificare il comportamento rispetto a requisiti e test che non siano stati riscritti per adattarsi alla patch. Nella ricerca significa chiedersi quale risultato metterebbe in dubbio la spiegazione proposta. Sono scelte di valutazione, non ulteriori risultati del rapporto di Anthropic.

Cosa cambierei in un flusso di lavoro di programmazione?

Definirei la revisione necessaria prima di delegare un compito più ampio. L’agente ha bisogno di un risultato atteso chiaro, ma chi lo verifica deve anche poter stabilire che sia corretto. Mi sembra una risposta più utile al rapporto che aumentare semplicemente il numero di agenti.

Per un’indagine chiederei le prove a sostegno della conclusione e le contraddizioni ancora aperte. Per una modifica al codice chiederei quale comportamento è cambiato e come è stato verificato. Valuterei poi se la revisione richiede meno impegno del lavoro svolto direttamente, incluso il tempo necessario a correggere un errore inizialmente convincente.

La stessa domanda va posta nella progettazione di applicazioni basate sulla OpenAI Agents API. Un’applicazione può delegare l’esecuzione lasciando l’accettazione alla persona responsabile del risultato. Decidere dove avviene questa accettazione fa parte del progetto del prodotto.

Al prossimo lancio di un modello, guarderei a ciò che un revisore può verificare dopo una lunga esecuzione. Un modello che svolge più lavoro è utile; sapere su quali parti si può fare affidamento determina quanto di quel lavoro posso davvero accettare.