Claude Academy
Wird geladen

Gib Claude eine Feedback-Schleife

Lektion 84 Min.

Gib Claude immer eine Möglichkeit, seine eigene Arbeit zu überprüfen – sei es durch Tests, einen Build oder einen Screenshot-Vergleich. Eine Sitzung überprüft ihre eigene Arbeit und behebt ihre eigenen Fehler, bevor ein Engineer sie sieht.

Die Feedback-Schleife sollte nicht mit einem Verifizierer-Subagenten verwechselt werden (Stufe 3: Build). Die Feedback-Schleife durchläuft die gesamte Aufgabe so oft, wie die Arbeit es erfordert. Der Verifizierer-Subagent hingegen ist eine Möglichkeit, die abschließende Prüfung zu verpacken, indem ein frisches Kontextfenster ausgeführt wird, sobald die Sitzung glaubt, dass die Arbeit erledigt ist. Auf diese Weise wird das Urteil nicht durch die Annahmen gefärbt, die den Code erzeugt haben.

Was sich ändert

TraditionellKI-nativ
Das Signal, dass Code funktioniert, kommt spät. CI Minuten später, ein Tester Tage später, Produktion Wochen später. Da ein Agent den Code produziert, bedeutet ein spätes Signal, dass eine Person die gesamte Ausgabe überprüfen muss, und diese Person wird zum Flaschenhals.Der Sitzung wird eine Möglichkeit gegeben, ihre eigene Arbeit zu überprüfen, bevor eine Person sie sieht. Führe die Tests aus, führe den Build aus, mache den Screenshot. Claude iteriert, bis die Prüfung bestanden ist, sodass das, was den Engineer erreicht, sie bereits bestanden hat. Das Einrichten der Schleife fällt dem Engineer zu, der die Sitzung ausführt, und die folgenden Schritte sind für ihn geschrieben.

Erste Schritte

  • Voraussetzungen: Keine.
  • Infrastruktur: Eine Testsuite und ein Build, die jeweils lokal mit einem einzigen Befehl ausgeführt werden. Für die UI-Arbeit ist eine Möglichkeit für Claude, das Ergebnis zu sehen, entscheidend – entweder ein Browser-Tool oder ein über MCP eingebundenes Screenshot-Utility.

So setzt du es um

  1. Wenn die Überprüfung der Arbeit heute eine Abfolge von Befehlen und einiges an Umgebungswissen erfordert, verpacke sie in ein einziges Ziel wie make test oder npm test, das bei einem Fehler mit einem Wert ungleich null beendet wird.
  2. Liste im Abschnitt „Commands" der CLAUDE.md jeden Befehl mit einem Beispiel für eine ordnungsgemäße Ausgabe auf.
  3. Formuliere ein Ziel und mache es quantifizierbar, damit Claude die Arbeit ohne Rückfrage bei dir überprüfen kann, zum Beispiel: „Alle Tests in test_status.py bestehen", „der Screenshot stimmt mit dem beigefügten Mock überein" oder „der Endpunkt liefert 200 mit dem neuen Feld".
  4. Schreibe bei Fehlerkorrekturen zuerst den fehlschlagenden Test. Bitte Claude, den Fehler als Test zu reproduzieren, ihn auszuführen und zu bestätigen, dass er aus dem erwarteten Grund fehlschlägt. Committe diesen Test. Erst dann bitte Claude, ihn zum Bestehen zu bringen, ohne den Test zu bearbeiten, wobei der Test-Datei-Hook aus dem letzten Schritt diese Einschränkung erzwingt. Ein Test, der vor der Korrektur existierte und den der Agent nicht umschreiben konnte, ist der Beweis, dass der Fehler behoben ist.
  5. Schließe bei UI-Arbeit die Schleife mit einer visuellen Prüfung. Gib Claude ein Browser- oder Screenshot-Tool, gib ihm den Mock und lass es iterieren. Implementieren, Screenshot machen, vergleichen und anpassen. Zwei oder drei Durchläufe sind normal, und das Ergebnis sollte sich mit jedem verbessern.
  6. Mache die Verifizierung zu einem Teil von „erledigt". Die Anweisung steht in CLAUDE.md: „Führe die Tests aus, bevor du eine Aufgabe als abgeschlossen meldest, und zeige die Ausgabe."
  7. Schließlich muss die Schleife selbst geschützt werden, denn ein Agent, der Code korrigiert, darf die Prüfung dieses Codes nicht abschwächen können. Ein Hook, der Bearbeitungen von Testdateien während einer Korrekturaufgabe blockiert, erreicht dies. Die Alternative besteht darin, den Diff bei der Überprüfung zu kontrollieren und jede Änderung abzulehnen, die einen Test berührt.

So sieht es aus

CLAUDE.md-Verifizierungsblock:

markdown
## Verifying your work

- Build: make build (must finish with "Build succeeded")
- Test: make test (all green; never skip or delete a failing test)
- Lint: make lint (zero warnings)

Run all three before reporting any task complete, and paste the output.
If a test fails, fix the code, not the test.

Governance-Überlegungen

  • Was erzwungen wird: Die Verifizierung, bevor eine Aufgabe als erledigt gemeldet wird, und die Blockierung des Agenten beim Bearbeiten von Testdateien während einer Korrektur, beide als Hooks implementiert, wo die Organisation sie garantiert haben möchte.
  • Was den Nachweis darstellt: Die tatsächliche Ausgabe von make test, das Build-Protokoll oder der Screenshot-Vergleich, den Claude ausgeführt und eingefügt hat, sodass der Nachweis aus der Toolchain stammt.
  • Wo es protokolliert wird: Im Sitzungstranskript, das der OpenTelemetry-Export an den Observability-Stack der Organisation weiterleitet, und im Check-Run des PRs, wo sowohl der Reviewer als auch ein späterer Auditor es sehen können.
  • Wer genehmigt: Der Code-Owner, der den PR überprüft und sich auf Absicht und Risiko konzentrieren kann, da der mechanische Nachweis bereits vorliegt.

So misst du es

  • Frühindikator: Die Erfolgsrate der CI beim ersten Durchlauf für vom Agenten geschriebene Änderungen, die das CI-System bereits unterstützt.
  • Spätindikator: Die Überprüfungszeit pro PR (aus den PR-Metadaten), die sinken sollte, sobald die Tests das erfassen, was Reviewer früher erfasst haben, sowie die Änderungsfehlerrate aus einem Incident-Tracker.