Effizienz-Muster

Problem: Nahezu identische Features einzeln nacheinander umzusetzen kostet Stunden und hinterlässt inkonsistenten Code zwischen den Runden.

Schneller Gewinn: Füge diesen Block in deine CLAUDE.md ein. Die Konsistenz verbessert sich, sobald Claude ihn liest:

# Component Generation Framework
 
When creating new [cards/forms/modals], follow the pattern in /components/examples/:
 
1. Copy the closest existing example
2. Replace data fields (keep structure identical)
3. Update types to match new data model
4. Run existing tests as template for new tests

Eine kurze Regel wie diese verhindert, dass Claude Muster neu erfindet, die in deinem Repo bereits existieren.

Was Permutations-Frameworks sind

Ein Permutations-Framework ist ein Trick. Du baust 8 bis 12 eng verwandte Features manuell auf und schreibst dann eine CLAUDE.md-Vorlage, mit der Claude Variante 11, 12 und 13 aus derselben Form erzeugen kann. Das Muster wird einmal erfasst. Claude füllt alles andere aus.

Deine Rolle verändert sich. Du hörst auf, jedes Feature selbst zu coden, und fängst an, die Varianten zu reviewen, die Claude aus einem bewährten Blueprint zieht.

Die drei Phasen

Phase 1: Manuellen Grundstein legen

Beginne damit, 8 bis 12 eng verwandte Features selbst zu coden. Halte dabei jede Entscheidung, jedes Muster und jede Einschränkung schriftlich fest. Diese Aufzeichnung wird die Referenzbibliothek, aus der Claude später lernt.

# Track your patterns
mkdir patterns/user-interfaces
# Build: LoginForm, SignupForm, ProfileForm, etc.
# Document decisions in each component

Ein SaaS-Dashboard mit einigen Datentabellen macht das konkret. UsersTable, OrdersTable, InvoicesTable, ProductsTable. Die ersten drei baust du selbst. Runde für Runde tauchen dieselben Entscheidungen wieder auf: Spaltenform, Signatur des Sort-Handlers, Pagination-Komponente, Empty-State-Layout, Lade-Skeleton.

Nach der dritten Runde kannst du benennen, was sich zwischen Instanzen ändert (Spaltendefinitionen, Datentypen, API-Endpunkt) und was feststeht (Table-Wrapper, Pagination-Logik, Sort-State, Zeilenselektion). Diese Bestandsaufnahme fließt in Phase 2 ein.

Vorher (jede Tabelle von Grund auf neu bauen):

// Each table re-implements pagination, sorting, selection...
// UsersTable: 180 lines
// OrdersTable: 195 lines (slightly different pagination)
// InvoicesTable: 210 lines (different sort logic)

Nachher (Muster extrahiert):

// Shared DataTable component: 120 lines
// UsersTable config: 35 lines (just column definitions + endpoint)
// OrdersTable config: 40 lines
// InvoicesTable config: 38 lines

Phase 2: Muster erkennen und als Vorlage festhalten

Gehe die manuellen Builds nochmals durch und extrahiere:

• Wiederkehrende Code-Strukturen, die in jeder Implementierung auftauchen
• Variable Elemente, die sich von Instanz zu Instanz ändern
• Qualitätsleitplanken (Typsicherheit, Barrierefreiheit, Testabdeckung)
• Prüfpunkte, die bestätigen, dass jede neue Variante tatsächlich funktioniert

Schreibe jetzt einen CLAUDE.md-Abschnitt, der diese Muster mit realen Beispielen von bestanden und nicht bestanden kodiert. Der Trick liegt in der Konkretion. Lass "bestehende Muster befolgen" weg. Verweise direkt auf Dateien: "Verwende das exakte Prop-Interface aus UsersTable.tsx Zeilen 12-28, ersetze den Entity-Typ."

Schwache Framework-Anweisung:

Create new table components following existing patterns.

Starke Framework-Anweisung:

# Data Table Framework
 
Reference: /components/tables/UsersTable.tsx (canonical)
 
To create a new [Entity]Table:
 
1. Props: { columns: ColumnDef<Entity>[], endpoint: string, defaultSort: SortConfig }
2. Use DataTable wrapper from /components/shared/DataTable.tsx
3. Column definitions follow the format in UsersTable lines 12-28
4. Include loading skeleton matching the column count
5. Empty state uses /components/shared/EmptyState.tsx with entity-specific message
6. Tests: copy UsersTable.test.tsx, replace User fixtures with [Entity] fixtures

