Da chi scrive codice a chi risolve problemi: il mestiere cambia, non sparisce

Qualche giorno fa ho guardato il keynote di apertura di David Heinemeier Hansson (DHH) a Rails World 2026. Per chi non lo conosce: è il creatore di Ruby on Rails, uno che il codice non lo ha solo scritto, lo ha insegnato a scrivere a una generazione intera di sviluppatori.

Il keynote dura più di un’ora e vale la pena vederlo tutto (qui il video completo). Ma ci sono due passaggi che mi hanno fatto dire: su questo devo scrivere. Ve li riporto, e vi racconto cosa ne penso da titolare di una software factory che dal 2019 vive di sviluppo software.

DHH, keynote di apertura di Rails World 2026, dal minuto 17:26 al 18:24. Cliccando, il video viene caricato da YouTube in modalità privacy avanzata.

Il primo passaggio è una provocazione. DHH dice che oggi non è più controverso affermare che tra il peggior programmatore senza strumenti di AI e il miglior programmatore con questi strumenti c’è una differenza di cento volte. Poi rilancia: forse mille.

E chiude con un dato personale:

“What I know to be true is that in the past twenty months, I have written half as much code as I did in the previous twenty-one years.”

“Quello che so per certo è che negli ultimi venti mesi ho scritto la metà del codice che avevo scritto nei ventun anni precedenti.”

Attenzione a leggerla bene: non sta dicendo che scrive meno. Sta dicendo che in venti mesi ha prodotto quanto in dieci anni di carriera. E notate chi è il “migliore con gli strumenti”: non uno qualsiasi, ma uno che ha alle spalle un quarto di secolo di codice.

Va presa per quello che è: l’esperienza personale di DHH, non una misura. Le righe di codice non hanno mai detto granché sulla produttività, e continuano a non dirlo.

Se si va a guardare la ricerca, il quadro è meno lineare di un keynote. E per questo è più interessante:

• in un esperimento controllato di GitHub, chi usava Copilot ha completato un compito circoscritto (scrivere un server HTTP in JavaScript) il 55,8% più velocemente (Peng et al., 2023);
• in tre aziende che hanno introdotto Copilot, i task completati ogni settimana sono aumentati in media del 26%, con un effetto più forte sui junior che sui senior (MIT Sloan, 2024);
• ma in uno studio di METR su 16 sviluppatori open source esperti, al lavoro su issue reali in progetti che conoscevano bene, con l’AI hanno impiegato il 19% di tempo in più. E si erano convinti di essere andati più veloci (METR, 2025).

Questi numeri non si contraddicono e non vanno mediati: misurano compiti, persone, strumenti e periodi diversi. Lo studio METR, tra l’altro, è di inizio 2025, e gli strumenti da allora sono cambiati parecchio. La lezione per me è un’altra: la domanda giusta non è “l’AI mi rende più veloce?”, ma su quale lavoro, in quale codice, con quali controlli. E la sensazione di essere più veloci non è una misura.

Un’idea del keynote mi ha colpito più di tutte: il software che diventa una scatola nera. Tu definisci le specifiche in ingresso, verifichi il risultato in uscita. Quello che succede in mezzo lo fa l’AI.

Detta così sembra una rivoluzione. Ma a pensarci bene è esattamente quello che succede da sempre a chi fa sviluppare software a un team o a una software house. Io lo vivo ogni giorno: nella mia software factory siamo circa quindici persone, tra interni e freelance a contratto, e il mio ruolo è quello di product owner. Vi confesso una cosa: spesso il software, per me, diventa fuori controllo. Dipendo dal team esattamente come domani dipenderò dall’AI.

La scatola nera non è nata con l’intelligenza artificiale. L’AI la sposta solo più in basso: dal cliente che la subisce dalla software house, allo sviluppatore che la subisce dall’agente.

Dal 2019 abbiamo seguito una regola dei nostri tech lead: conosci pochi linguaggi e pochi framework, e diventa il migliore in quelli. Abbiamo scelto TypeScript, i framework del suo ecosistema, React e React Native per il mobile. Abbiamo abbandonato Flutter, Swift, PHP, Python. E non abbiamo mai studiato Rust o Go: troppo difficili da dominare.

Ecco perché due passaggi del keynote mi hanno toccato da vicino. DHH racconta di un linguaggio, Rust, che dice di odiare, ma che con l’AI diventa improvvisamente accessibile, e molto più veloce e performante del resto. E racconta di come si possa passare da React Native al nativo, perché non servono più team specializzati su Swift o Android Studio.

