Come gli sviluppatori possono conservare il proprio lavoro (1)
Le aziende pensano di aver bisogno di meno sviluppatori perché il lavoro di fatica lo fa l'IA. Credo che sia una visione miope e che dovremmo guardare più da vicino.
Architettura del software
La scommessa che le aziende stanno facendo in questo momento
Le aziende hanno concluso che il lavoro di fatica lo fanno gli agenti di programmazione e che quindi servono meno sviluppatori. I tagli colpiscono soprattutto chi è all'inizio della carriera:
Uno studio di Stanford rileva che i giovani nei lavori esposti all'IA sono colpiti in modo particolarmente duro, mentre per le persone con esperienza non si osserva alcun effetto simile:
We find no evidence of widespread, economy-wide job displacement. However, employment of young workers (ages 22–25) in AI-exposed occupations now stands 19% below where it would be had it kept pace with that of their less-exposed peers; experienced workers show no comparable gap.
Uno studio di Harvard su 65 milioni di dipendenti va nella stessa direzione: entro sei trimestri dall'adozione dell'IA da parte di un'azienda, le sue assunzioni di junior (e non solo di sviluppatori) sono calate dal 9 al 10%, mentre quelle di senior sono rimaste stabili.
(Alcuni articoli molto noti online riportano addirittura un calo del 67%, ma quella cifra sembra impossibile da documentare, quindi qui non li cito.)
A mio avviso, il comportamento delle aziende si basa su un errore di ragionamento: da dove verranno i senior di domani, se smetti di assumere junior e di trasmettere loro l'esperienza?
Che cosa produce il vibe coding
Gli sviluppatori meno esperti oggi rilasciano software funzionante senza capirlo. Il codice gira, ed è proprio per questo che il problema resta invisibile. Un'analisi di GitClear su 623 milioni di modifiche al codice mostra che, rispetto al periodo precedente all'IA, la duplicazione del codice è aumentata dell'81% e il riuso è diminuito del 70%.
Secondo la mia esperienza, la duplicazione è tutt'altro che l'unico problema. Mettiamo che io dica a Claude Code che vorrei un'applicazione web basata su bun e descriva qualche user story. Claude genera davvero qualcosa che fa ciò che voglio.
Ma quando guardo il codice, la logica di dominio è mescolata alla rinfusa con l'accesso al database, e questo farà salire i costi di manutenzione in futuro.
Poi arriva il vero colpo di scena. Se ora chiedo a Claude Code se gli sembra che vada bene, risponde "assolutamente no, dovremmo separare la tecnologia dalla logica di dominio" e fa il refactoring di conseguenza.
Quindi, se non avessi chiesto, questo codice sarebbe semplicemente finito in produzione. Chi non ha esperienza di architettura produrrà codice scadente con gli agenti di IA e non se ne accorgerà.
Due tipi di debito, non uno
Il debito tecnico vive nel codice. Il debito di comprensione vive nel team: è il divario tra la quantità di codice esistente e la parte di esso che qualcuno capisce davvero. Il secondo tipo è più pericoloso, perché nessuna dashboard lo misura.
"Comprehension debt", debito di comprensione, è un termine coniato da Addy Osmani (già Director, Google Cloud AI - Gemini, Vertex, Agents). Nel suo articolo, Osmani descrive che cosa succede quando in un sistema esiste sempre più codice, ma la quota che un essere umano riesce ancora davvero a capire non tiene il passo.
Uno studio di Anthropic ha rilevato che gli sviluppatori che delegavano all'IA mentre stavano imparando a programmare ottenevano punteggi molto più bassi nei test di comprensione. Ciò significherebbe che per i junior è meglio risolvere a mano qualche problema difficile, perché così imparerebbero più in fretta. Gli sviluppatori che usavano l'IA come sparring partner e per farsi spiegare le cose hanno fatto meglio di un gruppo che le delegava interamente il lavoro. Quindi conta come usi l'IA, non solo se la usi.
Il giorno in cui andrà male
Soprattutto con applicazioni nuove e piuttosto piccole, il vibe coding senza una comprensione più profonda non fa alcun danno. A un junior puoi dare la ricetta seguente, e con essa arriverà piuttosto lontano:
- Di' all'agente di programmazione che cosa serve
- Lascia che generi codice finché tutti i test non sono di nuovo verdi
- Poi digli di fare una revisione approfondita di ciò che ha appena generato
- Se la revisione ha trovato bug o svantaggi, fai correggere all'agente
- Ripeti i passi 3 e 4 finché la revisione non trova solo problemi classificati come "minor".
- Fai una pull request delle modifiche e passala a qualcun altro.
Funziona finché non arriva il primo requisito che contraddice l'architettura esistente. In quel momento qualcuno deve comunque capire l'intero sistema per decidere che cosa fare. Quella persona potrebbe non essere più sul libro paga, perché era qualcuno di esperto che nel frattempo ha fatto il passo successivo nella propria carriera.
Che cosa fa allora un'azienda del genere? Lascia semplicemente che chi c'è prenda le decisioni necessarie, e l'architettura comincia a degradarsi.
L'obiezione che non ho potuto liquidare
Quando ho cercato persone che condividono questa preoccupazione, ne ho trovate molte, anche molto note. Per esempio Mark Russinovich, CTO, Deputy CISO e Technical Fellow di Microsoft Azure, e Scott Hanselman, VP e Member of Technical Staff di Microsoft/GitHub.
Nel loro articolo per Communications of the ACM sostengono che l'IA generativa ha incrinato l'economia dello sviluppo software, in un modo che il settore non vede ancora del tutto.
Ma ho trovato anche ingegneri seri secondo cui l'intero problema si risolverà da solo, e i loro argomenti sono in realtà migliori di quanto mi aspettassi. Nella prossima puntata di questa serie leggerai perché potrebbero avere ragione. Resta sintonizzato.