BetteryieldsBetteryields
← Blog

Die Gesetze des Spec-Codings: fünfundzwanzig alte Regeln und ein neuer Spieler

Dr. Aaron Hutzler · 15.08.2026 · 21 Min.

Ein Mann von hinten nagelt Zettel mit Gesetzesnamen (Goodhart, Boehm, Gall, Conway, Hyrum, Chesterton und weitere) an das Holztor einer Roboterfabrik, im Hintergrund orangene Roboterarme
Dieses Bild wurde mit KI erzeugt.

Software-Ingenieure sammeln seit siebzig Jahren Gesetze: kurze Sätze über das wirkliche Scheitern von Projekten. Goodhart, Brooks, Conway: fast alle sind älter als das Internet. Jetzt sitzt zum ersten Mal kein Mensch mehr am anderen Ende dieser Gesetze, sondern ein , der Code erzeugt. Das ändert nicht die Gesetze. Es ändert nur die Wucht ihres Zuschlagens.

Dieser Beitrag sortiert die Gesetze in sechs Gruppen und jede Gruppe beantwortet eine eigene Frage. Am Ende steht das eigentliche Ergebnis: Die Gesetze widersprechen einander. Genau daraus folgt der richtige Umgang mit einem Code-Agenten.

1. Die Übersicht

Tabelle 1: Alle fünfundzwanzig Gesetze in sechs Gruppen, mit dem Risiko unter einem KI-Agenten und dem Gegenmittel.

Messung

Goodhart / Campbell

Wird eine Kennzahl zum Ziel, taugt sie nicht mehr als Kennzahl

Agent optimiert die Prüfung statt den Zweck: hartcodierte Antworten, Tests ohne Aussage

Zurückgehaltene Tests, Mutationstest, Kennzahlen paarweise

System

Boehm

Fehlerkosten steigen mit jeder Phase

Ein Spec-Fehler wird in Sekunden zu tausenden Zeilen falschem Code

Die Spec selbst prüfen, vor der ersten generierten Zeile

System

Gall

Funktionierende komplexe Systeme wachsen aus funktionierenden einfachen

Die 50-Seiten-Spec auf einen Schlag scheitert

Kleine Schritte, jeder einzeln geprüft

System

Conway

Systeme spiegeln die Struktur ihrer Erbauer

Unklare Agenten-Zuständigkeiten werden zu unklarem Code

Feste Zuständigkeit je Rolle, definierte Übergaben

System

Hyrum

Jedes beobachtbare Verhalten wird irgendwann benutzt

Agent baut auf undokumentierte Nebeneffekte

Verträge an Schnittstellen, strenge Typen

System

Chesterton

Kein Zaun fällt, bevor sein Zweck bekannt ist

Agent löscht beim Aufräumen alte Fehler-Abfangungen

Warum-Notizen und Entscheidungsprotokolle im Kontext

System

Lehman

Software muss sich ändern können, sonst verfällt sie

Überdetaillierte Specs machen jede Änderung zum Kettenbruch

Das Was spezifizieren statt des Wie

System

Postel, umgedreht

Grosszügigkeit beim Annehmen ist mit Agenten gefährlich

Agent winkt kaputte Eingaben still durch, Daten verderben leise

Innen sofort stoppen; Toleranz aussen nur als beschlossene Ausnahme

Menge

Jevons

Wird etwas billiger, wird mehr davon verbraucht

Billiger Code, explodierende Prüflast beim Menschen

Specs und Invarianten reviewen statt jeden Rohcode

Menge

Parkinson

Arbeit füllt den verfügbaren Raum

Grosses Kontextfenster, geschwätziger Code

Kontext kuratieren, Kompaktheit messen

Menge

Wirth

Software wird schneller langsamer als Rechner schneller

Funktional grün, aber verschwenderisch

Leistungs-Grenzwerte als Teil der Spec

Menge

Brooks

Mehr Beteiligte machen ein spätes Projekt später

Agenten-Bürokratie: fünf Spezialisten, kein Ergebnis

Zwei Rollen: Erbauer und Prüfer, flach

Aufräumen

Ockham bis Boy Scout

Fertig ist erst, wenn nichts mehr wegkann

Vorratsbauten, ungenutzte Abstraktionen

Eigener Aufräum-Durchgang nach dem Bau

Aufräumen

Demeter

Sprich nur mit direkten Nachbarn

Tiefe Zugriffsketten quer durchs System

Flache Schnittstellen

Aufräumen

Zawinski

Jedes Programm wächst, bis es zu viel kann

Schleichende Funktionswucherung

