Ho scritto che il coding è morto, ecco come gli sviluppatori mi hanno risposto

Da quando ho iniziato a scrivere questo articolo sono successe due cose.

La prima: Dario Amodei, CEO di Anthropic, l’azienda che produce Claude, uno dei modelli AI più avanzati al mondo, ha dichiarato: “Potremmo essere a 6–12 mesi da modelli capaci di fare end-to-end tutto ciò che oggi fa un ingegnere del software.”

Le paure: una mappa emotiva dell’Italia davanti all’AI

“CHE SPROLOQUIO” — La negazione come armatura

La reazione più frequente è stata una variazione di “che sproloquio”, “stupidaggini”, “la realtà è totalmente diversa”. Un utente ha scritto, testuale: “Stiamo tremando tutti di paura, brrrrrr brividi di terrore… quando vi renderete conto che l’AI può solo agevolare il lavoro dello sviluppatore e mai e poi mai sostituirlo sarà il giorno più bello.”

Conosco bene questo meccanismo. L’ho vissuto in prima persona oltre vent’anni fa, quando spiegavo ai giornalisti della carta stampata che Internet avrebbe cambiato il loro mestiere. Stesse parole. Stesso tono. Stessa rabbia mascherata da ironia. Trattavano noi pionieri dell’informazione online come dei pariah, addirittura a un Web Awards, il presentatore ha definito la nostra categoria “pseudo-giornalisti”.

Non li biasimo. Chi ha costruito la propria carriera su competenze specifiche, quando vede quelle competenze potenzialmente svalutate, non percepisce un cambiamento professionale, percepisce una minaccia esistenziale. La negazione è il primo meccanismo di difesa.

Ma la negazione non ferma il cambiamento. E nel frattempo, Amodei parla di 6–12 mesi e, come leggerai qui sotto, c’è chi archivia tutto come “messaggi di marketing”.

2. L’oste e il vino — Il conflitto di interessi come scudo

“Citare un esponente di Anthropic per dire che il coding è morto è come chiedere all’oste se il vino è buono.”

Questo commento è apparso in diverse varianti ed è, in parte, legittimo. Chi sviluppa strumenti AI ha interesse diretto nel promuoverne la potenza. È un punto che merita attenzione critica.

Ma c’è un errore logico nell’usarlo come argomento finale: i dati vengono sempre da chi li ha. Quando Reed Hastings disse che lo streaming avrebbe ucciso il noleggio DVD, parlava pro domo sua. Blockbuster rise. Poi andò a gambe all’aria.

Ho cercato di bilanciare citando non solo Amodei, ma la mia esperienza diretta: tre webapp funzionanti sviluppate in cinque settimane, part-time, dopo 17 anni senza programmare. E la testimonianza di un software architect che nei commenti ha confermato: “Assumiamo meno, produciamo di più, e scriviamo poco.” E il caso di Peter Steinberger, che in meno di tre mesi ha creato e piazzato a OpenAI OpenClaw, il prodotto che mi ha dato lo spunto per questa serie di articoli.

Venerdì scorso poi, il mercato ha dato la sua risposta al dibattito. Non con le parole. Con i soldi. I titoli cybersecurity sono crollati alla sola notizia che un’AI può fare il lavoro che intere aziende vendono da anni. Non è l’oste che parla del vino. È il vino che si versa da solo.

Il conflitto di interessi è un buon filtro. Non è un paraocchi.

3. Le scatole nere sono veramente pericolose?

Tra tutti i commenti, quelli che mi hanno colpito di più parlano di opacità:

“Il rischio reale non è che spariscano i programmatori. È che si creino sistemi sempre più complessi e opachi. Infrastrutture critiche, sanità, sistemi bancari, come scatole nere. Se qualcosa va storto, chi saprà intervenire?”

E ancora: “Avere scatole nere su cui nessuno, e ripeto: nessuno, conosce i dettagli del funzionamento interno mi sembra molto azzardato.”

