Come gli sviluppatori possono conservare il proprio lavoro (2)
Personaggi noti del settore del software hanno reso mainstream l'allarme sull'esaurimento dei nuovi talenti. Essere d'accordo è comodo. Per questo la seconda puntata della serie prende invece sul serio la parte opposta.
Architettura del software
Ecco i link agli articoli di questa serie:
- Parte 1: Su che cosa scommettono le aziende con l'IA
- Parte 2: Che cosa dicono gli ottimisti e che cosa ne penso
- Parte 3: Le mie raccomandazioni per te come sviluppatore e per te come leader
A quanto pare non sono l'unico a vedere il problema: il muscolo della programmazione si indebolirà quanto meno lo si usa. La "pipeline HR" smetterà di trasformare i junior in senior se le aziende resteranno ferme all'idea di non assumere più junior.
Due anni fa, Charity Majors, cofondatrice e CTO di honeycomb.io, ha segnalato la stessa trappola nel suo saggio sul blog di Stack Overflow. Quindi potrei semplicemente sentirmi confermato e godermelo, no? Ma sarebbe troppo facile.
L'argomento degli ottimisti
Simon Willison sostiene che rilasciare codice peggiore con gli agenti è una scelta, e che il refactoring è un compito ideale per gli agenti.
Simon non è uno qualunque: è uno dei creatori del framework web Django. Ha anche coniato il termine prompt injection. È un sostenitore del coding agentico, ma con occhio critico.
Come me, Simon traccia una linea netta tra due cose: il vibe coding, in cui non controlli più il codice, e lo sviluppo responsabile assistito dall'IA. (Purtroppo oggi molti usano il nome "vibe coding" anche per il secondo, e questo annacqua il termine.)
Charlie Graham, un fondatore, è ancora più ottimista e si spinge oltre: il debito che il modello di oggi non vede lo trova il prossimo, quindi dura solo pochi mesi.
Un tempo il debito tecnico era qualcosa che si accumulava e superava in fretta la capacità delle persone di fare refactoring. Simon e Charlie dicono che l'IA ha cambiato questa situazione. Se hanno ragione, la crisi che sto prevedendo semplicemente non arriverà.
Fin dove gli ottimisti hanno ragione
Duplicazione, funzioni troppo lunghe, test mancanti e nomi incoerenti sono problemi locali. I modelli oggi sanno risolverli bene e stanno migliorando. Su questo punto cedo: la mia ipotesi iniziale era troppo ampia.
I modelli sono bravi in compiti come questi:
1. Unire il codice duplicato. Un modello nota la stessa logica di validazione, leggermente variata, in cinque controller e la sposta in una funzione condivisa. Puoi controllare la modifica file per file, perché il comportamento deve restare lo stesso e i test esistenti lo dimostrano.
2. Spezzare le funzioni troppo lunghe. Un metodo di 300 righe viene suddiviso in passi con un nome, come controllare l'input, calcolare e salvare. Per questo il modello deve capire solo questa funzione e i suoi chiamanti diretti, non l'intero sistema.
3. Aggiungere i test mancanti. Per una funzione esistente, un modello scrive unit test che coprono il caso normale, i valori limite e i casi di errore. Funziona bene, perché il comportamento atteso si può leggere dal codice stesso, e l'esecuzione dei test mostra subito se sono giusti.
4. Rendere coerenti nomi e stile. Quando la stessa cosa si chiama "customer" in un punto, "client" in un altro e "user" in un terzo, un modello la rinomina in modo coerente in tutto il progetto. È un noioso lavoro di fatica su molti file, ma non richiede decisioni di progetto, e gli errori emergono subito nel compilatore o nel linter.
Che cosa hanno in comune tutti e quattro gli esempi: le informazioni necessarie sono nel codice e il risultato si può verificare automaticamente.
Il mio argomento riguarda piuttosto l'architettura: strutture fondamentali, che richiedono molta esperienza, visione d'insieme e capacità di giudizio, a volte persino gusto. Non si possono ricavare da un singolo punto del codice.
Charlie Graham ammette che la maggior parte del debito tecnico non riguarda l'architettura:
But most technical debt is not architecture. It is imperfect implementation around an unproven idea. The slightly wrong abstraction. The feature built before anyone knew if users wanted it. The elegant system designed for a scale that never arrived.
Ma presume che i modelli potrebbero risolvere anche questo, già nel 2027.
Non sono d'accordo. Un'architettura sbagliata non è un file disordinato. È una decisione sbagliata. Le informazioni necessarie per correggerla (requisiti in arrivo, vincoli reali, principi di progettazione e di evoluzione) semplicemente non sono nel codice. Quindi deve dirle all'IA un essere umano con esperienza, altrimenti non può saperle.
La mia ipotesi, ora rivista
Gli ottimisti mi hanno costretto a precisare la mia ipotesi, e gliene sono grato. Su un punto hanno ragione: i modelli già oggi rimettono in ordine il codice duplicato, le funzioni troppo lunghe e i test mancanti, e stanno migliorando. Chi qui si aspetta la grande crisi aspetterà invano.
Quindi la mia ipotesi ora suona così: Modelli migliori elimineranno il disordine locale. Ma per ora non decideranno che cosa deve diventare il sistema. Il motivo è la mancanza di informazioni. Quali requisiti arriveranno l'anno prossimo, quali vincoli sono reali e quali sono solo cresciuti nel tempo, che cosa può sopportare il business durante una ricostruzione e così via: niente di tutto questo è nel codice.
Questa decisione richiede qualcuno con capacità di giudizio, che capisca l'architettura e padroneggi gli strumenti. Il modello esegue la ricostruzione. Di dove si va deve rispondere un essere umano.
L'offerta che si riduce
Se è vero, gli ingegneri più preziosi del prossimo decennio saranno proprio quelli che le aziende hanno appena smesso di formare. Nella prossima puntata: chi vince, dove potrei sbagliarmi e a che cosa dovrebbero fare attenzione sviluppatori e aziende.