Un'app da 150.000 righe scritta da agenti mostra duplicazioni nel data layer

Un singolo file supera le 6.000 righe nel livello dati di un’app generata da agenti; ogni operazione ripete setup HTTP e parsing JSON, e il blocco cresce a ogni nuova feature¹.

L’applicazione conta circa 150.000 righe, di cui 120.000 in Rust, con il resto in TypeScript e Terraform. Include una UI web con aggiornamenti dinamici, integrazioni esterne, job in background, funzioni di machine learning e analisi del testo. Il deploy è automatizzato¹.

Gli agenti hanno scritto tutto: soprattutto Claude Code, con alcuni passaggi in Cursor. L’autore non ha fatto code review continua; solo sguardi occasionali per curiosità¹.

La scoperta nasce da un evento preciso. Nel terminale compare un edit alla riga 4.000 di un file. Apertura del file: oltre 6.000 righe nel data layer. La stessa sequenza per ogni query, lettura o scrittura. Non un caso isolato: la duplicazione aumenta con l’arrivo di nuove funzionalità¹.

L’obiettivo dichiarato è stimare il beneficio economico di un refactoring. La domanda è di convenienza, non di tecnica: quando conviene intervenire per ridurre ripetizioni e accorpare responsabilità, osservando come il codice generato dagli agenti ha preso forma durante lo sviluppo¹?

Il contesto è esplicito. L’articolo fa parte di “Exploring Gen AI”, la serie in cui i tecnologi Thoughtworks documentano l’uso di sistemi generativi per costruire software. Pubblicato il 30 luglio 2026, descrive un progetto completo, con pipeline di deploy operativa, sviluppato interamente tramite agenti¹.

Pratica di progetto: nessuna revisione sistematica del codice durante la costruzione. Questa scelta rende visibile il pattern. Modifiche profonde attraversano file già lunghi. Un unico blocco si espande replicando lo stesso schema per ogni operazione sui dati¹.

Perimetro e fenomeno in un colpo solo: un’app medio‑grande, stack misto, funzionalità eterogenee; un unico strato, l’accesso ai dati, cresce fino a migliaia di righe con ripetizioni sistematiche a ogni feature. È il candidato naturale per chiedersi quando i costi della duplicazione superano i costi di un intervento¹.

Esempio concreto del pattern osservato: per ogni operazione sul data layer si ripetono gli stessi passi, costruzione della richiesta HTTP, invio, gestione della risposta, parsing del JSON, con variazioni minime legate ai parametri della singola query. La struttura resta uguale, la sequenza si copia e incolla, il file si allunga¹.

Qui sta il punto operativo dell’analisi: non si parla di “debito” in astratto, ma di un blocco specifico che si espande con una regola semplice e osservabile. L’autore cerca di capire quando ha senso accorpare quella logica, e quando no, usando l’evidenza che emerge dallo sviluppo tramite agenti¹.

L’articolo non fornisce numeri su tempi o difetti. Per una stima economica servirebbero metriche basiche: tempo medio per implementare una modifica che tocca il data layer; numero di punti duplicati da aggiornare per cambio requisito; frequenza delle modifiche su quello strato; tasso di errori introdotti in operazioni ripetitive; dimensione e crescita del file. Solo con questi dati si può collocare il “punto di pareggio” del refactoring rispetto alla crescita della duplicazione osservata¹.