Ho risposto pubblicamente nel thread: “Hai scritto una cosa sacrosanta.” E lo ribadisco qui. Questa non è una paura irrazionale. È un’analisi lucida di un rischio concreto.

Un utente esperto ha centrato il punto con precisione chirurgica: “Chi tratta applicazioni business sa bene che l’analisi, non la realizzazione, richiede molto più di un prompt. Un CRM personalizzato può richiedere decine di pagine di spiegazione. E dopo l’analisi c’è la manutenzione.”

Vero. Sacrosanto. L’AI non elimina la complessità dell’analisi dei requisiti. Accelera la realizzazione, ma la fase in cui capisci cosa costruire resta un lavoro profondamente umano.

E proprio qui si innesta la notizia di venerdì: Anthropic ha lanciato uno strumento che scansiona codice e trova vulnerabilità. Tradotto: le scatole nere iniziano ad avere un ispettore automatico. Non risolve tutto. Ma la direzione è chiara, l’AI non solo genera il codice, sta iniziando anche a controllarlo.

4. “Scritto da AI” — Il paradosso dell’autenticità

Almeno otto commenti dicevano varianti di: “Ennesimo articolo che parla di AI, scritto da AI. Che tristezza.”

Un utente ha puntualizzato: “L’AI avrebbe potuto scrivere questo articolo al posto tuo un anno fa. Perché stai ancora lavorando?”

Ho risposto con onestà: sì, ho usato Claude Opus per analizzare una trascrizione di tre ore. Cosa dovrei fare, vergare i pezzi con pennino e calamaio e poi disegnare i capoversi miniati? Ragazzi è il 2026, uso gli strumenti a disposizione in modo intelligente e onesto.

Anche oltre le ore spese a documentarmi e informarmi, ne ho passate due a riscrivere tutto, aggiungendo le mie esperienze personali, i miei casi, le mie opinioni. Le parti su come ho sviluppato il primo Tom’s Hardware, su come orchestro tre agenti in parallelo, su come Zuckerberg ha testato personalmente OpenClaw, quelle non le scrive nessuna AI. Per scrivere quell’articolo, aiutato da Opus, ci ho messo due mesi.

In un mondo dove tutti possono generare testo con un prompt, l’unica moneta che vale è avere qualcosa di vero da dire. L’autenticità nel 2026 non significa “scritto senza strumenti”. Significa “scritto con un punto di vista che nessuno strumento può inventare”.

5. Il costo della complessità — L’80/20 rovesciato

Un commento tecnico particolarmente acuto: “Fai l’80% del lavoro in giorni invece che mesi, e il 20% che rimane per andare in produzione ti costa più tempo che se avessi fatto tutto da solo.”

Questa è un’osservazione da chi usa davvero questi strumenti, non da chi ne parla per sentito dire. E ha ragione, oggi. La “coda lunga” della messa in produzione è ancora il collo di bottiglia. Bug sottili, edge case, integrazione con sistemi legacy, sicurezza.

Nel mio caso ho messo online tranquillamente le mie webapp con Vercel e Supabase, ma sono tool ad accesso riservato per un piccolo gruppo di utenti. È chiaro che non scriverei il codice di Tom’s Hardware con Lovable. Ma mi posso permettere di creare ottimi prototipi, veri e propri MVP funzionanti, che poi i miei sviluppatori mandano in produzione e manutengono.

Ma attenzione, la velocità con cui quel 20% si sta riducendo è il dato che conta. Da quando ho iniziato il 17 gennaio, sono passato attraverso tre generazioni di strumenti, ognuna drasticamente migliore della precedente. Claude Opus 4.6 con un milione di token, GPT Codex 5.3 l’app autonoma che mi esegue code review notturne, OpenClaw che gestisce il mio team di agenti.

