Sapere dove sono i problemi non significa essere in grado di governarli.
La maggior parte delle organizzazioni che adotta strumenti di analisi statica del codice arriva presto a una soglia: le metriche ci sono, i report anche, ma la qualità continua a dipendere dall’attenzione dei singoli, dall’esperienza del team che esegue la review, da chi decide di sollevare un problema e quando.
Misurare non è governare. E con la crescente diffusione di strumenti di AI generativa e coding agent, questa differenza sta diventando ancora più importante.
Avere le metriche non significa governare la qualità
La qualità del software viene spesso raccontata attraverso metriche: affidabilità, sicurezza, manutenibilità, duplicazioni, complessità, copertura dei test, technical debt. Sono indicatori necessari, ma da soli non bastano.
Una piattaforma di Static Application Security Testing non si limita infatti a contare i problemi nel codice. L’analisi può operare a diversi livelli: dalle violazioni di regole sintattiche e semantiche fino all’analisi dei control flow e data flow e, in ambito security, alla taint analysis, che consente di seguire il percorso di un dato potenzialmente non sicuro dalla sua origine fino a un’operazione sensibile.
Individuare correttamente questi problemi, però, non basta ancora a governare la qualità. Definire, ad esempio, che una modifica non possa introdurre nuove vulnerabilità o che debba rispettare determinati livelli di affidabilità, sicurezza e manutenibilità significa trasformare il risultato dell’analisi in una policy applicabile al processo di sviluppo.
Il problema si vede meglio quando crescono team, repository, tecnologie e pipeline. Con la sola revisione manuale è difficile applicare gli stessi criteri in modo uniforme: team diversi possono interpretare le stesse regole in modo diverso, adottare soglie differenti o intercettare i problemi in momenti diversi.
È qui che dalla Code Quality si passa alla Quality Governance: metriche, regole e standard smettono di descrivere semplicemente la qualità del codice e diventano criteri condivisi con cui stabilire, in modo sistematico e verificabile, quali modifiche possono proseguire nel ciclo di sviluppo.
Quando una regola diventa parte della pipeline
Perché questo modello funzioni, i criteri definiti dall’organizzazione devono essere verificati nel punto in cui il codice viene prodotto e integrati nel normale workflow di sviluppo.
Piattaforme come SonarQube operano in questo modo: l’analisi statica viene eseguita automaticamente sul codice e i risultati vengono valutati rispetto alle regole e alle policy definite dall’organizzazione.
Il Quality Gate rende concreto questo passaggio. Definisce le condizioni che il codice deve rispettare per essere considerato conforme agli standard stabiliti, e porta l’analisi nella CI/CD come un vero checkpoint: se le condizioni non sono rispettate, la pipeline può impedire che la modifica prosegua verso il merge o il deployment.
Un requisito come “non introdurre nuove vulnerabilità nel codice” smette quindi di essere una raccomandazione affidata alla responsabilità dei singoli team e diventa una condizione verificata automaticamente a ogni modifica. Il controllo diventa ripetibile, misurabile e indipendente da chi ha prodotto il codice.
Quest’ultimo punto diventa particolarmente rilevante quando quel codice non viene più scritto esclusivamente da persone.
Il debito tecnico migliore? Quello che non entra nella codebase
Intervenire su un’applicazione esistente significa spesso confrontarsi con anni di decisioni progettuali, dipendenze e criticità accumulate. Pretendere di correggere tutto prima di poter evolvere il software rischia di rendere la qualità un obiettivo irraggiungibile. Molto più efficace è evitare che ogni nuova modifica continui ad aumentare il debito esistente.
È la logica del Clean as You Code e del New Code: concentrare il controllo sul codice nuovo o modificato e richiedere che rispetti gli standard definiti prima che diventi parte della codebase. Il debito tecnico esistente può così essere affrontato progressivamente, senza generarne di nuovo nel frattempo.
Pensiamo a una pull request che introduce una nuova API. L’applicazione compila e i test funzionali passano, ma l’analisi statica segue il flusso di un parametro proveniente dalla request fino alla costruzione di una query SQL e individua un percorso potenzialmente vulnerabile a SQL injection. L’analisi non segnala una semplice riga di codice sospetta: mette in relazione source, propagazione del dato e sink potenzialmente pericoloso.
Se il finding viola i criteri di sicurezza definiti dal Quality Gate, la modifica non supera il controllo. Il problema viene intercettato prima dell’integrazione, quando il contesto è ancora disponibile e correggerlo costa meno.
Ma cosa succede quando a scrivere il codice è un agente AI?
L’adozione dell’AI cambia la scala del problema. Developer e coding agent possono oggi produrre modifiche con una velocità molto superiore rispetto al passato, e il collo di bottiglia tende a spostarsi dalla capacità di scrivere codice a quella di verificarlo. Più codice viene generato, più diventa difficile affidare la qualità esclusivamente alla review manuale.
Dal punto di vista della governance non conta se il codice sia stato scritto da una persona o da un modello. La domanda è se possiamo verificare che ogni modifica rispetti gli stessi standard di qualità, sicurezza e architettura prima di entrare nella codebase.
È su questo scenario che Sonar sta costruendo il paradigma AC/DC (Agent Centric Development Cycle).
Da CI/CD ad AC/DC: Guide, Verify, Solve
AC/DC estende il concetto di Continuous Inspection a un ciclo di sviluppo nel quale developer e agenti AI collaborano alla produzione del software. Il modello ruota attorno a tre momenti: Guide, Verify e Solve.
Guide significa fornire, prima della generazione, il contesto entro cui il codice deve essere prodotto: standard di sviluppo, regole, caratteristiche del progetto e vincoli architetturali. L’obiettivo è evitare che l’agente generi codice formalmente corretto ma incoerente con le convenzioni o l’architettura dell’applicazione.
Verify è il cuore della Quality Governance. Il codice prodotto deve essere sottoposto a una verifica indipendente rispetto a chi (o a cosa) lo ha generato. L’analisi deterministica di SonarQube controlla proprietà di reliability, security e maintainability attraverso regole, analisi del control e data flow e taint analysis. A questa si possono affiancare livelli di review AI-native, per intercettare problemi logici e comportamentali che richiedono una comprensione più ampia del contesto. Vale un principio: l’AI che genera codice non dovrebbe essere l’unico soggetto che ne certifica la correttezza.
Solve porta il processo dalla detection alla remediation. Gli issue individuati possono essere corretti con meccanismi assistiti o agentici, e la modifica viene poi sottoposta agli stessi criteri di verifica.
Il ciclo diventa quindi: guidare → generare → verificare → correggere → verificare nuovamente. Non un singolo controllo al termine dello sviluppo, ma un loop continuo in cui qualità e sicurezza accompagnano la produzione del codice.
La qualità comincia dove nasce il codice
Quality Governance non significa spostare la responsabilità lontano dai developer. Il feedback deve arrivare il più vicino possibile al momento in cui il problema viene introdotto.
Con SonarQube for IDE, le regole possono essere portate direttamente nell’ambiente di sviluppo e sincronizzate con quelle definite centralmente, così che alcuni problemi emergano mentre il developer sta ancora scrivendo il codice. Le successive analisi su branch e pull request e i controlli nella CI/CD verificano poi la modifica nel suo complesso.
Con gli agenti AI lo stesso principio viene portato ancora più vicino al momento della generazione: il controllo può entrare nel loop dell’agente, evitando che un problema si propaghi attraverso decine o centinaia di righe generate successivamente.
L’obiettivo non è moltiplicare i controlli, ma renderli coerenti e progressivi lungo tutto il workflow.
Dalle scelte individuali agli standard condivisi
La qualità resta una responsabilità delle persone, ma in organizzazioni con molti team, repository e tecnologie (e ora anche coding agent) non può dipendere solo dall’esperienza o dall’attenzione individuale. Una Quality Governance efficace richiede almeno due livelli.
L’organizzazione stabilisce gli standard: quali regole applicare, quali livelli di rischio accettare, quali soglie utilizzare e quali condizioni devono determinare l’esito di un controllo. La piattaforma rende poi questi criteri eseguibili, applicandoli in modo consistente e producendo evidenze verificabili nel tempo.
Una regola non cambia in base al team che lavora sul progetto. Una vulnerabilità non diventa meno rilevante perché il codice è stato prodotto da un agente AI. Una soglia non viene reinterpretata a ogni pull request. Quality Profile, analisi automatizzate, Quality Gate e controlli di pipeline diventano così componenti di un unico modello di governance.
La qualità si costruisce nel processo, non alla fine
Passare dalla Code Quality alla Quality Governance significa incorporare qualità e sicurezza nel processo con cui il software viene costruito: rendere esplicite le condizioni che ogni modifica deve rispettare, verificarle automaticamente e intervenire quando possono ancora orientare lo sviluppo.
Con l’AI generativa, aumentare la capacità di produrre codice richiede una capacità almeno equivalente di verificarlo. L’approccio AC/DC va un passo oltre l’analisi del risultato finale: guida la generazione, verifica in modo indipendente ciò che viene prodotto e supporta la remediation, mantenendo gli standard dell’organizzazione come riferimento comune.
Se a costruire il software sono sempre più spesso persone e agenti AI insieme, la vera domanda non è quanto codice siamo in grado di generare. È quanto del codice che generiamo siamo realmente in grado di verificare e governare.