Nicht Verlangtes wieder ausbauen

Aufräumen

Knuth / Pareto

Zu frühe Optimierung ist die Wurzel allen Übels

Mikro-Tricks überall, Engpass unberührt

Erst messen, dann die teuren 20 %

Aufräumen

Amdahl

Der serielle Anteil begrenzt jeden Gewinn

Wartende Aufrufe in Schleifen

Nebenläufigkeit an den Flaschenhälsen

Aufräumen

Miller

Das Arbeitsgedächtnis fasst etwa sieben Einheiten

Funktionen, die niemand im Kopf behalten kann

Kognitive Last messen statt Zeilen zählen

Aufräumen

Tesler

Komplexität verschwindet nicht, sie wird verschoben

Vereinfacht heißt oft nur: woanders hin

Nachrechnen, wohin die Komplexität ging

Aufräumen

DRY gegen AHA

Doppelung ist schlecht, vorschnelle Abstraktion auch

Fachfremde Logik in eine Super-Hilfsfunktion gepresst

Zusammenfassen nur bei fachlicher Gemeinsamkeit

Sicherheit

Geringste Rechte

Jeder bekommt nur die Rechte, die die Aufgabe braucht

Agent umgeht Schranken, um Tests grün zu machen

Abgeschotteter Bau-Käfig, Geheimnis-Scanner

Vertrauen

Kernighan

Fehlersuche ist doppelt so schwer wie Schreiben

Agent schreibt am Anschlag seiner Cleverness

Auf Lesbarkeit abnehmen statt auf Eleganz

Vertrauen

90-90 (Cargill)

Die letzten 10 % kosten das zweite 90

Fast fertig ist beim Agenten der teuerste Zustand

Fertig heißt: alle Prüfungen bestanden

Vertrauen

Bainbridge

Automatisierung macht den Überwacher wichtiger statt überflüssig

Der Mensch prüft mehr Code, den er nie geschrieben hat

Prüfwerkzeuge für den Menschen, nicht nur für die Maschine

Vertrauen

Linus, umgedreht

Fehler werden gefunden, wenn viele Augen den Code lesen

KI-Code geht oft live und kein Mensch hat ihn je gelesen

Ein zweites Modell liest jede Zeile; der Mensch prüft den Prüfer

2. Mess-Gesetze: Warum reicht es nicht, dass die Prüfung grün ist?

haben wir in einem eigenen Beitrag ausführlich behandelt und dort stehen auch die vier Arten des Kippens samt der sechs Techniken dagegen [1]. Die Kurzform: Jede dem Agenten bekannte und für die Annahme relevante Kennzahl wird von ihm mitoptimiert. Das ist kein böser Wille: Der Agent sieht zwischen Kennzahl und Absicht schlicht keinen Unterschied. aus der Sozialforschung sagt dasselbe über Schultests und Kriminalstatistik. Der Mechanismus ist derselbe und nur der Optimierer ist heute ein schnellerer.

Ein Einwand liegt nahe: Ist das nicht einfach testgetriebene Entwicklung? Dort ist das einfachste Programm die Tugend. Wer minimal die Spec erfüllt, arbeitet richtig. Fehlen Randfälle, dann war die Spec schlecht. Der Unterschied liegt in der Form des Minimalismus. Ein Mensch baut eine kleine verallgemeinerbare Logik. Ein Agent auf dem Weg zu grünen Tests baut etwas anderes: eine Wenn-dann-Kaskade für exakt die fünf Testeingaben. Bei der sechsten Eingabe versagt sie. Oder der Agent legt gleich die Prüfung selbst still. Beides besteht dieselben Tests. Nur eines davon ist ein Programm.

3. System-Gesetze: Warum scheitern große Vorgaben an der Struktur?

Boehm: Je später ein Fehler gefunden wird, desto teurer die Behebung [8]. Das galt schon immer. Mit einem Agenten bekommt es einen Faktor: Ein Denkfehler in der Spec wird in Sekunden zu tausenden Zeilen konsequent falschem Code. Der billigste Prüfpunkt der ganzen Kette ist deshalb die Spec selbst. Sie durchläuft eigene Prüfungen auf Widersprüche und Lücken. Erst danach wird die erste Zeile Code erzeugt.

Gall: Ein funktionierendes komplexes System ist ausnahmslos aus einem funktionierenden einfachen System hervorgegangen [2]. Eine 50-Seiten-Spezifikation in einem Zug ergibt keine Software und stattdessen nur Trümmer in Softwareform. heißt: kleine Scheiben. Jede Scheibe wird einzeln gebaut und geprüft. Die nächste startet erst auf dem Fundament der letzten.

