Compounding Engineering: Wie meine Codebase beschleunigt statt zu verfallen

Die meisten Codebasen werden mit zunehmendem Wachstum langsamer. Meine beschleunigt sich. Nachdem ich 95 Hooks, 44 Skills und 14 Konfigurationsdateien in meiner .claude/-Infrastruktur aufgebaut habe, kostet jede neue Funktion weniger als die vorherige, weil die Infrastruktur einen größeren Teil der Arbeit übernimmt.¹

TL;DR

Compounding Engineering beschreibt Codebasen, in denen jede neue Funktion die nachfolgenden günstiger in der Entwicklung macht. Ich habe das aus erster Hand erlebt: Mein Claude Code Hook-System begann mit 3 Hooks und wuchs auf 95. Der erste Hook brauchte eine Stunde. Aktuelle Hooks sind in 10 Minuten fertig, weil die Infrastruktur (Lifecycle-Events, Konfigurationsladen, Zustandsverwaltung, Test-Harness) bereits existiert. Das Gegenmuster, Entropy Engineering, beschreibt Codebasen, in denen jede Funktion die Kosten nachfolgender Funktionen erhöht. Der Unterschied zwischen einem Team, das im dritten Jahr schneller ausliefert als im ersten, und einem Team, das zum Stillstand kommt, liegt darin, ob sich die technischen Entscheidungen positiv oder negativ kumulieren.

Compounding in der Praxis: Meine .claude/-Infrastruktur

Die Wachstumskurve

Der erste Hook (git-safety-guardian.sh) erforderte den Aufbau des gesamten Hook-Lebenszyklus: PreToolUse-Events verstehen, Bash schreiben, das JSON-Eingaben parst, Fehlerfälle behandeln, manuell testen. Der 95. Hook erbte diese gesamte Infrastruktur. Die Zeit pro Hook sank um den Faktor 6 — nicht weil die Hooks einfacher wurden, sondern weil die Infrastruktur mehr Arbeit übernahm.

Was sich kumuliert

Musterkonsistenz. Jeder Hook folgt der gleichen Struktur: JSON-Eingabe lesen, mit jq parsen, Bedingungen prüfen, Entscheidungs-JSON ausgeben. Jeder Entwickler (oder KI-Agent), der einen beliebigen Hook liest, erkennt sofort das Muster. Mein 12-Modul-Blog-Linter folgt dem gleichen Konsistenzprinzip: Jedes Modul exportiert die gleiche Schnittstelle (check(content, meta) -> findings), was neue Module trivial hinzufügbar macht.

Konfigurationsgesteuertes Verhalten. Alle 14 JSON-Konfigurationsdateien kodieren Schwellenwerte und Regeln, die ursprünglich fest im Code standen. Als ich den Deliberation-Konsens-Schwellenwert von einem fest kodierten 0.70 in Python nach deliberation-config.json verschob, gewann ich die Möglichkeit, ihn pro Aufgabentyp zu justieren (Sicherheit=85%, Dokumentation=50%) — ohne Codeänderungen.²

Testinfrastruktur. Die ersten 20 Hooks hatten keine Tests. Das Hinzufügen des Test-Harness (48 Bash-Integrationstests, 81 Python-Unit-Tests) kostete zwei Wochen. Jeder Hook seitdem wird innerhalb von unter 5 Minuten mit Tests ausgeliefert, weil die Fixtures, Assertion-Helfer und Test-Runner bereits existieren.

Gedächtnissystem. Meine MEMORY.md-Datei erfasst Fehler, Entscheidungen und Muster über Sitzungen hinweg. Mit 54 Einträgen verhindert sie, dass ich Fehler wiederhole. Der ((VAR++)) Bash-Fallstrick aus Hook #23 hat den gleichen Bug in den Hooks #24 bis #95 verhindert. Jeder Eintrag kumuliert sich über jede zukünftige Sitzung.³

Das Compounding-Modell

Positives Compounding

Ingenieurproduktivität folgt einer Zinseszinsformel:

Productivity(n) = Base × (1 + r)^n

Wobei r die Produktivitätsänderungsrate pro Funktion und n die Anzahl der ausgelieferten Funktionen ist.

