Il problema emergente nella catena di sviluppo automatizzato

Le capacità delle intelligenze artificiali di scrivere codice hanno superato la velocità con cui gli umani possono rivederlo. Cole Gannaway, solutions engineer di Qodo, sostiene che il collo di bottiglia non sia più la generazione automatica, ma la revisione e la verifica dei cambiamenti all'interno della cosiddetta “software factory”, dove agenti autonomi producono l’intero ciclo di vita del software.

Durante il discorso al AI Engineer conference Gannaway ha dichiarato: “La generazione del codice non è ancora risolta, ma sta avanzando a un ritmo che non avevamo mai visto; questo ha creato un grande collo di bottiglia.”

Per illustrare il rischio ha citato il caso di Bitwarden, manager di password open‑source. Un singolo rinominare un campo nel modello dati passa tutti i test, i linters e le verifiche automatiche, ma il cambiamento si propaga a server back‑end, client web, app mobili, server MCP e strumenti da riga di comando. Solo in produzione si manifesta il bug, con crash dell’app o segnalazioni di errore.

La cultura del “merge senza lettura”

Gannaway ha sondato il pubblico chiedendo quanti avevano effettuato un merge senza leggere ogni riga modificata; quasi tutti hanno alzato la mano. Gli ingegneri confidano troppo negli strumenti di verifica, ma “non tutti gli strumenti sono costruiti allo stesso modo e non tutti i contesti sono uguali”. Un semplice “wall of green checks” non garantisce che siano stati considerati gli effetti a valle.

Il motivo per cui una suite di test può non rilevare questi errori è strutturale: i test verificano che il codice faccia ciò che l’autore intendeva, non che un nome di campo sia utilizzato in altri tre repository gestiti da team diversi.

Il grafo software di Qodo: mappare le dipendenze reali

La risposta di Qodo è un software graph che mappa automaticamente i repository di un team e, soprattutto, le superfici di integrazione tra di essi. Non basta elencare i repository; il grafo deve catturare quali componenti si collegano a quali, altrimenti le informazioni fornite al revisore sono inutili.

Nel modello di Gannaway, il “blast radius” di un cambiamento diventa una proprietà interrogabile del codebase, anziché qualcosa che gli ingegneri ricostruiscono dalla memoria.

Il grafo gestisce il rischio strutturale, mentre un secondo ingrediente gestisce il “gusto” — le euristiche non scritte ma applicate dagli esperti revisori. Gannaway cita regole personalizzate, ad esempio: “ogni modifica a un'API pubblica deve includere un flag di deprecazione o essere soggetta a revisione più approfondita”.

Portare la conoscenza a monte

L’ambizione è spostare queste regole a monte, verso il server MCP o l’agente di codifica, prima che venga generata la prima riga di codice. “C’è l’opportunità di introdurre queste informazioni prima di generare il codice, sapendo che potremmo avere effetti a valle”, ha osservato Gannaway, ammettendo che ciò migliora le probabilità di correttezza al primo tentativo ma non elimina la necessità di un doppio controllo.

Il ciclo di apprendimento continuo

Qodo può generare automaticamente una regola a partire da un commento lasciato da un revisore su una pull request, trasformando la conoscenza tribale di un senior engineer in conoscenza organizzativa. Gannaway sottolinea che i post‑mortem tendono a rivelare più spesso lezioni di processo o organizzative che tecniche; il suo meccanismo cattura proprio queste ultime.

Un’obiezione comune è: “Se Claude Code ha già scritto il cambiamento, perché non chiedere a lui di rivedere il proprio lavoro?”. Gannaway risponde in tre punti:

    • L’agente di implementazione è occupato con debug, esplorazione del codebase e non può gestire ulteriori revisioni; le finestre di contesto più ampie non risolvono il problema del “buried information”.
    • Un agente dedicato alla revisione può attingere a contesti curati — il grafo software, le regole personalizzate, informazioni specifiche della run — anziché a quello “sporco” accumulato durante la generazione.
    • L’indipendenza è cruciale: modelli diversi (Anthropic, OpenAI, open‑weight) e harness differenti riducono bias condivisi; revisioni avversarie su uno stesso codice forniscono segnali di alta affidabilità quando concordano, o avvertono di indagini quando divergono.

Integrazione con sistemi di ticketing e governance

Un partecipante ha evidenziato un altro punto critico: il contesto fornito all’agente di implementazione può mancare dell’intento reale, generando soluzioni sbagliate anziché solo sovra‑ingegnerizzate. Qodo risponde collegando il revisore a ticket di Jira e Linear, verificando che ogni PR soddisfi i criteri di accettazione.

Durante una demo live, Gannaway ha mostrato come un ticket collegato abbia evidenziato discrepanze tra i requisiti del ticket e il codice consegnato, segnalando la necessità di correzioni prima del merge.

Il suo consiglio pratico ai clienti è di far fermare periodicamente l’agente di codifica — intorno al 25 %, 50 % e 75 % della generazione — per consentire una revisione autonoma e confermare che il percorso sia ancora corretto.

Verso la automazione completa del merge

Il prossimo livello, secondo Gannaway, è determinare quali pull request possano essere mergiate senza intervento umano. Molte organizzazioni stanno già chiedendo indicazioni su quali PR siano “sicure” da approvare, e il grafo software fornisce il dato di “blast radius” necessario per tale giudizio.

Questa ambizione crea una tensione: lo stesso strato di contesto deve sia dare agli umani le informazioni necessarie a fidarsi del merge, sia eventualmente sostituire la decisione umana. Gannaway non specifica la soglia di accuratezza né i metodi di misurazione; l’argomento dell’indipendenza è più una tecnica di riduzione del bias che una garanzia di precisione.

Contesto di mercato e prospettive future

I dati di Alphabet’s Google DeepMind mostrano che, sebbene l’IA scriva più del 75 % del codice di produzione, solo l’11,9 % delle richieste di cambio è stato delegato completamente all’IA a settembre, rispetto al 7,5 % di aprile. La generazione di codice avanza rapidamente, ma la fiducia delegata segue più lentamente.

Amazon ha già avvertito i propri ingegneri di non confondere il consumo di token con la produttività, ricordando che il settore sta ancora cercando il giusto indicatore di valore, sia esso token consumati o merge approvati.

In sintesi, Qodo posiziona la sua soluzione di revisione indipendente come un servizio premium rispetto alla pratica più semplice di utilizzare lo stesso agente di generazione per la revisione. La sua strategia si basa su un grafo software dettagliato, regole personalizzate, apprendimento continuo e verifica indipendente, puntando a colmare il divario tra la velocità della generazione automatica e la sicurezza della consegna in produzione.