L’AI nel lavoro quotidiano: una risposta che dipende da chi sei
L’impatto dell’AI dipende molto dalla natura del lavoro. In ogni caso, queste tecnologie non annullano il bisogno di competenze: lo rafforzano.
Rispondo interpretando la parola “sviluppare” in senso generale e non limitata alla sola “produzione di software”. Credo che il tema sollevato da Gianluca richieda implicitamente tale generalizzazione.
Il mondo di Karpathy (e i suoi limiti)
Nel 2017, Andrej Karpathy pubblicò un saggio intitolato “Software 2.0”: le reti neurali stanno diventando un nuovo modo di scrivere software. Invece di istruire esplicitamente la macchina con regole e condizioni, l’alleni sui dati. Il vibe coding — termine che Karpathy ha contribuito a diffondere — porta il paradigma un passo oltre: non alleni più il modello, gli parli. Descrivi in linguaggio naturale: il modello genera il codice; tu supervisioni e iteri. Nell’orizzonte di Karpathy, gli agenti scrivono, testano e deployano in autonomia mentre l’umano orchestra dall’esterno.
In questo mondo — ricercatori AI, startup tech-first, sviluppatori di strumenti per sviluppatori — la pressione competitiva per l’adozione dell’AI è reale perché la velocità è un fattore determinante. Ma vale la pena fermarsi sui dati. Uno studio del METR, pubblicato a luglio 2025, ha misurato l'effetto degli strumenti AI su un campione di sviluppatori esperti che lavoravano sui propri repository open source: mentre questi credevano di lavorare il 20% più velocemente, i test oggettivi mostravano che erano il 19% più lenti. I dati di GitClear mostrano che l'adozione dell'AI ha più che raddoppiato il tasso di riscrittura del codice entro due settimane rispetto alla baseline del 2021, con un calo marcato in diverse misure di qualità — dal riuso del codice alla proliferazione dei duplicati. E chi ha provato ad applicare il vibe coding a qualcosa di più ambizioso di un prototipo conosce bene il problema che Ben Yoskovitz ha sintetizzato in un titolo: “Vibe Coding Without System Design is a Trap”. Quindi la velocità è importante, ma la persona ha un ruolo centrale nel garantire la qualità.
La risposta dipende dal settore, non dalla tecnologia
Peraltro, anche solo restando nel perimetro dello sviluppo software, il panorama è in realtà eterogeneo. Il software di sistema e gli strumenti per applicazioni di ricerca — compilatori, runtime, librerie di ML, firmware — sono il territorio naturale del paradigma Karpathy: alta densità di competenze tecniche, importanza della velocità.
Le applicazioni di business sono un pianeta a parte: ERP, CRM, sistemi gestionali, supply chain. Logiche di business stratificate in decenni di modifiche, regole fiscali che cambiano ogni anno, integrazioni con sistemi che nessuno ricorda più come funzionano. Qui, il codice generato da un LLM può essere sintatticamente corretto ma semanticamente sbagliato in modi che si manifestano solo mesi dopo, in produzione, durante un audit. E, in molti casi, il problema non è nemmeno scrivere codice, ma configurare e personalizzare le piattaforme. La criticità sta nel raccogliere e analizzare le informazioni necessarie per guidare questi processi.
Quando poi si esce dallo sviluppo software, la situazione cambia ancora più radicalmente. Il lavoro professionale — avvocati, medici, commercialisti — ha una relazione con la precisione e la responsabilità che non è negoziabile: un'allucinazione di un LLM in una parcella fiscale o in una cartella clinica non è un bug da correggere, ma un danno.
In ciascuno di questi settori, la domanda di Gianluca ha una risposta diversa. In alcuni casi la pressione per l’adozione è già intensa. In altri casi, i vincoli esistenti rallentano l’integrazione o ne limitano l’impatto non per inerzia culturale, ma per ragioni strutturali e di responsabilità del tutto legittime.
La risposta a una domanda che cambia forma
Allora: sarà antieconomico “sviluppare” senza AI?
Nel mondo di Karpathy — software di ricerca, strumenti per sviluppatori, startup tecnologiche — la pressione esiste già ed è destinata ad aumentare. Il differenziale di velocità tra chi usa strumenti AI e chi non li usa è reale in certi contesti, anche se più contenuto di quanto i titoli suggeriscano e da mediare tenendo conto della qualità finale. Chi sviluppa in quel territorio e ignora gli strumenti disponibili si troverà a giustificare tempi e costi che i suoi interlocutori non capiranno più.
Nelle applicazioni di business la risposta cambia forma. L’AI entra come strumento che valorizza il lavoro di chi già capisce il sistema: nell’analisi dei requisiti, nella documentazione, nel testing, nel refactoring guidato di codice legacy. Capire il sistema — la storia delle scelte fatte, i compromessi accettati, le dipendenze invisibili — rimane un lavoro umano che, ad oggi, nessun LLM esegue autonomamente per osmosi. Peraltro, sono fattori che riguardano tutti gli sviluppi e, quindi, l’osservazione ha riflessi anche sugli altri settori.
La consulenza vive di giudizio, lettura del contesto e fiducia costruita nel tempo: l'AI può accelerare la raccolta e l'analisi delle informazioni, ma il valore che il cliente paga non è l'informazione, bensì l'interpretazione di chi conosce la sua storia.
Non ho dati per dimostrarlo — ho un argomento strutturale ed epistemico, con tutti i limiti e i vantaggi che questo tipo di argomentazione comporta.
Il rischio concreto è rispondere alla domanda sbagliata: prendere il frame di Karpathy, applicarlo al proprio settore senza verificarne la pertinenza e investire tempo e denaro in adozioni che non producono il valore atteso — o che introducono rischi che non si sapeva di assumere.
Coda
La domanda di Gianluca merita una risposta onesta: sì, in certi contesti sviluppare senza AI credo che diventerà antieconomico. Ma quei contesti non sono il mondo — sono una parte di esso, per ora la più visibile nel dibattito, perché è la parte che lo produce. E le dinamiche non sono così chiare e nette da permettere affermazioni univoche che chiudano ogni discorso.
Non siamo tutti nerd. Il mondo del lavoro digitale non ha un solo futuro possibile — ne ha molti, uno per ciascun settore in cui operiamo. Chi capisce in quale di questi segmenti lavora e cosa l’AI può fare concretamente in quel segmento ha già un vantaggio su chi insegue una risposta universale a una domanda che universale non è.
Questo post è stato scritto con l’assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.
Fonti:
Karpathy, “Software 2.0”, Medium, 2017.
Karpathy, “Power to the people: How LLMs flip the script on technology diffusion”, apr 2025.
METR/arXiv, “Measuring the Impact of Early–2025 AI on Experienced Open-Source Developer Productivity”, lug 2025.
GitClear, “Coding on Copilot: 2023 Data Suggests Downward Pressure on Code Quality”, 2022–2025.
Yoskovitz, “Vibe Coding Without System Design is a Trap”, Focused Chaos, gen 2026.
Post abassavoce.it: “Perché non possiamo lasciare che le macchine pensino al nostro posto”, gen 2026.
Post abassavoce.it: “Claude Code e lo sviluppo di software”, apr 2026.
© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it
Buongiorno Prof, come sempre lettura molto interessante e che porta a riflessioni. Concordo sul fatto che sia l'industry ad influenzare pesantemente la risposta alla domanda, così come il tenere conto di tutte le componenti complessive di una sw solution