Perché il codice generato dall'AI è difettoso: una specifica dettagliata è già codice

La seduzione e l'illusione dello sviluppo guidato dalle specifiche

Il sogno è seducente: gli ingegneri del software evolvono da programmatori ad architetti, scrivendo specifiche ad alto livello che agenti AI traducono perfettamente in sistemi pronti per la produzione. Questa visione di "codifica agenziale" viene fortemente promossa, con figure come Salva di Google che evidenziano uno spostamento in cui il valore degli sviluppatori risiede nel "decidere cosa costruire" e "pensare al software a livello architetturale". I sostenitori sostengono che potrebbe essere la prossima generazione di outsourcing, semplificando ed elevando il ruolo dell'ingegneria.

Tuttavia, un'analisi approfondita di un esempio di punta, il progetto Symphony di OpenAI, rivela crepe fondamentali in questa premessa. L'argomento centrale, articolato dal programmatore Gabriella Gonzalez, è che un documento di specifica sufficientemente dettagliato per generare in modo affidabile un'implementazione funzionante è, a tutti gli effetti pratici, già codice. Ciò mette in discussione due concezioni errate che guidano il movimento della codifica agenziale.

Decostruire la "specifica" di Symphony

Symphony di OpenAI è presentato come un orchestratore di agenti generato da un documento di specifica (SPEC.md). Ad un esame più attento, questo documento non è una specifica tradizionale e astratta, ma piuttosto "codice a malapena velato". Contiene dump di prosa di schemi di database, algoritmi espliciti scritti in inglese strutturato e persino frammenti di codice letterale etichettati come `text` per aggirare la formattazione, un chiaro segno di generazione AI che obbedisce alla lettera, non allo spirito, di una richiesta.

Una sezione, esplicitamente etichettata come "Cheat Sheet", è ammessa essere "intenzionalmente ridondante in modo che un agente di codifica possa implementare rapidamente il livello di configurazione". Questa ammissione sottolinea il problema centrale: per rendere affidabile la generazione, la specifica deve contorcersi in un pseudo-linguaggio di programmazione. Come notò il pioniere dell'informatica Edsger Dijkstra, i tentativi di pura precisione verbale fallirono storicamente fino all'adozione di formalismi simbolici (come il codice).

Concezione errata 1: le specifiche sono più semplici del codice

La prima premessa difettosa è che i documenti di specifica sono intrinsecamente più semplici o più economici da produrre rispetto al codice corrispondente. La specifica di Symphony, lunga circa un sesto dell'implementazione in Elixir, dimostra che raggiungere la precisione necessaria richiede un'enorme quantità di dettagli. La specifica include logica di controllo della concorrenza espressa in pseudo-codice e definizioni di campo esaustive.

Gonzalez ha tentato di seguire le istruzioni di Symphony, chiedendo a Claude Code di generare un'implementazione in Haskell. Il risultato è stato pieno di bug e, anche dopo le correzioni, ha prodotto un agente non funzionante. Questa instabilità non è unica; anche la specifica YAML, ampiamente documentata e con un set completo di test, non è completamente implementata dalla maggior parte dei parser. L'affidabilità richiede un livello di dettaglio che cancella qualsiasi vantaggio di semplicità.

Concezione errata 2: le specifiche garantiscono un design ponderato

La seconda argomentazione di marketing è che filtrare il lavoro attraverso un documento di specifica impone migliori pratiche ingegneristiche e un design più ponderato. La realtà, come si vede in Symphony, può essere l'opposto. Spinte per la velocità di consegna, le specifiche possono degenerare in "spazzatura scritta dall'AI" - un sacco di frasi "a forma di specifica" prive di coerenza.

Un responsabile tecnico di Amazon sottolinea che "l'AI abbassa la barriera per scrivere codice, ma non la responsabilità di capirlo". Avverte che "creare codice sbagliato è molto pericoloso" perché la sua mera presenza crea un falso senso di sicurezza. Questo principio di "spazzatura dentro, spazzatura fuori" si applica direttamente allo sviluppo guidato dalle specifiche. Una specifica confusa e sciatta non produrrà un sistema coerente, indipendentemente dalla potenza dell'AI.

Il nucleo invariato del lavoro di ingegneria

La spinta del settore a svalutare il lavoro crea pressione per trattare la scrittura di specifiche come un'alternativa più veloce e facile alla codifica. Gli esperti sostengono che questo è un errore. Come evidenzia l'articolo del settore della difesa, requisiti non chiari espressi in linguaggio naturale (come "un buon sistema") sono "il peggior punto di partenza possibile" per un progetto, portando a requisiti vagi e al fallimento del programma.

I consigli di "vibe coding" del responsabile tecnico di Amazon rafforzano l'idea che il giudizio ingegneristico critico non può essere esternalizzato. Consigliano di chiedere all'AI domande difficili sui fallback, sulla scalabilità e sui casi limite - lo stesso pensiero critico richiesto per scrivere una buona specifica. Il lavoro non viene eliminato; viene spostato o, se fatto male, complicato.

Gonzalez conclude che le specifiche non sono mai state pensate come dispositivi per risparmiare tempo. Il tentativo di usarle come tali, aiutato dall'AI, spesso si traduce in una mappa borgesiana grande quanto il territorio che descrive - un artefatto inutile. La precisione richiesta per la costruzione del software richiede "interfacce strette", indipendentemente dal fatto che le chiamiamo codice, inglese strutturato o specifica. L'onere cognitivo di definire un sistema con sufficiente rigore per una macchina per eseguirlo rimane, con o senza un intermediario AI.

La strada da seguire: potenziamento, non sostituzione

L'evidenza collettiva di queste fonti dipinge un quadro chiaro. L'AI sta trasformando lo sviluppo del software, con oltre la metà degli sviluppatori che lo utilizzano per compiti come la creazione di casi di test e il debug, come notato da Business Insider. Il ruolo sta evolvendo verso un giudizio di alto livello, architettura e supervisione.

Tuttavia, la visione di ingegneri che scrivono semplicemente specifiche mentre l'AI fa il "lavoro" è un miraggio. La vera evoluzione è verso ingegneri che utilizzano l'AI come strumento potente per l'iterazione e l'esplorazione, mantenendo al contempo la responsabilità assoluta per la correttezza e il design del sistema finale. La chiave non è evitare il codice, ma utilizzare l'AI per navigare nella sua complessità in modo più efficace, mantenendo al contempo la profonda comprensione che è sempre stata la caratteristica di un ingegnere esperto. La macchina non può ancora assorbire l'ambiguità; quel peso, e il valore, risiede ancora nell'essere umano.