Der Skill-Benchmark, Teil 2: Claude TDD-Skill vs. kein Skill

Teil 1 dieser Reihe stellte einen Skill einem leeren Prompt bei einer Gerüstbauaufgabe gegenüber und erzielte einen deutlichen Sieg. Teil 2 tut dies nicht. Wir haben denselben Telegram-Bot zweimal mit Claude Sonnet erstellt, wobei ein Durchlauf den am höchsten bewerteten Test-Driven-Development-Skill in unserem Katalog erhielt, und der Skill hat Tokens hinzugefügt, ohne einen relevanten Test hinzuzufügen. Wir veröffentlichen dieses Ergebnis unverändert, denn ein Benchmark, den man nur bei einem Sieg des Skills veröffentlicht, ist kein Benchmark.

Einrichtung und Methodik

Dies ist N=1. Eine Aufgabe, ein Modell, ein Skill, einmal pro Testarm ausgeführt. Das sind nicht genug Daten, um einen prozentualen Qualitätsunterschied zu behaupten, und wir werden auch nicht so tun, als wäre es anders. Wofür es ausreicht, ist zu zeigen, was in einer einzelnen Sitzung Zeile für Zeile tatsächlich passiert – etwas, das die meisten Skill-Marketingkampagnen Ihnen überhaupt nicht zeigen.

Die Aufgabe: Erstellen Sie einen Telegram-Todo-Bot auf aiogram v3 mit vier Befehlen, /add, /list, /done, /delete, unterstützt durch einen pro Benutzer zugewiesenen In-Memory-Speicher. Die Vorgabe forderte eine klare Trennung: storage.py mit reiner Logik ohne Telegram-Imports, bot.py, das diese Logik mit aiogram-Handlern verbindet, und test_storage.py, das die Speicherschicht abdeckt. Führen Sie pytest aus, bis es grün ist, und stoppen Sie dann.

Beide Testarme erhielten den identischen Prompt, das identische Modell (Claude Sonnet) und das identische Repository-Gerüst als Ausgangspunkt. Die einzige Variable: Der Skill-Arm hatte obra/superpowers' test-driven-development SKILL.md installiert, denselben Skill, der in unserem Katalog 9.6 von 10 Punkten erreichte, weil er einen strikten Rot-Grün-Refactor-Zyklus durchsetzt und sich weigert, eine Sitzung als abgeschlossen zu markieren, solange ein Test fehlschlägt. Der Baseline-Arm hatte außer dem Standardverhalten von Claude Code nichts installiert. Die vollständige Methode, wie wir diese Läufe skripten und protokollieren, finden Sie unter how we test Claude skills, und die umfassendere Bewertungsrubrik ist auf unserer methodology page verfügbar.

Was beide Testarme geliefert haben

Beide Testarme wurden abgeschlossen. Beide erreichten einen vollständig grünen pytest-Lauf. Beide produzierten die im Brief geforderte Drei-Datei-Aufteilung, wobei die Speicherlogik vom aiogram-Handler-Code isoliert war. Oberflächlich betrachtet sieht dies nach einem Unentschieden aus, und wenn Sie bei „beide wurden grün“ aufgehört hätten zu lesen, würden Sie schlussfolgern, dass der Skill keinen Unterschied gemacht hat, und weitergehen.

Keine der bot.py-Dateien tat etwas Überraschendes. Jede verband die vier Befehle mit den Router- und Message-Handlern von aiogram, parste den Todo-Text oder Index aus den Befehlsargumenten und rief direkt die Speicherschicht für die eigentliche Arbeit auf. Das ist genau das, was die Vorgabe verlangte: die Bot-Datei schlank halten, die Logik testbar halten. Bei der aiogram-Verdrahtung konvergierten die beiden Sitzungen fast vollständig, was an sich ein nützlicher Datenpunkt ist. Wo sie divergierten, war ausschließlich auf der Speicherseite, nämlich darin, was jede als testenswert erachtete.

Der Unterschied zeigt sich darin, was jeder Testarm als testenswert erachtete und welche Kosten dafür anfielen.

