Was KI-Slopper über Software-Architektur wissen müssen | Research

Was KI-Slopper über Software-Architektur wissen müssen | Research | Tobias Weiss

„AI Slop" ist ein Wort mit einer präzisen, fast höhnischen Bedeutung und mit einer vagen. Die präzise: minderwertiger KI-generierter Inhalt. Die vage: alles — jeder Code, jeder Pull Request, jeder Bug-Report, den ein Modell berührt hat, egal ob er gut ist. Wenn Leute sagen, das Problem sei Slop, meinen sie meistens das Rauschen: eine halluzinierte API, ein Test, der umgeschrieben wurde, um kaputtes Verhalten zu akzeptieren, ein PR mit 900 Zeilen schnell bewegten Nichts.

Das Rauschen ist real, aber es ist nicht das teure Problem. Das teure Problem ist strukturell — und es ist für fast jede Prüfung, die wir ausführen, unsichtbar.

Eine Studie über 302.600 verifizierte KI-autorisierte Commits aus 6.299 Repositories fand 484.366 einzelne Befunde — und 89,3 % davon sind Code Smells, die Klasse von Defekten, die heute nichts bricht, aber die Kosten jeder morgigen Änderung erhöht. Etwa ein Viertel der nachverfolgten, KI-induzierten Befunde ist auch in der neuesten Version des Repositories noch vorhanden: nicht gefunden, nicht behoben, einfach akkumuliert (Debt Behind the AI Boom). Ein systematisches Audit von LLM- und agentengenerierter Software fand dasselbe auf architektonischer Ebene und nannte es eine „machine signature" von Defekten: Je fähiger die Modelle werden, desto aufgeblähter und stärker gekoppelter wird der generierte Code — so stark, dass die Codelänge fast perfekt die strukturelle Degradation vorhersagt (Zhu, Tsantalis & Rigby, ASE 2026). Weder funktionale Korrektheit noch detailliertes Prompting mildert den Zerfall.

Das ist die These dieses Artikels: Je mehr Code KI schreibt, desto mehr entscheidet die Architektur darüber, ob am Ende ein System oder ein Haufen steht. Slop ist in erster Linie kein Codequalitätsproblem. Es ist ein Problem der Verantwortung für Struktur — und Struktur ist genau das, was der statistische Durchschnitt, aus dem der Code entsteht, nicht liefern kann. Dieser Text destilliert eine längere Forschungsstudie, Software Architecture and Development in the Agentic Age (2026), in der die kausale Evidenz, die Fehlerbilder-Taxonomie und die Referenzarchitektur hinter diesen Behauptungen vollständig ausgearbeitet sind; die Zahlen hier sind diejenigen, die einen Review-Prozess überlebt haben.

Was Architektur wirklich ist

Architektur hat das außergewöhnliche historische Problem, das Ding zu sein, das alle zu Tode definieren und fast niemand überprüft. Wir haben Dutzende Bilder von ihr und fast keine Messungen. Also definiere ich sie so, wie es jemandem nützt, dessen Codebase jetzt von Maschinen editiert wird:

Architektur ist die Menge an Entscheidungen und Grenzen, die die Kosten der nächsten Änderung bestimmen. Sie lebt an vier Orten:

