Hacker News sostiene l’esperienza con gli LLM, ma le prove sulla produttività sono più complesse

Hacker News ha portato il saggio del 24 luglio di Sean Goedecke al centro di un dibattito più ampio, nonostante una tesi che inizialmente suona quasi rassicurante: gli LLM premiano l’esperienza.

L’argomento mette in discussione una lettura diffusa dell’IA generativa. I modelli linguistici di grandi dimensioni, o LLM, possono offrire a quasi chiunque codice, prosa, analisi e spiegazioni accettabili. Questo accesso sembra appiattire le differenze tra principianti e specialisti.

Goedecke sostiene che accada l’opposto quando il compito diventa difficile. I principianti possono ottenere un risultato accettabile, ma gli esperti sanno individuare direzioni promettenti, scartare errori sottili e guidare il modello verso risposte migliori. Lo stesso modello produce quindi valore ineguale.

Questa tesi ha raccolto centinaia di voti e oltre 100 commenti su Hacker News. Arriva inoltre in un momento complesso per la ricerca sulla produttività dell’IA. Gli studi mostrano oggi un lavoro più rapido in alcuni contesti, più lento in altri e una persistente difficoltà nel misurare ciò che gli utenti esperti guadagnano realmente.

Il vero conflitto non è tra esperti e IA. È tra accesso generalizzato e giudizio informato. I modelli rendono disponibili più capacità, ma è l’esperienza a determinare quali capacità resistano al contatto con il lavoro reale.

Il dibattito su Hacker News è iniziato con un esperto al lavoro

L’esempio centrale del saggio mostra che un prompting esperto riguarda meno formule speciali e più il controllo informato di una conversazione.

Nel suo saggio sull’esperienza con gli LLM, Goedecke indica il matematico Terence Tao mentre discute con ChatGPT un controesempio relativo alla Congettura Jacobiana. Tao non si affida a un prompt lungo e accuratamente elaborato.

I suoi messaggi sono spesso brevi. Reindirizza la conversazione quando un approccio diventa inutilmente complesso. Propone passaggi matematici, nota dettagli sospetti e decide quali frammenti meritino ulteriori verifiche.

Un principiante può imitare i messaggi brevi. Non può però riprodurre il processo di valutazione di Tao, perché i prompt utili dipendono da una comprensione matematica che esiste prima dell’inizio della conversazione.

Questa distinzione è importante perché le discussioni sul prompting si concentrano spesso sulla sintassi. Agli utenti viene consigliato di assegnare un ruolo, fornire esempi, richiedere un formato o chiedere al modello di ragionare passo dopo passo. Queste tecniche possono migliorare un’interazione, ma non creano giudizio di dominio.

Un esperto sa approssimativamente che aspetto dovrebbe avere il risultato. Può rilevare quando una risposta viola un vincolo non esplicitato, ignora la cronologia rilevante o propone una soluzione tecnicamente valida ma comunque sbagliata per la situazione.

Un ingegnere software che lavora in una codebase conosciuta dispone di vantaggi simili. Sa quali astrazioni esistono già, dove sono fallite le migrazioni precedenti e quale modifica apparentemente pulita creerà un problema operativo.

Questa conoscenza permette interventi precisi. Un esperto può chiedere perché il modello abbia introdotto una nuova interfaccia, se un helper esistente risolva già il problema o se una modifica più contenuta conserverebbe la compatibilità.

Un principiante di solito non dispone di questi punti di riferimento. Può richiedere codice funzionante, ma potrebbe accettare logica duplicata, dipendenze fragili o una soluzione che ignora le convenzioni locali. Un output fluente rende questo pericolo più difficile da individuare.

La discussione su Hacker News ha esteso questa osservazione oltre la matematica e il software. I commentatori hanno descritto schemi simili nel diritto, nella medicina, nella scrittura tecnica, nell’edilizia, nell’elettronica e nella ricerca.

Diversi resoconti seguivano la stessa struttura. L’IA ha aiutato gli utenti a entrare in territori poco familiari, ma la qualità del risultato dipendeva dalla capacità di qualcuno di riconoscere errori nascosti. L’esperienza contava soprattutto durante la verifica e la revisione.