Die Zahlen

| | Baseline (kein Skill) | Skill (test-driven-development) | Delta | |---| ---| ---| ---| | Gesamtzahl Tokens | 48,536 | 52,480 | +8% | | Geschriebene Tests | 23 | 13 | -10 | | Tests für Fehlerpfade | 9 | 5 | -4 | | Finaler pytest-Status | Grün | Grün | Unentschieden |

Der Skill-Arm verbrauchte mehr Tokens, um eine kleinere Testsuite mit geringerer Fehlerabdeckung zu erstellen. Das ist das gesamte Ergebnis. Kein versteckter Sternchenhinweis, kein „aber wenn man die Codequalität statt der Testanzahl betrachtet“. Die Baseline-Sitzung, die ganz ohne Prozessgerüst lief, schrieb fast doppelt so viele Fehlerpfad-Fälle.

Lesen der Testsuiten: 23 vs. 13

Die reine Testanzahl ist ein schwaches Signal, daher haben wir beide Suiten Zeile für Zeile gelesen, anstatt der Kopfzeilennummer zu vertrauen.

Die 23 Tests der Baseline deckten die vier Befehle auf der Happy-Path-Ebene ab und gingen dann weiter zu Edge-Cases, die niemand namentlich angefordert hatte: Was passiert, wenn man einen Index außerhalb des Bereichs als erledigt markiert, was ein Null- oder negativer Index bewirkt, ob die Aufgabenliste eines Benutzers in die eines anderen Benutzers übergeht und ob das Löschen von Element 2 die Indizes der Elemente 3 und 4 korrekt verschiebt, sodass /done 3 danach immer noch auf die richtige Aufgabe zeigt. Letzteres ist die Art von Fehler, die eine Demo überlebt und dann vor einem echten Benutzer bricht, wenn dieser zum ersten Mal etwas aus der Mitte einer Liste löscht. Neun der 23 Tests dienten ausschließlich dazu, diese Fehlerpfade zu untersuchen.

Die 13 Tests des Skill-Arms deckten dieselben vier Befehle auf der Happy-Path-Ebene ab, plus fünf Fehlerpfad-Fälle: hauptsächlich Indizes außerhalb des Bereichs und ein Szenario mit doppelter Hinzufügung. Was im Vergleich zur Baseline fehlt: kein expliziter Test zur Isolation pro Benutzer und kein Test, der das Indexverhalten nach einer Löschung, die die Liste verschiebt, bestätigt. Die Speicherlogik in der storage.py des Skill-Arms mag diese Fälle durchaus korrekt behandeln. Ungetestetes korrektes Verhalten und getestetes korrektes Verhalten sind jedoch nicht dasselbe, und der ganze Sinn einer Testsuite besteht darin, diese Lücke zu schließen.

Keine der Suiten ist schlecht. Dreizehn Tests mit fünf Fehlerfällen bei einem Vier-Befehls-Bot sind nach jedem normalen technischen Standard ein vertretbarer Ausgangspunkt. Der Vergleich wirkt nur dann vernichtend, wenn man ihn neben einer Baseline betrachtet, die, ausgehend von einem identischen Prompt ohne jegliches Rot-Grün-Gerüst, mehr Tests schrieb, nicht weniger.

Warum dies TDD nicht widerlegt

Hier ist etwas, das ein einmaliger Benchmark strukturell nicht erfassen kann: Das Argument von TDD war nie „Sie werden beim ersten Versuch mehr Tests schreiben“. Es geht darum, was über Wochen der Iteration passiert, bei der zehnten Funktion, die einer Codebasis hinzugefügt wird, die das Modell nicht von Grund auf neu geschrieben hat, an dem Punkt, an dem ein müder Ingenieur (oder ein Agent unter Zeitdruck) versucht ist, mit einem roten Test zu liefern und ihn „später“ zu beheben.

Das ist eine Disziplinbehauptung, keine einmalige Ausgabebehauptung, und dieser Benchmark lief genau einmal. Wir können Disziplin nicht in einer einzelnen Sitzung messen, weil Disziplin Sie davon abhält, in Sitzung sechs eine Abkürzung zu nehmen, und es hier keine Sitzung sechs gibt.