In altre parole: la barriera che ci ha fatto scegliere pochi linguaggi, cioè la fatica di impararli, l’AI la sta abbattendo.

E io? Vi rispondo francamente: sono ancora nella mia comfort zone. Per i progetti professionali e per i clienti restiamo su TypeScript e React Native, perché lì il rischio lo paga il cliente. Ma nei progetti interni sperimento su ambienti e linguaggi nuovi, perché lì il rischio è mio.

C’è una frase che sento sempre più spesso da software house partner: “il linguaggio non importa, faccio tutto con tutto, tanto c’è l’AI”.

Questa frase mi spaventa. Chi giudica la qualità? Dove finisce l’esperienza?

Eppure, quando ascolto DHH, o Robert C. Martin (lo “Uncle Bob” del Clean Code), capisco che il mondo sta cambiando davvero, e tanto. Persino FileMaker, lo strumento low-code per eccellenza, sta diventando una piattaforma di sviluppo agentico: Claris ha annunciato che FileMaker 2026 ne pone le basi, con anteprime per sviluppatori in arrivo, e che vuole rendere FileMaker un obiettivo di prima classe per strumenti come Claude Code, Cursor e Codex.

Uncle Bob, che di qualità del codice se ne intende, ha una posizione che trovo molto sana. Le AI, dice, “are tools, and they’re good tools, and they will help”: sono strumenti, e buoni strumenti, e ci aiuteranno. Ma quando racconta di averle usate per rifattorizzare funzioni già funzionanti, aggiunge: “Sometimes it makes it better. Sometimes it makes it worse”. A volte migliora il codice, a volte lo peggiora (intervista di Jesse Duffield, 2024).

La differenza tra le due posizioni è sottile ma decisiva. “Tanto c’è l’AI” è la scorciatoia di chi pensa che l’esperienza non serva più. Il 1000x di DHH è il contrario: è l’esperienza moltiplicata.

Simon Willison, uno degli sviluppatori che più ha scritto sull’uso serio di questi strumenti, dà un nome alla scorciatoia: vibe coding, costruire software con un LLM senza rivedere il codice che scrive. E fissa una regola d’oro che farei appendere in ogni software house:

“I won’t commit any code to my repository if I couldn’t explain exactly what it does to somebody else.”

“Non faccio commit di codice che non saprei spiegare esattamente a qualcun altro.”

— Simon Willison, 2025

Ecco la risposta alla domanda “chi giudica la qualità?”: qualcuno che sappia spiegare quello che sta consegnando. Con o senza AI.

DHH, keynote di apertura di Rails World 2026, dal minuto 39:16 al 42:05. Cliccando, il video viene caricato da YouTube in modalità privacy avanzata.

Il secondo passaggio è quello che mi ha convinto a scrivere questo articolo.

“I have retired from being a professional programmer.”

“Sono andato in pensione come programmatore professionista.”

DHH racconta di aver passato un quarto di secolo a “scalpellare codice a mano”, amando ogni momento. E invita a guardare a quell’epoca non con rimpianto, ma con gioia, accettando che è finita.

“Writing code by hand is no longer an economically productive enterprise for the vast majority of programmers working at the vast majority of companies.”

“Scrivere codice a mano non è più un’attività economicamente produttiva per la stragrande maggioranza dei programmatori, nella stragrande maggioranza delle aziende.”

Ma non finisce lì. Dall’altra parte del crepaccio, dice, c’è una nuova carriera: quella del “professional maker of things”, il costruttore professionista di cose.

“You will be steering intelligence that was only available in science fiction up until a few moments ago.”

“Guiderete un’intelligenza che fino a pochi istanti fa esisteva solo nella fantascienza.”

DHH lo chiama maker. Io lo chiamo progettista. Credo che sarà il ruolo più importante dei prossimi anni, molto più dello sviluppatore come lo intendiamo oggi.

Chi è? È quello che:

• sperimenta e si tiene aggiornato;
• sa guidare l’AI nella scelta di strumenti e linguaggi;
• sa definire il system design giusto;
• capisce la logica da adottare nel software.

Qui c’è il punto: la conoscenza dell’ultimo linguaggio o dell’ultimo framework basta superficiale, quanto serve per guidare l’AI. L’esperienza, invece, oggi è fondamentale.