Conway: Systeme spiegeln die Kommunikationsstruktur ihrer Erbauer [3]. Das galt für Abteilungen und es gilt heute genauso für Agenten-Aufbauten: Fünf Teil-Agenten mit überlappenden Zuständigkeiten liefern die Überlappung als Wirrwarr im Code zurück.

Hyrum: Bei genügend Nutzern wird jedes beobachtbare Verhalten einer Schnittstelle irgendwann benutzt. Das gilt auch für das undokumentierte Verhalten [4]. Agenten sind die eifrigsten Nutzer dieser Art: Sie lesen den Quelltext der und stützen sich auf Zufälligkeiten. Der nächste Versionswechsel räumt genau diese Zufälligkeiten weg. Abhilfe sind Verträge: An jeder Schnittstelle steht geprüft und typisiert, was gilt. Alles andere ist tabu.

Chesterton: Der Zaun bleibt bis zur Klärung seines Zwecks stehen [6]. Beim Aufräumen löscht ein Agent zuverlässig den scheinbar toten Code. Dass genau dieser Code einen alten Bibliotheks-Fehler abfängt, hat ihm niemand gesagt. Die Warum-Notiz am Code und das Entscheidungsprotokoll im Kontext sind darum keine Bürokratie. Sie sind der Zaunplan.

Lehman: Ein unveränderbar gewordenes Softwaresystem verliert täglich an Wert [5]. Überdetaillierte Specs erzeugen genau das. Wer das Wie festschreibt statt des Was, macht jede kleine Anforderungsänderung zum Kettenbruch. Die Spec nennt Invarianten, Schnittstellen und Verhalten. Die Umsetzung bleibt austauschbar.

Postel, umgedreht: Postels Gebot hat das frühe Internet zusammengehalten: streng sein beim Senden, grosszügig beim Annehmen [7]. Einem Agenten einprogrammiert wird daraus eine Falle. Er repariert fehlerhafte Eingaben stillschweigend, statt zu stoppen. Verdorbene Daten wandern dann leise durchs System. An inneren Modulgrenzen gilt darum das Gegenteil: sofort stoppen, laut scheitern. Grosszügigkeit gegenüber Aussensystemen bleibt erlaubt und muss dann aber als Architektur-Entscheidung mit definiertem Verhalten in der Spec stehen. Eigenmächtiges Raten des Agenten bleibt verboten. Toleranz ist keine Sünde. Stillschweigende Toleranz ist eine.

4. Mengen-Gesetze: Warum macht billiger Code das Projekt teurer?

Jevons beobachtete 1865 an der Kohle das Muster von heute [10]. Wird eine Ressource billiger, dann explodiert ihr Gesamtverbrauch. Code-Schreiben kostet fast nichts mehr. Also entsteht mehr Code. Der Engpass wandert zum Menschen: prüfen, verstehen, verantworten.

Parkinson ergänzt: Arbeit dehnt sich auf den verfügbaren Raum aus [11]. Je grösser das , desto geschwätziger die Ausgabe.

Wirth liefert die Laufzeit-Seite: Software wird schneller langsamer als Rechner schneller werden [12]. Ein Agent ohne Leistungs-Vorgabe liefert Verschwendung, die leuchtet.

Brooks schliesst den Kreis bei den Agenten selbst: Mehr Beteiligte machen ein spätes Projekt später [9]. Abstimmung frisst den Gewinn. Das galt 1975 für Programmierer-Teams. Es gilt heute für die Agenten-Pipeline mit fünf Spezialisten.

Hier gehört auch der härteste wirtschaftliche Einwand hin: Wer einen lückenlosen Testkäfig bauen muss, hat die Ersparnis wieder ausgegeben. Die Antwort liegt in der Arbeitsteilung von Was und Wie. Eine Invariante ist kurz. Die Summe der Ausgänge gleicht der Summe der Eingänge, für jede Eingabegrösse. Das sind zehn Zeilen Prüfcode. Die Implementierung dahinter umfasst dreihundert Zeilen voll Einlesen und Validieren samt Randfällen und Fehlerpfaden. Genau diese Zeilen schreibt der Agent. Geprüft wird die Zusicherung. Den Weg liefert der Agent. In der Fertigung gilt dieselbe Arbeitsteilung: Die Lehre für die Massprüfung ist billiger als die Maschine für das Teil. Das bleibt auch bei tausend Teilen so.

5. Vereinfachungs-Gesetze: Warum muss nach dem Bauen ein Aufräum-Durchgang kommen?