Chi guarda l’80/20 di oggi e ci costruisce sopra una certezza per domani, sta facendo una proiezione lineare su un fenomeno esponenziale. E non sottovalutiamo la dichiarazione di Amodei: “end to end” vuol dire che secondo lui quel 20% di area di pericolo scomparirà.

E poi ragazzi intendiamoci. Vogliamo essere veramente pessimisti? Ok, l’attuale modello di sviluppo non sarà sostituito tra 12 mesi perché noi che lo crediamo siamo tutti dei manichini al soldo dei grandi poteri dell’AI. Ma veramente credi che fra 3 anni — che è un’era geologica nel mondo nuovo — scriveremo ancora codice a manina e faremo preventivi da 10 mila euro per una landing page e 100 mila per un gestionale?

6. La sicurezza — Il tallone d’Achille reale

Diversi commenti hanno colpito su un punto concreto: la sicurezza di OpenClaw. Un utente ha linkato un articolo di ICT Security Magazine che evidenzia vulnerabilità. Nota, un articolo che il mio rilevatore di contenuti generati ha definito all’80% creato interamente da AI, ma per me non è un problema. L’importante è che dentro ci siano scritte cose che mi servono. Un altro ha scritto: “OpenClaw è una delle piattaforme con più buchi di sicurezza mai viste.”

Non mi sottraggo. Ho risposto nel thread con trasparenza: “Oggi OpenClaw è un prodotto per esperti. Devi blindarlo sotto VPN e con firewall. Su una VPS non lo installerei. La notte spengo il computer e stacco il cavo di rete.” Uso per ogni processo, anche i più banali cron (si chiamano Heartbeat) il costoso modello Opus 4.6 in modalità low thinking. Sono sicuro? No, ma dovrei essere protetto dal 99% dei prompt injection. E se mi bucano lo stesso? Amen, se non faccio la ricerca io che sono il titolare di Tom’s Hardware chi diavolo dovrebbe farla?

Come ho imparato al mio primo Hackmeeting a Catania un milione di anni fa: “L’unico computer sicuro è quello spento e scollegato dalla rete!”

Questa è la realtà dei prodotti di frontiera. Ogni tanto bucano colossi come Cloudflare, possiamo permettere a un progetto open source con pochi mesi di vita di avere qualche vulnerabilità. Dal 16 febbraio a oggi, data dell’articolo che mi è stato segnalato, il team ha mandato oltre 3.000 commit sul repository (ho chiesto di verificare a un mio agente su OpenClaw). Molti fix, nuovi bug, buchi di sicurezza sempre nuovi. Capisci che con mezzo milione di righe aggiunte e 300.000 cancellate, non stiamo più parlando dello stesso prodotto che ha dato determinati risultati, errori e vulnerabilità pochi giorni fa?

Ma la paura è legittima, e il decalogo che propongo più avanti parte proprio da qui.

7. Il divario delle competenze — Chi non sa fare lo SPID

“Gli imprenditori medio piccoli non sanno nemmeno farsi lo SPID da soli. Nel 90% dei casi i clienti non sanno cosa vogliono.”

Un commento duro ma realistico. L’AI non risolve il problema dell’incompetenza, lo amplifica. Se non sai cosa chiedere, non importa quanto sia potente lo strumento: il risultato sarà spazzatura. Un prompt abbozzato, senza il giusto contesto, produrrà risultati scadenti anche con il modello più evoluto.

Come ho scritto nel forum: “Senza i miei 15 anni di esperienza di sviluppo, avrei creato baracconi buggati e inutili.” Le mie competenze pregresse in progettazione di database relazionali e architetture multi-tenant sono state decisive. Insomma quando ho creato la prima versione di tomshw.it nel 2002, reggeva venti milioni di pagine al mese e non avevamo i server e gli strumenti di oggi. Quindi qualcosa ne sapevo.

L’AI è un moltiplicatore. Moltiplica le competenze di chi le ha. E moltiplica gli errori di chi non le ha.

8. Il futuro economico — SaaS 2.0