Positives r (Compounding): Jede Funktion macht die nächste 2–5 % günstiger. Nach 50 Funktionen: 1,03^50 = 4,38-fache Produktivitätsverbesserung.

Negatives r (Entropie): Jede Funktion macht die nächste 2–5 % teurer. Nach 50 Funktionen: 0,97^50 = 0,22-fache Produktivität — ein Rückgang von 78 %.

Der Unterschied zwischen diesen Verläufen beträgt nach 50 Funktionen eine 20-fache Lücke in der Entwicklungsgeschwindigkeit.⁴

Meine realen Zahlen

Meine blakecrosley.com-Seite begann als einzelne FastAPI-Route mit einem HTML-Template. Neun Monate später:

Der letzte Eintrag ist der Compounding-Gewinn: Ein neues Linter-Modul hinzuzufügen dauert 15 Minuten, weil die Modulschnittstelle, CLI-Integration, der Test-Harness und die CI-Pipeline bereits existieren. Das erste Modul brauchte 3 Stunden, weil nichts davon vorhanden war.⁵

Entropie-Beispiele aus meiner eigenen Codebasis

Compounding geschieht nicht automatisch. Auch ich habe Entropie erlebt:

Die ContentMeta-Schema-Abkürzung

Ich definierte die Blogpost-ContentMeta-Datenklasse in einer einzigen Sitzung: Titel, Slug, Datum, Beschreibung, Tags, Autor, Veröffentlicht. Ich nahm category, series, hero_image, scripts oder styles nicht auf. Jede spätere Ergänzung erforderte die Modifikation des Parsers, die Aktualisierung jedes Templates, das die Metadaten verwendete, und das erneute Testen der gesamten Pipeline. Fünf Ergänzungen über drei Monate kosteten insgesamt mehr Zeit, als ein sorgfältiges Schema-Design von Anfang an gekostet hätte. Das ist das Decision Timing-Problem: Irreversible Entscheidungen verdienen eine gründliche Vorabanalyse.

Die i18n-Cache-Key-Kollision

Eine schnelle Implementierung des Übersetzungs-Cachings verwendete Blog-Slugs als Cache-Keys. Als zwei Übersetzungen desselben Slugs in verschiedenen Sprachversionen existierten, gab der Cache die falsche Sprache zurück. Die Fehlersuche dauerte 3 Stunden. Die Behebung dauerte 15 Minuten (Locale-Präfix zum Cache-Key hinzufügen). Die Abkürzung, die bei der Implementierung 5 Minuten sparte, kostete 3 Stunden Debugging und eine Architekturüberprüfung jedes Cache-Keys im System.⁶

Das 3,2-GB-Debug-Verzeichnis

Hook-Debug-Ausgaben sammelten sich in ~/.claude/debug/ ohne Bereinigung an. Über drei Monate wuchs das Verzeichnis auf 3,2 GB. Der Context-Audit-Skill, den ich später erstellte, erkannte dies und bereinigte Dateien, die älter als 7 Tage waren — aber die Bereinigungsinfrastruktur hätte schon mit der ersten Debug-Ausgabe gebaut werden sollen.

Praktiken, die sich kumulieren

Konsistente Muster statt optimaler Muster

Ein Team, das dasselbe „gut genug”-Muster über 50 Funktionen hinweg verwendet, arbeitet schneller als ein Team, das für jede einzelne Funktion das „optimale” Muster wählt. Konsistenz reduziert die kognitive Belastung, ermöglicht automatisierte Werkzeuge und beschleunigt Code-Reviews.⁷

Mein Hook-System verwendet dasselbe Bash-Muster für alle 95 Hooks, obwohl manche Hooks natürlicher in Python ausgedrückt wären. Die Konsistenz bedeutet, dass jeder Hook für jeden (oder jeden KI-Agenten) lesbar ist, der einen Hook gelesen hat. Die suboptimale Sprachwahl wird durch die Null-Lernkurve für neue Hooks mehr als ausgeglichen.

Infrastruktur als erste Funktion