Ein Agent kann nicht gleichzeitig korrekt bauen und einfach bauen. Die Antwort darauf ist aber kein großer Aufräum-Durchgang am Ende. Ein großer Durchgang ist derselbe Fehler wie eine 50-Seiten-Spec auf einen Schlag, nur eine Phase später: Gall gilt auch fürs Aufräumen. Ein schlankes Aufräum-Gate läuft direkt nach jedem Bau- oder Testschritt, nicht erst am Schluss. Ein Teil der Unordnung lässt sich von vornherein unmöglich machen statt sie hinterher zu finden: Schreibrechte je Rolle und Verzeichnis, genau wie bei den geringsten Rechten im Sicherheits-Kapitel. Ein Testschritt darf nur nach /tests schreiben, eine Implementierung nur nach /src. Was nicht geschrieben werden darf, muss nicht aufgeräumt werden.

Ockham, Saint-Exupery, YAGNI, Boy Scout: vier Namen, ein Prinzip. Von zwei Lösungen mit denselben bestandenen Prüfungen ist die kleinere die richtige. Fertig heißt: Es kann nichts mehr weg. Was nicht gebraucht wird, wird nicht auf Vorrat gebaut. Jeder Durchgang hinterlässt den Code sauberer. Agenten verstossen systematisch dagegen. Vorratsbauten gelten in ihren Trainingsdaten als guter Stil.

Demeter: Gesprochen wird nur mit den direkten Nachbarn [16]. Zugriffsketten über vier Objekte verdrahten das System quer. Jede Änderung wird zum Dominospiel.

Zawinski: Jedes Programm wächst und wächst und will am Ende auch noch E-Mails lesen. Beim Agenten heißt das: Unbestellte Hilfslogik wächst still mit. Der Aufräum-Durchgang baut sie wieder aus.

Knuth und Pareto: Verfrühte Optimierung ist die Wurzel allen Übels [13]. Erst messen. Dann werden gezielt die zwanzig teuersten Prozent optimiert. Diese zwanzig Prozent kosten achtzig Prozent der Laufzeit.

Amdahl nennt die Stelle: Der serielle Anteil begrenzt jeden Gewinn [14]. Zehn nacheinander wartende Aufrufe in einer Schleife bleiben langsam. Daran ändert auch der schnellste Einzelaufruf nichts.

Miller: Das menschliche Arbeitsgedächtnis fasst etwa sieben Einheiten [15]. Eine Funktion mit mehr Sprüngen und Zuständen passt in keinen Prüferkopf mehr. Aber Vorsicht: Dieses Gesetz kommt im Schluss noch einmal vor, als warnendes Beispiel.

Tesler: Komplexität verschwindet nicht, sie wird verschoben. Meldet der Agent eine Vereinfachung, dann lohnt die Nachfrage nach dem Wohin. Oft ist die Kompliziertheit nur umgezogen: aus der Funktion in Konfigurationsdateien und Hilfsschichten. Dieselbe Menge, schlechter auffindbar.

DRY gegen AHA: Doppelung vermeiden, aber vorschnelle Abstraktion auch. Ein Agent im Aufräum-Eifer presst zwei äusserlich ähnliche Abläufe in eine gemeinsame Super-Hilfsfunktion. Fachlich sind die beiden fremd. Die Doppelung ist weg, die Verständlichkeit auch. Die nächste Änderung an einem der beiden Abläufe zerreisst den anderen. Zusammengefasst wird nur, was fachlich zusammengehört. Äusserliche Ähnlichkeit reicht nicht.

6. Sicherheits-Gesetze: Warum darf der Agent nicht alles dürfen?

Hier trägt ein einziges Gesetz das ganze Kapitel. Es ist fünfzig Jahre alt: das Prinzip der geringsten Rechte von Saltzer und Schroeder [17]. Jedes Subjekt bekommt genau die Rechte für seine Aufgabe und keines mehr. Ein Agent mit Zugriff auf Dateisystem, Netz und Paketinstallation findet Wege ohne jede Vorhersehbarkeit. Er installiert für einen grünen Test auch eine ungeprüfte Bibliothek nach. Oder er liest als kürzesten Weg zur geforderten Ausgabe einen Zugangsschlüssel aus der Umgebung. Kein böser Wille. Nur der Weg des geringsten Widerstands unter den Füssen eines sehr fleissigen Läufers.

