Compound Engineering
Compound Engineering ist eine Arbeitsweise in der Softwareentwicklung, bei der jede gelöste Aufgabe eine dauerhafte Spur hinterlässt: eine Notiz, eine Regel, einen automatischen Test. Ziel ist, dass Teams mit KI-Werkzeugen nicht nur schneller arbeiten, sondern von Woche zu Woche weniger dieselben Fehler wiederholen.
Compound Engineering beschreibt eine bestimmte Art, Software zu bauen. Der Grundgedanke: Jede Aufgabe soll die nächste Aufgabe leichter machen. Wer ein Problem löst, schreibt nicht nur die Lösung, sondern hält auch fest, was er dabei gelernt hat. Diese Notizen und Regeln gibt man dann den KI-Assistenten mit, die beim Programmieren helfen. Das Wort « compound » kommt aus dem Englischen und meint hier den Zinseszins: kleine Beträge, die sich über die Zeit aufaddieren und verstärken. Statt jeden Tag bei Null anzufangen, wächst also ein Vorrat an Wissen mit.
Der Zinseszins-Effekt im Entwicklungsalltag
In vielen Teams passiert das Gegenteil. Ein Entwickler entdeckt eine Stolperfalle, behebt sie und erzählt niemandem davon. Drei Monate später tappt ein Kollege in genau dieselbe Falle. Solche Wiederholungen kosten enorm viel Zeit, tauchen aber in keiner Statistik auf. Compound Engineering versucht, diesen Verlust systematisch zu stoppen.
Besonders wichtig wurde die Idee mit dem Aufkommen von KI-Assistenten, die Code vorschlagen. Diese Programme sind schnell, aber sie kennen die Eigenheiten eines Projekts nicht von sich aus. Ohne Anleitung machen sie in jedem neuen Gespräch dieselben Fehler. Wer dem Assistenten dagegen eine gepflegte Sammlung von Projektregeln mitgibt, bekommt spürbar bessere Vorschläge. Der Aufwand für diese Sammlung fällt einmal an, der Nutzen entsteht bei jeder weiteren Anfrage.
Für Unternehmen ist das ein wirtschaftliches Argument. Ein Team, das seine Erkenntnisse festhält, wird über Monate hinweg schneller, ohne neue Leute einzustellen. Ein Team ohne dieses Gedächtnis bleibt gleich schnell, egal wie viele KI-Werkzeuge es kauft.
Was bei jeder Aufgabe zurückbleibt
In der Praxis läuft es meist über drei Arten von Spuren. Erstens Textdateien mit Projektregeln, die der KI-Assistent bei jeder Sitzung mitliest. Dort steht etwa, welche Bibliotheken erlaubt sind oder wie Fehlermeldungen aussehen sollen. Zweitens automatische Tests: kleine Programme, die nach jeder Änderung prüfen, ob alles noch funktioniert. Wer einen Fehler behebt, schreibt einen Test dazu, damit derselbe Fehler nie wieder unbemerkt zurückkehrt.
Drittens dokumentierte Entscheidungen. Wenn ein Team sich für eine bestimmte Datenbank entscheidet, notiert es kurz die Gründe. Später fragt niemand mehr nach, warum es so gemacht wurde, und die Diskussion beginnt nicht von vorn. Ein passendes Bild ist ein Kochbuch, das nach jedem Essen um eine Randbemerkung wächst: « Ofen zehn Minuten kürzer, sonst wird es trocken. »
Wichtig ist die Abgrenzung zu reiner Dokumentation. Normale Dokumentation liegt oft in einem Wiki und wird selten gelesen. Beim Compound Engineering muss das Festgehaltene an der Stelle liegen, wo gearbeitet wird, also im Projektverzeichnis oder direkt in den Tests. Nur dann wirkt es automatisch. Ein häufiger Irrtum besteht darin, immer mehr Regeln anzusammeln. Zu lange Regeldateien verwirren sowohl Menschen als auch KI-Modelle, deshalb gehört das Aufräumen dazu.
Wo der Begriff auftaucht
Populär gemacht hat den Ausdruck der Entwickler Kieran Klaassen vom Software-Unternehmen Every, das damit seine Arbeit mit KI-Assistenten beschrieb. Seitdem findet man ihn in Blogbeiträgen, auf Entwicklerkonferenzen und in Stellenanzeigen. Manche Firmen benutzen ihn als Schlagwort für ihre gesamte KI-Strategie.
Handfest begegnet man der Idee in Werkzeugen wie Claude Code, Cursor oder GitHub Copilot. Diese Assistenten lesen Regeldateien aus dem Projekt, oft mit Namen wie AGENTS.md oder claude.md. Genau solche Dateien sind der praktische Kern von Compound Engineering. Wer selbst programmiert, kann das im Kleinen ausprobieren: eine Datei anlegen und nach jedem gelösten Problem eine Zeile ergänzen.
In Wirtschaftsnachrichten tauchte der Begriff zuletzt im Zusammenhang mit der Frage auf, warum KI-Werkzeuge in manchen Firmen viel Zeit sparen und in anderen kaum. Die gängige Erklärung lautet: Es fehlt nicht am Modell, sondern am gesammelten Projektwissen. Skeptiker halten dem entgegen, dass hier ein alter Grundsatz guter Ingenieursarbeit einen neuen Namen bekommen hat.