224.000 righe di codice generate con l'IA: cosa resta del lavoro umano?
224.000 righe di codice prodotte con l'IA per sviluppare un'applicazione completa: una retrospettiva sull'evoluzione del ruolo dello sviluppatore, tra definizione dell'ambito, scelte tecniche e gestione del debito tecnico.
Nota sulla stesura di questo articolo
Come il precedente, questo articolo è stato redatto con l'ausilio di un'IA, poi riletto, corretto e validato da me.
Si basa sulla mia esperienza di sviluppo di LingRise, sui miei appunti di lavoro e su un audit tecnico estratto dal codice e dalla cronologia Git. Se i numeri derivano da queste tracce oggettive, le intuizioni, i dubbi e i cambi di rotta appartengono invece all'esperienza vissuta.
Non mi considero un virtuoso della tecnica. Eppure, da settembre 2025, ho sviluppato da solo un progetto che oggi conta quasi 224.000 righe di codice, in gran parte generate con l'aiuto dell'intelligenza artificiale.
A questo punto, una domanda sorge spontanea: cosa resta concretamente del mio lavoro?
La spiegazione semplicistica vorrebbe che l'essere umano fornisca le idee mentre la macchina digita il codice. La versione opposta sosterrebbe che l'IA fa tutto mentre l'utente sta a guardare. Entrambe le visioni sono errate.
Per misurare cosa dipenda ancora dallo sforzo umano in un simile volume di codice, occorre osservare come la natura degli ostacoli sia cambiata nel corso dei mesi: prima una sfida di cadenza, poi un problema di metodo, e infine un lavoro di arbitraggio e scelte decisionali.
La realtà dietro i numeri
Preso singolarmente, un contatore di righe non dimostra nulla. Qualsiasi modello linguistico può generare migliaia di righe ridondanti o inutilizzabili in pochi minuti.
Nel caso di LingRise, queste 224.000 righe corrispondono a un'infrastruttura concreta sviluppata in circa un anno:
- TypeScript (~124.000 righe): l'applicazione web con Next.js e l'applicazione mobile in React Native.
- Python (~86.000 righe): il motore di gestione dei contenuti (trascrizione audio, traduzione, generazione e controllo qualità).
- SQL (~11.000 righe): quasi un centinaio di file di migrazione.
- Architettura: 96 route API, 56 pagine utente, 179 componenti React, oltre sessanta tabelle PostgreSQL e 332 commit.
Questo volume non fa di me uno sviluppatore eccezionale. Dimostra invece ciò che una sola persona può oggi pensare di costruire, ma anche le insidie che questa abbondanza fa emergere.
Dall'improvvisazione alla necessità di un metodo
All'inizio del progetto, il mio approccio non aveva nulla di metodico. Esponevo un'idea all'IA, discutevo rapidamente delle possibili soluzioni di implementazione, approvavo una proposta e passavo oltre.
Finché il progetto si limitava a poche decine di file, questa modalità "freestyle" era più che sufficiente. L'IA moltiplicava la mia velocità di esecuzione, permettendomi di testare intuizioni che non avrei mai avuto il tempo di scrivere manualmente.
L'attrito è emerso con l'accumularsi delle funzionalità. Quando una base di codice comincia a dipendere da scelte architetturali prese settimane prima, aprire un prompt vuoto per aggiungere un ulteriore tassello diventa rischioso. L'IA sa produrre in fretta, ma non garantisce spontaneamente la coerenza di un insieme in continua espansione.
Per evitare di impantanarmi, ho adottato il metodo BMAD, scoperto durante la mia attività di monitoraggio tecnologico. Pur senza formule magiche, ha imposto un rigore indispensabile: fasi esplicite, agenti specializzati e un percorso ben definito che va dalla raccolta dei requisiti fino alla specifica tecnica, prima ancora di generare una singola riga di codice.
Il vantaggio principale non è stato tecnico, ma cognitivo: ho iniziato a dedicare più tempo a chiarire i problemi piuttosto che a chiedere soluzioni. Fare brainstorming, formalizzare i vincoli, sottoporre una decisione a un agente critico e accettare di scartare un'idea prima ancora di scriverne il codice hanno permesso di risanare il flusso di sviluppo.
Eppure, un progetto può essere strutturato alla perfezione e andare comunque a sbattere contro un muro.
La trappola dell'abbondanza funzionale
All'inizio, LingRise doveva coprire uno spettro molto ampio: grammatica, coniugazioni, vocabolario tematico, libri interattivi, analisi di canzoni e dialoghi guidati. L'IA dà l'impressione di poter creare tutto in tempi rapidissimi: e allora, perché non fare tutto?
Era un'illusione. Anche con un metodo solido e agenti efficienti, accumulare sotto-prodotti porta a un sistema impossibile da testare, manutenere e lanciare sul mercato.
La vera sfida è quindi cambiata: non si trattava più di accelerare, ma di sapersi fermare.
Per prendere una decisione, ho avviato una sessione con l'agente bmad-brainstorming. L'obiettivo non era delegargli la scelta — la volontà di sfoltire veniva da me —, ma sottoporre le mie priorità a un contraddittorio sistematico.
A forza di mettere in discussione ogni caso d'uso, è emersa una linea guida chiara: LingRise doveva concentrarsi su una proposta forte e comprensibile. Nello specifico: immersione tramite podcast reali, trascrizioni sincronizzate, traduzione contestuale parola per parola e un modulo di shadowing per la pratica orale. Il resto è stato accantonato.
È qui che risiede una parte essenziale del lavoro: ideare un quadro di valutazione rigoroso per resistere alla tentazione di costruire qualsiasi cosa con il pretesto che il costo di generazione è invisibile.
Valutare le scelte sulla giusta scala
Una decisione tecnica raramente dipende da un semplice test unitario. La pipeline di traduzione di LingRise ne è un ottimo esempio.
Su un campione limitato di testi, la tentazione è quella di scegliere il modello più sofisticato senza badare troppo alle spese. Ma sulla scala dell'intero catalogo dell'applicazione, il volume raggiungeva i 2,16 miliardi di token. (Non controllo da tempo, ma probabilmente siamo a una cifra molto più alta, dato che genero nuovi podcast ogni giorno.)
Le proiezioni finanziarie hanno subito ridimensionato il dibattito:
- DeepSeek: ~1.900 €
- Claude Sonnet: ~30.000 €
- Claude Opus: ~165.000 €
Persino l'acquisto di una scheda grafica dedicata per l'esecuzione in locale non reggeva il confronto economico rispetto alle tariffe di alcune API specializzate.
L'IA può stilare alla perfezione questa tabella comparativa e calcolare i rapporti. Tuttavia, non prende l'iniziativa di valutare l'impatto di una scelta tecnica sulla scala di un modello economico globale: questa responsabilità resta interamente umana.
Quando la soluzione tecnica nasconde il vero problema
Il codice generato può girare senza il minimo errore mancando del tutto il proprio obiettivo.
Per proteggere i file audio a pagamento, l'IA mi aveva configurato un sistema di URL firmati temporanei. All'apparenza funzionava tutto. Non ho scoperto la vulnerabilità da solo improvvisandomi esperto di cybersicurezza: il problema è emerso semplicemente sottoponendo il codice a /bmad-code-review. A causa della mia configurazione di archiviazione e dei sottodomini, la firma poteva essere alterata senza bloccare l'accesso al file.
La prima IA aveva applicato l'istruzione tecnica alla lettera, senza rendere davvero sicuro il contenuto. È stato necessario iterare per progettare un sistema di token verificati al volo. Il mio lavoro non è stato analizzare il codice manualmente, ma mantenere alto il livello di rigore organizzando il confronto critico tra più agenti.
L'altra faccia della medaglia: il debito tecnico consapevole
Rivendicare 224.000 righe di codice senza parlare del debito tecnico sarebbe disonesto. LingRise presenta debolezze evidenti:
- Nessuna pipeline di integrazione continua (CI): le verifiche prima del deployment restano in gran parte manuali.
- Una migrazione a monorepo incompleta: la struttura complessiva conserva artefatti storici nella radice fin dal lancio dell'applicazione mobile.
L'IA consente di individuare queste criticità e di generare correzioni a catena. Tuttavia, il tempo di validazione e l'attenzione restano risorse limitate. Accettare queste lacune fa parte del compromesso: definire le priorità significa anche farsi carico di ciò che non si affronta nell'immediato.
Dopo questi undici mesi, l'opposizione binaria tra "l'essere umano che progetta" e "la macchina che esegue" non regge più. Gli agenti IA sono ormai capaci di redigere specifiche e proporre architetture coerenti.
Il ruolo dello sviluppatore non è svanito: si è spostato.
Consiste nel cogliere il momento in cui il problema cambia natura. Nel capire quando un'accelerazione diventa tossica, nel rifiutarsi di sviluppare nuove funzionalità anche se sembrano facili da far generare, nell'individuare le falle logiche dietro un codice pulito e nel garantire l'equilibrio economico di un sistema.
L'IA ha permesso di concretizzare LingRise a una velocità impensabile per un singolo sviluppatore. Ma la responsabilità di ciò che viene costruito — e soprattutto di ciò che non deve esserlo — continua a ricadere sulla persona dietro lo schermo.