Altri commentatori hanno contestato la natura rassicurante della tesi. I professionisti qualificati preferiscono naturalmente un futuro in cui la conoscenza accumulata diventa più preziosa. Un argomento virale che conferma quel futuro merita un esame attento.

Questa critica non invalida gli esempi di Goedecke. Stabilisce la domanda a cui le prove devono rispondere: l’esperienza aumenta in modo coerente i rendimenti degli LLM, oppure gli esperti notano semplicemente i casi in cui ciò accade?

L’esperienza sposta il collo di bottiglia dalla produzione al giudizio

Gli LLM riducono il costo di produrre una risposta, ma non eliminano il costo di decidere se quella risposta abbia posto nel mondo reale.

Prima della diffusione degli LLM, una lacuna di conoscenza spesso bloccava un compito. Chi non sapeva scrivere CSS, interrogare un database o interpretare un contratto aveva bisogno di un collega, un corso o un esempio online molto simile.

Ora un modello può produrre un punto di partenza plausibile in pochi secondi. Questo cambiamento trasforma più persone in generalisti funzionali, soprattutto quando il compito ha convenzioni chiare e conseguenze limitate.

Il risultato sembra una compressione delle competenze. Il primo tentativo di un principiante si avvicina di più all’output ordinario di un lavoratore esperto. Tuttavia, questa compressione riguarda soprattutto la produzione, non la responsabilità.

Generare una risposta e assumersene la responsabilità restano attività diverse. La responsabilità richiede di decidere quali prove contino, quali vincoli si applichino e quale sarebbe il costo di un fallimento.

Si consideri un ingegnere che chiede a un agente di modificare un sistema di autenticazione. L’agente può individuare file, generare test e proporre una patch. Non può sapere automaticamente ogni contratto non documentato che circonda il sistema.

Un ingegnere senior può ricordare che un client mobile invia ancora un vecchio formato di token. Il repository potrebbe non esprimere chiaramente questa dipendenza. Senza questo contesto, il modello può produrre codice coerente a livello locale che interrompe un flusso di lavoro reale di un cliente.

Il vantaggio dell’esperto deriva da una teoria operativa del sistema. Questa teoria include architettura, storia, contesto sociale e conseguenze operative. Agisce come filtro sulle proposte del modello.

Un buon retrieval può estendere questo vantaggio. Una knowledge base ingegneristica ricercabile può far emergere decisioni e documentazione locale che altrimenti resterebbero disperse.

Il retrieval non sostituisce però il giudizio. I documenti possono essere obsoleti, incompleti o incoerenti internamente. Qualcuno deve comunque decidere quale fonte rifletta la realtà attuale.

Per questo le sole finestre di contesto non risolvono il problema dell’esperienza. Un modello può assimilare più codice, documenti e messaggi, ma un contesto aggiuntivo non garantisce che individui il vincolo decisivo.

L’esperienza aiuta gli utenti a comprimere un ambiente disordinato in istruzioni rilevanti. Un utente informato sa quali dettagli siano abbastanza importanti da includere e quali assunzioni generate richiedano un controllo.

Il collo di bottiglia si sposta quindi. Quando la generazione diventa economica, la valutazione assorbe una quota maggiore del lavoro. La risorsa scarsa diventa una persona capace di riconoscere la qualità prima che le conseguenze ne rivelino l’assenza.

Questo spostamento modifica anche l’aspetto del prompting efficace. Il prompt più forte può essere una breve correzione basata su un modello mentale profondo, non un blocco riutilizzabile di istruzioni elaborate.

Un avvocato potrebbe chiedere al modello di riconsiderare una clausola in base a una determinata giurisdizione. Uno scienziato potrebbe respingere una spiegazione causale apparentemente sensata perché entra in conflitto con il disegno sperimentale.

Un product manager potrebbe notare che una strategia generata tratta le preferenze dichiarate dai clienti come comportamento osservato. Ogni correzione è piccola sul piano linguistico, ma ampia per la conoscenza implicita che contiene.

Questo meccanismo sostiene la tesi del saggio senza richiedere un talento mistico per il prompting. Gli esperti estraggono più valore perché restringono la ricerca del modello, diagnosticano gli errori e forniscono informazioni assenti dal prompt.

