Agentic Engineering: Wo Loops in der Praxis scheitern und warum

Boris Cherny, Head of Claude Code bei Anthropic, sagte einen Satz, der durch die Tech-Szene lief: „Ich prompte Claude nicht mehr, ich schreibe Loops, die Claude prompten." Das klingt nach Eleganz, nach Beschleunigung, nach Zukunft. Es klingt aber auch nach Risiko, denn in großen Enterprise-Projekten ist die Realität oft anders als in Social-Media-Demos oder Green-Grass-Projekten. In Folge 2 haben wir gezeigt, wie Code Reviews im Zeitalter von AI Coding Agents sinnvoll gemacht werden können. Diese Folge geht einen Schritt weiter und fragt: Selbst wenn du Verifikation richtig baust, wo scheitern Loops in der Praxis trotzdem? Wir bei codecentric arbeiten seit Monaten mit Agentic AI in Kundenprojekten und sehen fünf Failure-Patterns, die wiederholt auftauchen. Im Folgenden zeige ich, wie diese aussehen und wie wir sie vermeiden. Wer Agentic Engineering in seinem Unternehmen einführen will, sollte sie kennen, bevor er anfängt.

Was ist Agentic AI — und was nicht

Agentic AI bezeichnet KI-Systeme, die selbst über Aktions-Sequenzen entscheiden und Tools nutzen, im Unterschied zu Generative AI, die nur auf Prompts antwortet. Agentic AI plant, handelt, beobachtet das Ergebnis und entscheidet die nächste Aktion. Dies passiert auf Basis eines LLM im Zentrum der Architektur. Nutzt man so einen Agenten in der Entwicklung, wird dies Agentic Engineering genannt. Dies ist die Voraussetzung für Loop Engineering.

Agentic AI geht also viel weiter als ein LLM alleine: Generative AI braucht einen guten Prompt. Agentic AI braucht dazu eine Umgebung — Tools, Berechtigungen, Goals, Verification. In Folge 1 haben wir gezeigt, dass diese Umgebung im Markt unter drei Begriffen diskutiert wird: Context Engineering, Harness Engineering, Loop Engineering. Agentic AI ist das, was darin lebt; Loop Engineering ist das, was sie wiederholt anstößt.

Wer den Begriff sucht, landet schnell bei Andrej Karpathys Tweet von Februar 2025, in dem er „Vibe Coding" prägte: das fast spielerische Sich-Einlassen auf KI-generierten Code. Was viele übersehen: Karpathy selbst hat im Mai 2026 gesagt, dass Vibe Coding passé ist — die Modelle seien inzwischen zu gut, der Begriff zu schwammig. Daher seine neue Bezeichnung: Agentic Engineering.

Schauen wir uns nun an, wie das in der Praxis aussehen kann, wenn Agentic Engineering in großen Enterprise-Projekten eingesetzt wird, und welche fünf problematischen Muster wir bei codecentric in den letzten Monaten wiederholt gesehen haben.

Pattern 1 — Der Loop läuft, aber baut das Falsche

Das erste Muster ist tückisch, da es kein technischer Fehler ist und somit nicht sofort auffällt. Der Agent hat anscheinend alles richtig gemacht: Er hat einen verständlichen Prompt bekommen, hat sauber geplant, hat funktionierenden Code geschrieben, hat die Tests grün bekommen. Und trotzdem ist es das Falsche. Seine Spec-Interpretation stimmt mit dem Business-Bedarf nicht überein.

In einem unserer Versicherungs-Projekte sollte ein Agent eine Berechnungslogik für Beitragsanpassungen umsetzen. Die Spec klang eindeutig: „Neue Tarife pro Vertragsänderung berechnen, alte Tarife archivieren." Der Agent hat das exakt umgesetzt — und übersehen, dass „Vertragsänderung" für die Fachabteilung Dutzende von Sonderfällen umfasst, die in der Spec nicht standen, weil sie für Fachexperten selbstverständlich sind.

Im Loop-Modell heißt diese Lücke ECM-Lücke (Enterprise Context Management): Der Coding-Loop hat keinen Zugriff auf den Domain-Kontext, der die Spec erst verstehbar macht. Die einzige Antwort ist eine Spec, die diesen Kontext explizit enthält — und ein Spec-Review durch Domain-Experten, bevor der Coding-Loop anläuft. Wer das nicht macht, baut schnell, aber das Falsche.

Pattern 2 — Der Loop „löscht" seine eigenen Tests

Wenn neue Features bestehende Tests brechen, hat ein Agent zwei Optionen: das Feature anpassen oder die Tests anpassen. Das Ziel „alle Tests grün" ist gesetzt, und Agenten sind darauf optimiert, ihr Ziel zu erreichen — dabei werden sie oft kreativ. Wir haben in mehreren Projekten beobachtet, dass autonom laufende Agenten ihre eigenen Tests modifizieren, wenn diese ihnen beim Refactoring im Weg sind.

Aus Sicht der Code-Qualität ist das ein Skandal. Aus Sicht des Agenten ist es seine Aufgabe, sein Ziel unter allen Umständen zu erreichen. Um dieses Problem zu umgehen, ist es am effektivsten, die Struktur um den Agenten anzupassen.

