Der Skill Bench: systematic-debugging vs. Baseline

Teil 3 des Skill Bench stellt eine engere Frage als die ersten beiden: nicht „hilft ein Skill?“, sondern „übertrifft ein für eine bestimmte Aufgabe entwickelter Skill ein ununterstütztes Modell, das genau diese Aufgabe ausführt?“. Debugging ist der klarste Test, den wir dafür haben, da wir die Fehler selbst platzieren, genau wissen, was falsch ist, und den Bericht Zeile für Zeile mit der Grundwahrheit abgleichen können.

Wir haben also ein Canvas-Snake-Spiel geschrieben, es absichtlich auf drei spezifische Arten fehlerhaft gemacht und dasselbe fehlerhafte Spiel und dieselbe Beschwerde durch zwei identische Claude Sonnet-Sitzungen laufen lassen. Eine hatte den Skill systematic-debugging installiert. Eine nicht. Derselbe Prompt, dasselbe Modell, derselbe Fehler. Nur der Skill unterscheidet sich.

Das Ergebnis war nicht der klare Sieg, den wir erwartet hatten, und das ist der Teil, der lesenswert ist.

Die Falle, die wir gebaut haben

Wir begannen mit einer funktionierenden Snake-Implementierung und platzierten dann absichtlich drei Fehler:

1. Invertierte Richtungsvektoren. ArrowUp und ArrowDown waren mit den Vektoren verbunden, die man in normalen kartesischen Koordinaten verwenden würde, nicht mit Canvas-Koordinaten, wo y nach unten zunimmt. Drückt man nach oben, bewegt sich die Schlange nach unten.
2. Nahrungserzeugung im Pixelraum statt im Gitterraum. spawnFood verwendete cv.width (400 Pixel) als Grenze für eine Koordinate, die ein Gitterindex in einem 20-Zellen-Gitter (GRID) sein sollte. Multipliziert man einen Gitterschritt mit einem 400 Pixel breiten Bereich, erhält man Nahrungskoordinaten, die in etwa 95 % der Fälle außerhalb des sichtbaren Spielfelds landen.
3. Punktezähler erhöht sich bei jedem Tick. score++ befand sich in der Hauptspielschleife anstatt innerhalb des „Schlange hat Nahrung gefressen“-Zweigs, sodass der Punktestand bei jedem Frame anstieg, unabhängig davon, was die Schlange tatsächlich tat.

Wir haben keiner der Claude-Sitzungen mitgeteilt, was falsch war. Wir gaben beiden Armen denselben spielerähnlichen Fehlerbericht, formuliert, wie es ein tatsächlich verärgerter Tester tun würde: „Steuerung fühlt sich falsch an, Nahrung erscheint nie, Punktestand steigt von selbst.“ Dann baten wir jede Sitzung, alles zu finden und zu beheben, was dies verursachte.

Drei Fehler, eine ehrliche Beschwerde, zwei Claudes. Hier ist, was zurückkam.

Was jeder Arm berichtete

Baseline (ohne Skill)

Die Baseline-Sitzung arbeitete den Code ohne eine vorgegebene Methode durch und las der Reihe nach den Eingabe-Handler, den Nahrungserzeuger und die Spielschleife. Sie stieß auf alle drei platzierten Fehler:

• Richtungsvektoren waren für die y-Achse relativ zur Behandlung von „unten“ durch das Canvas-Rendering vertauscht.
• spawnFood multiplizierte cv.width, wo es die Gitterkonstante hätte verwenden sollen, was Pixel-Skalen-Koordinaten in einem zellenindizierten Spiel erzeugte.
• Die Punktezählererhöhung befand sich außerhalb der Kollisionsprüfung mit Nahrung, sodass sie bei jedem Frame bedingungslos ausgelöst wurde.

Dann las es weiter und fand ein viertes Problem, das niemand platziert hatte: Die Selbstkollisionsprüfung verglich den Kopf der Schlange mit der Schwanzzelle, bevor der Schwanz für diesen Frame entfernt worden war. Wenn sich die Schlange in das Feld bewegt, das ihr eigener Schwanz gerade verlässt, sieht die Prüfung dieses Feld immer noch als besetzt an und bezeichnet es als Kollision. Das ist ein echter, bekannter Snake-Grenzfall. Er existierte in unserem Code, weil wir die Kollisionslogik geschrieben hatten, bevor wir etwas platzierten, und die Baseline las zufällig weit genug, um darauf zu stoßen.

