La rivendicazione più importante e strutturale nella presentazione di Killian Carlsen-Phelan è anche la più semplice: la generazione del codice non è più la parte difficile. "Il collo di bottiglia era la generazione del codice", ha detto. "Con gli agenti AI, quella è stata risolta nella maggior parte dei casi. Quindi il collo di bottiglia si è spostato dalla semplice generazione del codice alla verifica del codice".

La Dati dietro la Rivendicazione

I dati a supporto di questa affermazione dovrebbero far riflettere i leader dell'ingegneria. Le ricerche di Sonar nell'ultimo anno, basate su un sondaggio di più di 1.000 sviluppatori, hanno trovato che il 42% del codice commesso è generato o assistito dall'IA. Ma il 96% degli sviluppatori afferma di non fidarsi pienamente di essa. Meno della metà riferisce di aver verificato completamente il codice prima di spingerlo e unirlo.

Questo è un divario significativo: una grande e crescente quantità di codice non fidato sta entrando nei codebase di produzione, e i responsabili della spedizione ammettono di non controllarlo con cura. La vecchia domanda era "come costruiamo questa applicazione?". La nuova domanda è "come posso essere sicuro che questo sia sicuro?" — e la risposta a questa domanda ora determina quanto velocemente qualsiasi team può spedire effettivamente.

La Prospettiva dell'Agente

Un relatore dal team di ingegneria di deployment di Codex ha inquadrato lo stesso problema dalla prospettiva dell'agente. Le implementazioni più economiche spostano il collo di bottiglia nella specifica e nella verifica, che ha detto nettamente "non è l'obiettivo desiderato". La sua descrizione del ciclo dell'agente è un ciclo a quattro stadi: azione del modello, esecuzione governata dal modello, osservazione dei cambiamenti e aggiornamento del piano. Ogni compito porta con sé un risultato, un'invariant, un ambito definito e i criteri di accettazione.

La corollaria che ha offerto è secca e vale la pena appiccicare al monitor: "Fatto significa che un compito è completo con prove. Il contenimento non è correttezza. Il contratto di feedback appartiene all'interno del ciclo".

Perché l'Agente Non Può Controllare il Lavoro da Solo

Perché l'agente non può semplicemente controllare il proprio lavoro? Il relatore di Codex ha nominato il pattern di fallimento con precisione: fallimento correlato. Gli agenti tendono a cadere in alcune trappole comuni — ricadendo su contesto incompleto, applicando una correzione locale che viola un'invariant globale, o generando test che propagano la stessa comprensione sbagliata che erano destinati a catturare. Quei test generati non sono un controllo neutro, perché provengono dalla stessa fonte del codice.

Il "self-critique" è utile, ha detto, ma non è un oracolo indipendente. L'output dell'agente e l'output del verificatore tendono ad essere ortogonali. Non puoi determinare se un compito è effettivamente completato senza guardare entrambi. L'istruzione pratica è quella di cercare attivamente prove disconfermanti: il compilatore lo ha confermato, i test sono stati eseguiti, l'analisi passa?

Ha anche tracciato una distinzione critica tra il livello di esecuzione — quali strumenti un agente può accedere, quale scopo ha, quali approvazioni richiede — e il livello dell'artefatto, dove vengono valutati i risultati: se il risultato è accettabile, quali test sono stati prodotti, quali analisi, quale politica, quale intenzione. La formulazione più affilata del perché queste sono preoccupazioni separate è: "Un sandbox può contenere una scrittura, ma non può provare che una query sia sicura".

La postura raccomandata è la difesa in profondità — controlli a strati con diversi confini — con l'umano che possiede l'intenzione, le eccezioni e la decisione finale di spedizione.

Il Framework di Sonar

La risposta di Sonar è un framework a quattro passi, dei quali Sonar possiede tre. Generate è qualsiasi strumento di codifica che lo sviluppatore usa — Codex o altro. Le altre tre sono il pitch del prodotto.

    • Generate: qualsiasi strumento di codifica usato dallo sviluppatore
    • Verify: verifica immediata all'interno dell'IDE dopo la generazione
    • Solve: utilizzo di agenti per risolvere i problemi rilevati

Il vero ritorno di investimento di questo framework è lo spostamento dal ciclo esterno al ciclo interno. Il ciclo esterno è il classico flusso di integrazione continua: scrivi codice, spingi su GitHub o GitLab, osserva il flusso fallire su un test o una scansione, torna nell'IDE, correggi, spingi di nuovo, fallisci di nuovo. Killian ha chiamato questo ciclo "il flagello dell'esistenza di molti sviluppatori".

Il ciclo interno verifica all'interno dell'IDE immediatamente dopo la generazione, prima di qualsiasi spinta. La sua formulazione del valore è: "Il tempo è denaro nelle aziende, e i tuoi ingegneri risparmiano molto denaro sulle fatture di terapia senza quella frustrazione".

Capacità Pratiche: Rilevamento dei Segreti