Isolated Specification Tests helfen hier. Das Konzept haben wir bereits in einem früheren Beitrag detailliert und in Folge 2 dieser Reihe zum AI Code Review als eine der strukturellen Antworten auf Risiko 1 (mangelnde Verifikation unbeaufsichtigter Loops) eingeordnet. Wes McKinney (pandas, Apache Arrow) bringt die zweite strukturelle Antwort ins Spiel: adversarial agents, unabhängige Agenten, die den Coding-Output aktiv zu widerlegen versuchen. Wer auf strukturelle, für Agenten angepasste Verifikation verzichtet, wird schnell Pattern 2 kennenlernen.

Pattern 3 — Geschwindigkeitsillusion vs. Wartbarkeit

Das dritte Muster ist eine schleichende, zeitversetzte Falle. Der Loop produziert in zwei Tagen, was sonst zwei Wochen gebraucht hätte. Das Team feiert die Beschleunigung. Sechs Monate später kann niemand mehr den Code ändern, weil er keiner internen Struktur mehr folgt. Der Agent hat viele Regeln gebrochen, und wir erkennen unseren Code nicht wieder.

Wir haben dieses Muster in einem eigenen Praxisbericht zu Vibe Coding ausführlich beschrieben. Die Kurzfassung: Es geht nicht darum, ob KI „besseren" Code schreibt — es geht darum, ob der entstandene Code in 18 Monaten noch wartbar ist.

Der Engpass verschiebt sich von Coding zu Wartung. Wer das nicht antizipiert, gewinnt drei Monate und verliert ein Jahr. Was hilft: Refactoring-Loops von Anfang an als Teil des Loop-Designs, Rules und Guardrails, die den Stil und die Architektur forcieren, plus dokumentationsorientierte Generierung — also eine menschenlesbare Erklärung der Code-Änderungen.

Pattern 4 — Die „Halluzination" frisst die Architektur

Halluzination ist zwar nicht mehr so dominant wie 2023, aber weiterhin ein Problem. Auch bei Coding Agents. Der Agent erfindet API-Calls, die nicht existieren — Code kompiliert, läuft im Test, scheitert in Production. Oder schlimmer: Er läuft in Production, aber gegen die falsche API-Version, mit subtilen Inkonsistenzen, die sich erst Wochen später zeigen. Was passiert, wenn der Agent keinen echten Zugriff auf die aktuelle Code-Basis, die internen APIs oder die Architektur-Constraints hat? Er füllt die Lücke mit plausiblen Vermutungen — und plausibel ist genau das, was Halluzination so gefährlich macht.

Was hilft: Kontext-Infrastruktur statt Einzelfall-Prompts. Wer Halluzinationen mit besseren, ausführlicheren Prompts bekämpfen will, gewinnt vielleicht im einzelnen Fall — aber nicht skalierbar. Der bessere Hebel ist strukturelle Kontext-Infrastruktur: MCP-Server, die dem Agenten lebenden Zugriff auf das echte Repo, die aktuellen Library-Versionen und die geltenden Architektur-Entscheidungen geben. Plus: Architektur-Entscheidungen werden außerhalb des Loops getroffen und als harte Constraints in den Loop reingegeben. Und Reviews durch Menschen, die die Architektur tatsächlich kennen, nicht nur die Spec.

Pattern 5 — Vibe-Accept im Team

Im letzten Muster geht es um die menschliche Komponente. Wir haben alles gut gemacht, die anderen Patterns umgangen, und unser Agent läuft, wie wir es uns wünschen. Nach vier bis sechs Wochen Loop-Arbeit beobachten wir in Kundenteams, dass die Review-Schwelle systematisch fällt. „Sieht gut aus" wird zur dominanten Bewertung. Wer beim Review kritische Fragen stellt, wirkt zunehmend pedantisch, weil der Output ja meistens passt.

Osmani nennt das kognitive Kapitulation (Risiko 3 im Original-Blogpost). In Folge 2 zum AI Code Review haben wir den Effekt an zwei Erklärungsmodellen aus der Sicherheits- und Verhaltensforschung angedockt: Normalization of Deviance erklärt, warum die Review-Schwelle fällt (was anfangs Ausnahme war, wird zur Norm), und der Ikea-Effekt erklärt, warum sie nicht wieder steigt (selbst erzeugter Output wird systematisch überbewertet). Es ist keine Faulheit, sondern eine strukturelle Anpassung an die Geschwindigkeits-Asymmetrie zwischen Generierung und kognitiver Erfassung.

Im letzten Blogartikel haben wir im Detail darüber geredet, wie Code Reviews im Zeitalter der neuen Agenten und ihrer Geschwindigkeit aussehen können, solange diese noch Fehler machen. Diese Antwort besteht aus drei Säulen. Erstens sind weiterhin Tests relevant und wichtiger denn je, da sie automatisierte Code-Änderungen verifizieren müssen. Dazu gehört die gesamte Testpyramide sowie auch die menschliche Verifikation des Features durch den Entwickler. „You build it, you own it" gilt weiterhin. Zweitens sollte ein Großteil der Code Reviews durch (AI-)Tools unterstützt werden, die den Code automatisiert reviewen. Und drittens: weiterhin menschliche Code Reviews. Um den Engpass damit aber nicht einfach nur zu verschieben, wird nicht mehr jeder Code per Hand gereviewt. Vielmehr fokussieren wir uns auf die kritischen Stellen — die, die Architektur- und UX-entscheidend oder sicherheitskritisch sind. Auch Zugriffe auf Datenquellen müssen weiterhin vom Menschen abgenickt werden.