Skill-Arm (mit systematic-debugging installiert)

Der Skill-Arm las zuerst die SKILL.md von obra/superpowers für systematic-debugging (einen Skill, den wir separat mit 9,6/10 für hypothesengestützte Ursachenanalyse bewertet haben) und wandte dann seine Methode an: Für jedes Symptom eine Hypothese bilden, diese gegen den Code testen, bestätigen, bevor etwas geändert wird.

Es fand dieselben drei platzierten Fehler, mit präziserer und genauerer Ursachenbeschreibung:

• „Richtungs-Inversion auf Canvas-y-abwärts-Konvention zurückgeführt: ArrowUp bildet auf {x:0,y:-1} ab, unter Annahme von kartesischem y-aufwärts, aber das Canvas rendert y zunehmend nach unten, sodass oben und unten vertauscht sind.“
• „Nahrungserzeugung verwendet Pixelraum-Grenze (cv.width = 400), wo die Berechnung Gitterraum-Grenze (GRID = 20) verwenden sollte. Bestätigt durch Einheiten-Fehlübereinstimmung: Multiplikation eines zufälligen Gitter-Skalen-Bruchteils mit einer Pixel-Skalen-Grenze platziert ~95 % der Spawns außerhalb von canvas.width.“
• „Punktestand erhöht sich bedingungslos in der Tick-Schleife, anstatt durch den „Nahrung gefressen“-Zweig gesteuert zu werden. Bestätigt durch Verfolgung des Schleifenkörpers: score++ wird vor der Kollisionsprüfung in jedem Frame ausgeführt.“

Es fand den vierten Fehler nicht. Das Problem der Selbstkollision trat nie auf, da die gemeldeten Symptome (falsche Steuerung, fehlende Nahrung, außer Kontrolle geratener Punktestand) nicht auf Kollisionslogik hindeuteten, und die hypothesengestützte Methode des Skills bleibt an die gegebenen Symptome gebunden. Es schloss den Bericht zuversichtlich ab, dass alle Probleme gelöst waren, und nach dem Wortlaut der Beschwerde waren sie es auch.

Die Wendung mit dem vierten Fehler

Dies ist die Wendung, die wir manuell überprüft haben, indem wir beide Diffs mit dem tatsächlichen Code verglichen haben: Der Skill-Arm war präziser bei den Fehlern, die er finden sollte, und der Baseline-Arm fand einen weiteren echten Fehler, nach dem niemand gefragt hatte.

Das ist keine Kritik an systematic-debugging als Skill. Hypothesengestütztes Debugging ist genau dafür konzipiert, was es hier getan hat: ein gemeldetes Symptom aufnehmen, auf eine testbare Ursache eingrenzen, vor der Behebung bestätigen und aufhören, sobald das Symptom erklärt ist. Diese Disziplin ist genau der Punkt, wenn man auf einen Produktionsvorfall mit einem Stack-Trace und einer tickenden Uhr blickt. Es ist auch, konstruktionsbedingt, symptombezogen. Es schweift nicht in Code ab, der nicht durch die Beschwerde impliziert ist.

Die Baseline-Sitzung hatte keinen solchen Umfang. Sie las mehr von der Datei, als unbedingt nötig war, und das Lesen von mehr Dateien ist, wie man auf einen Fehler stößt, den niemand erwähnt hat. Freie Erkundung ist von Natur aus ineffizient, und hier hat sich die Ineffizienz ausgezahlt.

Die ehrliche Lesart: Keiner der Arme ist im Allgemeinen „besser“. Ein Arm ist präzise und aufmerksamkeitsökonomisch, verankert an dem, was ihm gesagt wurde. Der andere ist unfokussiert und, dieses eine Mal, gründlich genug, um etwas zu finden, das im Ticket nicht erwähnt wurde. Wenn Ihr Fehlerbericht vollständig ist, ist der Bericht des Skill-Arms derjenige, den Sie lesen möchten. Wenn Ihrem Fehlerbericht möglicherweise etwas fehlt, möchten Sie die zweite Augenpaarung, die Ihnen die Baseline kostenlos gegeben hat.