Spiega anche perché l’accesso per i principianti resti prezioso. I principianti possono completare compiti prima irraggiungibili. Affrontano semplicemente un rischio maggiore di scambiare la plausibilità per adeguatezza.

Lo stesso LLM può amplificare gli esperti e fuorviarli

L’esperienza migliora la capacità di guidare il modello, ma l’assistenza del modello resta abbastanza disomogenea da premiare la fiducia proprio nel momento sbagliato.

Le prove più solide non sostengono una semplice tesi secondo cui l’IA aiuta sempre gli esperti. Mostrano un confine frastagliato, in cui l’assistenza migliora alcuni compiti e ne danneggia altri.

Un ampio esperimento sul campo che ha coinvolto 758 knowledge worker di Boston Consulting Group ha testato GPT-4 su incarichi realistici di consulenza. L’esperimento sul lavoro pubblicato ha rilevato guadagni sostanziali nei compiti che rientravano nelle capacità del modello.

I partecipanti con l’IA hanno completato il 12,2 percento di compiti in più e lavorato in media il 25,1 percento più rapidamente entro quel confine di capacità. Anche la qualità del loro output è migliorata.

Il risultato si è invertito in un compito complesso al di fuori della frontiera effettiva del modello. Gli utenti dell’IA avevano il 19 percento di probabilità in meno di produrre una soluzione corretta rispetto ai partecipanti che lavoravano senza di essa.

I ricercatori chiamano questo confine irregolare la frontiera tecnologica frastagliata. Compiti che a una persona sembrano altrettanto difficili possono cadere su lati opposti di ciò che un modello gestisce in modo affidabile.

Questa scoperta rafforza una parte dell’argomento sull’esperienza. Gli utenti qualificati devono riconoscere su quale lato della frontiera si trovano. Eppure l’esperimento mostra anche perché la sola esperienza non offra alcuna garanzia.

Una risposta plausibile del modello può convincere una persona competente ad abbandonare un ragionamento corretto. Gli specialisti hanno i propri pregiudizi, pressioni temporali e punti ciechi. La fluidità può far sembrare una risposta difettosa sufficientemente completa.

Il problema diventa più difficile perché la frontiera si muove. Un compito che superava le capacità di un modello alcuni mesi fa potrebbe ora essere ordinario. Un altro può apparire risolto in un benchmark, ma fallire sotto vincoli locali.

Gli esperti devono quindi apprendere due domini contemporaneamente. Hanno bisogno di conoscenza del lavoro sottostante e di un modello aggiornato dei limiti del sistema di IA.

Questo crea una forma insolita di calibrazione. Gli utenti devono sapere quando delegare, quando collaborare e quando escludere il modello dal passaggio decisivo del ragionamento.

Uno specialista che diffida di ogni output spreca la capacità del modello. Uno specialista che si fida per impostazione predefinita di un output fluente rischia di automatizzare gli errori a maggiore velocità.

Il miglior schema di lavoro si colloca tra questi estremi. L’essere umano fornisce obiettivi, vincoli e punti di controllo. Il modello esplora possibilità, redige artefatti o cerca in uno spazio di soluzioni più ampio.

L’essere umano valuta poi il risultato usando prove che non provengono soltanto dalla stessa conversazione. Test, documenti fonte, metriche di produzione e calcoli indipendenti diventano particolarmente importanti.

Questo schema differisce dal trattare il modello come un oracolo. Differisce anche dal suo utilizzo esclusivamente come sistema di completamento automatico. Il modello diventa un collaboratore fallibile, il cui valore dipende dalla selezione del compito.

Per i knowledge worker, mantenere il contesto delle fonti può rendere questa collaborazione più difendibile. Una knowledge base personale basata sull’IA può preservare le prove alla base delle decisioni invece di lasciare soltanto riepiloghi generati.

La lezione di fondo non è che gli esperti vincano sempre. È che l’esperienza rende possibile un controllo migliore, mentre l’affidabilità disomogenea del modello rende quel controllo necessario.

La ricerca sulla produttività rifiuta un verdetto semplice

Le prove sostengono una complementarità specifica per compito, non una regola universale secondo cui esperti o principianti traggono maggiori vantaggi dall’IA.

