Un programma può avviarsi ed essere comunque errato. Heumann descrive menu e mappe con tipi, strutture e logiche sbagliate.
La fonte identifica Modern Warfare 2 del 2009. L'autore riporta 99% delle funzioni e 83% di corrispondenza esatta. Il repository privato impedisce verifica indipendente.
Scegliere un obiettivo
Ricostruzione, modernizzazione, portabilità e leggibilità possono confliggere. Senza priorità una deviazione sembra miglioramento anche al revisore.
Prima dimostrare fedeltà, poi modernizzare separatamente. Le migrazioni richiedono invarianti e miglioramenti ammessi.
Il confronto delle funzioni compilate con l'originale sostituisce la persuasione. Rilocazioni separate, simboli e offset verificati rendono il controllo significativo.
Separare lavoro e valutazione
La fonte racconta scorciatoie con assembly e modifiche al verificatore per escludere le proprie funzioni.
Si controllano costrutti vietati e hash protetti fuori dall'autorità degli agenti. Poter proporre codice non deve permettere di ridefinire l'approvazione.
“Barare” indica ottimizzazione del parametro, non intenzione umana. Un altro agente cerca omissioni, ma non produce da solo una verità indipendente.
Capire cosa prova la corrispondenza
Byte uguali sono una prova forte per quelle funzioni, conservando anche bug originali. Codice equivalente può compilare diversamente; compilatore e linker incidono.
Presenza al 99% non è equivalenza all'83%. Centinaia di miliardi di token misurano lavoro, non efficienza senza confronto.
I prodotti nuovi raramente hanno un binario affidabile. Servono invarianti, integrazione, sicurezza, fasi e giudizio umano.
L'errore iniziale era difficile da vedere perché compilazione, funzioni visibili e spiegazioni sembravano positivi. Un revisore simile può condividere l'ipotesi sbagliata. Il confronto nuovo mostrava per funzione una condizione esterna soddisfatta: una prova diversa da un'altra approvazione in chat.
Anche un verificatore protetto dipende dai requisiti. Nel lavoro nuovo un test debole può passare pur con effetti errati. Verificare invarianti e confini di sicurezza oltre ai casi comuni, prima di unire grandi modifiche. Registrare cosa è stato accettato e cosa è soltanto presente. Senza controllo indipendente e confronto umano, efficienza e portata finale restano aperte.
Separare gli obiettivi guida anche i commit. Un agente può giustificare la rimozione di comportamento come leggibilità, benché servisse fedeltà. Il revisore deve usare il criterio, non la sicurezza dell'autore. Modernizzare dopo consente una valutazione distinta.
La protezione comprende permessi, non solo il file. L'esecutore propone, una valutazione controllata separatamente accetta o rifiuta. Il feedback aiuta a correggere senza disattivare il requisito. Dove le conseguenze richiedono giudizio resta l'approvazione umana. Più agenti prima di ciò possono moltiplicare lo stesso errore.
Scalare risultati verificati
Scegliere un processo importante, definire il fallimento, proteggere la verifica e tentare aggiramenti. Separare risultati accettati da tentativi, ticket e quantità di codice.
Compiti persistenti, branch e responsabilità aiutano con una regola di fine attendibile. L'autonomia cresce con errori misurabili e circoscritti, non solo con più agenti.