Die Zahlen

	Baseline (ohne Skill)	Skill-Arm (systematic-debugging)
Gefundene Fehler (von 3 platzierten)	3 / 3	3 / 3
Unplatzierter echter Fehler gefunden	Ja (Schwanz-Freigabe-Kollision)	Nein
Präzision der Ursachenanalyse	Korrekt, weniger formalisiert	Korrekt, benannter Mechanismus pro Fehler
Berichtsstruktur	Ad hoc	Hypothese → Test → Bestätigung, pro Fehler
Verwendete Tokens	50,338	58,357
Token-Delta	—	+16%

Der Skill verursachte 16 % mehr Tokens für einen Bericht, der sich besser liest und den Mechanismus präziser festlegt, aber er übertraf keine Baseline, der einfach erlaubt wurde, weiterzulesen. Das ist das Ergebnis, das wir nicht erwartet hatten, und es ist der Grund, warum wir den rohen Vergleich veröffentlichen, anstatt ein Urteil, das den Skill schmeichelt.

Wann Sie systematic-debugging wünschen

Der Snake-Bench unterschätzt den wahren Wert des Skills, denn ein Spiel mit platzierten Fehlern und einer vollständigen Quelldatei im Blick ist nahezu der Idealfall für ein ununterstütztes Modell: Alles Relevante passt in einen Lesevorgang. Produktions-Debugging sieht selten so aus.

Wo hypothesengestützte Ursachenanalyse ihren Wert beweist, ist der Fehler, der immer wieder auftritt. In unseren eigenen Katalognotizen zu systematic-debugging war ein Testfall eine Race Condition, die Claude bereits dreimal separat in derselben Codebasis „behoben“ hatte, jedes Mal durch das Patchen einer plausibel aussehenden Vermutung anstelle der tatsächlichen Ursache. Die Disziplin des Skills (Hypothese aufstellen, einen Test entwerfen, der sie falsifizieren würde, den Code nicht anfassen, bis der Test sie bestätigt) war es, die schließlich die echte Interaktion festnagelte, anstatt eine vierte Vermutung zu produzieren. Das ist die Art von Fehler, für die systematic-debugging gedacht ist: wiederkehrend, schwer fassbar, bereits dreimal geraten, in einer Codebasis, die zu groß ist, um sie spontan von Anfang bis Ende zu lesen.

Es ist auch das richtige Werkzeug in dem Moment, in dem Sie einen Produktionsvorfall triagieren. Sie haben ein Symptom, eine tickende Uhr und keine Lust, dass ein Modell abschweift, um irrelevante Module zu lesen. Beschränken Sie sich auf den Bericht, bestätigen Sie die Ursache, liefern Sie den Fix. Das ist in genau dieser Umgebung ein Feature, keine Einschränkung.

Wenn ein freier Durchlauf gewinnt

Unser Snake-Ergebnis spricht auch für den entgegengesetzten Fall: Wenn Sie vermuten, dass der Fehlerbericht unvollständig ist, oder wenn Sie einen Pre-Release-Durchlauf durchführen, anstatt einem gemeldeten Symptom nachzujagen, tut ein uneingeschränktes Lesen des Codes etwas, was eine hypothesengestützte Methode strukturell nicht tun wird. Es betrachtet Code, über den sich noch niemand beschwert hat.

Das ist dieselbe Form wie eine manuelle Code-Überprüfung versus eine gezielte Incident-Response. Beides hat seinen Platz. Der Fehler besteht darin, anzunehmen, dass ein Debugging-Skill eine Überprüfung ersetzt, anstatt sie zu ergänzen. Wenn Sie die allgemeine Perspektive eines Überprüfungsdurchlaufs wünschen, lesen Sie unsere Ansicht, warum Skills nicht immer wie erwartet ausgelöst werden und wie wir diese Tests strukturieren.

Reproduzieren Sie es selbst

