L'IA non eliminerà l'over-engineering. Lo accelererà
Perché il modello restituisce per impostazione predefinita soluzioni eccessive, quale freno naturale alla complessità è sparito e come usare l'IA come redattore anziché come generatore.
Il problema
L'over-engineering è risolvere un problema semplice in modo complicato: una landing page sui microservizi, Kubernetes per dieci utenti, un'architettura pensata per un milione di richieste con un traffico modesto. Paghi in denaro e in tempo una soluzione incomparabilmente più complessa del problema stesso.
Gli incentivi sono fatti così. Una soluzione complessa si legge come professionale, una semplice come incompiuta. Nessuno è stato licenziato per aver scelto Kubernetes. Sono stati licenziati quelli che non avevano pensato alla scalabilità. Con questa asimmetria, cautelarsi è razionale, e gli sviluppatori si cautelano.
Perché qui l'IA non aiuta
L'IA ha imparato da codice aperto e articoli, e lì prevalgono le soluzioni delle grandi aziende: sono loro a scrivere i blog, pubblicare i framework, dettare la moda. I loro problemi sono altri: milioni di utenti, centinaia di sviluppatori, requisiti normativi.
Alla richiesta «scrivi l'autenticazione» il modello restituisce ciò che ha incontrato più spesso: una struttura a livelli con astrazioni, interfacce e gestione di scenari che tu non avrai mai. È una risposta corretta alla richiesta media di internet. Il tuo progetto in quella media non ci sta.
Cosa è cambiato
Prima la complicazione si pagava con il tempo. Scrivere cinque livelli di astrazione era una settimana di lavoro. Verso il terzo giorno si cominciava a dubitare che servissero davvero. Il prezzo funzionava da freno.
Oggi quegli stessi cinque livelli si generano in un minuto. Il codice si legge bene, i test passano, la funzione va: all'apparenza è tutto a posto. Ma il costo principale della complessità non ricade sulla scrittura, ricade sulla manutenzione. Tra sei mesi in quel codice bisognerà cambiare qualcosa, e il conto arriverà allora. È debito tecnico contratto all'istante e senza una decisione consapevole.
L'unico freno naturale all'over-engineering è sparito. Non è una questione di qualità della generazione: il codice può essere ottimo. È che è diventato troppo economico.
Cosa funziona
Usare l'IA come redattore
Lo scenario diffuso è un altro: lo sviluppatore chiede di generare un modulo da zero, riceve 500 righe e le incolla nel progetto. Nessuno si metterà a capire cosa è superfluo: il codice funziona. È così che l'over-engineering entra in un progetto, in una sola generazione.
L'ordine inverso dà un altro risultato:
- Prima scrivi tu. Trenta righe, un JWT semplice, una funzione di verifica. In cambio capisci ogni riga.
- Poi lo dai all'IA da semplificare. «Ecco il codice. Togli tutto ciò senza cui continua a funzionare. Mostrami cosa si può buttare.»
- Esamini le proposte. Una parte sarà fuori bersaglio, ma in questa modalità il modello lavora meglio: trova il superfluo con più precisione di quanta ne abbia nell'inventare il necessario.
Nella revisione c'è un punto di riferimento: il tuo codice e la tua comprensione del compito. Nella generazione il punto di riferimento non c'è, e il modello ci mette quello medio.
Altri due accorgimenti:
- Vincoli nel prompt. Se generi da zero, definisci il perimetro in modo esplicito: «La soluzione più semplice che funziona. Senza framework, senza livelli di astrazione. SQLite, un solo file.»
- Contesto del progetto. La frase «ho 100 utenti e un server da dieci dollari» cambia la risposta più di qualsiasi rifinitura della formulazione.
Come se la cavano le grandi aziende
Le aziende che hanno adottato gli agenti IA più in profondità hanno costruito attorno alla generazione un intero strato di vincoli.
Stripe, stando alle descrizioni pubbliche, fa passare per l'IA più di mille pull request a settimana. I compiti per gli agenti sono formulati in modo stretto: non «fai una funzionalità», ma una modifica rigorosamente delimitata. Gli strumenti a disposizione dell'agente sono selezionati a mano. Ogni risultato passa da una verifica. L'azienda ha sacrificato consapevolmente l'ampiezza del compito in cambio della prevedibilità del risultato.
In Google, Shopify e Airbnb le architetture sono diverse: uno standard unico nel settore non esiste, ognuno costruisce sui propri rischi. Il tratto comune è che gli agenti vengono innestati nei processi già esistenti (GitHub, Slack, Linear) e circondati di controlli.
Nessuna di loro prende il risultato della generazione «così com'è». Il valore nasce dalla cornice attorno alla generazione.
Conclusione
L'IA amplifica ciò che è già nella testa dello sviluppatore. La propensione a complicare la realizza in pochi secondi, e l'abitudine a tagliare il superfluo pure.
La decisione che questo codice è troppo complesso per questo compito la prende ancora una persona. L'IA la esegue soltanto più in fretta.