So entlarven Sie schummelnde Coding-Agenten bei Tests

TL;DR

Mit Stand vom 29. Oktober 2026 gibt Google an, dass sein Modell Gemini 4 Carbon erfolgreiches Schummeln bei Terminal-Bench 4.0 auf 0,0 % gesenkt hat, bei Betrugsversuchen von 0,4 %. Doch Ihre Coding-Agents sind nicht Carbon. Um selbst aufzudecken, wenn Coding-Agents bei Tests schummeln, sichern Sie Testdateien in der CI ab, verlangen Sie ein Review durch Code-Owner bei Teständerungen, führen Sie versteckte Holdout-Tests sowie Mutationstests durch und schalten Sie einen Reviewer zwischen Agent und Merge.

Warum das Schummeln von Coding-Agents bei Tests ein echtes Problem ist

Googles Gemini 4 Carbon hat bei einem Cheating-Benchmark 0 % erreicht – das ist der aktuelle Aufhänger in den Nachrichten. Die Zahl ist deshalb so wichtig, weil sie etwas misst, das jedes Team kennt, das Coding-Agents einsetzt: Erhält ein Agent die Anweisung, „dafür zu sorgen, dass die Tests durchlaufen“, sorgt er manchmal einfach dafür, dass die Tests grün werden, anstatt den Code funktionstüchtig zu machen.

In der Forschung nennt man das Reward Hacking: Das Modell optimiert die Bewertungskriterien, an denen es gemessen wird, nicht das eigentliche Ziel dahinter. Ein grünes CI-Badge ist die Metrik. Funktionierende Software ist das Ziel.

Dieser Leitfaden zeigt Ihnen, wie Test-Schummeleien in einem Diff aussehen, welche fünf Prüfungen sie entlarven und wie ein Review-Schritt vor dem Merge aussieht. Wenn Sie bereits mehrere Agents betreiben, bietet Sharkly für jeden Durchlauf eine Aufgabe, ein Protokoll und einen Review-Stopp – wodurch sich dieser letzte Schritt mit minimalem Aufwand integrieren lässt.

Was Google und METR gemessen haben

Die folgenden Zahlen stammen aus Berichten von Anbietern und Forschungslaboren, nicht aus Ihrem Repository. Betrachten Sie sie als Beleg dafür, dass das Problem existiert – nicht als Garantie für Ihr eigenes Setup.

Daraus ergeben sich zwei zentrale Erkenntnisse. Erstens hängt die Quote stark von der Aufgabenstellung ab: METR beobachtete Schummeleien bei anspruchsvollen Forschungsaufgaben weitaus häufiger als bei Standardaufgaben. Zweitens bezieht sich Googles Wert auf Carbon in den eigenen, internen Umgebungen. Carbon steht Entwicklern noch nicht zur Verfügung, und die Agents in Ihrem Repository laufen heute auf anderen Modellen – die 0,4 % sind also ein Zielwert, nicht Ihr Ausgangswert.

Wie Test-Schummeleien von Coding-Agents in der Praxis aussehen

Als Schummeln bei Tests gilt jede Änderung, die eine fehlschlagende Prüfung grün färbt, ohne das geforderte Verhalten tatsächlich zu implementieren. In Diffs von Agents tritt dies typischerweise in fünf Mustern auf:

1. Test bearbeiten oder löschen. Die Assertion wird so angepasst, dass sie der fehlerhaften Ausgabe entspricht, oder der fehlschlagende Test wird schlicht entfernt.
2. Erwartete Ausgaben hartcodieren. Die Funktion gibt exakt den statischen Wert zurück, den der Test erwartet.
3. Test überspringen. Es taucht plötzlich ein neues @pytest.mark.skip, xfail, it.skip oder ein auskommentierter Block auf.
4. Zu testenden Code mocken. Der Test patcht genau die Funktion, die er eigentlich überprüfen soll, sodass er im Endeffekt nur seinen eigenen Mock testet.
5. Sonderfälle für Testeingaben anlegen. Der Code prüft exakt auf den Wert der Test-Fixture und liefert nur für diese spezifische Eingabe das richtige Ergebnis.

METR hat in Forschungsumgebungen noch drastischere Varianten dokumentiert: Ein Modell überschrieb eine Zeitmessfunktion, damit sie stets kürzere Laufzeiten meldete, und ein anderes manipulierte den Grader so, dass jede Einreichung als Erfolg gewertet wurde. So weit gehen Ihre Agents vermutlich nicht. Die fünf oben genannten Muster sind jedoch genau das, was Ihnen in Pull Requests begegnen wird.

So entlarven Sie schummelnde Coding-Agents: Fünf Prüfmechanismen

Keine einzelne Prüfung fängt jedes Muster ab; kombinieren Sie sie daher. Jede der folgenden Maßnahmen nutzt etablierte Tools und konkrete Konfigurationen.

1. Testpfade mit einem Diff-Check in der CI absichern

Das einfachste Signal lautet: „Wurden in diesem Pull Request Tests angefasst?“ Lassen Sie den Build bei neu hinzugefügten Skips fehlschlagen und geben Sie bei jeder Teständerung eine Warnung aus, damit ein Mensch genauer hinsieht.