Un commento in 58 ha centrato il cuore del cambiamento economico: “Il concetto di SaaS si sta solo spostando. In futuro non si pagherà per sviluppo software o consulenza. Si pagherà, e moltissimo, per gli abbonamenti alle AI, che faranno pagare a percentuale su quanto generato.”

Questa è l’intuizione strategica più importante dell’intero dibattito. Il valore non scompare, si redistribuisce. I margini migrano. I player cambiano.

Il crollo dei titoli cybersecurity di venerdì e quello precedente del settore legale ne sono la prova in tempo reale. Aziende che vendono servizi di consulenza legale e di sicurezza da decenni hanno visto i loro titoli scendere alla sola notizia che un’AI può fare lo stesso lavoro. Non è un’ipotesi. È il mercato che prezza il cambiamento prima ancora che sia completo.

E attenzione, OpenAI perde 15 milioni al giorno. Prima o poi ci presenterà il conto e aspetterà il momento giusto, quando ne saremo dipendenti. E le sue concorrenti non saranno certo da meno! E quindi che facciamo? In attesa di un temuto rincaro dei token o degli abbonamenti AI non sperimentiamo? Questo invece è proprio il momento giusto per investirci.

Le speranze: chi ci lavora in prima persona

Chi già usa l’AI e vede il potenziale

Un utente ha raccontato di aver costruito un’infrastruttura Proxmox a 7 nodi con Claude, inclusi server di backup e NAS. “Il tutto fatto abbastanza facilmente, senza molte domande ed affinamenti.”

Un software architect ha confermato il trend: “Assumiamo meno, produciamo di più, e scriviamo poco.” Non è una teoria. È il bilancio della sua azienda.

E chi ha testato Claude per scrivere codice e ha scoperto che “funziona, ma ha bisogno di correzioni.” Nessun entusiasmo cieco, realismo operativo.

L’utente che ha fatto la domanda giusta

In mezzo a decine di reazioni emotive, un utente ha chiesto: “Secondo te, entro metà 2027 ci sarà un’automazione completa nella creazione e sviluppo software, o dovremo aspettare di più?”

Gli ho dedicato la risposta più lunga del thread, la mia storia personale completa, dal primo prompt del 17 gennaio alla situazione attuale con tre webapp in produzione.

Alla luce della dichiarazione di Amodei, 6–12 mesi per modelli capaci di fare end-to-end tutto ciò che fa un ingegnere, la risposta si sta scrivendo da sola. E più velocemente di quanto chiunque avesse previsto.

Il Blue Ocean nascosto

Un commento brillante ha indicato la direzione: “Se cercate un blue ocean per imprese del futuro, pensate a una AI che controlli domani i miliardi di linee di codice spazzatura che si appresta a generare l’AI di oggi.”

Non è una battuta. È una previsione di mercato che venerdì ha trovato la sua prima conferma. Anthropic ha lanciato esattamente quel prodotto, un tool di sicurezza che scansiona codice alla ricerca di vulnerabilità, e il settore cybersecurity tradizionale è andato in rosso. Ma non è l’unica, ovviamente. GPT Codex ha la funzione Code Review da tempo; Cursor ha il suo Bugbot e non so quanti altri sistemi di controllo automatico delle PR ci siano sul mercato.

Più codice genera l’AI, più servono strumenti per validarlo, testarlo, mantenerlo. Il mercato della “pulizia AI” sarà enorme. E sta nascendo adesso.

I programmatori come nuovi imprenditori

Un utente ha colto un punto che ho rafforzato: “Una persona senza competenze che fa errori che costano migliaia o milioni, e le assicurazioni si stanno tirando indietro.”

Ho risposto: “Ed è qui che c’è la possibilità di fare un pozzo di soldi per i programmatori, che però devono cambiare identità e diventare builder a capo di un team di agenti AI.”

