La complessità è il soffitto: progettazione software nell'era della codifica AI

      L'IA ha reso la scrittura di codice più veloce che mai. Il lavoro più difficile è comprendere un sistema e modificarlo senza romperlo. Questo non è diventato più economico, e ora decide quanto puoi delegare a una macchina.

      Introduzione

      Nel 1987, in un saggio intitolato "No Silver Bullet", Fred Brooks prevedeva che nessuno strumento o tecnica avrebbe portato a un guadagno dieci volte superiore nella produttività del software entro un decennio [1]. I decenni successivi hanno ampiamente dimostrato che aveva ragione, e la ragione è che il suo argomento non si basava mai sulla tecnologia del suo tempo. Brooks ha suddiviso la difficoltà di costruire software in due tipi. La complessità accidentale è lo sforzo incidentale che i nostri strumenti impongono: sintassi, boilerplate, impianti. La complessità essenziale è ciò che il problema stesso richiede: capire cosa deve fare il sistema e progettare una struttura che regga mentre cresce. Gli strumenti, sosteneva, si limitano a intaccare l'accidentale. L'essenziale rimane intatto, e l'essenziale è la maggior parte del lavoro.

      Gli assistenti alla codifica AI sono l'attacco più efficace alla complessità accidentale fino ad ora. Scrivono una funzione o creano un'intera suite di test in pochi secondi, e hanno reso le parti meccaniche della programmazione più economiche che mai. Questo ha incoraggiato una conclusione ripetuta abbastanza spesso da sembrare ovvia: il codice è economico ora, quindi il codice stesso conta a malapena. Descrivi ciò che vuoi, lascia che il modello lo generi, e quando qualcosa si rompe, cambia la descrizione e rigenera.

      L'educatore software Matt Pocock ha recentemente presentato una versione del controargomento in un intervento a una conferenza, e corrisponde a ciò che vedo nel mio lavoro [2]. Guida l'ingegneria AI in un'azienda di ricerca legale, dove costruire con questi strumenti è il mio lavoro quotidiano, e in un vero codice sorgente la conclusione "il codice è economico" non regge. Scrivere codice è economico. Comprenderlo e modificarlo senza rompere qualcos'altro non lo è, e un modello deve comprendere un codice sorgente prima di poterlo modificare in sicurezza. La complessità di un sistema è quindi il limite su quanto di esso puoi delegare a una macchina. Piuttosto che rendere la progettazione del software facoltativa, l'IA aumenta il costo di trascurarla.

      Il costo che non è scomparso

      Quando le persone dicono che il codice è economico ora, ciò che intendono è che è economico da scrivere. Ma scrivere non è mai stato dove risiedeva la spesa. La parte costosa del software è tutto ciò che viene dopo che la prima versione funziona: dare un senso a ciò che è stato scritto in seguito e modificarlo senza rompere qualcosa che nemmeno stavi guardando.

      Il 💜 della tecnologia dell'UE

      Le ultime novità dalla scena tecnologica dell'UE, una storia dal nostro saggio fondatore Boris e alcune opere d'arte AI discutibili. È gratuito, ogni settimana, nella tua casella di posta. Iscriviti ora!

      John Ousterhout dà a questa spesa un nome preciso. La complessità, nella sua definizione, è qualsiasi cosa riguardo alla struttura di un sistema che rende difficile comprenderlo o modificarlo [3]. Si manifesta come amplificazione del cambiamento, dove una piccola modifica costringe a modifiche in molti posti contemporaneamente; come carico cognitivo, la quantità che uno sviluppatore deve tenere a mente per toccare il codice in sicurezza; e come sconosciuti sconosciuti, dove non puoi nemmeno dire quali parti una modifica potrebbe influenzare. Nessuna di queste ha a che fare con la velocità di digitazione. Riguardano tutte la comprensione, e la comprensione è esattamente ciò che generare codice più velocemente non acquista.

      L'IA muove questa aritmetica nella direzione sbagliata. Un modello produce molto più codice di una persona, e molto più velocemente. Ciò significa più superficie da comprendere e più posti in cui un singolo cambiamento può arrivare, tutto in competizione per la stessa memoria di lavoro. Anche il carico di comprensione raddoppia, perché ora due parti devono comprendere il sistema: il modello, che deve afferrarlo abbastanza bene da cambiarlo correttamente, e tu, che devi afferrare sia il sistema che le modifiche del modello abbastanza bene da fidarti di esse. "Il codice è economico" è parzialmente vero. È la metà pericolosa.

      L'IA è un programmatore tattico

      Ousterhout traccia una linea netta tra programmazione tattica e strategica [3]. Il programmatore tattico ottimizza per far funzionare il compito attuale e poi passa oltre. Il programmatore strategico spende sforzi extra per mantenere pulita la struttura del sistema, in modo che il cambiamento successivo sia più economico e sicuro. Il lavoro tattico è più veloce oggi e più costoso ogni giorno dopo.

      Un modello di linguaggio, lasciato ai suoi default, è un programmatore tattico implacabile. È addestrato e sollecitato a produrre codice che funzioni, non codice che un collega sarà felice di ereditare. Quindi duplica un blocco piuttosto che estrarre l'idea condivisa, aggiunge un altro parametro invece di ripensare un'interfaccia e cerca una soluzione locale che funzioni in isolamento e peggiora silenziosamente l'intero. Il Pragmatic Programmer chiama questo deriva entropia del software: ogni cambiamento effettuato senza considerare il design del sistema lo spinge ulteriormente verso il disordine [4].

      Questa deriva sta iniziando a mostrarsi nei dati. Uno studio del 2026 ha esaminato oltre 300.000 commit scritti da AI in oltre 6.000 repository pubblici, eseguendo analisi statiche prima e dopo ogni cambiamento per misurare ciò che il modello ha effettivamente introdotto [5]. Più del quindici percento di quei commit ha aggiunto almeno un nuovo problema, e di tutti i problemi trovati, quasi nove su dieci erano odori di codice: problemi strutturali che si compilano e superano i loro test ma rendono il codice più difficile da comprendere e modificare. Il codice funziona mentre il design degrada silenziosamente. Questa è la complessità accidentale che si accumula un commit alla volta, ed è esattamente il costo che un modello ottimizzante per un risultato positivo non si addebiterà. Qualcuno deve fornire il livello strategico che il modello non fornisce, e quel qualcuno è l'ingegnere.

      I moduli profondi sono la superficie di controllo

      Se la complessità è il problema, lo strumento più utile che Ousterhout offre contro di essa è il modulo profondo: un'unità con un'interfaccia semplice che nasconde un'implementazione potente [3]. L'idea precede il nome. Nel 1972, David Parnas sosteneva che un sistema dovrebbe essere suddiviso non secondo i passaggi della sua computazione, ma secondo le decisioni che ogni parte può nascondere al resto, in modo che un cambiamento all'interno di un modulo non debba propagarsi agli altri [6]. L'occultamento delle informazioni è il punto centrale, e la profondità è ciò che lo rende efficace.

      Quella stessa profondità si rivela decidere quanto puoi delegare in sicurezza all'IA. Un modulo profondo ti offre due cose contemporaneamente: un contratto abbastanza piccolo da tenere in testa e un'implementazione che puoi delegare. Specifichi l'interfaccia, lasci che il modello compili il corpo e rivedi ciò che conta al confine: il suo contratto, le sue invarianti, i suoi test e qualsiasi interno sensibile al rischio, senza dover ricostruire ogni dettaglio dell'implementazione. Il modulo diventa una sorta di scatola grigia: scrutinando i suoi bordi e le parti che comportano un reale rischio, e lasciando il resto rimanere complesso all'interno.

      Un design superficiale toglie questa opzione. Quando il comportamento è distribuito su molti piccoli moduli con interfacce porose, non c'è alcun confine contro cui verificare, e comprendere qualsiasi cambiamento significa tracciarlo attraverso tutti loro. Quel costo ricade su di te e sul modello allo stesso tempo. Nella pratica, un agente fa il suo miglior lavoro all'interno di un modulo ben definito, dove il compito è leggibile e il contratto è chiaro, e il suo peggior lavoro in codice aggrovigliato, dove non può dire cosa dipende da cosa e peggiora le cose in modo sottile mentre sembra aiutare. La struttura del codice sorgente, molto più dell'astuzia del prompt,