Lo sviluppo software rappresenta la sfida più netta alla tesi di Hacker News. Gli sviluppatori esperti sembrano nella posizione ideale per guidare gli agenti di programmazione, eppure uno studio importante ha rilevato che l’AI li rendeva più lenti.

METR ha condotto uno studio controllato randomizzato con 16 sviluppatori open source esperti, impegnati in 246 attività reali. I partecipanti avevano lavorato sui progetti pertinenti per una media di cinque anni.

Lo studio sulla produttività degli sviluppatori consentiva, per attività selezionate casualmente, l’uso dei comuni strumenti di inizio 2025, principalmente Cursor Pro e Claude 3.5 o 3.7 Sonnet. Per le altre attività, l’assistenza AI era vietata.

Prima di iniziare, gli sviluppatori avevano previsto che l’AI avrebbe ridotto del 24 percento il tempo di completamento. Dopo lo studio, hanno stimato una riduzione del 20 percento.

I risultati misurati indicavano la direzione opposta. Le attività con accesso all’AI richiedevano il 19 percento di tempo in più.

I ricercatori hanno esaminato 20 possibili spiegazioni, tra cui la complessità dei progetti, gli standard di qualità e la familiarità con gli strumenti. Hanno concluso che gli artefatti sperimentali difficilmente potevano spiegare l’intero rallentamento.

Questo risultato sembra contraddire l’idea che gli LLM premiano l’esperienza. Questi sviluppatori possedevano una profonda conoscenza del dominio e lavoravano all’interno di repository che comprendevano.

Tuttavia, la contraddizione è più circoscritta di quanto appaia inizialmente. L’esperienza può migliorare la qualità dell’output o ridurre lo sforzo mentale senza ridurre il tempo effettivamente trascorso. Anche la revisione del codice generato introduce un nuovo costo.

Un esperto può dedicare diversi minuti alla lettura di una patch plausibile prima di individuare un problema nascosto. Scrivere direttamente la soluzione corretta avrebbe potuto richiedere meno tempo.

I repository consolidati creano inoltre un ambiente difficile per gli agenti attuali. I progetti maturi contengono convenzioni implicite, lunghe storie e requisiti di qualità che resistono alla compressione in un prompt.

Lo studio ha fotografato una generazione di strumenti e un tipo di lavoro. Non ha stabilito una legge permanente per tutti gli sviluppatori, gli agenti o i repository.

L’esperienza successiva di METR illustra il problema. Nel febbraio 2026, l’organizzazione ha dichiarato che il suo esperimento più recente non poteva più fornire una stima affidabile della produttività AI attuale.

Il suo aggiornamento sull’esperimento ha riferito che alcuni sviluppatori si rifiutavano di partecipare se a metà delle loro attività fosse vietata l’AI. Tra il 30 e il 50 percento ha inoltre escluso determinate attività perché non voleva completarle senza AI.

Queste scelte hanno creato un bias di selezione. L’esperimento perdeva sistematicamente utenti e attività per cui ci si aspettava il maggior beneficio dagli agenti.

I risultati grezzi successivi suggerivano un miglioramento, ma gli intervalli di confidenza restavano ampi. METR ha esplicitamente avvertito di non considerare tali stime come una misura affidabile degli attuali guadagni di velocità.

Questo sviluppo conta più di qualsiasi singola percentuale. L’uso dell’AI modifica il comportamento delle persone studiate, mentre strumenti in rapido cambiamento compromettono confronti stabili.

Il problema di misurazione va inoltre oltre la velocità. Un agente potrebbe ridurre lo sforzo attivo aumentando al tempo stesso il tempo trascorso, perché lo sviluppatore lavora altrove durante la generazione. I tradizionali timer delle attività faticano a gestire agenti paralleli.

Al contrario, un completamento più rapido può nascondere costi futuri. Il codice generato può creare lavoro di manutenzione, indebolire la comprensione o trasferire complessità ai revisori.

Le organizzazioni hanno quindi bisogno di misure più ampie. Il cycle time resta utile, ma i team dovrebbero anche monitorare tassi di difetti, carico di revisione, frequenza dei rollback e tempo dedicato a comprendere le modifiche generate.

Dovrebbero segmentare i risultati per attività. Generazione di boilerplate, scaffolding dei test, pianificazione delle migrazioni, debugging e progettazione architetturale impongono richieste diverse sia ai modelli sia alle persone.