Genauigkeit macht den ganzen Unterschied. Die starke Version nennt exakte Dateien, Zeilennummern und gemeinsame Komponenten. Claude muss nichts raten. Es folgt einem verifizierten Pfad.

Phase 3: Automatisierte Generierung

Jetzt benutzt du das Framework. Fang mit den einfachen Fällen an und lass den Schwierigkeitsgrad steigen, während Claude beweist, dass es innerhalb deiner Grenzen bleibt.

Die erste generierte Variante kommt fast nie perfekt zurück. Vergleiche sie Zeile für Zeile mit deinen manuellen Beispielen und du findest ein oder zwei Stellen, an denen das Framework nicht spezifisch genug war. Schärfe diese Stellen, generiere erneut und wiederhole. Nach drei oder vier Durchgängen produziert das Framework Code, der das Review ohne manuelle Änderungen besteht.

Strategien zur Framework-Verbesserung

Einschränkungsbasierte Qualitätskontrolle

Enge Framework-Regeln schränken Claudes kreativen Spielraum ein, ohne nützliche Variation zu unterdrücken. Schreib die Einschränkungen direkt in CLAUDE.md:

CONSTRAINTS:
 
- All components must include PropTypes / TypeScript interfaces
- Use established naming conventions (camelCase for props)
- Include accessibility attributes (aria-label, role, tabIndex)
- Follow existing file structure in /components/
- Every new component gets a co-located test file

Varianz-Tests

Stresse das Framework, indem du 5 bis 10 Varianten generierst und sie nebeneinander vergleichst. Wenn sie zu stark abweichen, geh zurück und füge schärfere Beispiele und strengere Einschränkungen zur CLAUDE.md-Vorlage hinzu.

Ein konkreter Durchlauf mit einem API-Endpunkt-Framework zeigte das Problem. Bei den ersten 3 generierten Endpunkten blieb die Fehlerbehandlung konsistent, aber die Response-Formen divergierten. Einer kam als { data: ... } zurück. Ein anderer verpackte den Payload als { result: ... }. Der dritte gab das rohe Objekt ohne Wrapper zurück. Eine neue Zeile im Framework löste alles: "All endpoints return { data: T, error: null } or { data: null, error: ErrorShape }." Die Varianz verschwand aus den nächsten 8 Generierungen.

Iterative Verbesserung

Jeder Framework-Durchlauf schärft zwei Dinge gleichzeitig: wie genau Claude dein Muster einhält, und wie klar du verstehst, was AI-generierten Code zuverlässig macht.

Permutations-Framework in der Praxis

Ein konkreter Durchlauf. Angenommen, du hast UserCard, ProductCard und OrderCard manuell gebaut. Du fügst das in CLAUDE.md ein:

# Card Component Framework
 
Reference: /components/cards/UserCard.tsx (canonical example)
 
To create a new [Entity]Card:
 
1. Props: { data: [Entity], onClick?: () => void, variant?: 'compact' | 'full' }
2. Structure: Avatar/Icon + Title + Subtitle + Action buttons
3. Styling: Use existing Tailwind classes from UserCard
4. Tests: Copy UserCard.test.tsx, replace User with [Entity]

Bitte Claude, "eine SubscriptionCard zu erstellen", und das Ergebnis passt sich derselben Form an. Gleiche Prop-Struktur, gleicher Styling-Ansatz, gleiche Testabdeckung. Man kann sie nicht von einer der handgebauten Karten unterscheiden, weil sie vom selben Blueprint stammt.

Häufige Effizienz-Muster

API-Endpunkte: Frameworks für Routen mit einheitlicher Fehlerbehandlung, Validierung und Response-Formen. Leg dein Zod-Schema-Muster, dein Fehlerantwortformat und deine Middleware-Kette je einmal fest. Ein neuer Endpunkt schrumpft von einer Stunde auf 15 Minuten.

UI-Komponenten: Frameworks für Design-System-Komponenten, die verschiedene Datentypen verwalten. Das Card-Beispiel oben lässt sich direkt auf Modals, Formulare, Listenelemente und Detailansichten übertragen. Wenn eine Komponente bereits in 3+ Varianten existiert, qualifiziert sie sich als Framework-Material.

