Chi è scettico sull'AI è completamente fuori di testa: ecco chi lo dice

Thomas Ptacek, veterano della sicurezza informatica e ingegnere software presso Fly.io, ha recentemente scosso la comunità tech con un post dal titolo provocatorio: “All of my AI skeptic friends are crazy” ovvero “i miei amici scettici sull’AI sono tutti fuori di testa“. L’intervento, pubblicato sul blog aziendale, ha acceso un acceso dibattito tra sviluppatori, sostenitori dell’intelligenza artificiale e scettici convinti. Ma al di là delle provocazioni, il cuore dell’argomentazione di Ptacek è un invito lucido: smettere di idealizzare la scrittura del codice come un’arte sacra e riconoscere il potenziale trasformativo (e già tangibile) dei Large Language Models (LLM) nella pratica quotidiana dello sviluppo software.

La nuova era della programmazione: dagli snippet alle automazioni agent-based

Ptacek parte da un’osservazione chiave: oggi programmare con gli LLM non significa più copiare e incollare codice generato da ChatGPT. Le nuove pratiche emergenti ruotano attorno all’uso di agenti autonomi capaci di gestire l’intero ciclo di sviluppo: creare file, lanciare compilazioni, eseguire test, iterare sui risultati. Un’evoluzione che trasforma radicalmente il paradigma di sviluppo: l’AI non è più solo un suggeritore, ma un “collaboratore operativo”.

In questo scenario, lo sviluppatore non scompare: si trasforma. Più che scrivere codice da zero, il suo ruolo diventa quello di supervisore, revisore, raffinatore. Come sottolinea Ptacek, se un senior developer può migliorare la produttività di un junior, allora può (e deve) anche gestire e migliorare il codice prodotto da un LLM.

L’AI non si stanca, lo sviluppatore sì

Una delle affermazioni più efficaci di Ptacek riguarda il concetto di fatica cognitiva. Gli LLM non si stancano. Possono rifattorizzare centinaia di unit test per ore senza distrarsi, possono creare boilerplate code, scaffolding e script ripetitivi con una resilienza inumana. Questo non rende lo sviluppatore obsoleto, ma lo libera da una quota significativa del lavoro tedioso e meccanico, permettendogli di concentrarsi sulle decisioni di valore.

Approfondiamo meglio il concetto. Rifattorizzare unit test significa modificare e migliorare il codice dei test automatici (ad esempio riscrivere, ottimizzare, rendere più chiari o più robusti i test esistenti) senza alterarli nella loro logica.

Per boilerplate code si intende codice standard, necessario ma poco creativo (es. classi vuote, dichiarazioni iniziali, setup ripetitivo). Con scaffolding si intende codice e strutture generati automaticamente la costruzione delle applicazioni.

Grazie all’AI si può superare la “sindrome del foglio bianco”: iniziare un nuovo progetto diventa meno intimidatorio se gli ostacoli iniziali sono superati con la collaborazione di un agente AI che struttura l’ambiente, configura i tool, redige la documentazione iniziale.

Il vero problema non è la qualità del codice, ma l’abilità nel gestirlo

Contro l’accusa più comune — “il codice degli LLM è probabilistico, quindi inaffidabile” (ne parliamo nell’articolo sul funzionamento dell’AI spiegato facile) — Ptacek risponde con pragmatismo: la vera questione è quanto il programmatore è in grado di leggere, capire e adattare quel codice. I LLM, afferma, non generano output oscuri: producono codice leggibile, strutturato, spesso un po’ ridondante, ma funzionale. E se non lo si capisce, il problema non è nell’AI ma nel livello di competenza di chi la usa.

Il paradosso dell’eleganza: scrivere codice perfetto è spesso solo vanità

Uno dei passaggi più lucidi del post di Ptacek riguarda l’estetica del codice. Lo sviluppatore sfida un dogma radicato nella cultura hacker: “scrivere codice elegante è, in molti casi, un lusso che mira all’autocompiacimento“. Se la funzionalità è assicurata e il codice è leggibile, allora inseguire un’espressione “più elegante” è spesso solo tempo sprecato.

Viceversa, i LLM permettono agli sviluppatori di concentrare il loro giudizio e la propria creatività su ciò che conta: “risolvere problemi reali con soluzioni utili, manutenibili, scalabili“.

Ptacek riconosce i limiti dei LLM: possono non riuscire in contesti ad alta complessità, come la scrittura di codice in linguaggi come Rust. Tuttavia, sostiene che il codice generato da un LLM spesso supera in qualità il codice di un umano medio. E nei progetti aziendali reali, dove prevale il codice di supporto, ripetitivo, infrastrutturale, alzare la base qualitativa è una rivoluzione silenziosa.

La questione etica: plagio, proprietà intellettuale e cultura open

Una riflessione spinosa tocca il nervo scoperto della proprietà intellettuale. Ptacek, con toni provocatori, afferma che nessun altro professionista tratta il tema della proprietà intellettuale così alla leggera come lo sviluppatore.

Al di là della battuta, emerge una verità scomoda: i LLM riproducono schemi appresi da repository pubblici, spesso ignorando licenze e permessi. Se da un lato questo può essere visto come plagio, dall’altro è lo specchio di una cultura open che ha sempre fatto dell’emulazione costruttiva un pilastro evolutivo.

Le critiche: energia, centralizzazione e perdita di controllo

Le repliche al post di Ptacek non si sono fatte attendere. C’è chi denuncia il rischio di dipendenza da infrastrutture centralizzate, temendo che l’accesso ai LLM diventi un punto vulnerabile sia sul piano commerciale che etico.

Altri temono che l’AI faciliti truffe su larga scala, peggiori le disuguaglianze economiche e concentri troppo potere nelle mani di poche Big Tech. Si tratta di timori legittimi, ma che vanno separati dal merito tecnico della questione: i LLM funzionano già bene oggi per compiti concreti nello sviluppo software e, inoltre, c’è la possibilità di fare inferenza sui dispositivi locali, senza trasmettere un singolo byte su server remoti.

Conclusione: l’AI è qui per restare. Ma la responsabilità è nostra

Il post di Ptacek è tanto uno sfogo quanto un manifesto: non un’ode acritica all’AI, ma un invito urgente agli sviluppatori a smettere di guardare l’intelligenza artificiale con pregiudizio. I LLM sono strumenti potenti, ma richiedono competenze nuove, lucidità progettuale e soprattutto etica professionale.

Chi si ostina a rifiutare il cambiamento rischia non solo di restare indietro, ma di rinunciare al privilegio di modellare “come” questi strumenti saranno integrati nella nostra industria. Non si tratta di scegliere tra uomo o macchina, ma di capire come costruire un’alleanza produttiva tra intelligenza umana e artificiale, per il bene di chi scrive software e, soprattutto, di chi lo usa.