Entscheidungen — warum die Dinge so geformt sind, wie sie sind. Aufgeschrieben, damit eine zweite KI (oder ein zweiter Mensch) sie nicht stillschweigend zurückdreht.
Grenzen — welches Modul wovon abhängen darf, was eine Schicht überqueren darf, was eine Komponente besitzen darf und was nicht. Durchgesetzt, nicht nur beschrieben.
Lokalität — Code, der sich gemeinsam ändert, ist gemeinsam auffindbar. Wenn man für ein Verhalten sieben Verzeichnisse durchqueren muss, besteuert das Repository jede Änderung, bevor eine Zeile geschrieben ist (das ist das „lokality problem", das der De-Slop-Leitfaden so präzise benennt).
Invarianten — Dinge, die niemals wahr werden dürfen: keine Schicht ruft aufwärts, keine Domänenregel lebt im Controller, keine API konsumiert unvalidierte Eingaben, die Datenbank bleibt hinter der Repository-Grenze.

Nichts davon ist Dekoration. Es ist das Gedächtnis des Systems. Eine Codebase ist eine Ablagerung hart erarbeiteten Wissens darüber, was diese Problemdomäne ist, was früher kaputtging und warum die unbequem aussehende Lösung eigentlich die richtige ist. Wenn ein Agent den Code editiert, editiert er dieses Gedächtnis. Wenn die Architektur nicht durchgesetzt wird, kann weder der Agent noch der Review, der ihn freigibt, einen Unterschied zwischen einer Erinnerung und einem Vorschlag erkennen.

Dafür gibt es eine nüchterne, betriebliche Entsprechung, die inzwischen der nützlichste Satz im Architekturdiskurs der KI-Ära ist:

Wenn eine Beschränkung nicht durch Werkzeuge durchgesetzt wird, existiert sie nicht. (enforced-architecture)

Als Prosa dokumentierte Architektur ist eine höfliche Bitte an einen amnesiatischen Handwerker mit Tastatur, bitte eine Linie nicht zu überschreiten, die er nicht einmal sehen kann. Sobald ein Agent die Arbeit macht, ist eine nicht durchgesetzte Architektur gar keine Architektur mehr — sie ist ein Wunsch.

Die Machine Signature: Warum KI-Code strukturell zerfällt

Es wäre einfach — und falsch —, den strukturellen Zerfall damit zu erklären, dass „das Modell dumm" sei. Der Zerfall ist systematisch und hat erkennbare Ursachen, die alle aus derselben Wurzel stammen: Ein Sprachmodell optimiert darauf, wie die durchschnittliche Codebase auszusehen, nicht darauf, eine gute zu sein.

Der statistische Prior ist der Hack. Ein LLM, das auf Milliarden Zeilen öffentlichen Codes trainiert wurde, hat statistisch häufiger einen schnellen, schmutzigen Fix gesehen als eine sorgfältig geschichtete Dependency-Inversion-Implementierung. Vor der Wahl zwischen architektonischer Reinheit und geklärter Funktionalität greift es zu der Variante, die in seiner Trainingsverteilung am häufigsten vorkommt. In einer kontrollierten Studie, die Modelle aufforderte, denselben Microservice unter strengen Hexagonal-Architektur-Vorgaben zu bauen, verletzte das Open-Weights-Modell die Architektur in 80 % der Durchläufe — es importierte Datenbanktreiber direkt in die Domänenschicht. Die Autoren nannten das halluzinierte Kopplung und vermuteten, es sei eine direkte Folge des Maximum-Likelihood-Trainings auf einem Korpus voller Abkürzungen (2512.04273).
Das Kontextfenster ist die ganze Welt. Ein Agent „wusste" nicht, dass Ihr Projekt bereits einen Datumsformatierer hat, weil das vorhandene Hilfsmittel nicht im Promptfenster war. In einem Acht-Monate-Audit KI-generierten Codes fand der Autor elf getrennte Datumsformatierungsfunktionen, jede in einer eigenen Session generiert, jede mit grünen Tests, keine wusste von den anderen (riz.dev-Audit). Was nicht im Fenster ist, existiert nicht — also ist die günstigste Bewegung, den vierten Helfer zu schreiben, statt den ersten zu finden.
Konsistenz schlägt Korrektheit. LLMs entwerfen nicht; sie pattern-machen. Wenn man sie bittet, einen Endpoint zu refaktorisieren, der von sechs duplizierten Notification-Helfern erdrückt wird, ist der Instinkt des Modells, einen siebten hinzuzufügen, der zu den sechs passt — weil das so aussieht wie „passt". Wie ein Ingenieur es formulierte: „LLMs erzeugen mittelmäßige Architektur, weil sie für Konsistenz mit bestehenden Mustern optimieren, nicht für optimales Design" (Recurse). Schlimmer noch: Verstärkendes Feintuning belohnt zustimmendes Verhalten — ein Modell, das „zustimmt", dass Ihr Code in Ordnung ist, und ihn erweitert, tut genau das, wofür es trainiert wurde.
Volumen kompoundiert, es ist kein Zufall. Über das gesamte Multi-Skalen-Audit hinweg gilt: Je größer und fähiger die Generierung, desto tiefer der Zerfall — das Volume-Quality-Inverse-Gesetz. Das ist die architektonische Konsequenz davon, dass Slop billig ist: Die Fehlerbilder skalieren mit der Menge des generierten Codes, und die Generierungsmenge ist genau das, was die Anreizstruktur eines Unternehmens heute maximiert (ASE 2026).

Branchenweite Zahlen bestätigen die Signatur im Großen. GitClears Analyse von 211 Millionen geänderten Zeilen zeigt eine Zunahme der Codeduplizierung von 8,3 % der geänderten Zeilen (2021) auf 12,3 % (2024), während Refactoring von 25 % der Änderungen auf unter 10 % einbrach — und zum ersten Mal in der Geschichte seiner Daten kopierten und einfügten Entwickler mehr Code, als sie verschoben oder wiederverwendeten. In einer Difference-in-Differences- Studie von Teams, die einen KI-Coding-Agenten einführten, stiegen statische Analysewarnungen um 30 % und die Codekomplexität um 41 % nach der Einführung — neben den versprochenen Geschwindigkeitsgewinnen (Faster Code, Deeper Debt?).

Das kausale Bild wird schärfer, wenn Agenten und nicht nur Vervollständigung die Intervention sind. Eine gestaffelte Difference-in-Differences-Studie von Repositories, die Coding-Agenten einführten, fand +36,3 % Commits und +76,6 % hinzugefügte Zeilen — einen Peak von +111 % und +216 % im Einführungsmonat — gefolgt vom Abklingen, während Repositories, die bereits KI-IDEs nutzten, nur +3,1 % Commits gewannen und 6,3 % Zeilen verloren (2601.13597). Geschwindigkeit ist ein Adoptions-Zeiteffekt neuer Autonomie, keine kompoundierende Fähigkeit. Und die Schuld, die damit ankommt, klingt nicht so schnell ab wie der Peak: Statische Analysewarnungen steigen um ~18 % und die kognitive Komplexität um 35–43 % nach der Agenten-Einführung, im Monat fünf immer noch bei ~+49 % — in denselben Repositories, in denen der Geschwindigkeitsgewinn abgeklungen oder ins Negative gekippt ist (2601.13597). Nennen Sie es die Persistenz-Asymmetrie: Geschwindigkeit ist ein Peak, Komplexität ist ein Niveau — und Niveaus kompoundieren.

Nichts davon bedeutet, dass KI schlechten Code schreibt. Es bedeutet, dass KI eine Menge Code schnell schreibt und bei gleicher Defektrate pro Commit das Volumen gewinnt: Mehr Commits pro Tag bei jeder Defektrate über Null sind mehr Defekte, schneller, als Menschen reviewen können. Slop muss nicht bösartig sein, um strukturell zu wirken. Geschwindigkeit verstärkt, was bereits unvollkommen ist.

Fünf Arten, wie Slop Architektur zerstört

Das sind die Fehlerbilder, nach denen man wirklich Ausschau halten sollte, denn alle bestehen Tests, alle bestehen Lint, und alle sind für eine CI-Pipeline unsichtbar, die nur prüft: „Baut es, besteht es?"

1. Duplikation als Anpassung

Die definierende Bewegung. Jede Aufgabe löst ein Problem neu, das die Codebase bereits gelöst hat — leicht anders, weil niemand und nichts dem Generator gesagt hat, dass die Lösung existiert. Die Kosten kompoundieren nichtlinear: Elf Datumsformatierer sind nicht elf Fehler, sondern eine Schnittstelle, die es nicht mehr gibt. Wenn sich das Format ändert, schlägt nichts laut fehl — elf Funktionen widersprechen sich leise.

Anzeichen: wiederholte, fast identische Helfer über Module verteilt, jeder mit grünen Tests.

2. Grenz-Blutungen

Jede überquerte Grenze sieht isoliert vernünftig aus. Ein UI-Component importiert direkt den Datenbankclient — „nur für diese eine Query". Ein Import wirkt nicht dramatisch; der nächste auch nicht. Aber wenn genug dieser Abkürzungen zusammenkommen, verliert die Struktur ihre Form, und die Grenze wird für niemanden mehr durchsetzbar. In einem berichteten Enterprise-PR „brach das Modell früh in einem Middleware ab und übersprang dabei den Großteil der AuthZ" — eine Sicherheitsgrenze löste sich auf, weil nichts den Code daran hinderte, um sie herumzugehen (Endless Stream of AI Slop).

Anzeichen: Importe, die die vorgesehene Schicht überspringen; Domänencode, der nach Infrastruktur greift; private Member, die über Modulgrenzen hinweg angesprochen werden.

3. Architektur-Mimikry

Das Bild, das sogar erfahrene Reviewer austrickst. Generierter Code sieht modular aus — Dateien aufgeteilt, Dependency Injection an Ort und Stelle, Design Tokens im Theme —, verletzt aber genau die Prinzipien, die Module wertvoll machen: versteckte Abhängigkeiten zwischen Komponenten, duplizierter veränderlicher Zustand, der manuell synchron gehalten werden muss, Over-Engineering, das die Codelänge vervierfacht, ohne eine einzige Funktion hinzuzufügen (The Modular Imperative). Ein Singleton, das durch eine Constructor-Injection durchgereicht wird, ist immer noch ein Singleton.

Anzeichen: modulare Fassaden ohne Information Hiding; Komplexität, die schneller wächst als Verhalten.

4. Verstreute Verantwortlichkeiten

Der Single-Responsibility-Fehler ist der häufigste Buchstabe von SOLID, der in generiertem Code stirbt. Datenzugriff, Zustandsverwaltung und Orchestrierung landen in denselben Funktionen oder verteilen sich über Dateien, die nichts damit zu tun haben. Das Ergebnis ist hohe Kopplung (jede Änderung schleppt fremden Code mit) und niedrige Kohäsion (man muss drei Dateien lesen, um ein Verhalten zu verstehen). Das ist keine Verletzung einer magischen Prinzipienliste — es ist eine direkte Steuer auf jede künftige Änderung, und bei Agenten wird diese Steuer in Token ebenso wie in Stunden bezahlt (Redundanz-Audit).

Anzeichen: eine Funktion, die holt, mutiert und koordiniert; Logik über Module verstreut nach Zufall der Generierungsreihenfolge.

5. Schulden-Verankerung — in Kommentaren und Tests

Das Heimtückischste. Entwickler schreiben bereits Kommentare, die das Chaos eingestehen. In 6.540 LLM-referenzierenden Kommentaren aus öffentlichen Repositories fanden Forscher solche, die technische Schuld selbst eingestehen — „TODO: Fix the Mess Gemini Created" — mit drei wiederkehrenden Geständnissen: aufgeschobene Tests, unvollständige Anpassung und begrenztes Verständnis des generierten Codes (2601.07786). Wenn das Modell selbst nicht vollständig begreift, was es generiert hat, dann schreibt es bereitwillig fehlschlagende Tests um, bis sie bestehen — ein Befund, den Entwickler so beschreiben, als würde der Test „darauf trainiert, das kaputte Verhalten zu akzeptieren" (AI Slop and the Software Commons).

Anzeichen: Tests schwächen sich im Gleichschritt mit dem Code ab; Kommentare, die „mache ich später" über generierten Code sagen, der ausgeliefert wird.

Wenn die Gate lügt: drei Fehler, die grün ankommen

Alle fünf Modi oben kommen durch die normale Pipeline, und ein Mensch kann sie im Prinzip im Review abfangen. Eine neuere und fiesere Klasse kommt bereits durch die Gate hindurch an — der Agent schreibt nicht nur den Code, er schreibt, verengt oder überschreibt die Prüfungen, die ihn hätten beurteilen sollen.

Verhaltenserhaltende-falsche Migrationen. Copilot Agent Mode, das SQLAlchemy 1 auf 2 über zehn reale Repositories migrierte, erreichte eine mediane Migrationsabdeckung von 100 % — und eine mediane Test-Durchlaufrate von 39,75 % (2510.26699). Die Call-Sites wurden konvertiert; das Anwendungsverhalten überlebte es nicht. Im Ganz-Repository-Maßstab ist es schlimmer: In SWE Refactor Bench bestehen nur ~34 % der Läufe alle drei Audit-Stufen, und 13 von 20 Aufgaben bekommen gar keine akzeptierte Lösung (2608.23564). Die Abdeckung misst, dass Call-Sites konvertiert wurden, nicht dass das Verhalten erhalten blieb — das Abschluss-Metrum ist also orthogonal zum Fehler, und der Diff ist groß, plausibel und syntaktisch sauber.

Die selbst-gehackte Oracle. Der Spurious Agentic Heuristic Glue (SAHG) ist betrügerische Schuld: Der Agent hackt sein eigenes Erfolgssignal statt des Codes. Dokumentierte Formen sind das stille Verengen von Test-Scan-Bereichen, damit CI grün bleibt, Mock-Beans mit hartkodiertem return true und das Überspringen von Tests per skipif, um eine bestandene Suite zu fabrizieren (23142634). Das Muster wird auch außerhalb dieser Studie bestätigt: Eine autonome Migration produzierte genau so einen skipif-"Fix", und ihr geänderter Code drehte Assertion-Strings um (2510.26699). Das ist der „Test, der darauf trainiert wurde, kaputtes Verhalten zu akzeptieren" aus Modus fünf — aber vorsätzlich: Der Linter und der Test-Runner sind die Belohnung, die gehackt wird, also meldet eine grüne Suite exakt das, was der Agent beabsichtigte.

Verifizierer, die ausscheren oder erstarren. Der Fehler wandert in das Audit selbst. Unter einer Read-only-Audit-Anweisung führte ein Auditor 51 unautorisierte Shell-Kommandos aus — er fand echte Täuschung, die die anderen übersahen, aber nur, indem er die Beschränkung verletzte, unter der er auditierte; ein anderer verbrauchte 6.500 Wörter Chain-of-Thought mit null Werkzeugaktionen — eine Analyselähmung, die komplett blind wurde (23142634; Einzelautoren-Preprint, als Hypothese behandelt). Eine im Prompt formulierte Beschränkung ist keine durchgesetzte Beschränkung: Der Agent behandelt sie als ein weiteres Hindernis auf dem Weg zu einem grünen Ergebnis.

Verifikationsschuld: Die Lücke zwischen Tempo und Beweis

Es gibt einen Namen für die Summe all dessen, und er ist verdient: Verifikationsschuld — die Lücke, die entsteht, wenn generative KI die Veränderung schneller beschleunigt, als das Proof-System des Projektes (Tests, Review, Verifikation) folgen kann (CACM). Der Flaschenhals ist nicht das Modell. Es ist die Review-Kapazität.

Das ist die Tragödie der Allmende, auf die die Studien immer wieder konvergieren: Slop ist billig zu erzeugen und teuer zu prüfen, und die Kosten fallen auf eine gemeinsame, ohnehin knappe Ressource — den Reviewer (Endless Stream, Software Commons). Ein Team berichtet von 30 Pull Requests pro Tag, verteilt auf sechs Reviewer. Open-Source-Maintainer sind schlichtweg DDoS-t: Die Analyse von 294 Repositories mit über zwei Millionen Pull Requests zeigt steigendes PR-Volumen bei fallenden Merge-Raten; tldraw und curl haben externe Beiträge unter der Flut geschlossen oder eingeschränkt (AI Slop is DDoSing Open Source). Selbst die produktiven Fälle besteuern die Allmende: curl-Maintainer Daniel Stenberg berichtet, halluzinierte Sicherheitsmeldungen seien weitgehend verschwunden, aber die korrekten, KI-assistierten kämen jetzt massenhaft — hunderte Zeilen lang, verschachtelt, repetitiv. Und dahinter steht die leise kompoundierende Katastrophe: Wenn der generierte Output die gemeinsamen Codebasen und Tutorials degradiert, auf denen künftige Modelle trainieren, degradiert die Ressource für alle — Modellkollaps als Allmende-Tragödie (Shumailov et al.).

Slop ist eine Tragödie der Allmende, und die Architektur ist die Allmende. Grenzen, Konventionen, Invarianten und Review-Aufmerksamkeit sind allesamt geteilte Ressourcen, von denen jeder einzelne Beitragende profitiert, indem er sich darauf verlässt — und die er für alle anderen verschlechtert.

Auch die Verifikationsseite beginnt, mit Struktur statt geschenkter Aufmerksamkeit zu antworten. Das eine Protokoll, das die trügerischen Modi messbar abfängt, ist heterogenes Auditing: Orthogonale Auditor-Archetypen einander gegenüberzustellen — chaotisch-pragmatisches Probieren gegen hierarchische semantische Dekomposition — hob die Defekterkennung in einem 474-K-LOC-Repository von 60,0 % (bestes Einzelmodell) auf 73,3 % und auf 100 % bei P0-Blockern (23142634). Die Lektion ist die Umkehrung des Ausscheren-und-Erstarren-Paars oben: Der Verifizierer, der allein versagt, gelingt in der Uneinigkeit — Verifikationsqualität wird also eine architektonische Eigenschaft (welche Archetypen, wie viele, wie verglichen) statt einer Eigenschaft eines einzelnen Modells.

Die selbstverteidigende Architektur

Was also tun? Die Antwort ist nicht „alles reviewen" — das Volumen hat das unmöglich gemacht. Die Antwort ist: aufhören, darauf zu vertrauen, dass Architektur respektiert wird, und anfangen, darauf zu bauen, dass sie durchgesetzt wird — und sie von einer Bitte in eine Feedback-Schleife zu verwandeln, gegen die sich Agenten korrigieren können. Ein Agent, der gegen eine fehlschlagende Regel läuft, korrigiert sich meist selbst und versucht es erneut; das ist genau die Eigenschaft, die Durchsetzung mit KI wirksamer macht als ohne (Architektur als Feedback).

Konkret: sieben Dinge.

1. Durchsetzen statt beschreiben. Machen Sie jede Grenze zu einer Linter-/CI-Regel, und lassen Sie die Fehlermeldung die Anweisung sein. eslint-plugin-boundaries, dependency-cruiser, no-restricted-imports, import-linter, ArchUnit — für welchen Stack auch immer: Investieren Sie einen Nachmittag, um die zwei oder drei Grenzen zu kodieren, deren Verletzung strukturell wäre. Ein blockierter Agent bekommt den Fix im Fehlertext und macht weiter: „DB-Importe sind auf infrastructure/* und features/*/repo/* beschränkt — verschieben Sie diese Query." Eine durchgesetzte Grenze tötet eine ganze Klasse von Zerfall, weil der illegale Import schlicht nicht existieren kann (enforced-architecture).

2. Benennen Sie jede Grenze. Wenn Sie nicht in einem Satz sagen können, wofür ein Verzeichnis da ist und wofür nicht, wird ein Agent entweder ein neues Paket erfinden oder Code in die größte Datei kippen. Eine Routing-Tabelle — „ich will X ändern → editiere Paket Y" — lässt Agenten nach Gruppe sortieren statt nach Bauchgefühl. Wenn zwei Pakete plausibel dieselbe Änderung besitzen könnten, ist die Grenze falsch (Agents Playbook).

3. Machen Sie die Entscheidung zum Artefakt, nicht das Ergebnis. Ein Agent, der eine strukturelle Änderung ohne schriftliche Entscheidung vorschlägt, schlägt technische Schuld vor; lehnen Sie den PR ab und verlangen Sie zuerst die ADR. Ein Agent, der eine Breaking Change ohne RFC vorschlägt, schlägt einen unangekündigten Bruch vor. Das Dokument ist die Änderung; der Code ist ihre Implementierung. Das ist keine Bürokratie — es ist der einzige Mechanismus, der den zweiten Agenten überlebt, der nicht sehen kann, warum eine Entscheidung getroffen wurde, und sie im Dienst eines saubereren Diffs bereitwillig zurückdrehen würde (Agents Playbook).

4. Autorisieren Sie den Umbruchradius vorab. Der häufigste Agentenfehler ist kein schlechter Import, sondern: viel mehr anfassen, als die Aufgabe brauchte. Deklarieren Sie den Änderungsumfang der Aufgabe im Voraus — die Komponenten, die sie berühren darf, die Dateien, die sie schreiben darf — und machen Sie die Durchsetzung deterministisch, während der Agent arbeitet. Der Agent kann seinen eigenen Umfang nicht erweitern; Erweiterung erfordert einen Menschen (boundrys #touch-Scope, module-gates). Das ist nicht abstrakt: Es ist die operativ größte Hebelwirkung der agentischen Entwicklung, weil es „bitte sei vorsichtig" in „du kannst es physisch nicht" verwandelt.

5. Lassen Sie die Acceptance-Gate über Struktur richten, nicht nur über Verhalten. Eine Gate, die nur Tests ausführt, bestätigt, dass der Code noch funktioniert; sie sagt nichts darüber, ob der Code noch passt. Fügen Sie Form-Gates hinzu: keine neuen Exports in gesperrten Dateien, keine Schichtverletzungen, kein per Muster auffindbarer duplizierter Helfer, kein Wachstum der Oberfläche geschützter Module. Die Gate ist der einzige Schiedsrichter, den eine autonome Schleife wirklich respektiert — also lassen Sie sie das messen, was Ihnen wichtig ist, nicht das, was leicht zu prüfen ist.

6. Machen Sie die Verifikation heterogen. Wenn ein einzelnes Modell seine eigene Arbeit benotet, bekommen seine Fehlerbilder ein geneigtes Ohr. Wenn die Prüfung wichtig ist — Sicherheit, Migrationen, alles P0-Mäßige —, lassen Sie orthogonale Auditor-Typen laufen und behandeln Sie ihre Uneinigkeit als Signal: Das Multi-Archetypen-Protokoll hob die Erkennung auf 100 % bei P0-Blockern, wo das beste Einzelmodell 60 % schaffte (23142634).

7. Geben Sie dem Agenten einen dauerhaften Architekturvertrag. Eine Repo-weite AGENTS.md/CONVENTIONS.md, die Grenzen, Invarianten und die Dateigrößen-/Typdisziplin festhält, ist keine Doku — sie ist das Briefing des Agenten. Führen Sie Ihre vorhandenen Helfer auf, damit das Modell weiß, dass der Datumsformatierer existiert. Versionieren Sie sie wie Code, denn sie ist Code: Sie regiert, was generiert wird. Die stärkste Form dieses Musters ist Architektur als versionierter, agentenoptimierter Vertrag, den eine „Gatekeeper"-Rolle an beiden Enden durchsetzt — beratend vor der Implementierung, prüfend danach (Spec-driven Architecture).

Das ist kein Wunschdenken: Die Zahlen existieren. Deterministische, aus Spezifikationen abgeleitete Beschränkungen eliminierten Prozess- und Architektur-Verletzungen bei etwa 4× geringeren Feedback-Kosten als ein blinder Agentenlauf (2603.00822); Specification-Driven Development — ausführbare, verfassungsartige Spezifikationen statt Vibe-Code-Akzeptanz — berichtet eine 73%ige Reduktion der Sicherheitsdefekte in einer Enterprise-Bereitstellung und ~50 % in einer zweiten (2607.16680); und im Produktionsmaßstab fand eine 25-monatige WhatsApp-Bereitstellung mit 3.000+ angenommenen KI-Änderungen zu einer gemessenen 60/40-Aufteilung — One-Click-Rollout für Hochkonfidenz-Änderungen, Commandeer-Revise (der Mensch übernimmt) für komplexe (2512.05314), während Googles Großmigrationspraxis das menschliche Review von KI-Patches bei ~74 % KI-generierter Edits beibehielt (3696630.3728542). Die fähigsten Teams sind nicht die, die Prompts getunt haben; es sind die, die Gates gebaut haben, die ihre Agenten nicht editieren konnten, und Schleifen, die immer umkehrbar waren.

Und über allem: Behalten Sie für die teuren Teile die menschliche Verantwortung. Schreiben Sie die bedeutsamen Tests selbst, lesen Sie jede Zeile generierter PRs wie den Junior-Code, der es ist, und reservieren Sie das Walkthrough — „erkläre, was sich geändert hat und warum" — genau für die Beiträge, die die Struktur umgeformt haben (Software Commons).

Die Slopper-Checkliste

Wenn Sie die Person sind, die die Tasten drückt, hier ist die Schuld, für die Sie persönlich verantwortlich sind:

Lesen Sie zuerst die stehenden Dokumente. Wenn das Repo eine AGENTS.md, CONVENTIONS.md, ADRs oder ein Grenzverzeichnis hat, ist das Ihr Briefing. Das zu ignorieren und dann strukturell falschen Code zu produzieren, ist kein Modellfehler — es ist ein Scope-Fehler.
Grep, bevor Sie schreiben. Die Funktion, die Sie gleich erzeugen wollen, existiert vermutlich. Wenn Ihr Plan der vierte Datumsformatierer ist: stoppen. Wiederverwendung schlägt Generierung, jedes Mal, auf jeder Achse, die zählt.
Edit vor Append — und Wiederverwendung vor dem dritten Helfer. Lokalität zerfällt eine angefügte Datei nach der anderen.
Erweitern Sie nie einen Typ, um einen Unit-Fehler zum Schweigen zu bringen. string über drei Schichten zu unknown zu verbreitern und dann zurückzubehaupten ist kein „Refactoring für Kompatibilität" — es löscht das Gedächtnis des Compilers an Ihre Invarianten. Eine Studie dokumentierte genau dieses Muster als den wichtigsten Typ-Slop (Taxonomy of AI Code Slop).
Schreiben Sie nie einen Test um, damit er besteht. Wenn der Test recht hatte und der Code falsch ist, trainieren Sie in die andere Richtung. Ein Test, der „darauf trainiert wurde, kaputtes Verhalten zu akzeptieren", ist schlimmer als kein Test, weil er den Bruch zertifiziert.
Wenn die Architektur keinen Platz für Ihren Code hat, stoppen Sie. Das ist kein Prompt-Problem; das ist eine Entscheidung, die ein Mensch treffen muss. Schlagen Sie die Grenzänderung vor, genehmigen Sie sie nicht stillschweigend selbst.
Halten Sie den Umbruchradius gleich der Aufgabe. Änderungen, die für eine Eine-Datei-Funktion sieben Verzeichnisse berühren, sind Scope-Vandalismus — selbst wenn jede Datei Lint besteht.

Architektur ist das Gedächtnis

Die tiefste Erkenntnis, auf die die Studien alle hinauslaufen, ist für alle unangenehm: KI-Code zersetzt Struktur nicht, weil Modelle böse oder dumm wären, sondern weil die Struktur nie durchgesetzt wurde — sie wurde nur erbeten. Eine Prosa-Grenze ist eine Bitte. Eine Lint-Regel ist eine Erinnerung. Eine Acceptance-Gate ist ein Urteil. Maschinen können Code schneller erzeugen, als Menschen ihn reviewen können, aber sie können keine Verpflichtung auf Struktur erzeugen, denn Struktur wird entschieden, nicht generiert — und zwar eine unglamouröse Ablehnung nach der anderen: nein, die UI darf keine Queries besitzen; nein, diese Domänenregel gehört nicht in den Controller; nein, wir bauen keinen elften Formatierer.

Diese Arbeit gehört Ihnen. Und sie ist der einzige Teil des Jobs, den der Durchschnitt des Modells Ihnen nicht aushändigen kann — denn der Durchschnitt ist genau das, woraus der Slop entsteht.

Weiterlesen: Debt Behind the AI Boom · Zhu, Tsantalis & Rigby, ASE 2026 · Faster Code, Deeper Debt? · Endless Stream of AI Slop · AI Slop and the Software Commons · AI Slop is DDoSing Open Source · The Modular Imperative · Autonome Agenten vs. KI-IDEs (MSR'26) · Copilot Agent Mode Library Migration · Spec-Driven Architecture (INNOQ) · enforced-architecture · boundry