Reins Engineering — KI mit Zugeln Image: AI generated

Ein Pferd ohne Zugel


KI-Coding-Tools wurden schnell. Login in 30 Sekunden. Zahlung in 2 Minuten. Ein MVP wird in drei Wochen ausgeliefert.

Drei Monate spater bricht es zusammen.

Die KI „raumt" die Zahlungslogik auf und andert die Rabattberechnung. Eine Refactoring-Anfrage andert Feldnamen der offentlichen API. Das Hinzufugen eines neuen Features bricht die Authentifizierung. Laut einer Studie von Carnegie Mellon (MSR 2026) steigt die Code-Komplexitat nach der Einfuhrung von KI-Coding-Tools dauerhaft um 41 %. Der Google DORA Report (2025) zeigt einen Ruckgang der Lieferstabilitat um 7,2 % bei jeder 25-prozentigen Zunahme der KI-Nutzung.

Das Problem ist nicht, dass KI dumm ist. Es fehlen die Zugel.


Geschirr ist ein Zaun

Die Branche antwortete mit „Harness Engineering". Linters, Formatter, CI/CD, Projektstruktur, Coding-Richtlinien. Zaune, die den Agenten im Inneren halten.

Zaune setzen keine Richtung. Was auch immer der Agent innerhalb des Zauns tut — bestehende Logik uberschreiben, Typen andern, Zustandsubergange uberspringen — der Linter besteht. Der Formatter besteht. CI besteht. Code erreicht die Produktion „sauber, aber falsch".

Der Sattel sitzt. Der Reiter ist aufgestiegen. Aber ohne Zugel halt er sich mit den Schenkeln und fallt nach drei Monaten herunter.


Reins Engineering

Reins Engineering ist ein ingenieurwissenschaftlicher Ansatz, der KI-Agenten deterministische Vertrage gibt und den Fortschritt blockiert, wenn Vertrage verletzt werden.

Er besteht aus drei Elementen:

1. Deterministisches Feedback

Gib dem Agenten Fakten, keine Meinungen. Nicht „das sieht komisch aus", sondern „Zeile 41: Feldname stimmt nicht uberein, erwartet ‘user_id’, erhalten ‘userId’." Feedback ohne Raum fur Sycophancy. Laut der TDAD-Studie (arxiv 2026) verschlechtern prozedurale Anweisungen wie „mach TDD" die Regressionen (6,08 % → 9,94 %), wahrend das Bereitstellen spezifischer Testdateien im Kontext Regressionen um 70 % reduziert (6,08 % → 1,82 %).

2. Vertragssicherung (Ratchet Pattern)

Wenn die Verifikation besteht, wird gesperrt. Verifizierungscode, der auf diese Weise geschrieben wird, heißt ratchet code. Hurl-Tests deklarieren API-Verhalten in Klartext und werden bei jedem Commit im CI ausgefuhrt. Bestandener ratchet code kann nicht geloscht werden. Der Agent kann Code frei andern, aber nicht das Verhalten. Drift wird strukturell unterdruckt.

3. Trennung von Entscheidungen und Implementierung

Drei im Code vermischte Dinge — Benutzerentscheidungen, Geschaftslogik, Implementierungsdetails — werden getrennt. Entscheidungen leben in deklarativen Spezifikationen (OpenAPI, DDL, Zustandsdiagramme). Implementierung wird frei von der KI generiert. Die KI kann Entscheidungen nicht mit Details verwechseln und uberschreiben. Das Uberleben von Entscheidungen wird unabhangig von der Modellgrosse.


Evolution

Prompt Engineering      → Sag es richtig und es funktioniert
Context Engineering     → Gib guten Kontext und es funktioniert
Harness Engineering     → Einschliessen durch Struktur
Reins Engineering       → Lenken mit Zugeln

Jede Stufe entstand aus den Grenzen der vorherigen. Prompts allein fehlte es an Konsistenz. Kontext hielt den Agenten nicht davon ab, abzuschweifen. Zaune konnten Drift innerhalb des Perimeters nicht verhindern.

Reins Engineering ist kein Zaun — es sind Zugel. Es schrankt die Freiheit des Agenten nicht ein; es stellt sicher, dass der Agent das Ziel erreicht.

