henning thies.

Arbeitsweise

Verifizierung einbauen

Damit Claude sich selbst prüfen kann

Damit Claude sich selbst prüfen kann

Claude performt dramatisch besser, wenn es seine eigene Arbeit verifizieren kann. Tests, Screenshots, erwartete Outputs – alles was Claude ermöglicht zu prüfen: "Ist das, was ich gebaut habe, richtig?"

Ohne Verifizierung bist du die einzige Feedback-Schleife. Jeder Fehler braucht deine Aufmerksamkeit. Das skaliert nicht.

Das Problem ohne Verifizierung

Wenn Claude keinen Weg hat zu prüfen, ob das Ergebnis stimmt, passiert Folgendes:

  • Claude produziert etwas, das plausibel aussieht
  • Du musst es manuell prüfen
  • Du findest einen Fehler
  • Du korrigierst Claude
  • Claude macht eine neue Version
  • Du prüfst wieder... und wieder... und wieder

Wichtig

Du wirst zum Bottleneck. Ohne Verifizierung ist jede Iteration auf dein manuelles Review angewiesen.

Arten der Verifizierung

1. Tests

Die mächtigste Form der Verifizierung. Claude kann Tests schreiben, ausführen und iterieren bis sie grün sind.

" Implementiere die validateEmail-Funktion. Verifizierung: - test@example.com → true - invalid → false - user@.com → false - @ → false Schreibe erst die Tests, dann die Implementation. Iteriere bis alle Tests grün sind. "

Claude hat jetzt klare Erfolgskriterien. Es kann selbstständig iterieren bis die Tests bestehen.

2. Screenshots

Für UI-Änderungen: Claude kann Screenshots machen und mit der Vorgabe vergleichen.

" [Bild: Design-Mock] Implementiere dieses Design. Mache einen Screenshot vom Ergebnis. Vergleiche mit dem Mock und liste Unterschiede auf. Fixe die Unterschiede. "

3. Erwartete Outputs

Wenn Tests zu aufwändig sind: Definiere erwartete Outputs.

" Die API soll folgendes JSON zurückgeben: { "users": [...], "total": 42, "page": 1 } Implementiere den Endpoint. Rufe ihn mit curl auf und prüfe, ob das Format stimmt. "

4. Lint & Type Checks

Automatische Code-Qualitätsprüfung:

" Nach jeder Änderung: - Führe rubocop aus - Prüfe mit TypeScript (falls vorhanden) - Fixe alle Errors Erst wenn keine Fehler mehr kommen, bist du fertig. "

5. Build-Prozess

Der Build muss durchlaufen:

" Führe nach der Änderung 'bin/rails test' aus. Wenn Tests fehlschlagen, analysiere warum und fixe es. Iteriere bis der Build grün ist. "

Test-Driven Development mit Claude

TDD wird noch mächtiger mit AI

Das klassische TDD-Pattern – Test schreiben, dann Code – funktioniert hervorragend mit Claude. Die Tests sind die Spezifikation und die Verifizierung in einem.

TDD-Workflow mit Claude:

  1. 1. Claude schreibt Tests basierend auf deiner Spec
  2. 2. Du prüfst: Sind die Tests richtig?
  3. 3. Tests werden committed (noch rot)
  4. 4. Claude implementiert bis Tests grün sind
  5. 5. Implementation wird committed
TDD Beispiel
" Feature: User kann sich mit E-Mail/Passwort registrieren. 1. Schreibe erst Tests für: - Erfolgreiche Registrierung - Fehlende E-Mail - Ungültiges Passwort (zu kurz) - E-Mail bereits vergeben 2. Zeig mir die Tests bevor du implementierst. 3. Implementiere dann bis alle Tests grün sind. Nutze Minitest. Keine Mocks. "

Prompts mit Verifizierung

Der Unterschied zwischen vagen und verifizierbaren Prompts:

"Füge Validierung zum User-Model hinzu"

Keine Erfolgskriterien. Claude weiß nicht, wann es fertig ist.

Besser
" Füge Validierung zum User-Model hinzu: - email: format prüfen, muss unique sein - name: min. 2 Zeichen, max. 50 Schreibe Tests die das prüfen. Verifiziere dass die Tests grün sind. "

Noch ein Beispiel:

"Mach die Suche besser"

Was heißt 'besser'? Schneller? Genauer? Welche Fälle?

Besser
" Verbessere die Suche: - 'Test' soll 'testing' finden (partial match) - 'TEST' soll 'test' finden (case-insensitive) - Suche in title UND content Schreibe Tests für jeden Fall. Miss die Query-Zeit vorher und nachher. "

Verifizierung in CLAUDE.md

Du kannst Verifizierung als Standard-Verhalten definieren: 

## Nach jeder Code-Änderung

1. Führe bin/rails test aus
2. Prüfe mit rubocop
3. Bei Fehlern: Analysiere und fixe

Erst wenn Tests grün und kein Lint-Error, ist die Aufgabe fertig.

Die Feedback-Schleife verkürzen

Je schneller Claude verifizieren kann, desto schneller iteriert es:

Verifizierung Feedback-Zeit Effektivität
Dein manuelles Review Minuten bis Stunden Niedrig
Lint/Type Check Sekunden Hoch
Unit Tests Sekunden Sehr hoch
Integration Tests Sekunden bis Minuten Sehr hoch
Screenshot-Vergleich Sekunden Hoch für UI

Tipp

Investiere in schnelle Tests. Wenn deine Test-Suite 10 Minuten braucht, wird Claude sie nicht nach jeder Änderung ausführen. Schnelle Feedback-Loops ermöglichen schnellere Iteration.

Zusammenfassung

  • Verifizierung ermöglicht Selbstvalidierung – Claude kann ohne dich iterieren
  • Tests sind die mächtigste Verifizierung – klare Erfolgskriterien
  • TDD funktioniert hervorragend – Tests sind Spec und Verifizierung
  • Schnelle Feedback-Loops – je schneller die Verifizierung, desto mehr Iterationen
  • In CLAUDE.md als Standard definieren – "immer Tests ausführen nach Änderungen"