Non sono l’unico a vederla così. Kent Beck, il padre dell’Extreme Programming e del TDD, chiama questo modo di lavorare augmented coding, e lo distingue bene dal vibe coding: “The value system in augmented coding is similar to hand coding — tidy code that works. It’s just that I don’t type much of that code.” I valori restano quelli di sempre, codice ordinato che funziona: semplicemente, gran parte di quel codice non lo digita più lui (Kent Beck, 2025).

E Willison aggiunge una competenza nuova alla lista del progettista: “designing agentic loops”, progettare il ciclo in cui l’agente lavora. Cioè l’obiettivo, gli strumenti, l’ambiente isolato, i permessi limitati, i criteri per dire “questo è fatto bene” (Simon Willison, 2025).

Nella nostra software factory questo lavoro ha già un nome: è la fase di Discovery & Design che facciamo prima di scrivere una riga di codice. Ricerca UX, wireframe, flussi, personas. Poi il design funzionale: database, integrazioni, componenti. E infine il system design: stack, hosting, disaster recovery. Per anni l’abbiamo considerata la premessa allo sviluppo. Oggi scopro che è il cuore del mestiere.

C’è un’altra verità scomoda: oggi un team di sviluppo di 5 o 6 persone sta diventando troppo lento e troppo costoso.

Ci sto ancora ragionando, ma la direzione che vedo è questa:

• un product owner;
• una figura UX/UI e product design;
• due sviluppatori che si fanno review a vicenda, uno più front-end e uno più back-end, ma di fatto entrambi full stack;
• a supporto, un DevOps per infrastruttura e scelte tecnologiche: da noi è il nostro CTO, Andrea Schwibbert.

Team più piccoli e più agili. Oppure team esterni completi, con un tech lead interno a fare da garante.

Lo dico chiaramente: è una mia ipotesi di lavoro, non un dato. Nessuno studio, oggi, dimostra che un team più piccolo con l’AI mantenga qualità, sicurezza e manutenibilità. Per questo la misureremo su quello che conta davvero: tempi di consegna, difetti in produzione, incidenti, tempo di inserimento delle persone nuove, valore per il cliente. Non sulle righe di codice.

E c’è un motivo per cui nel team restano due sviluppatori che si fanno review a vicenda, e non uno solo. Come osserva ancora Willison, quando gli agenti lavorano in parallelo “the natural bottleneck on all of this is how fast I can review the results”: il collo di bottiglia diventa la velocità con cui un umano riesce a rivedere il risultato (Simon Willison, 2025). La review non è burocrazia, è il nuovo lavoro.

Mi rendo conto che è un cambio di rotta. Sulla nostra pagina dedicata allo sviluppo software custom scriviamo ancora che puntiamo sugli specialisti più che sui generalisti. Era vero, e ha funzionato. Ma il mestiere sta cambiando, e noi con lui.

Non ne parlo per sentito dire. Di recente ho realizzato Sigillo, un progetto open source nato come risposta a un problema reale, quello che vi avevo raccontato nell’articolo sulla copia della carta d’identità.

E ora sto per avviare lo sviluppo di due miei progetti interni, mydinner.club e DigitalBee (entrambi in corso di sviluppo). Partiremo dal lavoro di due colleghe molto esperte: Federica Casadei per UX/UI e Albina Cuni come product designer e project manager. E li svilupperemo senza coinvolgere, per ora, il team di sviluppatori: solo AI e la nostra esperienza.

Vi racconterò com’è andata quando avremo in mano l’MVP. E vi parlerò anche del contenitore in cui nascono, il mio nuovo startup studio, in un prossimo articolo.

DHH è netto: oggi scrivere codice a mano non conviene per la maggior parte dei programmatori, ed entro fine anno varrà per quasi tutti i settori, quasi tutti i programmatori, quasi tutte le aziende.

Nel mondo delle PMI italiane che conosco, credo servirà un po’ più di tempo. Ma il 2027 cambierà molte cose, ed entro il 2028 l’industria del software sarà stravolta.

E comunque, francamente, fissare una data serve a poco. Misurare il modo di lavorare di uno sviluppatore con la velocità con cui evolvono gli strumenti è un errore: fra sei mesi cambia di nuovo tutto. Bisogna essere veloci. Chi aspetta la data esatta per muoversi è già in ritardo.

C’è una domanda a cui non ho una risposta, e preferisco dirlo.

