Una sera mi sono ritrovato a patchare un errore che avevo già patchato. Con una correzione diversa. Sopra un’altra correzione. E ho pensato: quand’è che ho smesso di costruire e ho iniziato a riparare?
Non era un bug isolato. Era un pattern. L’AI aveva generato codice che funzionava. Poi era emerso un caso limite. L’AI aveva proposto una correzione. La correzione aveva introdotto un nuovo strato di complessità. Il nuovo strato aveva generato un nuovo caso limite. E così via.
Un report di CodeRabbit pubblicato questo mese mostra che le pull request con codice assistito dall’AI contengono 1.7 volte più problemi di quelle scritte interamente da umani. Il dato non mi sorprende — l’ho vissuto. Ma sento che il numero racconta solo metà della storia. La metà più insidiosa non è il bug. È il loop.
Il loop funziona così: l’AI genera codice plausibile. Il codice funziona nel caso base. Un caso reale fa emergere un’eccezione. Correggi l’eccezione con un nuovo strato. Il nuovo strato funziona per quel caso. Un altro caso reale fa emergere un’altra eccezione — spesso causata dal primo strato di correzione. E ricomincia.
Ogni strato di compensazione è tecnicamente corretto. Ogni singolo patch risolve il problema che doveva risolvere. Ma l’insieme diventa fragile in un modo che nessun singolo pezzo rivela. È complessità strutturale, non superficiale.
A un certo punto ho detto a voce alta una frase che mi è rimasta in testa: stiamo spalando complessità sopra altra complessità per correggere errori causati da eccessiva complessità. Un loop fallimentare.
La svolta non è stata tecnica. È stata metodologica. Ho smesso di cercare il prossimo bug e ho ricominciato a leggere tutto da zero. Non una lettura veloce — una lettura atomica, funzione per funzione, per capire cosa fosse davvero necessario e cosa fosse solo una toppa messa lì per compensare qualcosa che non avrebbe dovuto rompersi.
Quello che ho trovato mi ha sorpreso. Una parte significativa di ciò che avevo costruito nelle ultime settimane non era funzionalità — era compensazione. Strati di difesa aggiunti sopra strati di difesa. Ognuno giustificato dal bug che risolveva. Ma l’insieme era un sistema che esisteva solo per proteggere se stesso dai propri effetti collaterali.
Forrester prevede che entro la fine dell’anno il 75% delle enterprise affronterà debito tecnico moderato o alto causato dallo sviluppo accelerato dall’AI. Sento che il debito più pericoloso non è quello che si vede nel codice — è quello che si nasconde nella struttura. Il codice che funziona ma che esiste solo per compensare qualcos’altro che non avrebbe dovuto rompersi.
Non ho una risposta definitiva. Ma da quel momento ho iniziato a fare una cosa diversa: prima di aggiungere qualsiasi correzione, mi chiedo se sto costruendo o riparando. Se sto aggiungendo qualcosa che ha ragione di esistere — o se sto mettendo una toppa sopra un’altra toppa.
È più lento. Ma sento che la distinzione tra costruire e riparare potrebbe essere la domanda più importante quando si lavora con un’AI.