Come revisionare codice generato dall'IA: i test verdi non bastano
Vibe Coding accelera la produzione di codice, ma non riduce automaticamente il lavoro di review. Un LLM può creare rapidamente un diff ordinato. Una spiegazione convincente o una suite verde non dimostrano da sole che l’implementazione sia sicura per la produzione.
Il caso riguarda un validatore pre-build per gli SVG di terminale animati di questo programma del blog. Controlla regole XML/CSS limitate, percorsi e SHA-256 del manifest e immagini demo visibili negli articoli in otto lingue. Un SVG canonical fisso è il caso positivo. I quattro difetti sono stati trovati in test isolati prima del merge; le prove valgono solo per il validatore offline.
La suite iniziale ha superato 8/8, ma una review indipendente ha trovato due accettazioni non sicure. Dopo la prima correzione sono passati 10/10 test, poi sono emersi altri due difetti. La versione finale fissata ha superato 12/12 test principali; quattro probe d’attacco aggiuntivi sono stati eseguiti separatamente e respinti. Tre file JavaScript hanno superato anche node —check.
Il metodo ha cinque passaggi: fissare ambito e invarianti; creare controesempi minimi; registrare RED solo se esiste un’esecuzione realmente fallita; verificare indipendentemente casi positivi e negativi sul commit esatto; decidere in base al rischio. I test logici non sostituiscono build, controlli di piattaforma e verifica runtime. Per modifiche rischiose, una scheda può registrare ambito, commit Base/Head, invarianti, caso positivo, controesempio, comando e ambiente reali, limiti non verificati e conclusione. Il validatore è un componente pre-build del blog, non un CLI generico distribuito separatamente. Non è stato misurato alcun risparmio di tempo di review.
Il repository pubblico contiene solo controesempi sintetici sanificati e test didattici eseguibili; non include il validatore di produzione di questo programma del blog, le correzioni reali né l’architettura interna. La sequenza 8/8 → 10/10 → 12/12 proviene dalla revisione offline originale; i test pubblici riproducono i quattro schemi di difetto, non l’implementazione di produzione.
Esempi sintetici sanificati e test riproducibili
Perché 8/8 test hanno accettato input errati?
Una suite verde mostra solo che gli input correnti soddisfano le asserzioni correnti. Non dimostra che ogni input non valido venga respinto.
Il primo controesempio metteva un’immagine consentita e un riferimento non autorizzato a un altro articolo sulla stessa riga. La vecchia logica trovava un’immagine consentita e lasciava passare tutta la riga. La review indipendente ha creato un SVG reale sotto un altro slug e aggiunto il riferimento Markdown accanto all’immagine valida negli otto articoli localizzati. Il file è stato creato per escludere un falso fallimento per destinazione mancante. La vecchia implementazione restituiva ancora successo con posts_checked=8.
<img src="/assets/terminal-demo.svg" alt="Terminal demo" width="356" height="137" /> Il secondo controesempio è una race del filesystem: il percorso controllato può non essere il file aperto alla fine. Il test ha sostituito una directory genitore al confine di apertura; fuori dal checkout c’era un SVG canonical con SHA-256 corretto. Dopo la sostituzione con un symlink, la vecchia implementazione ha letto e accettato il file esterno. È stata aggirata la provenienza, non il controllo hash.
Il percorso Linux finale apre la radice fidata del checkout e risolve i componenti rispetto a descrittori di directory genitore già aperti. I componenti intermedi devono essere directory e usano O_NOFOLLOW; anche il file finale rifiuta symlink. Vengono controllati tipo, numero di link e dimensione, confrontati device, inode e dimensione prima/dopo la lettura e infine verificato il digest. Usa Linux /proc/self/fd e fallisce in modo chiuso se procfs non è disponibile. Il perimetro presume checkout fidato e procfs disponibile, non aggressori arbitrari con lo stesso UID o privilegi host. Vedi Linux openat2(2).
Secondo round: l’hash è corretto, ma il contenuto può essere invisibile
Dopo il primo fix, 10/10 test sono passati. Il terzo controesempio riguarda reduced motion: i frame SVG partono trasparenti e l’animazione li rivela. Se la regola riduce il movimento fermando solo l’animazione senza mostrare il frame finale, il risultato resta vuoto.
.f { opacity: 0; }
@media (prefers-reduced-motion: reduce) {
#f0 { animation: none; opacity: 1; }
#f3 { animation: none; } /* il frame finale resta trasparente */
}Il test ha ricalcolato SHA-256, dimensione, nome content-addressed e manifest canonical per mantenere validi i controlli circostanti. Ha verificato il contratto “il risultato finale deve essere visibile”. Vedi MDN su prefers-reduced-motion.
Il quarto controesempio viene da Markdown. La vecchia regex contava immagini anche nei commenti HTML. Commentando l’unica immagine, il tag restava nel sorgente ma non appariva nella pagina. Secondo le regole HTML block di CommonMark 0.31.2, un tag commentato non è un’immagine visibile.
<!-- <img src="/assets/demo.svg" alt="Terminal demo" /> -->
Collegare i risultati ai commit esatti
| Versione | Suite principale | Review indipendente successiva |
|---|---|---|
| Versione iniziale | 8/8 superati | Accettazioni errate SEC-01 e SEC-02 |
| Versione dopo la prima correzione | 10/10 superati | Accettazioni errate SEC-03 e SEC-04 |
| Versione finale verificata offline | 12/12 test principali superati | Quattro probe separati respinti |
La suite finale include regressioni per SEC-01–04. I quattro probe aggiuntivi non fanno parte del 12/12 e non vanno sommati come 16/16. Tre file JavaScript hanno superato node —check, che verifica la sintassi, non il comportamento.
Gli ultimi due test di regressione sono stati committati prima del fix del sorgente, ma la suite completa non è stata eseguita sul commit con i soli test. Non esiste quindi un’esecuzione completa 10/12 RED registrata. È verificabile che la review indipendente ha riprodotto le accettazioni errate nel vecchio validatore e che la versione finale ha superato suite e probe separati.
Solo dopo aver stabilizzato le prove sul comportamento controllo la complessità: quale invariante protegge ogni helper, ramo o configurazione, se la logica è duplicata e se esistono chiamanti reali. Meno codice non significa sempre più semplicità; rimuovere una protezione del percorso può reintrodurre una race.
Pannello interattivo delle evidenze
Seleziona un controesempio sintetico per esaminare input, invariante, errore riprodotto e limiti delle prove.
Caso selezionato: SEC-01 · Presenza non significa esclusività
SEC-01 · Presenza non significa esclusività
- Condizione di input
- Un'immagine consentita e un riferimento non autorizzato a un altro articolo compaiono insieme.
- Invariante da preservare
- Ogni riferimento rilevante deve rispettare la regola; uno consentito non rende sicuro tutto l'input.
- Errore riprodotto dall'esempio sintetico
- La vecchia logica accettava l'intera riga dopo aver trovato un'immagine consentita e ignorava il riferimento extra.
- Comportamento corretto atteso
- Controllare ogni riferimento e rifiutare l'input se uno supera il limite.
- Round di review originale
- Trovato nella prima review indipendente
- Lezione di review riutilizzabile
- Creare un controesempio minimo con contenuto valido e non valido e controllare tutto l'input.
SEC-02 · Race tra controllo e uso
- Condizione di input
- Dopo la verifica del percorso, una directory padre o un link simbolico viene sostituito prima dell'apertura.
- Invariante da preservare
- L'oggetto verificato deve restare quello usato e dentro il confine previsto del filesystem.
- Errore riprodotto dall'esempio sintetico
- Controllare un percorso e riaprirlo dopo permette di cambiare destinazione tra controllo e uso.
- Comportamento corretto atteso
- Verifica e accesso devono mantenere il confine; l'esempio sintetico non dichiara una correzione di produzione.
- Round di review originale
- Trovato nella prima review indipendente
- Lezione di review riutilizzabile
- Esaminare l'intervallo tra verifica e uso per trovare stato modificabile da altri.
SEC-03 · Il movimento ridotto deve mostrare il frame finale
- Condizione di input
- I frame SVG iniziano trasparenti; con movimento ridotto l'animazione si ferma.
- Invariante da preservare
- Disattivare l'animazione non deve nascondere il contenuto finale importante.
- Errore riprodotto dall'esempio sintetico
- Se si ferma solo l'animazione senza mostrare il frame finale, il risultato può essere vuoto.
- Comportamento corretto atteso
- Con movimento ridotto deve apparire direttamente lo stato finale completo e leggibile.
- Round di review originale
- Trovato nella seconda review indipendente
- Lezione di review riutilizzabile
- Trattare la preferenza di accessibilità come input indipendente e verificare la visibilità.
SEC-04 · I commenti non sono contenuto visibile
- Condizione di input
- Un commento HTML contiene testo che sembra un elemento immagine valido.
- Invariante da preservare
- Il testo sorgente è diverso dagli elementi realmente renderizzati dal browser.
- Errore riprodotto dall'esempio sintetico
- Il conteggio dei tag può considerare visibile un'immagine dentro un commento.
- Comportamento corretto atteso
- Analizzare la struttura, escludere i commenti e valutare solo elementi renderizzati.
- Round di review originale
- Trovato nella seconda review indipendente
- Lezione di review riutilizzabile
- Inserire un tag falso in un commento per verificare una convalida consapevole della struttura.
Evidenza didattica sintetica pubblica
Il repository pubblico riproduce solo schemi di difetti sintetici. Un test superato riproduce il caso di errore, non dimostra una correzione di produzione.
Apri il repository didattico sintetico fissatoRiepilogo offline dell'ingegneria originale
Registrazione originale: 8/8 → 10/10 → 12/12. Quattro probe indipendenti sono stati eseguiti separatamente e non fanno parte del 12/12.
Limite della verifica
L'ambito è il validatore offline su Node.js v22.16.0 / Linux x64. macOS nativo contro scritture concorrenti malevole e runtime completo del sito restano non verificati.
Articoli correlati: Mutation Testing, il limite fail-open della review pre-push di OpenQodex e gli ancoraggi dei commenti di Diffle.
Cosa manca tra test superati e approvazione alla produzione?
La verifica finale ha riguardato il validatore offline su Node.js v22.16.0, Linux x64: 12/12 test principali superati, quattro probe d’attacco aggiuntivi respinti, casi positivi di SVG canonical, manifest e otto lingue superati; tre file JavaScript hanno superato node —check.
Questo sostiene una conclusione limitata: le quattro accettazioni errate note sono state corrette in quell’ambiente e con quelle regole. Non dimostra che tutto il blog sia pronto per la produzione. La resistenza nativa di macOS a scrittori filesystem concorrenti malevoli non è verificata; build completa e controllo runtime della pagina finale erano fuori dal test offline.
Una vera linea di rilascio va suddivisa per rischio: test unitari per il comportamento coperto, controlli statici per pattern specifici, build e integrazione per la composizione, test di piattaforma e runtime per i confini del deployment. Se una frontiera critica resta non verificata, un successo locale non è piena prontezza alla produzione.
Contratti e controesempi aiutano a trovare il comportamento sospetto; test della versione esatta e prove indipendenti decidono dove approfondire. Non elimina il giudizio umano, ma trasforma “sembra a posto” in una decisione di review con prove, ambito e verificabilità.