Zwei Uhr morgens. Sie starren auf die Zeile if is_premium and not is_trial and billing_cycle == 'annual' im Diff, der Cursor schwebt über dem »Request Changes«-Button, ohne dass Sie ihn drücken können. Der Titel des Pull Requests lautet »Rabattberechnungslogik von customer und broker zusammenführen«. Die beiden Codeblöcke sehen sich tatsächlich sehr ähnlich — einen Datensatz laden, ein Prozentfeld aktualisieren, in die Datenbank zurückschreiben. Ein Ingenieur hat diese »Duplizierung« entdeckt und eine einheitliche Methode mit einem entity_type-Parameter extrahiert. Das sieht sauber, vernünftig und DRY aus.
Aber Sie wissen, dass der customer-Rabatt morgen auf eine Staffelpreisberechnung umgestellt wird, während sich die broker-Provision in den nächsten zwei Jahren nicht ändern wird. Wenn man jetzt die Zusammenführung erzwingt, beseitigt man zwar eine scheinbare Duplizierung, schweißt aber zwei Konzepte mit völlig unterschiedlichen Entwicklungsrichtungen zusammen. Genau das ist die Falle, vor der Sandi Metz vor zehn Jahren gewarnt hat. Im Juni 2026 ist ihr Artikel mit 409 Punkten und 272 Kommentaren wieder an die HN-Spitze gestiegen — in einer Zeit, in der eine KI auf Knopfdruck fünfhundert Zeilen »anscheinend korrekten« Code generieren kann, verdient dieses Prinzip mehr denn je eine erneute Diskussion.
Sandi Metz hat eine Karte des Verfalls gezeichnet
Auf der RailsConf 2014 sprach Metz zum ersten Mal den Satz »duplication is far cheaper than the wrong abstraction« aus, 2016 schrieb sie ihn als Blog-Artikel nieder. Ihre Argumentation ist von entwaffnender Einfachheit, ohne Rückgriff auf irgendeinen theoretischen Rahmen — sie beschreibt lediglich einen Degenerationsprozess, den jeder erlebt, aber kaum jemand benannt hat:
Programmierer A entdeckt duplizierten Code. Er extrahiert eine gemeinsame Methode oder Klasse, ersetzt alle Duplikationsstellen und geht zufrieden weiter. Zeit vergeht, neue Anforderungen kommen, die bestehende Abstraktion ist »fast« ausreichend. Programmierer B übernimmt und beginnt, aus Respekt vor dem bestehenden Code, nicht von vorne, sondern fügt einen Parameter zur Methode hinzu, dann einen bedingten Zweig im Inneren. Dann eine dritte Anforderung, ein vierter Parameter, ein fünftes if-else. Beim achten Schritt treten Sie auf den Plan, konfrontiert mit Tausenden von Zeilen verflochtener Bedingungslogik, und versuchen zu verstehen, welche Zweige zu welchem Aufrufer gehören.
Metz’ Lösung ist ebenso einfach: Die Abstraktion zurück-inlinen, jeden Aufrufer nur den Code behalten lassen, den er wirklich braucht, und dann von vorne beobachten — welche Ähnlichkeiten sind echt, welche sind nur scheinbar.
Diese Aussage ist durchschlagend, weil sie eine quasi-religiöse Überzeugung in der Programmierer-Community zertrümmert: dass Duplizierung das Böse ist und ihre Beseitigung intrinsisch richtig.
Das historische Gepäck von DRY: Eine Fehlübersetzung von der Datenbank in die Codebasis
Das DRY-Prinzip wurde 1999 von Andy Hunt und Dave Thomas in The Pragmatic Programmer formuliert. Die ursprüngliche Formulierung lautet: »Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.« Der Schwerpunkt liegt auf »Wissen«, nicht auf »Zeichen«. Eine SQL-Abfrage, eine Geschäftsregel, ein Konfigurationswert — das ist Wissen. Zwei zufällig ähnliche for-Schleifen sind es möglicherweise nicht.
Doch die Branche hat diese Unterscheidung im Laufe der Verbreitung zunehmend komprimiert. »Wiederhole dich nicht« wurde zu »Lass keine duplizierten Codezeilen erscheinen«. Ein heuristisches Prinzip, zur harten Regel erhoben, brachte eine Unmenge von Abstraktionen hervor, die nie hätten existieren sollen: generische Repository-Basisklassen, universelle Processor-Methoden, Service-Funktionen mit Parameterlisten, die länger sind als die Geschäftslogik.
Was Metz tut, ist im Wesentlichen eine Neukalibrierung von DRY: Sie wendet sich gegen das »verfrühte DRY«. Dieser Punkt wurde in der HN-Diskussion auch wiederholt betont — »dieser Artikel sagt nicht, man solle nicht abstrahieren, er sagt, man solle Abstraktion nicht erzwingen«.
Die Ingenieurssignale einer »falschen Abstraktion«
In den HN-Kommentaren teilten zahlreiche Ingenieure ihre Kriterien zur Erkennung falscher Abstraktionen. »Macht dieser Code dasselbe, oder sieht er nur gleich aus?« — das ist das zentrale, mehrfach zitierte Kriterium. Die folgenden Signale deuten, wenn sie gehäuft auftreten, auf eine wahrscheinlich falsche Abstraktion hin:
Parametergetriebene bedingte Verzweigungen. Eine Methode erhält boolesche oder Enum-Parameter und verteilt intern auf nahezu überlappungsfreie Codepfade. Jeder neue Parameter multipliziert den Zustandsraum, den der Aufrufer verstehen muss.
Das Verhalten eines Aufrufers zu ändern, zwingt dazu, für die anderen »aufzufangen«. Das bedeutet, dass zwischen den Aufrufern keine echte Ko-Variationsbeziehung besteht. Sie führen heute nur zufällig ähnlichen Code aus.
Die Abstraktion hat keinen selbsterklärenden Existenzgrund. Eine gesunde Abstraktion kann ohne Blick auf ihre Aufrufer verstanden werden. Wenn man bei jedem Lesen den Kontext von drei Aufrufstellen nachverfolgen muss, um zu verstehen, was diese Logik tut, hat die Abstraktion ihren größten Wert verloren — die Reduzierung der kognitiven Last.
Wenn Sie eine neue Funktionalität hinzufügen, denken Sie zuerst daran, die Abstraktion zu umgehen, statt sie wiederzuverwenden. Dies ist das zuverlässigste Signal. Die menschliche Intuition erfasst strukturelle Probleme oft früher als die nachträgliche Rationalisierung.
Die Kerndebatte bei HN: Einzige Wahrheit vs. Lokalität
In der HN-Diskussion grenzten zwei hoch bewertete Kommentare präzise die Kontroverse ein.
Der Kommentar von Nutzer lg5689 vertritt das Kernargument des Lagers »Abstraktion zuerst«: »Man sollte stets dem Prinzip der einzigen Wahrheitsquelle folgen. Wenn zwei duplizierte Codestellen im Falle ihrer Divergenz einen Bug darstellen, sollte refaktorisiert werden. Duplizierung erzeugt unsichtbare weitreichende Kopplung im Code.« Diese Logik entspringt einer gesunden Ingenieursintuition: Wenn dieselbe Geschäftsregel an zwei Stellen verteilt ist, wird eines Tages jemand die eine ändern und die andere vergessen, und der Bug ist gesät.
Die Antwort von Nutzer jonahx zielt auf das Szenario, das Metz wirklich beschäftigt: »Im Kern behandelt der Artikel genau den Fall, in dem man noch nicht weiß, wie viele Wahrheitsquellen es gibt. Verwenden diese beiden Stellen denselben Algorithmus, oder leicht unterschiedliche Versionen? Und vor allem: Werden sie sich aus denselben Gründen ändern? Der entscheidende Punkt ist, dass eine falsche Abstraktion die Lokalität zerstört — und das ist tatsächlich die einzige Eigenschaft, die einen wirklich interessiert, wenn man Code ändert. Ich möchte diese eine Änderung vornehmen, ohne mir Sorgen über Seiteneffekte auf nicht verwandte Teile des Systems machen zu müssen.«
Beide Argumente haben ihre Berechtigung, aber ihre Anwendungsbereiche unterscheiden sich. Wenn Sie sicher sind, dass zwei Stellen dieselbe invariante Tatsache repräsentieren — denselben Steuersatz, denselben Verschlüsselungsalgorithmus, dieselbe Datenvalidierungsregel — dann ist Abstraktion die richtige Wahl, und der Nutzen der einzigen Wahrheitsquelle überwiegt bei weitem die Kosten der Abstraktion selbst.
Das Problem ist, dass wir in dieser Branche unsere Fähigkeit überschätzen zu »erkennen, ob zwei Codeblöcke synonym sind«. Die beiden Berechnungen in Metz’ Beispiel sehen sich sehr ähnlich: customer-Datensatz laden, Rabattprozentsatz aktualisieren; broker-Datensatz laden, Provisionsprozentsatz aktualisieren. Heute folgen sie zufällig demselben Muster »Entität laden — Prozentsatz aktualisieren«. Aber die Geschäftslogik des customer-Rabatts kann jederzeit auf eine Staffelberechnung umgestellt werden, während die broker-Provision beim einfachen Prozentsatz bleibt — weil diese beiden Felder rechtlich, vertraglich und buchhalterisch völlig unterschiedlicher Natur sind.
Die Grenze zwischen »Code, der sich ähnlich sieht« und »Code, der dieselbe Wahrheit repräsentiert« ist schwieriger zu ziehen, als die meisten Ingenieure zuzugeben bereit sind.
Wie KI-Codegenerierung dieses Problem verstärkt
Genau das ist der Grund, warum Metz’ Artikel im Zeitalter großflächiger KI-Programmierwerkzeuge wieder an die Spitze gestiegen ist.
LLMs haben zwei strukturelle Tendenzen in der Codegenerierung. Erstens neigen sie natürlicherweise dazu, »scheinbare Duplizierung zu beseitigen«. Wenn Sie zwei ähnliche Funktionsmodule mit demselben Prompt generieren, extrahiert das Modell aus seinen Trainingsdaten die »standardmäßigste« Fusionsmethode und produziert eine parametrisierte Abstraktion. Es fragt Sie nicht, wo die Geschäftsgrenze zwischen customer und broker liegt — es hat an keinen Anforderungsdiskussionen teilgenommen. Es hat lediglich im statistischen Sinne die optimale gemeinsame Repräsentation gefunden.
Zweitens, und das ist heimtückischer und gefährlicher: Die von LLMs generierten Abstraktionen sind abnorm glatt. Die Benennung ist treffend, die Einrückung korrekt, die Parameteranordnung strahlt Logik aus. Eine von einem Menschen geschriebene schlechte Abstraktion riecht oft — holprige Benennung, lockere Struktur, man spürt, wie sie sich gewaltsam anpasst. Die falsche Abstraktion des LLM wirkt professionell, selbstbewusst, unangreifbar. Der Reviewer ist eher geneigt, sie durchgehen zu lassen.
Zahlreiche HN-Kommentatoren haben diese Spannung aufgegriffen. Einer sagte, das »LLM ist eine natürliche Anti-Abstraktions-Maschine«, weil es keine Geschäftssemantik versteht, sondern nur Oberflächenmuster. Ein anderer sagte, das »LLM senkt die Kosten des Kopierens drastisch, daher muss die Begründungsschwelle für Abstraktion viel höher liegen«. Eine noch schärfere Beobachtung: »Womit ich die meiste Zeit verbringe, ist, einem LLM zu erklären, wie eine bestehende Codebasis tatsächlich funktioniert, ohne dass es sie durch Missverständnis verzerrt.«
Ein interessantes Ingenieursphänomen zeichnet sich ab: Massenhaft von KI generierter Code neigt zum Kopieren statt zum Abstrahieren. Nicht weil das Modell Metz’ Prinzip versteht — es hat keine dateiübergreifende Persistenz zwischen den Anfragen. Es weiß nicht, dass es in der vorherigen Session etwas Ähnliches geschrieben hat — es sei denn, Sie stopfen den relevanten Code ins Kontextfenster. So entstehen in KI-Produkten sowohl zahlreiche Codeblöcke, die »hätten abstrahiert werden sollen, aber nicht wurden«, als auch Blöcke, die »bereits abstrahiert wurden, aber in völlig falscher Richtung«. Beide Fehlerarten koexistieren im selben Repository — das ist vielleicht der neue Alltag, den KI den Code-Maintainern beschert.
Zwischen zwei Fehlern wählen
Metz’ Position wird oft verkürzt zu »Duplizierung ist besser als Abstraktion«, was nicht ganz fair ist. Was sie wirklich sagt, ist: Wenn Sie zwischen Duplizierung und falscher Abstraktion wählen müssen, wählen Sie Duplizierung. Dies ist ein Prinzip zweiter Ordnung — es sagt Ihnen nicht, was richtig ist, sondern, wenn Sie unsicher sind, was richtig ist, welche Fehlerrichtung billiger ist.
Ein hoch bewerteter HN-Kommentar schlägt eine praktische Handlungsregel vor — die »Dreierregel«: Erstes Vorkommen: aufschreiben. Zweites Vorkommen: Duplizierung tolerieren, aber zu beobachten beginnen. Drittes Vorkommen: Abstraktion in Betracht ziehen — und zwar nur entlang der Achse, die sich tatsächlich verändert. Diese Regel enthält eine wesentliche Voraussetzung: Es braucht Zeit, damit die echten Muster hervortreten. Erst wenn der Code eine Weile im Repository gelaufen ist, wird erkennbar, welche Aufrufstellen sich gemeinsam verändern und welche auseinanderlaufen.
Ein anderer Kommentator fasste es noch schärfer: »Das Gegenteil von DRY ist nicht Duplizierung, sondern WET — Write Everything Twice. Alles zweimal schreiben, dann beobachten. Beim dritten Mal handeln.«
Ingenieursurteil jenseits der Daten
Die HN-Abstimmungszahlen — 409 Punkte, 272 Kommentare — zeigen, dass dieses Thema eine noch offene Wunde in der Ingenieursgemeinschaft berührt. Jeder weiß, dass DRY falsch angewendet werden kann. Das Problem ist, dass neue Ingenieure Generation für Generation bei ihrer Einarbeitung immer noch eine Ausbildung erhalten, die »Duplizierung beseitigen« als nicht verhandelbare Priorität in Code-Reviews setzt.
In einer Zeit, in der eine KI regelkonformen Code für Sie schreiben kann, ist die wirklich knappe Fähigkeit nicht mehr »wie abstrahiere ich?«, sondern »wann abstrahiere ich?«. Letzteres erfordert keine Technik, sondern Geduld, ein durch kontinuierliche Beobachtung der Fachdomäne geformtes Urteilsvermögen und die Kaltblütigkeit, angesichts versunkener Kosten eine Abstraktion wieder rückgängig zu machen. Metz’ Worte hallen bis heute nach: »Angesichts einer falschen Abstraktion ist der schnellste Weg nach vorn der zurück.«
In dieser Sache gibt es keine endgültige Antwort. Ich beziehe in diesem Streit keine absolute Position. Abstraktion ist eines der wenigen wirklich fundamentalen Konzepte der Softwareentwicklung, aber ihr Wert hängt stark von Zeitpunkt und Kontext ab. Dieser Artikel wirbt nicht dafür, Abstraktion durch Duplizierung zu ersetzen. Was ich aufzeigen möchte, ist ein engeres Urteil: In diesem neuen Regime, in dem Code abwechselnd von Menschen und Maschinen produziert wird, sind die Kosten des »Wartens vor dem Abstrahieren« vielleicht viel niedriger als wir lange geglaubt haben, während die Kosten des »falsch Abstrahierten und Wieder-Rückgängigmachens« vielleicht höher sind, als wir dachten.
Erklärung des Autors: Dieser Artikel basiert auf der Analyse von Sandi Metz’ Originalartikel, der HN-Diskussion vom Juni 2026 und zugehöriger Ingenieursliteratur. Er stellt keine absolute technische Handlungsempfehlung dar. Ingenieursentscheidungen müssen den spezifischen Kontext einbeziehen — Teamgröße, Produktlebensphase, Codebasis-Alter, Testabdeckung — jede dieser Variablen kann die Richtung des hier vorgeschlagenen Urteils umkehren.