La prima capacità concreta della dimostrazione è un gancio per il rilevamento dei segreti. Killian ha piantato una chiave API di OpenAI in testo semplice nel codice sorgente — un errore che ha ammesso di aver fatto lui stesso — e ha notato che il tempo medio di rimedi per un segreto in un repository pubblico è attualmente di 90 giorni. Durante quella finestra, il token è esposto al mondo e ai bot di scraping.

Quando ha chiesto a Codex di eseguire un commit usando un segreto falso, il plugin ha bloccato la richiesta istantaneamente. Nessun segreto è arrivato nel contesto LLM e nulla è stato archiviato nei log. Chiedere all'agente di leggere un file contenente un segreto è stato anch'esso bloccato, quindi Codex non ha mai visto le credenziali perse.

Un membro del pubblico ha posto la domanda che le persone della sicurezza pongono sempre: un agente potrebbe scrivere uno script per leggere il file e aggirare il gancio? Killian ha ceduto che è possibile. Il gancio scatta sull'invio strumento del prompt dell'utente, quindi se quel percorso viene aggirato, il gancio potrebbe non essere invocato. Per l'uso di base di Codex — prompt e chiamate di strumento — i segreti nel prompt vengono rilevati. È una confessione onesta che nessun controllo è assoluto, coerente con il framing del relatore che nessun oracolo singolo è la prova.

Integrazione e Entitlement

La sequenza di impostazione è meccanica ma vale la pena essere registrata perché definisce cosa l'integrazione aggiunge effettivamente. Il comando finale sonar integrate codex installa il gancio di rilevamento dei segreti, una direttiva dell'agente che istruisce l'agente a usare le competenze SonarQube, competenze aggiuntive e una configurazione MCP. Il server MCP gira dentro Docker ed espone strumenti che permettono a Codex di interagire con la dashboard SonarQube Cloud — ad esempio, elencare i problemi del progetto.

La divisione del lavoro: la CLI fornisce e configura, il server MCP esegue le competenze, e una richiesta può instradare attraverso uno o l'altro a seconda del compito.

Due capacità sono accedute tramite entitlement a pagamento. Context augmentation rileva quando Codex sta per eseguire un compito e gli fornisce le linee guida del progetto e l'architettura rilevante. Agentic analysis è un gancio che scatta immediatamente dopo qualsiasi modifica dell'agente, eseguendo un'analisi lato server sul codice appena scritto. Entrambe sono state escluse dal piano gratuito.

Il Cuore della Dimostrazione: Regola S8702

Il cuore della dimostrazione è la regola S8702, che Killian ha descritto come una regola scritta da Sonar specificamente per i flussi di lavoro degli agenti AI: prevenire gli agenti di codifica AI di scrivere codice che altri agenti possono sfruttare. La vulnerabilità piantata è un'iniezione SQL in database.py, dove una query viene passata direttamente in un f-string ed eseguita dal cursore, con search_task che prende il suo argomento da sys.argv. Chiunque controlli sys.argv controlla il database.

SonarQube rileva il difetto usando esecuzione simbolica e analisi di taint, tracciando il flusso dei dati dalla fonte attraverso più file e funzioni fino alla sorgente. Killian ha detto a Codex di correggere S8702. Il risultato è stato una query parametrizzata. Poi il gancio post-strumento-uso è scattato: agentic analysis ha riesaminato il codice modificato lato server e ha segnalato che un problema persisteva nel file — ma che problema preesisteva ed era uno dei problemi piantati. Il gancio è circoscritto al codice modificato e non tenta di risolvere tutto il resto. Ha confermato che non sono stati introdotti nuovi problemi e che S8702 non è stato più segnalato.

Questo è la risposta concreta al problema Idra: correggere un problema e guardare che ne appaiano tre altri. Il gancio verifica che una correzione non abbia introdotto nuove vulnerabilità, chiudendo il ciclo automaticamente. Per gli utenti senza agentic analysis, la stessa verifica avviene al prossimo push CI.

Guida, Verifica e Risoluzione

L'ultima dimostrazione ha chiesto a Codex di aggiungere una nuova funzione — eliminare un compito per ID — a database.py. Context augmentation ha fornito le regole e l'architettura rilevanti, il codice è stato implementato e agentic analysis lo ha verificato, con Codex che iterava finché non erano stati rimediati eventuali problemi segnalati. Quindi è Guida, Verifica e Risoluzione che operano all'interno del terminale.

Le Tensioni Non Risolte

Due tensioni attraversano la sessione senza una risoluzione completa. La prima è il divario tra l'ambiente di dimostrazione e la realtà di produzione: la passeggiata live era rallentata dalla Wi-Fi della conferenza, e la ripetuta cautele di Killian — "immagina che questo abbia preso 15 secondi" — segnalano che l'ergonomia degli strumenti non è stata dimostrata effettivamente a velocità. La seconda è il limite riconosciuto del gancio dei segreti, a cui un pubblico...