Approfondimento
Affidabilità AI nel codice e nei test: rischi operativi e leve di controllo
Testo scritto con l’intelligenza artificiale a partire da 4 fonti citate, senza revisione umana prima della pubblicazione.
L'AI accelera codice, test e ricerca di vulnerabilità ma funziona solo se lavora su dati di test collegati e con revisione umana; altrimenti genera suite illusorie e rischi di governance.
Una suite Playwright generata dall’AI fallisce. Lo script include un identificatore allucinato. Il team cerca l’elemento, non esiste. Diagnosi bloccata. Ministry of Testing chiama questo scivolone “vibe testing”: automazione scritta da prompt vaghi, accettata perché “sembra” buona, non perché qualcuno ne risponda davvero1.
Il problema pratico: “vibe testing” e l’illusione del verde
Il “vibe testing” si vede dal cruscotto pieno di verde e dal vuoto dietro. L’AI produce centinaia di casi o un intero framework in pochi minuti. Il volume tranquillizza. La copertura resta incerta. Senza chi conosce codice e prodotto, i test possono mancare i rischi che contano, puntare a elementi inesistenti e bruciare budget su tentativi ripetuti1.
Gli esempi sono diretti. Chiedere a un agente “500 test positivi e negativi” e aggiungerli in blocco alla regressione fa crescere la suite senza migliorarla. Spedire script che includono un identificatore allucinato blocca la diagnosi: la suite fallisce e nessuno trova la causa, perché quell’elemento non c’è. Ripetere il ciclo “genera, esegui, correggi” può consumare il budget mensile per l’AI in dieci giorni, lasciando le suite senza manutenzione prima di una release1.
Se il giudizio di test lascia il posto all’apparenza, nessuno sa spiegare perché qualcosa si rompe in produzione. La leva visiva sostituisce la responsabilità. Il risultato è una copertura presunta, non reale1.
Una leva concreta: “tests as context” e dati collegati
Ministry of Testing definisce “tests as context” l’uso dei dati di test, strutturati e collegati ai requisiti, come contesto per assistant e agenti durante la scrittura di codice e test2. Gli strumenti lavorano meglio quando sanno cosa il sistema deve fare e come ha già fallito. Se l’assistente vede requisiti collegati ai test e i difetti già emersi, è più probabile che il codice rispetti le attese al primo giro. Per i tester, lo stesso contesto guida aggiornamenti mirati dell’automazione. Conta la qualità del contesto più della potenza del modello scelto2.
La pratica richiede disciplina dei dati. I team tengono casi, risultati, difetti e link ai requisiti in una test management platform. Espongono questi dati agli strumenti AI tramite API o un server Model Context Protocol, MCP. L’assistente li interroga mentre si lavora in un editor abilitato all’AI2. La cronologia conta: versioni di test e requisiti si legano a tag di release o milestone. In questo modo l’assistente vede come il sistema è cambiato release per release2.
Potenza e doppio uso: modelli che trovano e sfruttano falle
Un sistema automatizzato, supportato dal modello GPT-6 Cyber di OpenAI, ha individuato 1.724 vulnerabilità nel kernel Linux. Nei test ne ha sfruttate 948 per ottenere accesso con privilegi di amministratore. Il costo operativo dichiarato: circa 1,2 milioni di dollari in crediti API. OpenAI cita anche almeno 10 tecniche d’attacco che non risultavano note prima dei test3.
L’attività è proseguita oltre il kernel. Con lo stesso approccio, OpenAI riferisce di 81 falle ad alta gravità nel browser Firefox di Mozilla. Anche in questo caso le vulnerabilità erano sconosciute prima dei test, secondo quanto afferma l’azienda3. Ricercatori umani hanno rivisto ogni evidenza, preparato le segnalazioni e proposto correzioni ai manutentori del progetto. OpenAI descrive il modello come supporto a un sistema automatizzato, non come sostituto dell’analisi e della disclosure3.
I numeri mostrano un ciclo completo, dal rilevamento allo sfruttamento controllato, fino alla proposta di correzioni. Al tempo stesso, l’operazione ha un costo significativo in crediti API3. Nelle suite di test, cicli “genera, esegui, correggi” possono consumare rapidamente il budget disponibile1.
Apertura dei modelli e verifica: il caso Inkling e SWE-2 Flash
Cognition ha lanciato SWE-2 Flash, un modello di coding addestrato partendo da Inkling-Small, e non pubblicherà le pesature finali. L’azienda dice che Flash costa un quinto del modello maggiore SWE-2 e genera token circa tre volte più in fretta. Inkling-Small è sotto licenza Apache 2.0, che consente derivati non open. Cognition motiva la chiusura con la cybersecurity4.
Inkling-Small arriva da Thinking Machines Lab, guidata dalla cofondatrice e CEO Mira Murati. È un mixture-of-experts da 276 miliardi di parametri, con 12 miliardi attivi. È stato rilasciato il 30 luglio sotto Apache 2.0, con pesature scaricabili da Hugging Face4. Cognition attribuisce il salto prestazionale di Flash a uno stadio di addestramento intermedio inserito prima del reinforcement learning. Su Terminal-Bench 4.0, Flash tocca il 20 per cento contro lo 0,9 per cento del base; su FrontierCode 2.0 passa dal 3,2 per cento al 24 per cento. Su SWE-Bench Pro v2 Hard, Flash arriva all’89,9 per cento contro il 90,6 per cento di SWE-2. Su altre prove resta indietro. In diverse valutazioni, Claude Haiku 5.5 e DeepSeek V4.1 Flash lo superano. L’account CultOfAI su X definisce il mid-training “un modo pratico per trasformare una base open debole in un agente utilizzabile”, e avverte che i numeri non sono verificati in modo indipendente4.
Cosa cambia per team di sviluppo e QA: pratiche e responsabilità
I fatti convergono sul lavoro quotidiano. L’AI produce valore quando opera su contesto affidabile e quando qualcuno ne risponde.
- Per i test: evitare “vibe testing”. Niente suite generate in blocco senza capire cosa coprono. Integrare “tests as context”: collegare casi, esiti, difetti e requisiti in una piattaforma, esporli via API o MCP, e usare l’assistente in un editor abilitato all’AI1,2.
- Per la sicurezza: usare l’automazione per cercare e riprodurre falle con revisione umana delle evidenze e processi di disclosure. I cicli intensivi possono costare caro, come mostra l’operazione descritta da OpenAI3.
- Per la governance: tenere conto della trasparenza del modello. Nel caso di SWE-2 Flash, le pesature non sono pubbliche. Con Inkling-Small, le pesature sono scaricabili, con licenza indicata dalla fonte4.
La scelta riguarda il modo di lavorare con l’AI: dati di test collegati, versioni tracciate e un processo di revisione. La differenza tra un cruscotto verde e un sistema affidabile passa da qui.
Se i team consolidano questi prerequisiti, l’AI può sostenere cicli completi, come già visto nella ricerca di vulnerabilità. Se li ignorano, i prossimi “verde integrale” possono coprire non test utili, ma buchi difficili da spiegare in produzione.
Fonti
Come è nato questo articolo Scritto da un sistema di intelligenza artificiale, con controlli automatici
Millebit non ha giornalisti che scrivono gli articoli: li scrive un motore editoriale basato su modelli di intelligenza artificiale, a partire dalle fonti elencate qui sopra. Prima di uscire, ogni testo passa questi controlli:
- Rilettura. Un passaggio toglie i tic della prosa generata da un modello, come i contrasti costruiti e le frasi che annunciano invece di informare, senza toccare fatti e fonti.
- Fedeltà alle fonti. Un passaggio dedicato toglie ogni affermazione che le fonti non sostengono. Valutazione su questo pezzo: 9/10.
- Anti-cliché. Un filtro scarta frasi fatte, enfasi e tic della prosa artificiale: superato.
- Giudizio editoriale. Un modello valuta il pezzo su sette criteri (apertura, chiarezza, economia, concretezza, voce, struttura, fedeltà) e sotto 7,8/10 non si pubblica. Questo articolo ha preso 8,1/10.
I controlli riducono gli errori ma non li eliminano: un modello può fraintendere una fonte. Per le decisioni importanti, risali alla fonte originale. Se trovi un errore, segnalacelo.
Per vedere Millebit nelle notizie principali di Google, aggiungilo alle tue fonti preferite. Oppure segui l’edizione di oggi, il feed RSS o La Sintesi.