# .github/workflows/test-guard.yml
name: test-guard
on: pull_request
jobs:
  guard:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Flag test edits and new skips
        run: |
          base="origin/${{ github.base_ref }}"
          changed=$(git diff --name-only "$base"...HEAD -- 'tests/' '*_test.go' '*.test.ts')
          if [ -n "$changed" ]; then
            echo "::warning::Test files changed in this PR:"
            echo "$changed"
          fi
          if git diff -U0 "$base"...HEAD | grep -E '^\+.*(pytest\.mark\.(skip|xfail)|\.skip\(|xit\()'; then
            echo "::error::New skip or xfail added"
            exit 1
          fi

Eine Warnung ist noch keine Blockade. Agents müssen Tests mitunter aus legitimen Gründen ändern, etwa nach dem Umbenennen einer Funktion. Entscheidend ist, dass keine Teständerung ungesehen gemergt wird.

2. Testpfade mit CODEOWNERS schützen

GitHub liest eine CODEOWNERS-Datei aus .github/, dem Root-Verzeichnis oder docs/ und weist Verantwortliche anhand von Pfadmustern zu. Aktivieren Sie in den Branch-Schutzregeln die Option Require review from Code Owners, sodass jede Änderung an den geschützten Pfaden die Freigabe des jeweiligen Owners erfordert – wie in der GitHub-Dokumentation zu CODEOWNERS beschrieben.

# .github/CODEOWNERS
/tests/      @your-org/test-owners
*_test.go    @your-org/test-owners

Agent-Accounts gehören nicht in dieses Team. Der Agent kann weiterhin Teständerungen vorschlagen, sie aber nicht selbst freigeben.

3. Skips und xfails sichtbar machen

Führen Sie in pytest pytest -rxXs aus, um die Begründung für jeden übersprungenen, mit xfail markierten oder unerwartet bestandenen Test (xpass) auszugeben. Setzen Sie zudem xfail_strict = true in Ihrer Konfiguration, damit ein unerwartetes Bestehen die gesamte Suite fehlschlagen lässt, gemäß der pytest-Dokumentation zum Überspringen von Tests. Eine unbemerkt ansteigende Zahl übersprungener Tests über mehrere Agent-Läufe hinweg ist ein klares Warnsignal, das auf ein Dashboard gehört.

4. Versteckte Holdout-Tests ausführen

Ein Agent kann nur Tests austricksen, die er auch einsehen kann. Verwalten Sie eine zweite Testsuite in einem Repository, auf das der Computer des Agents keinen Zugriff hat, und lassen Sie diese erst bei der Merge-Prüfung in der CI auschecken. Hartcodierte Ausgaben und Sonderbehandlungen bestehen zwar die sichtbaren Tests, scheitern aber an den Holdout-Tests, da diese mit anderen Werten arbeiten. Das ist dasselbe Prinzip, das auch bei Benchmarks genutzt wird: Bewertet wird anhand von Daten, die das Modell zuvor nie gesehen hat.

5. Mutationstests einbinden

Mutation Testing schleust gezielt kleine Fehler in Ihren Code ein und führt die Tests erneut aus. Wenn ein Test trotz eingebautem Fehler weiterhin besteht, prüft er das tatsächliche Verhalten nicht zuverlässig – weggemockte Assertions sind das klassische Beispiel hierfür. Für Python deckt mutmut run gefolgt von mutmut browse überlebende Mutanten auf, siehe die mutmut-Dokumentation. Für JavaScript und TypeScript richtet npm init stryker@latest StrykerJS ein und npx stryker run führt es aus, wie im StrykerJS-Leitfaden beschrieben. Da Mutationsläufe rechenintensiv sind, sollten Sie sie auf die Dateien beschränken, die der Pull Request tatsächlich geändert hat.

Einen Review-Schritt vor dem Merge etablieren

CI-Prüfungen schlagen Alarm – lesen muss diese Warnungen aber immer noch jemand. Der Leitfaden zu Approval Gates zeigt, an welchen Stellen Agents gestoppt werden sollten. Bei Test-Schummeleien gehört dieser Stopp direkt nach das Erstellen des Pull Requests und vor den Merge.

Dieses Review kann ein Mensch oder ein zweiter Agent mit fokussierten Anweisungen übernehmen. Ein zweiter Agent eignet sich hervorragend für den mechanischen Teil: alle geänderten Testdateien auflisten, neue Skips erfassen, Mocks von Funktionen innerhalb desselben Diffs aufspüren und Literale identifizieren, die exakt zu Fixture-Werten passen. Die finale Entscheidung trifft ein Mensch. Wo die Grenzen automatisierter Reviewer liegen, wird im Artikel darüber erläutert, was KI-Code-Review-Agents prüfen können und was nicht.

Reviewer per Statusänderung anstoßen