Datenbankoperationen: Frameworks für CRUD mit gemeinsamer Transaktionsbehandlung über Modelle hinweg. Definiere den Query-Builder, den Pagination-Ansatz und das Soft-Delete-Verhalten einmal. Neue Modelle werden auf denselben Schienen eingehängt.

Wann du KEIN Framework bauen solltest

Frameworks sind nicht kostenlos. Zu viel Framework zu bauen kostet dich, genauso wie zu viel Code zu bauen.

Ein oder zwei Beispiele reichen nicht. Drei manuell gebaute Versionen sind das Minimum. Bei zwei sperrt sich das Framework auf genau diese Fälle ein und generalisiert nicht.

Überspringe Frameworks für einmalige Features. Ein einzelnes benutzerdefiniertes Admin-Dashboard ohne Geschwister fügt nur Overhead hinzu und bringt nichts zurück. Spar dir das Framework-Budget für Muster, die sich wiederholen.

Warte, bis Muster sich stabilisieren. Im ersten Monat eines Projekts ändern sich Komponentenformen von Woche zu Woche. Eine in Woche eins festgelegte starre Vorlage bedeutet Nacharbeit in Woche zwei. Stabilisiere die Form durch 8 bis 10 manuelle Builds zuerst.

Vermeide Über-Einschränkungen. Wenn die Regeln so eng sind, dass Claude nicht mit echter Variation umgehen kann, kostet das Framework mehr als es einbringt. Gute Einschränkungen sichern die Struktur und lassen Raum für entity-spezifische Details.

Erfolgsmetriken für Frameworks

Beobachte diese Indikatoren, um zu bestätigen, dass das Framework sich lohnt:

• Konsistenz-Score: Stimmen generierte Varianten mit deinen handgebauten Beispielen bei Imports, Prop-Formen und Dateilayout überein? Ein gesundes Framework erzielt hohe strukturelle Übereinstimmung.
• Implementierungsgeschwindigkeit: Ein gut abgestimmtes Framework verkürzt den Weg von der Anfrage zum funktionierenden Feature spürbar. Keine echte Beschleunigung bedeutet, dass mehr Detail benötigt wird oder die Muster noch nicht festgelegt sind.
• Review-Zeit: Wie lange dauert ein Validierungsdurchlauf? Diese Zahl sollte sinken, je reifer das Framework wird. Frühe Ausgaben brauchen sorgfältiges Review. Ausgereifte Ausgaben brauchen nur einen kurzen Blick zur Korrektheitsprüfung.
• Bug-Häufigkeit: Vergleiche Bugs pro generierter Variante mit Bugs pro handgebautem Feature. Ein gutes Framework senkt die Zahl, weil es Muster einbettet, die du bereits praxiserprobt hast.

Von linearem zu exponentiellem Skalieren

Klassische Entwicklung skaliert linear. Ein Entwickler produziert ein Feature nach dem anderen. Permutations-Frameworks schreiben diese Mathematik um. Ein einziges Framework produziert viele Varianten, und deine Geschwindigkeit steigt.

Der Gewinn ist am größten in Codebasen, wo sich wiederholende Muster verschiedenen Nutzern dienen, aber dieselbe technische Form teilen. Die Rendite wächst von da an. Sobald du Frameworks für Komponenten, API-Endpunkte und Datenbankoperationen hast, läuft ein neues Feature, das alle drei Schichten umspannt, in einem Bruchteil der alten Zeit, weil jede Schicht ihren Blueprint bereits bereitstellt.

Nächste Schritte:

1. Heute: Durchsuche dein Repo nach 3 eng verwandten Komponenten. Cards, Formulare und Modals sind die saubersten Ausgangspunkte.
2. Diese Woche: Verwandle diese Geschwister in dein erstes Framework, indem du genau aufschreibst, was zwischen ihnen konstant bleibt.
3. Tiefer eintauchen: Studiere die CLAUDE.md-Techniken, die Framework-Dokumentation effektiv machen.
4. Verwandt: Greife auf Planungsmodi zurück, wenn eine Framework-Anfrage komplex wird.
5. Optimieren: Nutze Modellauswahlstrategien, um Kosten und Qualität abzustimmen.
6. Automatisieren: Richte Feedback-Loops ein, damit sich Verbesserungen summieren.
7. Experimentieren: Führe systematische Varianz-Tests durch, um zu bestätigen, dass die Ausgabe des Frameworks standhält.