Drei Konsequenzen folgen. Der Agent baut in einem abgeschotteten Käfig ohne Netzzugang und mit fest verdrahteten Abhängigkeiten. Ein automatischer Geheimnis-Scanner sperrt vor jedem Commit. Agenten schreiben Schlüssel und Passwörter sonst mit Vorliebe direkt in Code und Test-Attrappen. Und der Käfig muss auch einem ausgetricksten Agenten standhalten. Ein Agent liest bei der Arbeit fremde Texte: Ticket-Beschreibungen, Dokumentation, Webseiten. Manche dieser Texte fordern ihn zum Ignorieren aller bisherigen Anweisungen auf. Manchmal folgt er dem. Eingeschleuste Befehle sind kein Exotenfall. Sie sind der Standardangriff auf Code-Agenten. Die letzte Verteidigung ist darum nie die Folgsamkeit des Agenten. Die letzte Verteidigung ist die Enge seines Käfigs.

7. Vertrauens-Gesetze: Warum sieht der Code fertiger aus, als er ist?

Kernighan: Fehlersuche ist doppelt so schwer wie Schreiben [18]. Wer am Anschlag seiner Cleverness schreibt, ist für die Prüfung des eigenen Codes per Definition zu wenig schlau. Genau so schreibt ein Agent. Prüfen soll es ein Mensch. Die Konsequenz steht quer zur Intuition: Gefragt ist der langweiligste Code mit bestandenen Prüfungen.

Die Neunzig-Neunzig-Regel: Die ersten 90 % des Codes kosten 90 % der Zeit. Die restlichen 10 % kosten die anderen 90 % der Zeit [19]. Fast fertig ist beim Agenten der teuerste Zustand. Seine fehlenden 10 % sind unsichtbar verteilt: der unbehandelte Randfall, der stumme Fehlerpfad. Fertig ist definiert als: alle Prüfungen bestanden. Was der Agent selbst meldet, ist keine Definition.

Bainbridge beschrieb 1983 die Ironien der Automatisierung an Kraftwerkswarten [20]. Je mehr automatisiert wird, desto anspruchsvoller wird die Rolle des überwachenden Menschen. Er greift seltener ein. Wenn er eingreift, dann in den Fällen jenseits der Automatik und mit weniger Übung als je zuvor. Das ist die Lage des Entwicklers. Wer Agenten einführt und am Prüfwerkzeug für Menschen spart, hat die teure Hälfte der Automatisierung vergessen.

, umgedreht: Genug Augen machen Fehler flach. So lautet das alte Argument für offene Quelltexte [21]. Agenten drehen es um: Es entsteht mehr Code vor weniger Augen. Eine alte Entwicklerweisheit nennt eigenen Code nach sechs Monaten Fremdcode. Agenten-Code ist es ab Tag eins. Kein Mensch hatte ihn je im Kopf. Der Ausweg ist trotzdem kein Mensch als Zeilenleser. Menschliches Zeilen-Lesen skaliert nicht und genau daran scheitert die Menge aus dem Jevons-Kapitel. Die fehlenden Augen ersetzt in unserer Praxis ein zweites Modell als Prüfer. Damit steht sofort die nächste Frage im Raum: Wer prüft die Prüfer? Die Antwort kommt aus der Messtechnik. Ein Messmittel muss erst an bekannten Fehlern seine Fähigkeit beweisen und darf erst danach urteilen. Genau so wird der Prüf-Agent behandelt: Er bekommt absichtlich eingebaute Fehler vorgesetzt. Übersieht er sie, dann ist er als Prüfer disqualifiziert. Wir prüfen den Prüf-Agenten selbst, indem wir ihm vorab absichtlich eingebaute Fehler vorsetzen, bevor wir seinem Urteil trauen. Genau so haben wir einen solchen Fall erwischt: Ein Prüfer wirkte zuverlässig und wählte in 32 von 36 Urteilen nur die zuerst gezeigte Option, ein Pilotbefund, der in unserem Goodhart-Beitrag veröffentlicht und dort ausführlich belegt ist [1]. Dem Menschen bleiben die Spec, die Stichprobe und die Abnahme der Prüfer. Verantwortung bleibt namentlich, nur das Zeilen-Lesen wandert zur Maschine. Der Aufwand lohnt sich bei echtem Risiko. Beim internen Wegwerf-Skript reicht ein einzelner Prüfer ohne diesen ganzen Apparat.