La speranza più concreta che ho trovato in quel thread è questa: gli sviluppatori bravi non stanno perdendo il lavoro. Stanno per diventare i professionisti più richiesti e meglio pagati del mercato. Ma devono accettare che il loro ruolo è cambiato: da chi scrive codice a chi orchestra macchine che scrivono codice.

E attenzione, come sempre succede quando arriva una rivoluzione tecnologica, le eccellenze fanno una fortuna, i medi galleggiano e i mediocri sono spazzati via.

Il decalogo: 10 regole per usare prodotti di frontiera come OpenClaw senza farsi male

Ho imparato queste regole sulla mia pelle, nelle ultime cinque settimane di sviluppo intensivo con agenti AI. Alcune le conoscevo già dai miei anni da sviluppatore. Altre le ho scoperte sbattendoci contro.

1. Non installare su server esposti a Internet (VPS e simili)

Prodotti come OpenClaw, nella fase embrionale, vanno installati in ambienti controllati. Il mio setup: Mac Mini dietro VPN, firewall configurato, zero porte aperte verso l’esterno. La notte spengo e stacco il cavo di rete. Sembra paranoico? È il minimo sindacale quando dai a un agente AI accesso al tuo file system.

2. Un agente, un ambito. Mai poteri illimitati

Ogni agente deve avere un perimetro chiaro: quali file può leggere, quali può scrivere, a quali servizi esterni può accedere, quali skill può usare. Se usi una sola chat Telegram dove un singolo agente ha accesso a tutto — email, file, browser, terminale — stai costruendo una bomba a orologeria. Separa gli agenti per funzione. Il mio agente di content creation non ha accesso al codice. L’agente di coding non tocca le email.

3. Usa modelli con reasoning attivo per task sensibili

Per limitare prompt injection — attacchi che arrivano tramite email, siti web o messaggi esterni — usa modelli con capacità di ragionamento come Claude Opus ultima versione con thinking attivo almeno in low. Non è una garanzia assoluta, ma un modello che “pensa” prima di agire è meno manipolabile di uno che esegue e basta.

4. Non scaricare skill da sconosciuti

Le skill sono estensioni che danno capacità agli agenti. Io me le scrivo tutte e, per ora, non le pubblico. Prima di installare una skill di terze parti, leggi il codice sorgente. Tanto mica lo leggi tu, lo fa il tuo coding agent giusto? Ogni skill è un potenziale vettore di attacco. Io ho deciso, per ora, di non usare skill scaricate dal marketplace ClawHub.

5. Leggi il codice che l’AI produce — almeno le parti critiche

Peter Steinberger ha dichiarato di non leggere il codice prodotto dai suoi agenti. Con il suo PSPDFKit ha fatto una exit da 100 milioni e 13 anni fa non programmava con AI. Quindi ha competenze che gli consentono quel livello di fiducia. Dal canto mio, leggo sempre l’autenticazione, le query al database, le policy di accesso, la gestione dei segreti. Il resto sinceramente lo ignoro. La UI non so nemmeno come si faccia! Del resto facevo il programmatore, l’ufficio grafico ai miei tempi era al piano sopra! Io condividevo il seminterrato con il sistemista.

6. Backup prima di ogni sessione agentica

Prima di lanciare un agente su un progetto, fai un commit Git e un backup completo del database. Imposta backup fisici dei tuoi DB come minimo quotidiani. Gli agenti possono sovrascrivere file, cancellare configurazioni, rompere dipendenze. Con un backup, il danno massimo è perdere una sessione di lavoro. Il mio Claude Code per esempio, nonostante avessi istruito CLAUDE.md di non fare mai DB Reset, mi ha sparato un paio di tentativi di reset su progetti in produzione che per fortuna ho intercettato e bloccato!

7. Revisioni di sicurezza automatiche — di notte

Uso GPT Codex per eseguire routine notturne: scansione di vulnerabilità note, ricerca in linguaggio naturale di segreti hardcoded (password, API key, token), verifica delle dipendenze, verifica dell’integrità dell’output. Costa pochi centesimi di token e serve perché gli agenti non hanno memoria e fanno ancora errori banali.

