PandaProbe im Alltag: Was ein Verifier für KI-Code leisten muss
PandaProbe ist nur dann hilfreich, wenn ein Team daraus keinen weiteren Agenten baut, sondern einen überprüfbaren Weg von Auftrag über Diff bis zur Freigabe.
Der Pull Request sieht sauber aus: Tests grün, Diff nachvollziehbar, der KI-Agent hat sogar Kommentare hinterlassen. Beim Rollout fällt auf, dass ein Sonderfall aus einem Nachbarsystem nicht mehr funktioniert. Niemand hat gelogen; die Änderung wurde nur gegen das geprüft, was im Repository sichtbar war. Genau dort liegt das Versprechen von PandaProbe und ähnlichen Verifier-Ansätzen: nicht noch schneller Code erzeugen, sondern die Lücke zwischen Auftrag und tatsächlich geprüfter Wirkung verkleinern.
Das Problem ist nicht die Zahl der Diffs
KI-Agenten machen Änderungen billig. Das verschiebt den Engpass zur Prüfung: Welche Annahme hat sich geändert? Welcher Vertrag zwischen Services wird berührt? Welche Tests beweisen das Gegenteil einer Regression? Ein großes Diff ist nicht automatisch riskant, ein kleines kann es sehr wohl sein.
PandaProbe ist deshalb nicht als magischer Qualitätsstempel interessant, sondern als Anlass, diese Fragen vor dem Merge zu strukturieren. Ohne klare Akzeptanzkriterien kann auch ein Verifier nur gut klingende Kommentare erzeugen.
Ein brauchbarer Pilot hat einen engen Auftrag
Nimm keine komplette Produktfunktion. Wähle eine wiederkehrende Änderung, etwa eine Validierungsregel für einen API-Endpunkt. Vor dem Start schreibt das Team auf: erwartetes Verhalten, drei Gegenbeispiele, betroffene Schnittstellen, vorhandene Tests und ein Rückfallplan.
Der Agent darf implementieren. Ein separater Prüfschritt vergleicht Diff, Tests und diese kurze Spezifikation. Scheitert ein Gegenbeispiel oder bleibt eine Annahme offen, wird nicht gemergt. Erst dann hat ein Verifier einen klaren Job.
Rollen statt Agenten-Theater
Ein sinnvoller Ablauf trennt vier Rollen: Auftrag klären, Änderung umsetzen, Verhalten prüfen, Freigabe verantworten. Cursor, GitHub Copilot, Aider oder Claude können in einzelnen Schritten helfen. Kein Modell sollte jedoch gleichzeitig die Anforderung erfinden, den Code schreiben und die eigene Lösung für korrekt erklären.
Besonders nützlich ist die Trennung bei paralleler Arbeit. Git-Worktrees geben jeder Agenten-Session einen eigenen Arbeitsbereich; Tests laufen gegen einen klaren Stand, und Experimente landen nicht im Hauptverzeichnis. Das ist keine exotische Infrastruktur, sondern eine einfache Form von Schadensbegrenzung.
Wo PandaProbe an Grenzen stößt
Ein Verifier kann nur gegen etwas prüfen, das beschrieben oder beobachtbar ist. Veraltete Spezifikationen erzeugen falsche Sicherheit. KI-generierte Tests können dieselben blinden Flecken wie der Code enthalten. Und Architekturregeln, Berechtigungen oder Performance-Ziele brauchen oft unabhängige Checks in CI, SAST oder menschlichem Review.
Darum sollte ein Team nicht fragen, ob PandaProbe „den Review ersetzt“. Die bessere Frage lautet: Welche Fehlerklasse wird heute zu spät entdeckt, und welchen belastbaren Nachweis brauchen wir davor?
Fazit: Erst den Prüfweg bauen, dann skalieren
PandaProbe kann für Teams interessant sein, die KI-Code nicht nur schneller erzeugen, sondern nachvollziehbarer einführen wollen. Der Wert entsteht nicht durch einen weiteren Agenten im Diagramm. Er entsteht aus kurzen Spezifikationen, reproduzierbaren Tests, isolierten Arbeitsbereichen und einer klaren Freigabe.
Wer nur Geschwindigkeit sucht, erhält mehr Diffs. Wer diesen Prüfweg etabliert, erhält bessere Entscheidungen darüber, welche Diffs überhaupt gemergt werden dürfen.