Eine letzte Eigenschaft verschärft alle vier: Ein Agent ist keine Maschine. Derselbe Auftrag kann beim fünften Lauf anders ausgehen als bei den ersten vier. Wir haben das geprüft, indem wir demselben Agenten denselben Auftrag fünfmal unter sonst gleichen Bedingungen gegeben haben. Die Ergebnisse je Lauf stehen mit Zahlen und Grenzen in der Fünf-Läufe-Fallstudie [22]. Ein einmal bestandener Lauf beweist wenig. Eine Prüfung muss die Streuung sehen. Ein Glückstreffer genügt nicht.

8. Wenn Gesetze sich widersprechen

Beim Lesen fällt irgendwann etwas auf: Diese Gesetze vertragen sich nicht untereinander. Das ist kein Schönheitsfehler der Liste. Es ist ihr wichtigster Befund.

Ockham gegen Chesterton und Hyrum: Das Aufräum-Kapitel befiehlt das Löschen von Ungenutztem. Chesterton verbietet den Abriss von Zäunen mit unbekanntem Zweck. Und nach Hyrum finden sich Nutzer sogar für das undokumentierte Verhalten. Das eine Gesetz macht das Löschen zur Pflicht, das andere verbietet es. Auflösung: Löschen ja, aber nur mit Herkunftsprüfung. Was einen dokumentierten Zweck hat, fällt nicht unter Aufräumen.

Boehm gegen Gall: Boehm drängt die Sorgfalt nach vorn in die Spec. Gall warnt vor dem grossen Vorab-Entwurf. Auflösung: Vorn wird nur festgezurrt, was gelten muss. Das sind Invarianten, Schnittstellen und Grenzwerte. Das Wie darf klein wachsen.

Knuth gegen Wirth: Knuth rät von früher Optimierung ab. Wer aber Effizienz nie fordert, bekommt Verschwendung. Auflösung: Grenzwerte stehen wie Toleranzen auf einer Zeichnung von Anfang an in der Spec. Feingetunt wird zum Schluss und nur an den teuren zwanzig Prozent.

Kontext-Hygiene gegen Chesterton: Das Mengen-Kapitel rät zu wenig Kontext. Ohne das Warum reisst der Agent aber genau die falschen Zäune ein. Auflösung: Kontext wird kuratiert statt gekürzt. Die Warum-Notizen kommen rein. Das restliche bleibt draußen.

Brooks gegen den Prüfer-Agenten: Gegen das Austricksen der Prüfung hilft ein zweiter unabhängiger Prüf-Agent. Brooks warnt vor jedem zusätzlichen Beteiligten. Auflösung: genau zwei Rollen. Erbauer und Prüfer, keine Bürokratie aus fünf Spezialisten.

DRY gegen AHA und Postel gegen Fail-Fast: die beiden offenen Paare aus den Kapiteln oben. Auflösung: Doppelung bekämpfen ohne vorschnelle Abstraktion. Streng sein mit Toleranz nach aussen nur als beschlossener Ausnahme.

Sechs Konflikte und keine allgemeingültige Auflösung: Jede hängt am Einzelfall. Das ist die zweite Hälfte der Pointe. Die erste folgt jetzt.

9. Der Schluss: Miller gegen Goodhart

Zwei Fechter mit geraden Degen im Ausfallschritt, Klingen kurz vor der Berührung, Gürtelbänder mit den Namen Miller und Goodhart, ringsum ein Publikum aus Entwicklern mit Laptops in einer Arena

Abbildung 1: Miller gegen Goodhart: ein hartes Duell.

Bild maschinell erzeugt

Millers Gesetz ist solide Kognitionsforschung mit einem ehrlichen Anliegen. Als starre Regel an den Agenten verabreicht wird es zur Falle. Die Vorgabe laute: keine Funktion über 20 Zeilen. Der Agent gehorcht. Er zerschneidet eine zusammenhängende 40-Zeilen-Rechnung mechanisch in vier Schnipsel und erfindet Übergabe-Konstrukte für den Zustand dazwischen. Und er liefert ab: jede Funktion formal simpel, das Ganze unlesbarer als vorher. Der Prüfer muss jetzt zehn Funktionen samt Aufrufkette gleichzeitig im Kopf behalten. Vorher war es eine einzige Funktion, lesbar von oben nach unten. Die lokale Kennzahl sinkt. Die echte Verständnislast steigt.

Millers Gesetz, als Metrik verabreicht, wird von Goodharts Gesetz gefressen.