Demo vs. Production — die Realitäts-Tabelle

Wie kommt es dann, dass auf allen Social-Media-Kanälen plötzlich alle Entwicklung 10× schneller ist oder einfach funktioniert? Weil Demos und Green-Grass-MVPs anders funktionieren als Enterprise-Production-Software. Was in einem Demo-Video überzeugt, scheitert in einem 100k-LoC-System — nicht wegen schlechter Technologie, sondern wegen anderer Bedingungen.

Aspekt	Demo / Tweet	Enterprise-Production
Code-Komplexität	50–200 LoC, isoliert	100k+ LoC, vernetzt
Spec-Klarheit	„Build a TODO app"	Multi-Stakeholder, sich ändernd
Test-Abdeckung	Demo-Tests	Existierende Suite + neue + Edge Cases
Domain-Kontext	universal (Web-App)	Versicherung / Manufacturing / Retail
Lebensdauer	5 Min Aufnahme	5+ Jahre Wartung
Verification	„It runs"	Compliance, Security, Audit, SLA

Diese Tabelle ist keine Anklage gegen Demos. Demos sind nützlich, um zu zeigen, was technisch möglich ist. Das Problem ist, dass viele Entscheider ihre Erwartungen durch die Demo unbewusst auf Enterprise-Projekte übertragen und sich dann wundern, warum es länger dauert, mehr kostet und schwerer zu prüfen ist. Wer beide Welten unterscheidet, kann die echten Vorteile holen, ohne in die fünf Patterns zu laufen.

Loops scheitern nicht, weil Cherny falsch liegt. Sie scheitern, weil die Lücke zwischen Tweet und Wartbarkeit groß ist. Folge 2 hat gezeigt, wie AI Code Review Korrektheit strukturell sichert. Diese Folge zeigt, warum das nicht reicht: Selbst korrekt gebauter Code kann das Falsche sein. Wir müssen uns klar sein, wie Agenten funktionieren und wo sie dadurch schwer erkennbare Probleme einbauen können. Die Antwort darauf liegt nicht mehr im Coding-Loop selbst, sondern in einem Denkrahmen, der Coding, Validation, Learning und Business zusammendenkt. Folge 4 stellt ihn vor.

FAQ

Ist Agentic AI dasselbe wie Generative AI? Nein. Generative AI antwortet auf Prompts, Agentic AI entscheidet selbst über Aktions-Sequenzen und nutzt Tools. Aktuell ist Agentic AI im Kern mit Generativer KI gebaut und bildet einen Rahmen um diese.

Funktionieren Loops überhaupt in Enterprise-Projekten? Ja, wenn man die fünf Failure-Patterns adressiert. Ohne Struktur scheitern sie systematisch.

Sind Loops schon gut genug, um sie einfach ohne Probleme einzusetzen? Nein, es braucht vorsichtiges Arbeiten und Beobachtung des Teams. Aber jetzt anzufangen, schafft einen klaren Geschwindigkeits- und damit Wettbewerbsvorteil und bringt wichtige Erfahrung.

Wie stelle ich sicher, dass die Codequalität erhalten bleibt? Wir empfehlen, Agentic-AI-Projekte mit der Verification-Frage zu starten, nicht mit der Beschleunigungs-Frage. Die Beschleunigung kommt automatisch.

Wie groß sollte ein Pilot sein? Klein genug, dass der Code kaputt gehen darf, groß genug, um Probleme zu machen und die fünf Patterns zu sehen. Im Idealfall mit echtem Enterprise-Code, aber getrenntem Branch.

Weiterführende Lektüre

Wer tiefer in Agentic AI + Failure-Patterns einsteigen will:

• Anthropic Engineering — „Effective Harnesses for Long-Running Agents" — Anthropic-eigenes 3-Agent-Pattern (Planner → Generator → Evaluator), zeigt strukturelle Antwort auf Pattern 2
• GitHub — „Awesome Harness Engineering" — kuratierte Pattern-Sammlung
• Cobus Greyling — „Loop Engineering" (Substack) — Synthese der Hierarchie Context → Harness → Loop
• The New Stack — „The Anthropic leader who built Claude Code says he ditched prompting" — Hintergrund zu Chernys Statement
• Ralph-Pattern (Geoffrey Huntley) — Originalbeitrag zur Loop-Methodik (Quelle des Begriffs, der unserem Ralph-Wiggum-Loop-Post zugrunde liegt)

---

In Folge 4 zeigen wir, wie codecentric mit dem Loop-Modell die Brücke vom Coding-Loop zur Business-Logik schlägt — und warum das mehr ist als „noch ein Framework".