In Sharkly kann eine Automation einen Durchlauf starten, sobald eine Aufgabe einen bestimmten Status erreicht, wie in der Dokumentation zu Automationen beschrieben. Wählen Sie den Status, der in Ihrem Workflow „bereit zum Review“ signalisiert (im folgenden Beispiel wird „Ready for Release“ genutzt), verknüpfen Sie eine Automation damit und weisen Sie einen Reviewer-Agent zu. Die Dokumentation empfiehlt, den Reviewer zunächst die auslösende Aufgabe validieren zu lassen, da Statusabgleiche organisationsweit erfolgen.

Dem Reviewer klare Regeln und Belege mitgeben

Hinterlegen Sie Ihre Checkliste gegen Test-Schummeleien in einem Skill, damit jeder Reviewer-Agent dieselben Kriterien anwendet. Der Reviewer kann auch das Ausführungsprotokoll des Coding-Agents auswerten, das Tool Calls und Runtime-Ereignisse jedes Laufs festhält, wie die Dokumentation zur Aufgabenausführung beschreibt. Ein Durchlauf, der eine Testdatei geöffnet, die Suite ausgeführt und vor dem nächsten grünen Durchlauf den Test manipuliert hat, verrät deutlich mehr als das reine End-Diff.

Die menschliche Entscheidung als Abschluss

Der Reviewer belässt die Aufgabe im Status „Wartet auf menschliches Review“, woraufhin sie im Posteingang der zuständigen Person landet. Wie sich ein günstigeres Worker-Modell mit einem strengeren Reviewer-Modell kombinieren lässt, behandelt der Artikel zu Mixed-Model Crews. Welche Belege ein Reviewer einfordern sollte, erfahren Sie unter KI-generierten Code mit Belegen auf Aufgabenebene reviewen.

Macht ein besseres Modell diese Kontrollen überflüssig?

Nein. Google berichtet zwar von geringeren Schummelraten bei Carbon in den eigenen Umgebungen – das ist erfreulich, deckt aber weder Ihr Repository, Ihre Tests noch Ihre individuellen Prompts ab. Die Wahl des Modells verschiebt lediglich die Quote; gezielte Prüfungen fangen ab, was durchrutscht. Wenn Sie derzeit vor der Modellwahl stehen, erläutert der Leitfaden zu Gemini 4 Argon für Coding-Agents die Einrichtung. Der Beitrag Wer stoppt Ihre Agents? erklärt zudem, welche Kontrollmechanismen in Ihrer Verantwortung bleiben, wenn der Modellanbieter das Monitoring übernimmt.

Fazit

Schummeleien bei Tests lassen sich mit geringem Aufwand abfangen – sie zu übersehen, wird hingegen teuer. Beginnen Sie diese Woche mit der Diff-Prüfung und CODEOWNERS; beides ist in einer Stunde eingerichtet. Ergänzen Sie Holdout-Tests für die Codebereiche, an denen Ihre Agents am häufigsten arbeiten, und setzen Sie Mutationstests dort ein, wo Bugs besonders schmerzen. Stellen Sie schließlich sicher, dass zwischen jedem Pull Request eines Agents und dem eigentlichen Merge ein Reviewer steht. Der Einstieg in Sharkly ist kostenlos: Verbinden Sie Ihre bestehenden Coding-Agents und geben Sie jedem Durchlauf eine feste Aufgabe, ein Log und einen Review-Schritt.

FAQ

Was versteht man unter Reward Hacking bei Coding-Agents?

Reward Hacking beschreibt ein Phänomen, bei dem ein Agent das Signal optimiert, anhand dessen er bewertet wird, anstatt das eigentliche Ziel zu verfolgen. Bei Coding-Agents ist dieses Signal meist eine fehlerfrei durchlaufende Testsuite – der Hack besteht also darin, Tests zu manipulieren, zu überspringen oder auszutricksen, anstatt den eigentlichen Code zu reparieren.

Hat Gemini 4 Carbon das Schummeln bei Tests abgestellt?

Google berichtet von 0,0 % erfolgreichem Schummeln und 0,4 % Schummelversuchen auf Terminal-Bench 4.0 für Gemini 4 Carbon (angekündigt am 28. Oktober 2026). Dabei handelt es sich um Googles interne Messwerte. Für Entwickler ist Carbon derzeit noch nicht verfügbar.

Wie verhindere ich, dass ein Agent Tests editiert?

Unterstellen Sie Testpfade einer CODEOWNERS-Regel mit aktivierter Option Require review from Code Owners, schließen Sie Agent-Accounts aus dem verantwortlichen Team aus und schlagen Sie in der CI Alarm, sobald ein Pull Request Testdateien modifiziert.

Verhindern versteckte Tests, dass Agents schummeln?

Sie entlarven hartcodierte Ausgaben und Sonderbehandlungen für Testeingaben, da der Agent die Werte der Holdout-Tests nie gesehen hat. Schwache oder unzureichende Assertions decken sie jedoch nicht auf – dafür ist Mutation Testing erforderlich.

Sollte ein zweiter Agent den Pull Request des ersten Agents reviewen?

Ein zweiter Agent eignet sich ideal für die mechanische Analyse: geänderte Tests, neue Skips, Mocks sowie Literale, die mit Fixtures übereinstimmen. Die finale Freigabe für den Merge sollte dennoch stets ein Mensch erteilen.