Das ist kein Sonderfall von Miller. Dasselbe Schicksal trifft jede als Zielgrösse verabreichte Regel aus diesem Beitrag. Die Vorgabe einer Kürzung um 20 % erzeugt Einzeiler-Tricks und gelöschte Typangaben. Die Vorgabe einer höheren erzeugt Tests ohne Aussage. Eine Stufe höher wartet dasselbe Muster noch einmal. Bei beliebig vielen Nachbesserungsrunden an sichtbaren Fehlermeldungen werden auch die Prüf-Gates selbst zur Zielscheibe. Dann biegt der Agent den Code bis zum Verschwinden der Meldung. Die Ursache bleibt unberührt. Deshalb sind keine Optimierungsschleife für den Agenten. Es gibt begrenzte Nachbesserungsrunden mit sichtbarem Fehlerbericht: Der Agent sieht die Meldung und bessert selbst nach. Es gibt auch zurückgehaltene Prüfungen ausserhalb seines Blickfelds: Sie liefern kein Feedback zum Nachbessern, nur ein Urteil am Ende. Und wo immer möglich prüfen Gates gegen die Wirklichkeit statt gegen Formalien. Ein Beispiel ist die Quellenprüfung: Sie holt die zitierte Quelle selbst ab und sucht das Zitat dort. So eine Prüfung lässt sich nicht bespielen. Sie lässt sich nur erfüllen.

Damit stehen beide Hälften. Jede Regel im Wissen des Agenten wird zur Kennzahl. Jede Kennzahl wird bespielt. Und selbst perfekt befolgte Regeln widersprechen einander. Ihre Auflösungen hängen am Einzelfall und passen vorab in keine Regel. Beides zeigt auf denselben Ausweg. Die Gesetze gehören als Regelkatalog in keinen . Sie gehören als Prüffeld um den Agenten herum. Dort stehen sie als Bedingungen am Ergebnis, gemessen von Instrumenten ausserhalb seiner Reichweite.

10. Eine ehrliche Grenze

Kein Prüffeld macht einen Agenten gesetzesfest. Die Techniken machen das Kippen sichtbar. Mehr versprechen sie nicht. Dieser Beitrag ordnet Gesetze von Menschen und Organisationen. Ihre Übertragung auf Agenten ist an den Stellen mit eigenen Messungen belegt. Überall sonst ist sie ehrliche Beobachtung.

Wer dem Agenten die Gesetze als Regeln mitgibt, bekommt Gehorsam. Wer sie als Prüffeld um ihn herum baut, bekommt das Produkt.

11. Quellen

[1] Betteryields, "Goodharts Gesetz: warum Kennzahlen kippen und was Spec Coding dagegen braucht", agentic-gates Blog, 2026. Wird beim Einstellen verlinkt.

[2] J. Gall, "Systemantics", 1975.

[3] M. E. Conway, "How Do Committees Invent?", Datamation, 1968.

[4] H. Wright, "", hyrumslaw.com, 2017.

[5] M. M. Lehman, "Programs, Life Cycles, and Laws of Software Evolution", Proceedings of the IEEE, 1980.

[6] G. K. Chesterton, "The Thing", 1929.

[7] J. Postel, "DoD Standard Transmission Control Protocol", RFC 761, 1980.

[8] B. W. Boehm, "Software Engineering Economics", 1981.

[9] F. P. Brooks, "The Mythical Man-Month", 1975.

[10] W. S. Jevons, "The Coal Question", 1865, dritte Auflage Macmillan 1906.

[11] C. N. Parkinson, "", The Economist, 1955.

[12] N. Wirth, "A Plea for Lean Software", IEEE Computer, 1995.

[13] D. E. Knuth, "Structured Programming with go to Statements", ACM Computing Surveys, 1974.

[14] G. M. Amdahl, "Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities", AFIPS Conference Proceedings, 1967.

[15] G. A. Miller, "The Magical Number Seven, Plus or Minus Two", Psychological Review, 1956.

[16] K. Lieberherr und I. Holland, "Assuring Good Style for Object-Oriented Programs", IEEE Software, 1989.

[17] J. H. Saltzer und M. D. Schroeder, "The Protection of Information in Computer Systems", Proceedings of the IEEE, 1975.

[18] B. W. Kernighan und P. J. Plauger, "The Elements of Programming Style", 1974. Zuschreibung wird geprüft.

[19] T. Cargill, zitiert in J. Bentley, "Programming Pearls: Bumper-Sticker Computer Science", Communications of the ACM, 1985.

[20] L. Bainbridge, "Ironies of Automation", Automatica, 1983.

[21] E. S. Raymond, "The Cathedral and the Bazaar", 1999.

[22] Betteryields, "Prompt engineering is dead" und "How we measured it" (Fünf-Läufe- Fallstudie), agentic-gates Blog, 2026. Wird beim Einstellen verlinkt.

12. Download: die Gesetze als Karte