Wir haben einen Nachweis, wie diese Disziplin in der Praxis aussieht, aus unseren eigenen Testnotizen auf der test-driven-development skill page: Über eine Drei-Feature-Sitzung hinweg weigerte sich der Skill, den Rot-Grün-Zyklus zu überspringen, selbst wenn die Lösung offensichtlich schien und die Versuchung, direkt zu Grün zu springen, direkt vorhanden war. Er schrieb zuerst den fehlschlagenden Test, sah zu, wie er aus dem richtigen Grund fehlschlug, und schrieb dann den minimalen Code, um ihn zu bestehen, jedes Mal, über alle drei Features hinweg. Niemand musste eingreifen und sagen: „Warten Sie, schreiben Sie zuerst den Test.“ Das ist das Verhalten, das ein Disziplin-Skill bieten soll, und es ist nicht dasselbe Verhalten wie „schreibt mehr Tests in einem Versuch an einem kleinen, gut abgegrenzten Modul“.

Bei einer Aufgabe dieser Größe und dieser guten Spezifikation war Claude Sonnets Baseline-Urteil darüber, was zu testen ist, bereits solide. Der Skill fügte einen expliziten Prozess über ein Urteil hinzu, das noch nicht viel Korrektur benötigte, und dieser Prozess kostete 8% mehr Tokens ohne einen entsprechenden Qualitätsgewinn bei diesem speziellen Versuch. Beides kann wahr sein: TDD ist es wert, installiert zu werden, und es hat hier nicht geholfen.

Es gibt auch eine einfachere Erklärung, die es wert ist, genannt zu werden: Einen fehlschlagenden Test zu schreiben, ihn fehlschlagen zu sehen und dann den minimalen Code zu schreiben, um ihn zu bestehen, erfordert mehr Hin und Her, als die Implementierung und einen Test dafür in einem Durchgang zu schreiben. Dieser Overhead ist der Sinn der Disziplin, wenn die Implementierung nicht trivial ist oder das Modell dazu neigt, Schritte zu überspringen. Bei einem Vier-Befehls-Todo-Bot stand die Implementierung nie in Frage, sodass der Overhead einen Prozess kaufte, ohne eine Überprüfung für etwas zu kaufen, das tatsächlich Gefahr lief, schiefzugehen.

Was das bedeutet, wenn Sie Skills kaufen

Der unangenehme Teil für uns, speziell, ist, dass wir getestete Skills verkaufen, und unser eigener Benchmark hat gerade gezeigt, dass ein top-bewerteter Skill einen einmaligen Vergleich gegen überhaupt keinen Skill nicht gewonnen hat. Wir möchten lieber, dass Sie das sehen als eine Zusammenfassung der besten Momente.

Die praktische Erkenntnis ist, den Skill an die Aufgabe anzupassen, nicht an die Punktzahl. Eine Katalogbewertung von 9.6/10 bedeutet, dass der Skill zuverlässig das tut, was er verspricht, und Ihr Setup nicht beeinträchtigt, nicht dass er jeden Benchmark bei jeder Aufgabengröße gewinnt. Wenn Ihre Aufgabe ein kleines, gut spezifiziertes Modul ist, das Sie frisch in einer Sitzung erstellen, kann das Standardurteil eines starken Modells bereits die Fehlerpfade abdecken, die Ihnen wichtig sind, und ein Prozess-Skill ist ein Overhead, für den Sie bezahlen, ohne einen entsprechenden Vorteil in dieser Sitzung zu erhalten. Wenn Ihre Aufgabe eine Codebasis ist, die Sie über Monate hinweg bearbeiten werden, mit mehreren Mitwirkenden und langen Pausen zwischen den Sitzungen, in denen sich Abkürzungen stillschweigend summieren, dann ist das genau das, was ein Disziplin-Skill wie TDD verhindern soll, und ein Einzelsitzungs-Benchmark hätte diesen Wert von vornherein nie erfassen können.