Le prove disponibili sostengono una conclusione condizionale. L’esperienza migliora la capacità di usare un LLM, ma un’interazione migliore non produce automaticamente un flusso di lavoro più rapido.

Il vero rischio è perdere l’esperienza che rende utile l’AI

Se le organizzazioni automatizzano il lavoro attraverso cui le persone sviluppano giudizio, possono indebolire la capacità umana che mantiene affidabile l’output degli LLM.

L’argomento di Hacker News si concentra sul valore dell’esperienza esistente. La domanda più difficile riguarda il modo in cui i lavoratori del futuro la acquisiranno.

Gli esperti non hanno iniziato con modelli mentali rifiniti. Li hanno costruiti leggendo materiale difficile, commettendo errori, ricevendo feedback e confrontandosi ripetutamente con i dettagli.

Molti incarichi di livello iniziale servono a due scopi. Producono un artefatto immediato e formano la persona che lo produce.

Un sistema AI può completare l’artefatto aggirando parte del processo di apprendimento. L’organizzazione vede efficienza nel breve termine, ma il lavoratore riceve meno opportunità per sviluppare giudizio indipendente.

Questa tensione emerge nell’ingegneria del software. Gli sviluppatori junior imparano tradizionalmente i sistemi correggendo piccoli bug, tracciando i flussi di dati e scrivendo test di routine.

Se gli agenti gestiscono queste attività, gli ingegneri junior possono consegnare più lavoro acquisendo però meno comprensione del perché il sistema si comporti in quel modo. In seguito, potrebbero non avere le basi necessarie per rivedere modifiche più complesse.

Lo stesso schema si applica ad analisti, ricercatori e scrittori. Riassumere documenti sviluppa la comprensione delle prove. Abbozzare un argomento mette in luce le lacune logiche. Rivedere una prosa debole chiarisce il rapporto tra linguaggio e pensiero.

I ricercatori Microsoft hanno messo in guardia da questa transizione. La loro ricerca sul lavoro della conoscenza descrive il rischio che i lavoratori diventino validatori di opinioni prodotte dalle macchine.

La preoccupazione non è semplice nostalgia per il lavoro manuale. La valutazione stessa dipende dalla conoscenza. Una persona che non costruisce mai tale conoscenza non può in seguito validare in modo affidabile il modello.

Le organizzazioni affrontano un problema di feedback ritardato. Gli effetti dannosi di un apprendimento ridotto possono restare invisibili mentre gli esperti attuali supervisionano l’output dell’AI.

La carenza emerge solo dopo che il personale esperto se ne va, i sistemi cambiano oppure un guasto insolito richiede un ragionamento che non può essere delegato in sicurezza.

Esiste anche un problema di distribuzione. L’AI può aiutare i principianti nelle attività circoscritte, aumentando al contempo il vantaggio relativo dei migliori specialisti in quelle complesse.

Questa combinazione produce maggiore accesso e maggiore concentrazione allo stesso tempo. Più persone possono produrre lavoro accettabile, mentre un gruppo più ristretto controlla il giudizio necessario per decisioni ad alta posta in gioco.

Le aziende possono reagire ponendo dipendenti senior a supervisione di bacini più ampi di produzione assistita dall’AI. Questa struttura può aumentare il throughput, ma può anche sovraccaricare i revisori e restringere il percorso verso la seniority.

Una risposta diversa tratterebbe l’apprendimento come un output esplicito. I team potrebbero chiedere agli utenti di spiegare importanti modifiche generate, conservare registri delle decisioni e far ruotare il personale nel lavoro di verifica.

I manager potrebbero separare l’accelerazione a basso rischio dal lavoro cruciale per la formazione. Non ogni attività manuale merita protezione, ma alcune attività apparentemente inefficienti costruiscono un giudizio trasferibile.

I prodotti AI possono anche sostenere il pensiero invece di sostituirlo. Un sistema potrebbe far emergere prove contraddittorie, chiedere una previsione prima di rivelare una risposta o invitare l’utente a confrontare alternative.

Questi progetti creano attrito, ma un attrito utile può rendere visibile il ragionamento. L’obiettivo non è rallentare ogni attività. È evitare di ottimizzare l’output erodendo silenziosamente le capacità.

