Qualità del software con i coding agent: generare, comprendere, verificare.

Produttività e qualità non hanno un rapporto automatico.

L'esperimento di Borg e colleghi, pubblicato nel 2026 con 151 partecipanti, non trova differenze significative nella successiva manutenibilità del codice sviluppato con assistenti IA. Le attività risalgono a fine 2024 e precedono i coding agent attuali.

Liu e colleghi analizzano invece circa 302.600 commit attribuiti all'IA in 6.299 repository. Individuano problemi con analisi statica, dei quali il 22,7% resta presente all'ultima revisione osservata. È evidenza di problemi persistenti nel campione, non una misura di tutti i difetti o del confronto con ogni sviluppatore umano.

GitClear osserva più duplicazione e meno refactoring nel periodo di diffusione dell'IA. Sono segnali da monitorare; da soli non dimostrano una causa unica. Leggere insieme questi lavori suggerisce di misurare gli effetti nel proprio processo.

Se l'agente modifica più codice di quanto il team riesca a comprendere e verificare, la velocità iniziale può diventare lavoro di revisione e manutenzione. È il rischio che considero centrale.

La mia proposta è separare la produzione dalla validazione: criteri di accettazione e risultati di riferimento devono essere controllati anche fuori dal processo che ha generato la modifica. Un secondo agente può aiutare, ma può condividere gli stessi errori del primo.

• Test di comportamento, integrazione, contratti e regressione proporzionati al rischio.
• Analisi statica, controlli di sicurezza e verifiche delle dipendenze.
• Revisioni con criteri espliciti e confronto con requisiti e vincoli del dominio.
• Modifiche abbastanza piccole da rendere visibili errori e conseguenze.

Non ogni riga richiede lo stesso controllo umano. Serve però una persona responsabile della decisione, con verifiche più forti dove un errore ha conseguenze maggiori.

Una harness contiene contesto, regole, strumenti e procedure. Migliorarla può rendere l'agente più efficace; può anche propagare più rapidamente un'interpretazione sbagliata.

Per questo considero parte della harness anche i limiti alle azioni e le condizioni per fermarsi: test falliti, requisiti ambigui, differenze inattese o controlli mancanti. Conta la capacità di rilevare una modifica errata prima che entri nel prodotto.

Il mio metodo: specifiche e harness di progetto →

Uso «debito di comprensione» per descrivere un rischio: il software continua a funzionare, ma sempre meno persone sanno perché è stato costruito così. È un concetto utile, non una metrica standard consolidata.

Decisioni documentate, discussione del dominio e verifiche con il team aiutano a mantenere questa conoscenza. Il ruolo dello sviluppatore comprende requisiti, architettura, contesto e giudizio sulle modifiche; delegare l'esecuzione richiede ancora queste competenze.

Nel settembre 2026 Shopify descrive il passaggio da React Native a Swift e Kotlin. Non parla di un fallimento del framework: i coding agent hanno cambiato il costo di mantenere due implementazioni native.

La Shop app è stata ricostruita e pubblicata in circa 12 settimane. La migrazione della Shopify app, con oltre 300 schermate, è invece descritta come in corso. È un'esperienza aziendale specifica, non una stima trasferibile ad altre applicazioni.

Per la migrazione Shopify usa Helix: piccoli checkpoint con test, confronto visivo e due revisioni agentiche indipendenti. L'approvazione dell'ingegnere è l'impostazione normale, anche se è prevista una modalità autonoma.

Il caso sostiene una possibilità: ridurre il costo dell'implementazione può rendere praticabile una scelta architetturale prima troppo costosa. Il risultato dipende anche da processo, test e controllo delle modifiche.

Shopify descrive anche un’architettura accessibile agli agenti: logica separata dall’interfaccia e prove rapide tramite riga di comando.

Ne ricavo una proposta più generale: responsabilità chiare, contratti espliciti, test rapidi e osservabilità comprensibile rendono più facile lavorare sul sistema, sia alle persone sia agli agenti. Non occorre adottare lo stesso stack per applicare questi criteri.

Un coding agent può lavorare con maggiore autonomia quando dispone di un ciclo di verifica: modifica il codice, esegue i controlli, legge gli errori e corregge. I test automatici sono una parte centrale di questo ciclo, insieme alla compilazione e alle altre verifiche pertinenti. Non occorre necessariamente adottare un processo TDD rigoroso; servono riscontri ripetibili sul comportamento richiesto.

In alcune applicazioni legacy, provare una modifica richiede l’avvio dell’intero sistema, un database con dati adatti, servizi esterni e configurazioni difficili da ricostruire. Se la logica è strettamente legata a queste dipendenze e mancano test automatici, predisporre un ciclo di verifica richiede lavoro aggiuntivo. Anche un’applicazione recente può avere gli stessi vincoli.

La presenza di un database non impedisce l’automazione: si possono predisporre ambienti di test e dati ripristinabili. Può però essere necessario documentare l’avvio, introdurre test che descrivano il comportamento esistente e separare gradualmente alcune dipendenze. Questo lavoro va incluso nella valutazione iniziale dell’adozione. Dove la verifica resta soprattutto manuale, considererei più limitata l’autonomia dell’agente e manterrei modifiche piccole con controlli umani espliciti.

Percentuale di codice generato, token, prompt o numero di pull request non bastano a misurare il beneficio. Confronto tempi di completamento e revisione, difetti, regressioni, rilavorazioni e capacità di evolvere il prodotto.

Il framework SPACE tratta la produttività come multidimensionale. In questo senso propongo di valutare insieme risultati, collaborazione e sostenibilità del lavoro, senza trasformare una singola misura in una graduatoria dei singoli sviluppatori.

L'obiettivo che sceglierei è produrre software corretto, utile e mantenibile a un costo sostenibile.

Gli studi hanno metodi e ambiti diversi. Le proposte su validazione e ruolo dello sviluppatore sono criteri di lavoro ricavati da queste evidenze, non promesse di un risultato universale.

• Borg et al. — Echoes of AI (si apre in una nuova scheda): esperimento sulla manutenzione successiva; dati raccolti a fine 2024.
• Liu et al. — Debt Behind the AI Boom, versione 2 (si apre in una nuova scheda): commit attribuiti all’IA e problemi rilevati mediante analisi statica.
• GitClear — Maintainability Gap (si apre in una nuova scheda): segnali osservazionali su duplicazione, riuso e manutenzione.
• Shopify — scelta dello sviluppo native (si apre in una nuova scheda): ragioni del cambiamento e architettura accessibile agli agenti.
• Shopify — migrazione della Shop app (si apre in una nuova scheda): esperienza e tempi del progetto specifico.
• Shopify — Helix (si apre in una nuova scheda): checkpoint e verifiche per la migrazione della Shopify app.
• Forsgren et al. — SPACE (si apre in una nuova scheda): dimensioni complementari della produttività degli sviluppatori.
• Claude Code — Best practices (si apre in una nuova scheda): criteri e controlli eseguibili dall’agente.
• Martin Fowler — Legacy Seam (si apre in una nuova scheda): separazione delle dipendenze per verificare il codice esistente.
• Microsoft — Choosing a testing strategy (si apre in una nuova scheda): test con database reali, isolamento e limiti dei sostituti nei progetti EF Core.