Il dominio batterà il codice: perché l'agente sposta il collo di bottiglia
I manager programmano con più successo dei software engineer. Il dato Anthropic su 400.000 sessioni Claude Code ridisegna chi può creare software, e come.
Manager, avvocati e analisti finanziari completano task di coding con tassi di successo che distano 7 punti percentuali dai software engineer. In alcuni casi li superano.
Non è un aneddoto. È il dato principale emerso dall'analisi di Anthropic su 400.000 sessioni reali di Claude Code, condotta su 235.000 utenti tra ottobre 2025 e aprile 2026 e pubblicata a giugno 2026.
I ricercatori hanno etichettato ogni sessione per professione dell'utente, livello di expertise sul task specifico e tasso di verified success: commit passati, test superati, conferme esplicite dell'utente. Il risultato ribalta l'idea comune che l'AI "democratizzi la programmazione".
La democratizzazione c'è, ma non nel senso che chiunque può programmare. Il dato dice qualcosa di più preciso: la barriera non è mai stata la sintassi. Era la capacità di specificare e validare. E ora che l'agente ha reso irrilevante la prima, la seconda è diventata l'unica cosa che conta.
L'agente non sostituisce la competenza: la cambia di natura. Non serve più saper scrivere codice. Serve sapere cosa far scrivere. E saper dire se è giusto.
La divisione del lavoro: tu decidi cosa, Claude decide come
Il rapporto introduce una distinzione tra planning (cosa fare, quale approccio, cosa significa "fatto") ed execution (quali file toccare, che codice scrivere, quali comandi eseguire). In una sessione, l'umano prende il 70% delle decisioni di pianificazione ma solo il 20% di quelle di esecuzione. Claude fa il resto.
Non è un dettaglio. È il perno che spiega tutto il resto.
Quando un utente con dominio sulla materia dice a Claude esattamente quali regole di riconciliazione deve applicare uno script contabile, e poi riconosce l'edge case che l'agente ha gestito male, quella sessione ha molte più probabilità di successo rispetto a un prompt generico. L'expertise di dominio si traduce direttamente in specifiche più precise e validazione più efficace: le due cose che l'agente non può inventare.
In una sessione classificata come novice, ogni prompt dell'utente innesca circa 5 azioni di Claude e 600 parole di output. In una sessione expert, ogni prompt produce 12 azioni e 3.200 parole: più del doppio di azioni, più del quintuplo di output.
Chi programma con successo (non sono solo i programmatori)
I dati per professione sono il punto di novità principale. Tra le sessioni che producono codice, ognuna delle dieci professioni più rappresentate nel dataset raggiunge tassi di verified success entro 7 punti percentuali dai software engineer. I manager, in particolare, registrano tassi leggermente superiori agli stessi sviluppatori.
La metodologia è importante: il classificatore di Anthropic inferisce la professione dal contesto del progetto (documenti legali, report finanziari, file clinici) e non dall'atto di scrivere codice. Un avvocato che usa Claude per generare uno script che segnala clausole mancanti in una cartella di contratti viene classificato come Legal Occupations, non come programmatore.
Le professioni non-software in più rapida crescita nel dataset sono management, sales e legal. Il dato è stabile: il gap di 5 punti tra professioni software e non-software non si è né allargato né ristretto in sette mesi, anche se i tassi di successo di entrambi i gruppi sono migliorati.
Gli autori lo dicono esplicitamente: «Il successo è determinato da quanto bene una persona capisce il problema che sta cercando di risolvere, non dal fatto che sia stata formata nella programmazione.» E ancora: «Gli agenti di coding stanno rendendo un background di programmazione meno rilevante per programmare con successo.»
Il contro-dato: la sessione è riuscita, ma il codice è buono?
Qui serve una pausa. Il verified success di Anthropic misura evidenze verificabili di completamento: commit, test passati, conferme dell'utente. Non misura se il codice prodotto è effettivamente usato dopo la sessione, o se sopravvive nel tempo.
Il dataset SWE-chat, che analizza sessioni reali di coding agent da repository pubblici, fornisce un contrappunto importante: solo il 44% del codice prodotto dagli agenti sopravvive fino al commit umano. In altre parole, più della metà di ciò che l'agente scrive viene scartato prima di entrare nel repository.
Il dataset mostra anche che i pattern di coding sono bimodali. Nel 41% delle sessioni l'agente produce virtualmente tutto il codice commitato: è il cosiddetto vibe coding. Nel 23% dei casi, invece, è l'umano a scrivere tutto. Gli utenti spingono indietro contro l'output dell'agente (con correzioni, segnalazioni di fallimento, interruzioni) nel 44% dei turni di conversazione.
C'è una tensione reale tra "la sessione è andata a buon fine" e "il codice è effettivamente utilizzabile". Il verified success di Anthropic cattura il primo. SWE-chat documenta il secondo. La verità sta nel mezzo, ed è qui che il dominio torna a contare.
Il framework Fowler/Majors: il codice come cache dell'understanding
Chad Fowler, nel suo saggio The Deletion Test, propone un esercizio mentale che calza con questi dati: immagina di cancellare l'intera implementazione del tuo software. Se il pensiero ti fa venire il voltastomaco, non è perché sei imprudente. È perché non sai cosa sopravviverebbe.
Quando il codice è l'unico posto in cui risiede la conoscenza (delle regole di business, degli edge case, dei bug corretti intenzionalmente), cancellarlo è impensabile. Ma quando la conoscenza vive altrove (in specifiche, test, contratti, segnali operativi), il codice diventa quello che Fowler chiama «una vista materializzata dell'understanding: utile finché è corrente, sacrificabile quando è obsoleto.»
Charity Majors ha ripreso questo framework e l'ha portato alle conseguenze operative. La sua tesi: l'AI non riduce la necessità di disciplina ingegneristica; la aumenta. Perché se puoi rigenerare codice a costo zero, l'unica cosa che conta è la qualità del sistema di validazione. Test, observability, behavioural test, characterization test: tutto ciò che ti permette di distinguere "codice corretto" da "codice che sembra corretto" senza doverlo leggere riga per riga.
Il dato Anthropic lo conferma: in sette mesi, la quota di sessioni dedicate al debugging è scesa dal 33% al 19%, mentre il valore stimato del task medio è salito del 27%. Claude sta diventando più capace, e gli utenti stanno imparando a delegare meglio. Ma il debugging che resta è presumibilmente quello più difficile: richiede di capire perché qualcosa non funziona, non come aggiustarlo.
Cosa significa in pratica: chi vince e chi perde
Ecco il punto: il coding agent non abbatte la barriera all'ingresso. La sposta.
Prima la barriera era saper scrivere codice. Ora è saper specificare cosa il codice deve fare e saper validare che lo faccia. La prima era una barriera tecnica, insegnabile. La seconda è una barriera di dominio, che richiede esperienza sul campo.
Per i software engineer junior, questo è un problema serio. Non hanno né il dominio profondo dell'avvocato che sa esattamente quali clausole cercare, né l'esperienza architetturale del senior che sa quali astrazioni funzioneranno su scala. Hanno una competenza di sintassi che l'agente ha reso commodity e il loro margine si è assottigliato.
Il junior developer oggi è nella posizione peggiore: non ha il dominio del lawyer, non ha l'architettura del senior, e la sintassi non vale più niente.
Per i domain expert con capacità di specifica, è un moltiplicatore di forza inedito. Tre profili guadagnano più di tutti dallo shift:
- Il manager che sa esattamente cosa deve succedere in produzione e può delegare all'agente con la precisione di chi conosce gli outcome attesi.
- L'analista che padroneggia le regole di trasformazione dei dati e ora le applica direttamente senza passare da un team di sviluppo.
- Il legale che conosce la logica di riconciliazione e può farla eseguire all'agente invece di spiegarla a qualcuno.
Per i manager in particolare, il dato suggerisce qualcosa di intrigante: le competenze manageriali (delegare con precisione, specificare outcome attesi, verificare risultati) sono esattamente le competenze che servono per pilotare un agente di coding. Non è un caso che i loro tassi di verified success siano leggermente superiori a quelli degli sviluppatori.
Cosa non sappiamo ancora
Lo studio ha limiti importanti.
- Sessioni headless escluse: prompt singoli da riga di comando, sessioni via SDK e integrazioni IDE di terze parti. Rappresentano una quota sostanziale dell'uso reale e non compaiono nel dataset.
- Nessuna misurazione di outcome reali: non sappiamo se il codice prodotto in una sessione viene effettivamente usato, deployato, o abbandonato la settimana dopo.
- Classificazioni fatte da un modello: Claude Sonnet 4.6 legge i transcript e inferisce expertise, professione e successo. L'accordo con la telemetria indipendente è direzionale (i trend coincidono), mentre l'accordo con un reference model separato mostra concordanza nella maggior parte delle classificazioni.
Soprattutto, non sappiamo se il pattern reggerà. Se i modelli continueranno a migliorare, potrebbe ridursi anche il gap di expertise: la capacità di specificare e validare potrebbe diventare meno critica se l'agente impara a fare domande migliori. Per ora, i dati dicono che il dominio resta il fattore predittivo più forte del successo.
Il trend in sette mesi non mostra segni di convergenza.
Nel frattempo, l'adozione degli agenti di coding continua ad accelerare. Uno studio separato sui repository GitHub pubblici mostra che l'adozione è più che raddoppiata rispetto a fine 2025, e l'uso è «significativamente più intensivo» in termini di commit assistiti dall'agente.
Il collo di bottiglia si è spostato. Dalla sintassi alla semantica, da "so scrivere codice" a "so cosa far scrivere." La domanda non è più se sai programmare: è se sai cosa deve fare il programma.
Further Reading
Joachim Baumann
Romain Robbes
Charity Majors
