Zum Inhalt springen

Wissensbasis

Das Qualitätssystem rund um den Coding-Agenten

KI verstärkt die Engineering-Praktiken, die ein Team schon hat. Solide Versionskontrolle, Observability und kleine Batches werden zu Tempo. Ein Review-Bottleneck oder eine fragile Pipeline führen zu längeren Verzögerungen und mehr Ausfällen. Regeln, Reviews und harte Checks rund um den Agenten steuern, was er produziert.

Verfasst von

Aktualisiert:

Agentic Engineering 5

Unsere Position. KI verstärkt, was eine Organisation schon ist und tut. Eine schwache Organisation repariert sie nicht. Füttert ihr KI mit Slop, bekommt ihr Slop. Deshalb bringen wir zuerst die Qualitätsstandards in Ordnung (öffnet in einem neuen Tab) und setzen KI erst dann innerhalb dieser Standards ein.

Dieselbe Verstärkung wirkt auf das Verständnis. KI vergrößert die Lücke zwischen dem, was der Code tut, und dem, was er nach dem Verständnis des Teams tut. Diese Lücke nährt gewöhnliche technische Schulden.

Warum verstärkt KI die Praktiken, die ein Team schon hat?

Der Kernbefund des DORA-Reports 2025 lautet: KI verstärkt die Praktiken, die schon existieren (DORA-Report zu KI-gestützter Entwicklung).

  • Ist Code Review schon ein Bottleneck, führt mehr Änderungsvolumen zu längeren Verzögerungen.
  • Ist die Deployment-Pipeline fragil, bricht sie öfter.
  • Fehlen einer Organisation grundlegende Fähigkeiten, korreliert die KI-Einführung mit schlechterer Performance, mehr Reibung und größerer Instabilität.
  • Teams mit solider Versionskontrolle, Observability und Auslieferung in kleinen Batches gewinnen Tempo und Resilienz.

Praktiker:innen beschreiben denselben Mechanismus auf Ebene der Codebasis: Die Qualitätsinfrastruktur steuert den Agenten. Der Artikel Code Quality Foundations for AI-assisted Codebases (öffnet in einem neuen Tab) ordnet die Techniken in drei Gruppen:

  • Regeln: Lint-Regeln verbieten any und Type Assertions, begrenzen Komplexität, Verschachtelungstiefe und Dateigröße und untersagen generische Namen wie utils/helpers.
  • Reviews: Feedbackschleifen auf den erzeugten Output.
  • Sperren: harte Checks, damit sich keins von beiden umgehen lässt.

Stößt der Agent an ein Lint-Limit, muss er modulareren und besser benannten Code schreiben.

Ein Projektbericht beschreibt dieselbe Umkehrung aus Projekterfahrung. Dort stand die Verifikation am Anfang: Tests, Lint, Type Checks, Strict Mode, Pre-Commit-Hooks und Mutation Testing, das die Selbst-Feedbackschleife des Agenten schließt. Danach “features just kind of happened”. Qualität ermöglicht schnelle Auslieferung, statt sie zu bremsen (The way to deliver fast with AI: Quality (öffnet in einem neuen Tab)).

Ein operatives Detail aus dem Artikel schärft das Muster. Haltet eine einzige Quelle der Wahrheit für Konventionen und lasst jedes Tool darauf verweisen. Dann setzen CLAUDE.md, der automatische Reviewer-Agent und der CI-Reviewer die Regeln aus denselben Dateien durch statt aus drei auseinanderdriftenden Kopien. Den Reviewer-Agenten startet ein Hook, jedes Mal wenn der Agent fertig ist (Code Quality Foundations for AI-assisted Codebases (öffnet in einem neuen Tab)). Außerdem sichert der Artikel die Gates gegen den Agenten ab, der sie zu bestehen versucht. Das behandelt Deterministische Quality Gates.

Earendil, die Firma hinter dem Coding-Agenten pi, macht aus derselben Idee eine Liste mechanischer Checks für die Lesbarkeit durch Agenten (AI Engineer - The Friction is Your Judgment (öffnet in einem neuen Tab), AI Engineer Europe 2026):

  • Lint-Regeln verbieten pauschale Catch-alls. So fällt ein verdeckter Fehler auf, ohne dass sich jemand im Review an die Konvention erinnern muss.
  • Alles SQL läuft über eine einzige Query-Schnittstelle, die ganze UI über eine einzige Bibliothek von Primitives. Ein Agent muss nie nach einer zweiten Stelle suchen, die die Änderung auch braucht.
  • Dynamische Imports sind verboten, Funktionsnamen müssen eindeutig sein. Ein grep mit einem Treffer kostet den Agenten weniger Kontext als einer, den er erst auflösen muss.
  • Das Team probiert außerdem den TypeScript-Modus erasableSyntaxOnly aus. Er lehnt Konstrukte wie Enums ab, die eine Transformation zur Laufzeit brauchen. So bleibt der Quelltext, den der Agent liest, nah am Code, der läuft.