8. Non fidarti del primo output — itera

L’AI è bravissima a generare codice che sembra funzionare. Ma, ed è un consiglio che ho proprio preso da Steinberger, appena finisce un’esecuzione, fai questa domanda. Io ce l’ho salvata come shortcut nel mio TextExpander:

“Adesso che hai appena sviluppato il codice, lo conosci bene. Ci sono parti che potresti migliorare o correggere:

identifica potenziali errori
calcoli e logiche restituiscono dati coerenti e corretti?
cerca fonti di cali di prestazione
cerca potenziali bug da fixare oppure problemi di sicurezza
pensi che ci sia bisogno di un refactor di qualche componente?
ci sono elementi di interfaccia grafica che potresti migliorare?
hai usato logica ottimistica per tutte le interazioni utente?
hai usato una UI e delle logiche coerenti con PRD e design del prodotto?
abbiamo rispettato le regole di CLAUDE.md?“

9. Diversifica i provider

Non dipendere da un singolo modello. Io uso Claude Opus o GPT Codex per creare piani e per scrivere nuove funzioni, Claude Sonnet per bug fixing e interfaccia utente, GPT Codex per le automazioni notturne, GPT Pro per le analisi e la creazione dei prompt. Se domani uno di questi servizi raddoppia i prezzi, cambia le policy o ha un’interruzione prolungata, il mio workflow sopravvive. Il costo di switching oggi è basso.

10. Mantieni le competenze fondamentali

L’AI è un moltiplicatore, non un sostituto delle competenze. Se non capisci cosa fa il codice prodotto dall’agente, non sarai in grado di debuggare quando qualcosa si rompe — e si romperà. Impara a leggere il codice anche se non lo scrivi più. Comprendi l’architettura. Conosci i pattern di sicurezza. Il giorno in cui l’agente produce spazzatura e tu non te ne accorgi, è il giorno in cui il danno è già fatto.

Il messaggio che vorrei lasciare

La comunità italiana di sviluppatori, tecnici e appassionati di tecnologia non è né cieca né stupida. È preoccupata, e ha ragione di esserlo. Il cambiamento in atto è reale, è veloce, ed è irreversibile. Le parole di Amodei — 6–12 mesi — e i crolli azionari sono sirene d’allarme.

Ora non dobbiamo né farci paralizzare dalla paura né farci accecare da speranza e dichiarazioni di marketing, su questo concordo con i nostri lettori.

Lo sviluppatore che oggi dice “mai e poi mai” e quello che domani installa OpenClaw senza cautele stanno facendo lo stesso errore: rifiutarsi di guardare la realtà per quella che è. Complessa, piena di rischi, piena di opportunità, e in evoluzione così rapida che qualsiasi certezza ha una data di scadenza di pochi mesi o addirittura settimane.

I programmatori bravi hanno davanti la più grande opportunità della loro carriera. I programmatori medi hanno davanti l’ultima finestra per aggiornarsi. Gli imprenditori che capiscono il trend possono costruire con costi e tempi impensabili fino a ieri. Quelli che non lo capiscono pagheranno qualcun altro per farlo, come hanno sempre fatto.

Il decalogo che ho proposto non è una lista definitiva. È il punto di partenza di qualcuno che sta imparando insieme a voi, che sbaglia e corregge, che la notte stacca il cavo di rete e la mattina riaccende il computer e dà la sveglia ai suoi agenti.

Se il mio primo articolo era una provocazione, questo vuole essere una mano tesa. Non a chi ha ragione o torto, ma a chi vuole capire.

Ci continuiamo ad aggiornare su queste pagine!

Roberto Buonanno è co-fondatore di 3Labs, editore di Tom’s Hardware Italia. Scrive codice con agenti AI da poco più di un mese e ci sta perdendo il sonno. In un’altra era geologica, sviluppava in PHP e MySQL.