henning thies.

Fortgeschritten

Patterns & Anti-Patterns

Was funktioniert und was nicht

Was funktioniert – und was nicht

Diese Patterns sind erprobte Vorgehensweisen für verschiedene Situationen. Die Anti-Patterns zeigen dir, was du vermeiden solltest.

Pattern: Explain First

Wann: Wenn du Code verstehen willst, bevor du ihn änderst.

Bevor Claude was ändert, soll es erklären. Das gibt dir die Kontrolle und hilft, Missverständnisse früh zu erkennen.

" Erkläre mir erst, wie der Authentication-Flow funktioniert. Ändere noch nichts. "

Pattern: Show Options

Wann: Bei Architektur-Entscheidungen oder wenn mehrere Lösungen möglich sind.

" Zeige mir 3 verschiedene Ansätze für die Suche. Für jeden Ansatz: - Kurze Beschreibung - Vor- und Nachteile Implementiere noch nichts – ich entscheide erst. "

Pattern: Planning First

Wann: Vor größeren Features oder Refactorings.

" Ich will Feature X implementieren. Erstelle erst einen Plan: - Welche Dateien werden betroffen? - In welcher Reihenfolge vorgehen? - Welche Tests brauchen wir? Warte auf mein OK bevor du anfängst. "

Tipp

Wenn du mehr als 2-3 Dateien anfassen musst, lohnt sich ein Plan. Die 2 Minuten Planung sparen 20 Minuten Korrektur.

Pattern: Step by Step

Wann: Für größere Features oder wenn du die Kontrolle behalten willst.

" Gehe Schritt für Schritt vor: 1. Erst: Was muss am Model ändern? 2. Dann: Was am Controller? 3. Dann: Was an der View? Nach JEDEM Schritt: Warte auf mein OK. "

Pattern: Test First

Wann: Wenn du sicherstellen willst, dass die Änderung funktioniert.

" Für das neue Feature: 1. Schreibe erst einen Test, der zeigt was wir erwarten 2. Zeig mir den Test 3. Dann implementiere, bis der Test grün ist "

Wann welches Pattern?

Situation Pattern
Code verstehen wollen Explain First
Architektur-Entscheidung Show Options
Großes Feature Planning First
Kontrolle behalten Step by Step
Neue Funktionalität Test First

Anti-Pattern: Der Einzeiler

Zu wenig Information → Claude muss raten

"Fix it"

Was fixen? Wo? Welches Verhalten ist gewünscht?

Besser:

Mindestens Kontext + Aufgabe. Was ist wo und was soll passieren?

Anti-Pattern: Der Roman

500-Wörter-Prompt → Claude verliert den Fokus

"Ich habe hier dieses Projekt und das macht XYZ und früher haben wir ABC gemacht aber jetzt wollen wir DEF und dabei sollte man beachten dass GHI und außerdem JKL..."

Zu viel Information auf einmal. Claude weiß nicht, was wichtig ist.

Besser:

Kurz und klar, dann iterieren. Fokus auf EINE Sache.

Anti-Pattern: Alles auf einmal

"Füge Validierung hinzu, ändere das Layout, optimiere die Query, schreibe Tests und update die Docs"

5 Aufgaben = 5 Fehlermöglichkeiten. Schwer zu reviewen.

Besser:

Eine Aufgabe nach der anderen. Teste dazwischen.

Anti-Pattern: Blindes Vertrauen

"Claude hat das geschrieben, wird schon passen."

Besser:

Änderungen reviewen. Verstehen was passiert. Tests laufen lassen.

Anti-Pattern: Code-Diktator

"Füge in Zeile 42 'if user.valid?' ein und dann in Zeile 45..."

Du denkst noch wie bei Copy-Paste. Claude könnte es besser lösen.

Besser:

Beschreibe das gewünschte ERGEBNIS, nicht den genauen Code.

Zusammenfassung

Tu das

  • Erst erklären lassen, dann ändern
  • Optionen zeigen lassen
  • Planen vor großen Features
  • Schritt für Schritt vorgehen
  • Ergebnisse beschreiben

Vermeide das

  • Zu wenig Kontext
  • Zu viel auf einmal
  • Blindes Vertrauen
  • Code diktieren
  • Nach einem Versuch aufgeben

Wichtig

Die goldene Regel: Wenn Claude nicht macht was du willst, ist zu 90% das Briefing schuld. Prompt verbessern. Iterieren. Nochmal.