Die Gesetze des Spec-Codings: fünfundzwanzig alte Regeln und ein neuer Spieler
Dr. Aaron Hutzler · 15.08.2026 · 21 Min.

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.
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
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
Gall
Funktionierende komplexe Systeme wachsen aus funktionierenden einfachen
Die 50-Seiten-Spec auf einen Schlag scheitert
Kleine Schritte, jeder einzeln geprüft
Conway
Systeme spiegeln die Struktur ihrer Erbauer
Unklare Agenten-Zuständigkeiten werden zu unklarem Code
Feste Zuständigkeit je Rolle, definierte Übergaben
Hyrum
Jedes beobachtbare Verhalten wird irgendwann benutzt
Agent baut auf undokumentierte Nebeneffekte
Verträge an Schnittstellen, strenge Typen
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
Lehman
Software muss sich ändern können, sonst verfällt sie
Überdetaillierte Specs machen jede Änderung zum Kettenbruch
Das Was spezifizieren statt des Wie
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
Jevons
Wird etwas billiger, wird mehr davon verbraucht
Billiger Code, explodierende Prüflast beim Menschen
Specs und Invarianten reviewen statt jeden Rohcode
Parkinson
Arbeit füllt den verfügbaren Raum
Grosses Kontextfenster, geschwätziger Code
Kontext kuratieren, Kompaktheit messen
Wirth
Software wird schneller langsamer als Rechner schneller
Funktional grün, aber verschwenderisch
Leistungs-Grenzwerte als Teil der Spec
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
Ockham bis Boy Scout
Fertig ist erst, wenn nichts mehr wegkann
Vorratsbauten, ungenutzte Abstraktionen
Eigener Aufräum-Durchgang nach dem Bau
Demeter
Sprich nur mit direkten Nachbarn
Tiefe Zugriffsketten quer durchs System
Flache Schnittstellen
Zawinski
Jedes Programm wächst, bis es zu viel kann
Schleichende Funktionswucherung
Nicht Verlangtes wieder ausbauen
Knuth / Pareto
Zu frühe Optimierung ist die Wurzel allen Übels
Mikro-Tricks überall, Engpass unberührt
Erst messen, dann die teuren 20 %
Amdahl
Der serielle Anteil begrenzt jeden Gewinn
Wartende Aufrufe in Schleifen
Nebenläufigkeit an den Flaschenhälsen
Miller
Das Arbeitsgedächtnis fasst etwa sieben Einheiten
Funktionen, die niemand im Kopf behalten kann
Kognitive Last messen statt Zeilen zählen
Tesler
Komplexität verschwindet nicht, sie wird verschoben
Vereinfacht heißt oft nur: woanders hin
Nachrechnen, wohin die Komplexität ging
DRY gegen AHA
Doppelung ist schlecht, vorschnelle Abstraktion auch
Fachfremde Logik in eine Super-Hilfsfunktion gepresst
Zusammenfassen nur bei fachlicher Gemeinsamkeit
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
Kernighan
Fehlersuche ist doppelt so schwer wie Schreiben
Agent schreibt am Anschlag seiner Cleverness
Auf Lesbarkeit abnehmen statt auf Eleganz
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
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
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

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.
Das Blatt als PDF herunterladen
HerunterladenBetteryields
Setzen Sie Qualitäts-Gates in Ihren Build, die ein Agent nicht fälschen kann