Geschwindigkeits-Skills und Disziplin-Skills beantworten unterschiedliche Fragen. Lesen Sie die Beschreibung eines Skills, welche Frage er beantwortet, bevor Sie ihn für die falsche Aufgabe installieren. Wir behandeln, wie man dieses Signal liest, in unserer Zusammenfassung der besten Coding-Skills.

Reproduzieren Sie es selbst

Die Aufgabe ist klein genug, um sie an einem Nachmittag erneut auszuführen. Klonen Sie ein leeres aiogram v3-Projekt und führen Sie dann den identischen Prompt zweimal aus: einmal in einer sauberen Claude Code-Sitzung, einmal mit installiertem obra/superpowers' test-driven-development-Skill. Fordern Sie /add /list /done /delete mit pro-Benutzer-In-Memory-Speicher, einer storage.py/bot.py-Aufteilung und einer pytest-Suite an, die grün läuft, bevor Sie sie als erledigt betrachten. Protokollieren Sie die Gesamtzahl der Tokens aus der Nutzungsübersicht jeder Sitzung und vergleichen Sie dann die beiden test_storage.py-Dateien manuell: Zählen Sie Assertions und markieren Sie speziell alles, was negative Indizes, fehlende Schlüssel, Isolation pro Benutzer und Indexverschiebungen nach einer Löschung betrifft. Diese vier Kategorien sind die, in denen wir die Lücke sahen, und sie sind diejenigen, die bei jeder CRUD-App im Todo-Stil überprüft werden sollten, unabhängig davon, welchen Skill Sie testen.

FAQ

Bedeutet das, dass der TDD-Skill schlecht ist?

Nein. Es bedeutet, dass ein einmaliger Benchmark an einem kleinen, gut spezifizierten Modul nicht der Test ist, der zeigt, wofür TDD gedacht ist. Der Wert des Skills liegt darin, Abkürzungen über eine lange Sitzung oder ein langes Projekt hinweg zu verhindern, was dieser Benchmark, konstruktionsbedingt, nicht lange genug messen konnte.

Warum schrieb der Skill-Arm weniger Tests, wenn er einen strengeren Prozess durchsetzt?

Der Rot-Grün-Refactor-Zyklus treibt Sie dazu an, einen Test für das Verhalten zu schreiben, das Sie implementieren werden, es dann zu implementieren und dann zum nächsten Verhalten überzugehen. Er fordert Sie nicht automatisch dazu auf, zurückzugehen und Tests für Edge-Cases hinzuzufügen, die niemand explizit angefordert hat, es sei denn, die Sitzung nimmt sich Zeit, diese separat zu brainstormen. Der Baseline-Arm, der nicht durch einen festen Zyklus eingeschränkt war, verbrachte anscheinend mehr seiner Ausgabe genau mit diesem Brainstorming.

Sollte ich einen TDD-Skill für Claude Code installieren?

Wenn Sie an einer Codebasis arbeiten, zu der Sie wiederholt zurückkehren werden, insbesondere mit anderen Mitwirkenden oder langen Pausen zwischen den Sitzungen, ja. Es ist eine Versicherung gegen einen spezifischen Fehlermodus: stillschweigendes Ausliefern mit einem roten Test, weil die Lösung offensichtlich schien. Dieser Fehlermodus zeigt sich nicht in einem Benchmark eines einzelnen Nachmittags, aber er zeigt sich in realen Projekten.

Was kommt als Nächstes in dieser Reihe?

Teil 3 von „Der Skill-Benchmark“ betrachtet einen Debugging-Skill im Vergleich zu einer unveränderten Fehlersuche in einem Snake-Spiel. Teil 4 prüft ein Google zx-Automatisierungsskript. Beide folgen derselben Regel wie dieser: gleiche Aufgabe, gleiches Modell, eine Variable, Zahlen werden so oder so gedruckt.

Die Skill-Benchmark-Reihe

Teil 2 von 4. Lesen Sie Teil 1: Landingpage-Erstellung, Teil 3: Debugging Snake und Teil 4: Audit eines Google zx-Skripts.