Im Juni 2026 kam ein weiterer Name zur Linie hinzu. Loop Engineering — sei nicht langer die Person, die den Agenten promptet; entwirf stattdessen Schleifen, die die Prompts erzeugen (Addy Osmani, 2026). Die Diagnose ist korrekt. Schleifen skalieren die Generierung. Aber sie skalieren nicht das Urteilen. Osmani selbst hat die Schwachstelle notiert — „A loop running unattended is also a loop making mistakes unattended." Wenn Schleifen universell werden, wandert der Engpass an einen einzigen Ort: Was steckst du in den Verifikationsslot der Schleife?

Nenne diese Schicht verifier engineering, eval engineering oder gate engineering — die Substanz ist dieselbe. Der Urteilsslot der Schleife braucht einen deterministischen Vertrag, kein LLM. Ich nenne es Reins Engineering. Ohne Zugel konvergieren Schleifen nicht.


80 : 20

Reins Engineering deckt nicht alles ab. Es weiss genau, was es abdeckt.

Deque Systems analysierte ca. 300.000 Barrierefreiheits-Qualitatsprobleme auf uber 13.000 Seiten (2021). 57 % waren vollstandig automatisierbar, 23 % erforderten KI-Unterstutzung, 20 % konnten nur Menschen beurteilen. Barrierefreiheit und Code sind verschiedene Domanen, aber sie teilen dieselbe Struktur: „Welchen Anteil konnen Maschinen beurteilen?"

Durch diese Linse betrachtet verteilt sich Codequalitat wie folgt:

  • 57 % — Territorium der Ratsche. Verhalten deklarieren, Maschinen urteilen uber Verstösse ohne Ruckfrage. go test, Hurl, yongol check, filefunc validate.
  • 23 % — Territorium des Geschirrs. Linter, Formatter, CI. Der Mechanismus ist deterministisch, aber die Pruftiefe bleibt an der Oberflache. Sie erfassen keine Verhaltenskorrektheit, aber sie erzwingen Struktur und Stil und heben die Qualitat der KI-Generierung.
  • 20 % — Territorium des Menschen. Geschaftseignung, UX, Architekturrichtung.

Reins Engineering ersetzt das Geschirr nicht. Es sitzt darauf.

Geschirr (Oberflachen-Determinismus)   23 %
+ Ratsche (Verhaltens-Determinismus)   57 %
───────────────────────────────────
                                       80 %

Menschen konzentrieren sich auf die verbleibenden 20 %.


Warum grossere Modelle nicht die Antwort sind

„GPT-6 wird es richten."

Wird es nicht. Das Problem ist nicht die Intelligenz des Modells — es ist das Medium. Code als Medium unterscheidet nicht zwischen Entscheidungen und Implementierung. Jedes Modell, das Code liest, sieht Entscheidungen und Details im selben Text vermischt.

Ein lokales 4,5B-Modell (Gemma4) mit deterministischem Feedback + Beispielkontext bearbeitet SSOTs fehlerfrei. Ein Frontier-Modell, das Rohcode bearbeitet, erzeugt Drift. Der Unterschied liegt in der Struktur, nicht in der Intelligenz.

Wechsle nicht das Modell. Fuge einen Vertrag hinzu.


Evidenz

yongol ist die Implementierung von Reins Engineering. Es kreuzvalidiert die Konsistenz von 10 deklarativen Spezifikationen (SSOT) mit 287 Regeln und generiert Code.

ZenFlow-Benchmark — ein mandantenfahiges SaaS zur Workflow-Automatisierung. 32 Endpoints, 14 Tabellen, 47 Hurl-Anfragen. 11/11 Stufen bestanden. Das Hinzufugen von Features verlangsamte den Prozess nicht. Bestehende Tests brachen nie.

Ein funktionierendes Backend wurde erfolgreich mit einem lokalen 4,5B-Modell generiert. Kosten: 0 $. Offline. Reins schliesst die Lucke, die Modellgrosse hinterlasst.


Nicht KI-Review-Automatisierung — sondern Code-Review-Automatisierung

Der vorherrschende Ansatz der Branche ist KI-Review-Automatisierung. Ein LLM generiert Code, ein anderes LLM reviewt ihn. Ein Betrunkener fragt seinen betrunkenen Freund „Bin ich betrunken?". Die Sycophancy-Kapitulationsrate von Frontier-Modellen liegt bei 58 %. Die False-Pass-Rate von LLM-as-Judge liegt bei 36 %. Multipliziert man probabilistische Generierung mit probabilistischer Verifizierung, verschlechtert sich die Genauigkeit.

Reins Engineering ist Code-Review-Automatisierung. Das LLM generiert, deterministischer Code verifiziert. validate schmeichelt nicht. go test halluziniert nicht. Coverage-Messung lugt nicht. Pass ist pass und fail ist fail.