Io, i miei tech lead, DHH, Uncle Bob: giudichiamo la qualità del software perché lo abbiamo scritto per anni. Se i junior non scrivono più codice, da dove arriverà l’esperienza per diventare progettisti? La scala su cui siamo saliti noi rischia di sparire.

Non sono il solo a non avere la risposta. Martin Fowler, uno dei nomi più autorevoli dell’ingegneria del software, si pone le stesse domande: vale la pena entrare oggi in questo mestiere? Gli LLM elimineranno i junior? I senior devono uscirne prima che sia tardi? E risponde: “I haven’t the foggiest”, non ne ho la più pallida idea (Martin Fowler, 2025). Nello stesso articolo mette in guardia anche da un paragone troppo comodo: l’LLM viene spesso descritto come un collega junior, ma è “quite happy to say ‘all tests green’”, e quando i test li lanci tu, qualcosa fallisce.

I pochi dati che ci sono non chiudono la questione. Nelle tre aziende dello studio MIT i junior sono quelli che hanno guadagnato di più in task completati, ma quello studio non misura la qualità né quanto hanno imparato. E una piccola ricerca su 19 sviluppatori ha osservato che chi lavora con Copilot tende a verificare meno le proposte dell’AI di quanto farebbe con un collega in pair programming (Saarland University). L’AI cambia il modo in cui un junior impara, ma non rende inutile imparare.

Oggi, lo confesso, questo problema lo sto ignorando. Penso all’oggi: a come restare competitivi e rilevanti in un’industria che cambia sotto i piedi. Ma andrà affrontato, e prima o poi ne scriverò.

Da poco collaboro come esterno con Direct Impact Solutions, un gruppo che dal 1996 progetta soluzioni software per le aziende. Qualche giorno fa, parlando internamente del futuro dello sviluppatore FileMaker che diventa agentico, siamo arrivati a una conclusione che faccio mia:

Il nostro ruolo si trasforma da chi scrive codice a chi trasforma i problemi del cliente in istruzioni per le nuove piattaforme di sviluppo agentico. Il ruolo del professionista rimane, e cresce. Solo, cambia.

Quindi, se sei uno sviluppatore con vent’anni di carriera o il titolare di una software house e ti chiedi “domani mattina cosa faccio?”, la mia risposta è semplice: inizia un progetto o due con questo nuovo approccio. Studia, sperimenta, apriti a tecnologie e strumenti che fino a ieri avevi scartato.

Per me è un ritorno alle origini. Quindici anni fa ho fondato la mia società con un nome che era anche una missione: Technology Made Easy, risolvere i problemi delle aziende e delle persone con l’uso delle migliori tecnologie.

È un passo indietro? No. È un’evoluzione ciclica: da sviluppatore a system integrator, da software factory a startup studio, fino alle soluzioni software complete. Gli strumenti cambiano, e cambieranno ancora fra sei mesi. Lo scopo no.

DHH chiude il suo keynote parlando del privilegio di trovarsi su entrambi i lati del crepaccio: di esserci stati quando si faceva tutto a mano, e di esserci proprio nel momento in cui si cambia. La penso esattamente così.

È un momento meraviglioso per essere vivi, per partecipare a una rivoluzione tecnologica e per essere uno sviluppatore software. Bisogna solo cambiare il modo di lavorare.

E voi, come state cambiando il vostro modo di lavorare? Raccontatemelo nei commenti o scrivetemi direttamente.

• DHH, Rails World 2026 Opening Keynote, canale Ruby on Rails, YouTube
• Peng, Kalliamvakou, Cihon, Demirer, The Impact of AI on Developer Productivity: Evidence from GitHub Copilot (2023)
• MIT Sloan, How generative AI affects highly skilled workers (2024)
• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (2025)
• Simon Willison, Not all AI-assisted programming is vibe coding (2025)
• Simon Willison, Designing agentic loops (2025)
• Simon Willison, Embracing the parallel coding agent lifestyle (2025)
• Kent Beck, Augmented Coding: Beyond the Vibes (2025)
• Martin Fowler, My thoughts on AI (2025)
• Jesse Duffield, My interview with Uncle Bob Martin (2024)
• Saarland University, An Empirical Study of Knowledge Transfer in AI Pair Programming
• Claris, Agentic development with Claris FileMaker
• F.technology, Processo di sviluppo di un’applicazione custom
• F.technology, Sviluppo software custom