Ich habe meine CI/CD-Pipeline, den Test-Harness und den Deployment-Workflow aufgebaut, bevor ich irgendwelche Produktfunktionen auf blakecrosley.com entwickelte. Die Investition fühlte sich zunächst langsam an. Jede Funktion seitdem wird in unter 2 Minuten mit automatisierten Tests bereitgestellt.⁸

Das Mind-Palace-Muster

Mein .claude/-Verzeichnis funktioniert als „Gedächtnispalast” — eine strukturierte Sammlung von Dokumenten, optimiert sowohl für menschliche als auch für KI-Nutzung:

~/.claude/
├── configs/     # 14 JSON files — system logic, not hardcoded
├── hooks/       # 95 bash scripts — lifecycle event handlers
├── skills/      # 44 directories — reusable knowledge modules
├── docs/        # 40+ markdown files — system documentation
├── state/       # Runtime tracking — recursion depth, agent lineage
├── handoffs/    # 49 documents — multi-session context preservation
└── memory/      # MEMORY.md — 54 cross-domain error/pattern entries

Der Gedächtnispalast kumuliert, weil jeder neue Eintrag den Kontext bereichert, der für zukünftige Entwicklungssitzungen verfügbar ist. Nach 54 MEMORY.md-Einträgen vermeidet der KI-Agent Fehler, die ich bereits gelöst habe. Nach 95 Hooks schreiben sich neue Hooks praktisch von selbst, indem sie etablierten Mustern folgen. Der reichere Kontext erzeugt besser passenden KI-generierten Code, was die nächste Funktion günstiger macht.⁹

Compounding im KI-Zeitalter

KI verstärkt beide Richtungen

KI-Codierassistenten beschleunigen das Muster, dem die Codebasis bereits folgt. Meine 95 Hooks mit konsistenten Mustern erzeugen hervorragend KI-generierte Hooks, weil die KI die etablierte Struktur übernimmt. Eine Codebasis mit 5 verschiedenen Hook-Stilen würde schlechteren KI-generierten Code hervorbringen, weil die KI kein konsistentes Muster zum Abgleichen hat.¹⁰

Der Compounding-Effekt verdoppelt sich: Konsistente Muster machen die menschliche Entwicklung schneller (Reduktion der kognitiven Belastung) UND die KI-gestützte Entwicklung schneller (Musterabgleich). Inkonsistente Muster verlangsamen beides.

Agenten-lesbare Codebasen

Ich habe meine .claude/-Infrastruktur für die Nutzung durch KI-Agenten konzipiert:

• Strukturierte Konfigurationen (JSON, keine fest kodierten Werte), die Agenten programmatisch parsen
• Konsistente Namenskonventionen (verb-noun.sh für Hooks, SKILL.md für Skill-Definitionen)
• Maschinell überprüfbare Qualitätschecks (141 Tests, die Agenten autonom ausführen)
• Explizite Dokumentation (MEMORY.md, Handoffs, docs/), die Agenten zu Sitzungsbeginn lesen

Jede Investition in Agenten-Lesbarkeit kumuliert sich, je leistungsfähiger KI-Werkzeuge werden.¹¹

Wichtigste Erkenntnisse

Für Ingenieure: - Verfolgen Sie Ihre „Zeit pro Funktion” mit wachsender Codebasis; steigt sie, haben Sie Entropie — sinkt sie, haben Sie Compounding - Wenden Sie die Dreierregel an, bevor Sie Abstraktionen extrahieren: Bauen Sie die spezifische Lösung zweimal, dann extrahieren Sie beim dritten Mal das wiederverwendbare Muster - Investieren Sie 15–20 % jedes Sprints in Infrastruktur- und Werkzeugverbesserungen; die kumulierten Erträge übersteigen die kurzfristigen Kosten für die Feature-Geschwindigkeit innerhalb von 3–5 Sprints

Für Engineering-Manager: - Messen Sie die Ingenieursgesundheit anhand der Durchlaufzeit pro Funktion über die Zeit; steigende Durchlaufzeit signalisiert Entropie - Behandeln Sie Dokumentation und Testinfrastruktur als Funktionen, nicht als Overhead; meine Testinfrastruktur-Investition (2 Wochen) hat über 50 Stunden bei 95 Hooks eingespart

Referenzen