Il caso scettico contro l’idea che “gli LLM premiano l’esperienza” ha quindi un peso reale. L’affermazione descrive i rendimenti attuali, non la futura disponibilità di esperti.

I modelli possono premiare l’esperienza oggi indebolendone però lo sviluppo domani. Che ciò accada dipende dalla progettazione dei flussi di lavoro, dagli incentivi, dall’istruzione e da come le organizzazioni misurano il successo.

Cosa deve dimostrare ora la tesi di Hacker News

La prossima fase delle prove deve misurare risultati duraturi, strumenti in cambiamento e lo sviluppo dell’esperienza, non soltanto il completamento immediato delle attività.

Tre segnali mostreranno se la tesi di Hacker News resiste oltre gli aneddoti convincenti.

Il primo è una ricerca sulla produttività ripetuta usando agenti attuali. Il primo studio di METR ha catturato lavoro reale, ma l’adozione successiva ha reso difficile sostenere lo stesso disegno sperimentale.

I nuovi studi necessitano di metodi che tengano conto degli agenti paralleli, della selezione delle attività e degli utenti che considerano l’AI essenziale. Se gli sviluppatori esperti mostrano guadagni sostenuti in queste condizioni, la tesi dell’esperienza diventa più forte.

Se i risultati restano negativi su sistemi familiari, l’affermazione richiede una delimitazione. L’esperienza può migliorare controllo e qualità senza migliorare la velocità.

Il secondo segnale è la qualità misurata dopo il deployment. I team hanno bisogno di prove su difetti, incidenti di sicurezza, carico di manutenzione e inversioni di rotta diverse settimane dopo la consegna del lavoro assistito dall’AI.

Il tempo di completamento immediato non può rivelare se un esperto abbia individuato errori sottili o abbia semplicemente approvato un output fluente. Gli esiti longitudinali possono distinguere una leva reale dalla pulizia rimandata.

Un risultato forte dimostrerebbe che gli esperti usano gli agenti per muoversi più rapidamente senza spostare i costi a valle. Un risultato debole mostrerebbe un throughput maggiore accompagnato da revisione e manutenzione più pesanti.

Il terzo segnale è la progressione dei lavoratori junior. Le organizzazioni dovrebbero esaminare se gli utenti frequenti dell’AI diventino risolutori di problemi indipendenti migliori dopo mesi di lavoro assistito.

Prontezza alla promozione, capacità di debugging, comprensione dei sistemi e prestazioni senza AI possono rivelare se lo strumento supporta l’apprendimento. Il solo volume di output non basta.

Se i lavoratori junior si sviluppano più rapidamente usando i modelli, l’AI diventa un acceleratore dell’esperienza. Se restano dipendenti dalle risposte generate, il mercato del lavoro potrebbe affrontare un divario crescente tra produzione e giudizio.

La conclusione più ampia è già visibile. Gli LLM non rendono irrilevante l’esperienza, ma non ne moltiplicano automaticamente neppure il valore economico.

Cambiano il punto in cui opera l’esperienza. Gli specialisti dedicano meno tempo alla produzione delle prime bozze e più tempo alla selezione dei problemi, alla definizione dei vincoli, al test degli output e all’assunzione di responsabilità.

Questa transizione premia le persone che sanno distinguere una risposta plausibile da una adeguata. Crea inoltre pressione per preservare i processi di apprendimento che producono tali persone.

Il dibattito su Hacker News conta perché rifiuta due narrazioni semplici. L’AI non è né un livellatore universale né un semplice amplificatore per ogni esperto.

È un collaboratore variabile che opera lungo una frontiera disomogenea. Gli utenti più capaci conoscono il dominio, comprendono il sistema e riconoscono quando il modello non dovrebbe guidare.

I lettori dovrebbero verificare questa affermazione nel proprio lavoro. Monitorate dove l’AI fa risparmiare tempo, dove la revisione consuma quel risparmio e quali attività richiedono ancora conoscenze che nessun prompt può fornire.

La prossima volta che un modello produce una risposta impressionante, ponetevi una domanda più difficile: chi possiede abbastanza esperienza per sapere se è quella giusta?