Das Dark-Factory-Modell benennt den Fehlermodus, wenn diese Reihenfolge kippt: die Bullshit Factory. Sie hat Produktionsinfrastruktur ohne ausgereifte Validierungsinfrastruktur. Die Factory erzeugt viel Output, der größtenteils unbrauchbar ist. Das liegt nicht an schlechten Agenten. Schwache Quality Gates sind leicht zu bestehen, und Agenten optimieren darauf, sie zu bestehen. Die richtige Reihenfolge lautet: erst Validierung und Observability, dann Produktionsvolumen. Die Quelle der Wahrheit sind programmatische Tests und Fitness Functions, nicht die Spezifikation. Specs beschreiben die Absicht, Tests prüfen die Realität (Dark Factory Patterns).

KI verstärkt neben den Quality Gates noch etwas Zweites: die Lücke zwischen dem, was der Code tut, und dem, was er nach dem Verständnis des Teams tut. Das Triple Debt Model trennt drei Orte, an denen sich dieses Risiko ansammelt:

  • Technische Schulden stecken im Code. Sie sind beobachtbar und lassen sich refactoren.
  • Kognitive Schulden stecken in Menschen. Das gemeinsame Verständnis eines Teams vom System erodiert mit der Zeit.
  • Intent-Schulden stecken in Artefakten oder in ihrem Fehlen. Es fehlen Begründungen, Ziele und Constraints, die Menschen und Agenten brauchen, um das System sicher weiterzuentwickeln.

KI wirkt als Multiplikator, und sie multipliziert genau die Schulden, die wir am schlechtesten managen. Tools erzeugen gut Code und messen sogar technische Schulden. Wenige verbessern aber das Verständnis oder bewahren die Absicht. Dorthin verschiebt sich das eigentliche Risiko (From Technical Debt to Cognitive and Intent Debt (öffnet in einem neuen Tab), 23. März 2026).

Intent-Schulden zeigen sich, wenn Agenten plausible, aber falsche Entscheidungen treffen und Token verbrennen. Der Grund: Niemand hat das Warum der Architektur aufgeschrieben. Dagegen helfen:

  • Entscheidungs- und Begründungsprotokolle (ADRs),
  • Domain-Driven Design, das die Absicht explizit macht, bevor sie in Code landet,
  • ausführbar festgehaltene Absicht wie BDD-Specs, die zeigen, wenn das System von seinem Zweck abdriftet.

Thoughtworks verfolgt dieselbe Idee der kognitiven Schulden. Der Radar warnt, dass die höhere Änderungsgeschwindigkeit durch KI sie vergrößert, besonders bei mehreren Beitragenden oder Agent-Schwärmen. Am Ende steht eine sich selbst verstärkende Schleife mit gewöhnlichen technischen Schulden, in der jede Seite die andere schwerer abbaubar macht (Thoughtworks Technology Radar Vol 34, April 2026 (öffnet in einem neuen Tab)). Die Kosten wachsen über unordentlichen Code hinaus. Ein Team, das das System nicht mehr versteht, steuert den Agenten schlechter. Es übersieht die Edge Cases und Architekturfallen, die ein:e Maintainer:in erkannt hätte. Schwächeres Verständnis erzeugt so schwächeren Code, und der schwächt das Verständnis weiter.

Genau dieses gemeinsame mentale Modell soll Code Review schützen. Am 9. Februar 2015 argumentierte der Artikel Code Review Essentials for Software Teams (öffnet in einem neuen Tab) so: Review dient vor allem dazu, das Modell jedes Teammitglieds vom System synchron zu halten, während es sich ändert. Bugs finden und Stil rangieren darunter. Kleinkram zu Einrückung und Namen sollte beim Check-in automatisiert laufen. Dann kann sich Review der schwierigeren Abstimmung widmen.

Wenn Generieren billig ist und die Aufmerksamkeit der Reviewer:innen knapp, ist genau dieses gemeinsame Modell in Gefahr. Die Forschung bietet einen direkten Test, um die Erosion in einer Retrospektive zu erkennen (From Technical Debt to Cognitive and Intent Debt (öffnet in einem neuen Tab), 23. März 2026):

  • Kann das Team ein Modul erklären, ohne den Code zu öffnen?
  • Kann es das Modul um 2 Uhr nachts ohne KI debuggen?
  • Kann es sagen, warum genau diese Implementierung gewählt wurde?
  • Könnte es das Modul weiter warten, wenn die KI wegfiele?

Kommen genug Neins zusammen, ist das Verständnis schon verloren.

Verwandte Seiten

Quellen

Talks