Code Guideline
Die Lösung​
Vier Prinzipien in einer Datei, die diese Probleme direkt adressieren:
| Prinzip | Adressiert |
|---|---|
| Think Before Coding | Falsche Annahmen, versteckte Verwirrung, fehlende Trade-offs |
| Simplicity First | Überkomplizierung, aufgeblähte Abstraktionen |
| Surgical Changes | Seitliche Änderungen, unnötig angefasster Code |
| Goal-Driven Execution | Mehr Hebel durch tests-first und ĂĽberprĂĽfbare Erfolgskriterien |
Die vier Prinzipien im Detail​
1. Think Before Coding​
Nichts annehmen. Verwirrung nicht verstecken. Trade-offs sichtbar machen.
LLMs wählen oft stillschweigend eine Interpretation und laufen damit los. Dieses Prinzip erzwingt explizites Denken:
- Annahmen explizit benennen — Wenn du unsicher bist, frage statt zu raten
- Mehrere Interpretationen darstellen — Nicht still eine auswählen, wenn es Ambiguität gibt
- Sinnvoll widersprechen — Wenn ein einfacherer Ansatz existiert, sprich ihn an
- Bei Unklarheit stoppen — Benenne, was unklar ist, und frage nach
2. Simplicity First​
So wenig Code wie möglich, um das Problem zu lösen. Nichts Spekulatives.
Dieses Prinzip wirkt der Tendenz zum Overengineering entgegen:
- Keine Features ĂĽber die Anfrage hinaus
- Keine Abstraktionen fĂĽr Single-Use-Code
- Keine "Flexibilität" oder "Konfigurierbarkeit", die nicht gefordert wurde
- Kein Error Handling für unmögliche Szenarien
- Wenn 200 Zeilen auch 50 sein könnten, dann umschreiben
Der Test: WĂĽrde ein Senior Engineer sagen, dass das ĂĽberkompliziert ist? Wenn ja, vereinfachen.
3. Surgical Changes​
Nur das anfassen, was du wirklich musst. Nur den eigenen Schaden aufräumen.
Beim Bearbeiten bestehenden Codes:
- Benachbarten Code, Kommentare oder Formatierung nicht "verbessern"
- Nichts refactoren, was nicht kaputt ist
- Den vorhandenen Stil matchen, auch wenn du es anders lösen würdest
- Wenn dir toter Code auffällt, erwähne ihn, aber lösche ihn nicht
Wenn deine Ă„nderungen Orphans erzeugen:
- Imports/Variablen/Funktionen entfernen, die durch deine Ă„nderung ungenutzt wurden
- Vorher schon vorhandenen toten Code nicht ohne Auftrag löschen
Der Test: Jede geänderte Zeile muss direkt auf die Nutzeranforderung zurückführbar sein.
4. Goal-Driven Execution​
Erfolgskriterien definieren. In Schleifen arbeiten, bis sie verifiziert sind.
Verwandle imperative Aufgaben in ĂĽberprĂĽfbare Ziele:
| Statt... | Besser... |
|---|---|
| "Add validation" | "Write tests for invalid inputs, then make them pass" |
| "Fix the bug" | "Write a test that reproduces it, then make it pass" |
| "Refactor X" | "Ensure tests pass before and after" |
Bei mehrstufigen Aufgaben eine kurze Planung formulieren:
1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]
Starke Erfolgskriterien erlauben dem LLM, selbstständig zu iterieren. Schwache Kriterien wie "mach es lauffähig" zwingen zu ständiger Klärung.
Zentrale Erkenntnis​
Von Andrej Karpathy:
"LLMs are exceptionally good at looping until they meet specific goals... Don't tell it what to do, give it success criteria and watch it go."
Das Prinzip "Goal-Driven Execution" greift genau das auf: imperative Anweisungen in deklarative Ziele mit Verifikationsschleifen verwandeln.
Woran man erkennt, dass es funktioniert​
Diese Guidelines funktionieren, wenn du Folgendes siehst:
- Weniger unnötige Änderungen in Diffs — Es tauchen nur angeforderte Änderungen auf
- Weniger Rewrites wegen Überkomplizierung — Der Code ist beim ersten Mal einfacher
- Klärende Fragen kommen vor der Implementierung — Nicht erst nach Fehlern
- Saubere, minimale PRs — Kein Drive-by-Refactoring und keine Nebenverbesserungen
Anpassung​
Diese Guidelines sind dafĂĽr gedacht, mit projektspezifischen Anweisungen kombiniert zu werden. Du kannst sie in eine bestehende CLAUDE.md ĂĽbernehmen oder eine neue Datei daraus machen.
Für projektspezifische Regeln kannst du zum Beispiel Abschnitte wie diesen ergänzen:
## Project-Specific Guidelines
- Use TypeScript strict mode
- All API endpoints must have tests
- Follow the existing error handling patterns in `src/utils/errors.ts`
Trade-off-Hinweis​
Diese Guidelines gewichten Vorsicht höher als Geschwindigkeit. Bei trivialen Aufgaben wie kleinen Tippfehlern oder offensichtlichen Einzeilern solltest du mit Augenmaß vorgehen - nicht jede Änderung braucht die volle Strenge.
Ziel ist es, kostspielige Fehler bei nicht-trivialer Arbeit zu reduzieren, nicht einfache Aufgaben unnötig zu verlangsamen.
Lizenz​
MIT