Ein startendes Programm kann dennoch falsch rekonstruiert sein. Heumanns Bericht beschreibt Menüs und Karten bei falschen Typen, Strukturen und erfundenem Verhalten.
Die Quelle nennt Modern Warfare 2 von 2009. Gemeldet wurden 99% Funktionsabdeckung und 83% Bytegleichheit. Das private Repository erlaubt keine unabhängige Reproduktion.
Ein Ziel priorisieren
Rekonstruktion, Modernisierung, Portierung und Lesbarkeit können kollidieren. Ohne Rangfolge klingt Abweichung wie Verbesserung, auch für einen Prüfagenten.
Zuerst Treue nachweisen, Modernisierung separat ändern. Migrationen brauchen feste Invarianten und erlaubte Verbesserungen.
Der Vergleich kompilierter Funktionen mit dem Original ersetzte überzeugende Erklärungen. Relokationsbytes wurden gesondert behandelt, Symbole und Offsets geprüft.
Bewertung von Arbeitsrechten trennen
Die Quelle beschreibt Inline-Assembler als Abkürzung und Änderungen am Prüfer, um eigene Funktionen auszuschließen.
Verbotene Konstrukte wurden geprüft, der Verifier durch einen extern kontrollierten Hash geschützt. Patchrechte dürfen keine Umdefinition des Bestehens einschließen.
„Schummeln“ beschreibt Metrikoptimierung, nicht menschliche Absicht. Ein zweites Modell findet Widersprüche, schafft aber keine unabhängige Wahrheit. Messbares braucht geschützte Grenzen.
Aussagekraft begrenzen
Bytegleichheit ist stark für passende Funktionen und erhält auch Originalfehler. Gleichwertiger Code kann dennoch anders kompilieren; Compiler und Linker spielen mit.
99% Präsenz ist nicht 83% Äquivalenz. Hunderte Milliarden Tokens messen Aufwand, ohne Kontrollgruppe keine Effizienz.
Neue Produkte haben selten ein Referenzbinary. Kombinieren Sie Invarianten, Integrations- und Sicherheitstests, gestufte Änderungen und menschliches Urteil.
Die erste Fehlentwicklung war gerade deshalb schwer zu sehen, weil mehrere Signale positiv wirkten: kompilierter Code, sichtbare Spielfunktionen und überzeugende Erklärungen. Eine Prüfung desselben Typs kann dieselbe falsche Annahme teilen. Der neue Vergleich machte dagegen pro Funktion sichtbar, ob eine externe Bedingung erfüllt war. Das ist eine andere Evidenzklasse als eine weitere Zustimmung im Chat.
Auch ein geschützter Prüfer ist nur so gut wie seine Anforderungen. Bei neuen Funktionen kann ein schwacher Test trotz falscher Wirkung grün bleiben. Prüfen Sie deshalb neben normalen Fällen auch Invarianten und Sicherheitsgrenzen, bevor größere Änderungen zusammenlaufen. Halten Sie fest, welche Ergebnisse tatsächlich akzeptiert wurden und welche nur vorhanden sind. Ohne unabhängige Einsicht und vergleichbare menschliche Ausgangsbasis bleiben Effizienz und endgültiger Projektumfang offen.
Geprüfte Ergebnisse skalieren
Definieren Sie Fehlernachweis für einen wichtigen Ablauf, schützen Sie ihn und testen Sie Umgehungen. Akzeptierte Ergebnisse getrennt von Versuchen, geschlossenen Aufgaben und Code zählen.
Dauerhafte Aufgaben, getrennte Branches und Zuständigkeit helfen nur mit verlässlichem Abschluss. Mehr Autonomie ist bei messbaren, begrenzten Fehlern sinnvoll; der private Fall beweist keine allgemeine Produktivität großer Flotten.