KI-Review-Automatisierung:   LLM → LLM-Verifikation → Schmeichelei → falscher Pass → Drift
Code-Review-Automatisierung: LLM → Code-Verifikation → Fakten → pass/fail → Konvergenz

In einer Ara, in der KI-Agenten dutzende Zeilen pro Sekunde generieren, konnen Menschen nicht den gesamten Code lesen. Aber die Delegation des Reviews an KI bedeutet, dass Schmeichelei die Verifikation ersetzt. Wenn Code die mechanisch verifizierbaren Teile ubernimmt, konnen sich Menschen ausschliesslich auf Entscheidungen konzentrieren, die Maschinen nicht beurteilen konnen — Geschaftseignung, UX, Architekturrichtung.

Menschliches Review wird nicht null. Der Schmerz des menschlichen Reviews wird reduziert. Was Code reviewen kann, reviewt Code. Was nur Menschen reviewen konnen, reviewen Menschen.


Geschirr ohne Zugel ist nur ein Zaun

KI ist bereits leistungsfahig genug. Was fehlt, ist Richtung.

Baut hohere Zaune und der Agent driftet schneller darin. Nehmt die Zugel und der Agent lauft zum Ziel.

Reins Engineering — strukturierte deterministische Verifikation fur KI-Agenten.


Unabhangige Konvergenz

5 Projekte, die unabhangig voneinander zum selben Prinzip konvergierten:

  • episteme — Eine kognitive Steuerungsebene fur KI-Agenten von einem UIUC-Forscher. Erzwingt die Erstellung einer Reasoning Surface auf Dateisystemebene vor irreversiblen Aktionen. Gleiches Prinzip wie Ratchet, andere Implementierung.
  • MagLab — Eine Physik-Forschungspipeline eines KAIST-Spintronik-Forschers. “LLMs only reason and plan. They do not compute numbers, fabricate citations, or generate figure data.” Deterministische Werkzeuge erzeugen alle numerischen Ausgaben.
  • Manifesto — MEL zur deklarativen Definition von Frontend-Zustandsubergangen. “Agent proposes, World verifies.” Der Agent schlagt nur die Absicht vor; Zustandsubergange werden deterministisch verifiziert.
  • NEKOWORK — Sicherheitsgate, das KI-Code-Diffs mit deterministischen Regeln vor dem Merge scannt. Funktioniert unabhangig von der Quelle. Das LLM urteilt nicht.
  • oh-my-kamisama — Ein Multi-CLI-Conductor, der Claude, Codex und Gemini orchestriert. Er liest den echten git diff statt der Behauptungen der Worker („diffs beat claims") und erklärt die Aufgabe erst als fertig, wenn die Projekt-Tests bestanden sind. Jeder Lauf bleibt als auditierbares Artefakt auf der Festplatte — kein verschwindender Chat.

Zusammengefasst: Generierung darf probabilistisch sein. Verifikation muss deterministisch sein.


Verwandte Artikel


References

  • Cursino, D. et al. (2026). “Speed at the Cost of Quality? The Impact of AI Coding on Software.” MSR 2026. arxiv.org/abs/2511.04427
  • Google Cloud (2025). DORA Report 2025. cloud.google.com
  • Wang, Z. et al. (2026). “TDAD: Test-Driven Agentic Development.” ACM AIWare 2026. arxiv.org/abs/2603.17973
  • Karpathy, A. (2026). “From Vibe Coding to Agentic Engineering.” thenewstack.io
  • Deque Systems (2021). “Automated Testing Study…” deque.com
  • Anthropic (2026). “Demystifying Evals for AI Agents.” anthropic.com
  • Osmani, A. (2026). “Loop Engineering.” addyosmani.com

Anderungshistorie

  • 2026-05-23: Erstveröffentlichung
  • 2026-05-27: Abschnitt „Unabhangige Konvergenz" hinzugefugt (episteme, MagLab, Manifesto, NEKOWORK)
  • 2026-05-28: Abschnitt „80 : 20" — Geschirr (23 %) + Ratsche (57 %) = 80 %, empirische Deque-Daten
  • 2026-05-31: oh-my-kamisama zur Unabhangigen Konvergenz hinzugefugt
  • 2026-06-10: Loop-Engineering-Absatz zum Abschnitt „Evolution" hinzugefugt — der Urteilsslot der Schleife, Aliasse absorbiert (verifier/eval/gate engineering)