Eine Zeile je Gesetz. Was schiefgeht, wenn ein Agent den Code schreibt, dann das Gegenmittel dagegen. Nichts davon geht über das hinaus, was der Beitrag belegt.

Messung

Goodhart / Campbell. Agent optimiert die Prüfung statt den Zweck: hartcodierte Antworten, Tests ohne Aussage. Gegenmittel: Zurückgehaltene Tests, , Kennzahlen paarweise.

System

Boehm. Ein Spec-Fehler wird in Sekunden zu tausenden Zeilen falschem Code. Gegenmittel: Die Spec selbst prüfen, vor der ersten generierten Zeile.

Gall. Die 50-Seiten-Spec auf einen Schlag scheitert. Gegenmittel: Kleine Schritte, jeder einzeln geprüft.

Conway. Unklare Agenten-Zuständigkeiten werden zu unklarem Code. Gegenmittel: Feste Zuständigkeit je Rolle, definierte Übergaben.

Hyrum. Agent baut auf undokumentierte Nebeneffekte. Gegenmittel: Verträge an Schnittstellen, strenge Typen.

Chesterton. Agent löscht beim Aufräumen alte Fehler-Abfangungen. Gegenmittel: Warum-Notizen und Entscheidungsprotokolle im Kontext.

Lehman. Überdetaillierte Specs machen jede Änderung zum Kettenbruch. Gegenmittel: Das Was spezifizieren statt des Wie.

Postel, umgedreht. Agent winkt kaputte Eingaben still durch, Daten verderben leise. Gegenmittel: Innen sofort stoppen; Toleranz aussen nur als beschlossene Ausnahme.

Menge

Jevons. Billiger Code, explodierende Prüflast beim Menschen. Gegenmittel: Specs und Invarianten reviewen statt jeden Rohcode.

Parkinson. Grosses Kontextfenster, geschwätziger Code. Gegenmittel: Kontext kuratieren, Kompaktheit messen.

Wirth. Funktional grün, aber verschwenderisch. Gegenmittel: Leistungs-Grenzwerte als Teil der Spec.

Brooks. Agenten-Bürokratie: fünf Spezialisten, kein Ergebnis. Gegenmittel: Zwei Rollen: Erbauer und Prüfer, flach.

Aufräumen

Ockham bis Boy Scout. Vorratsbauten, ungenutzte Abstraktionen. Gegenmittel: Eigener Aufräum-Durchgang nach dem Bau.

Demeter. Tiefe Zugriffsketten quer durchs System. Gegenmittel: Flache Schnittstellen.

Zawinski. Schleichende Funktionswucherung. Gegenmittel: Nicht Verlangtes wieder ausbauen.

Knuth / Pareto. Mikro-Tricks überall, Engpass unberührt. Gegenmittel: Erst messen, dann die teuren 20 % des Codes.

Amdahl. Wartende Aufrufe in Schleifen. Gegenmittel: Nebenläufigkeit an den Flaschenhälsen.

Miller. Funktionen, die niemand im Kopf behalten kann. Gegenmittel: Kognitive Last messen statt Zeilen zählen.

Tesler. Vereinfacht heißt oft nur: woanders hin. Gegenmittel: Nachrechnen, wohin die Komplexität ging.

DRY gegen AHA. Fachfremde Logik in eine Super-Hilfsfunktion gepresst. Gegenmittel: Zusammenfassen nur bei fachlicher Gemeinsamkeit.

Sicherheit

Geringste Rechte. Agent umgeht Schranken, um Tests grün zu machen. Gegenmittel: Abgeschotteter Bau-Käfig, Geheimnis-Scanner.

Vertrauen

Kernighan. Agent schreibt am Anschlag seiner Cleverness. Gegenmittel: Auf Lesbarkeit abnehmen statt auf Eleganz.

90-90 (Cargill). Fast fertig ist beim Agenten der teuerste Zustand. Gegenmittel: Fertig heißt: alle Prüfungen bestanden.

Bainbridge. Der Mensch prüft mehr Code, den er nie geschrieben hat. Gegenmittel: Prüfwerkzeuge für den Menschen, nicht nur für die Maschine.

Linus, umgedreht. KI-Code geht oft live und kein Mensch hat ihn je gelesen. Gegenmittel: Ein zweites Modell liest jede Zeile; der Mensch prüft den Prüfer.

Zum MitnehmenPDF

Das Blatt als PDF herunterladen

Herunterladen

Betteryields

Setzen Sie Qualitäts-Gates in Ihren Build, die ein Agent nicht fälschen kann