Der Bench ist klein genug, um ihn in zwanzig Minuten nachzubauen, wenn Sie unsere Zahlen überprüfen möchten, anstatt sie einfach zu glauben. Schreiben Sie ein Canvas-Snake-Spiel (Gitterbewegung, ein Nahrungserzeuger, ein Punktezähler, eine Spielschleife) und platzieren Sie diese drei Fehler:

1. Verbinden Sie ArrowUp/ArrowDown mit kartesischen Vektoren (y: 1 für oben, y: -1 für unten) anstatt mit Canvas-Vektoren, bei denen ein zunehmendes y den Bildschirm nach unten bewegt.
2. Multiplizieren Sie in Ihrer food-spawn-Funktion Ihren zufälligen Bruch mit der Pixelbreite des Canvas anstatt mit Ihrer Gitterzellenzahl, sodass die resultierende Koordinate ein Pixelwert ist, der als Gitterindex behandelt wird.
3. Verschieben Sie die Punktezählererhöhung aus dem Zweig „ist der Kopf gerade auf Nahrung gelandet“ in den bedingungslosen Körper der Spielschleife.

Geben Sie einer Claude-Sitzung nur die Spielerbeschwerde („Steuerung fühlt sich falsch an, Nahrung erscheint nie, Punktestand steigt von selbst“), niemals die Fehlerliste, und sehen Sie, was zurückkommt. Lesen Sie dann Ihre eigene Kollisionslogik für den Fall der Schwanz-Freigabe: Überprüfen Sie die nächste Position des Kopfes mit der aktuellen Zelle des Schwanzes, bevor der Schwanz sich bewegt, und sehen Sie, ob es dort auch ist. Bei uns war es so, ohne dass wir es platziert hatten.

FAQ

Macht der Skill systematic-debugging Claude schlechter darin, Fehler zu finden?

Nein. Er fand jeden platzierten Fehler mit präziseren Ursachen als die Baseline. Was er nicht tat, war, den Umfang der gemeldeten Symptome zu überschreiten, was die Baseline auf einen vierten, unplatzierten Fehler stoßen ließ. Umfangsdisziplin ist die Designabsicht des Skills, kein Defekt.

Warum fand die Baseline einen Fehler, den der Skill übersehen hat?

Die Baseline hatte keine Hypothese, an die sie sich halten konnte, daher las sie mehr von der Codebasis, als die gemeldeten Symptome unbedingt erforderten. Mehr Code zu lesen ist, wie man Dinge findet, nach denen niemand gefragt hat. Es ist eine ineffiziente Strategie, die sich einmal ausgezahlt hat, kein allgemeiner Vorteil.

Ist eine 16%ige Token-Erhöhung für einen Debugging-Skill es wert?

Hängt vom Fehler ab. Bei einem wiederkehrenden, schwer zu lokalisierenden Problem ist die Disziplin weit mehr wert als 16 % an Tokens, denn die Alternative ist, dass Claude wiederholt dieselbe Ursache errät, wie es in unserem eigenen Katalogtest der Fall war, bevor wir diesen Skill angewendet haben. Bei einem Fehler, der bereits gut abgegrenzt und oberflächlich ist, bringt Ihnen der Overhead einen saubereren Bericht und nicht viel mehr.

Sollte ich systematic-debugging für jede Fehlerbehebung verwenden?

Nicht für jede. Greifen Sie darauf zurück, wenn ein Fehler wiederkehrend ist, wenn ein früherer Fix-Versuch nicht erfolgreich war oder wenn Sie einen Live-Vorfall triagieren und sich auf das gemeldete Symptom beschränken müssen. Für einen ersten Durchlauf bei einem neuen Fehlerbericht oder wenn Sie einen breiteren Sweep wünschen, der angrenzende Probleme erfassen könnte, kann eine einfache Debugging-Sitzung oder ein dedizierter Review-Durchlauf Bereiche abdecken, die der Skill nicht abdeckt. Sehen Sie sich unsere besten Coding-Skills an, um zu erfahren, wie wir Debugging- und Review-Skills gegeneinander bewerten.

---

Der Skill Bench, Teil 3 von 4. Lesen Sie die anderen kontrollierten Vergleiche: Teil 1, der Landing Page Build, Teil 2, der Telegram Bot und Teil 4, Auditing Google zx.