Die 8 Stufen des Agentic Engineering: Ein Leitfaden für KI-gestützte Softwareentwicklung

Die Programmierfähigkeiten von KI entwickeln sich schneller als unsere Fähigkeit, sie effektiv einzusetzen. Deshalb stimmen all die SWE-bench-Score-Maximierungen nicht mit den Produktivitätsmetriken überein, die für Engineering-Leitung tatsächlich relevant sind. Wenn das Team von Anthropic ein Produkt wie Cowork in 10 Tagen ausliefert und ein anderes Team mit denselben Modellen nicht über ein fehlerhaftes POC hinauskommt, liegt der Unterschied darin, dass das eine Team die Lücke zwischen Fähigkeit und Praxis geschlossen hat und das andere nicht.

Diese Lücke schließt sich nicht über Nacht. Sie schließt sich in Stufen. 8 davon. Die meisten von euch, die dies lesen, haben wahrscheinlich die ersten paar bereits hinter sich, und ihr solltet bestrebt sein, die nächste zu erreichen, denn jede weitere Stufe bedeutet einen großen Sprung in der Produktivität, und jede Verbesserung der Modellfähigkeiten verstärkt diese Gewinne zusätzlich.


Ein weiterer Grund, warum euch das interessieren sollte, ist der Multiplayer-Effekt. Eure Produktivität hängt stärker als gedacht vom Level eurer Teamkollegen ab. Angenommen, ihr seid ein Level-7-Wizard und erstellt mehrere solide PRs mit euren Hintergrundagenten, während ihr schlaft. Wenn euer Repository jedoch die Freigabe eines Kollegen vor dem Merge erfordert und dieser Kollege auf Level 2 ist und PRs noch manuell überprüft, bremst das euren Durchsatz. Daher liegt es in eurem Interesse, euer Team auf ein höheres Niveau zu bringen.

Aus Gesprächen mit verschiedenen Teams und Einzelpersonen, die KI-unterstütztes Coding praktizieren, ergibt sich folgende (nicht perfekt sequenzielle) Entwicklung:

Stufen 1 & 2: Tab Completion und Agent IDE

Ich behandle diese beiden kurz, hauptsächlich der Vollständigkeit halber. Überspringt sie ruhig.

Es begann mit Copilot und Tab Completion. Tab drücken, Code automatisch vervollständigen. Wahrscheinlich von vielen längst vergessen und von Neueinsteigern im Agentic Engineering komplett übersprungen. Es bevorzugte erfahrene Entwickler, die ihre Code-Struktur geschickt vorbereiten konnten, bevor die KI die Lücken füllte.

KI-fokussierte IDEs wie Cursor veränderten das Spiel, indem sie Chat mit der Codebasis verbanden und Multi-File-Änderungen erheblich vereinfachten. Doch die Grenze war immer der Kontext. Das Modell konnte nur mit dem arbeiten, was es sehen konnte, und oft sah es entweder nicht den richtigen Kontext oder zu viel vom falschen.

Die meisten auf diesem Level experimentieren auch mit dem Planmodus ihres Coding-Agenten: eine grobe Idee in einen strukturierten Schritt-für-Schritt-Plan für das LLM übersetzen, diesen iterieren und dann die Implementierung auslösen. Das funktioniert in dieser Phase gut und ist eine sinnvolle Möglichkeit, Kontrolle zu behalten. Später sehen wir jedoch eine geringere Abhängigkeit vom Planmodus.

Stufe 3: Context Engineering

Buzzword des Jahres 2025: Context Engineering entstand, als Modelle zuverlässig gut darin wurden, eine angemessene Anzahl von Anweisungen mit genau dem richtigen Kontext zu befolgen. Rauschender Kontext war genauso schlecht wie unzureichend spezifizierter Kontext, daher lag der Fokus auf der Erhöhung der Informationsdichte pro Token. „Jedes Token muss seinen Platz im Prompt verdienen“ war das Mantra.

In der Praxis betrifft Context Engineering mehr Bereiche, als viele denken. Es umfasst euren System-Prompt und Regeldateien (.cursorrules, CLAUDE.md). Es umfasst die Beschreibung eurer Tools, da das Modell diese liest, um zu entscheiden, welche es verwenden soll. Es umfasst das Management der Gesprächshistorie, damit ein langfristig laufender Agent nicht den Faden verliert. Und es umfasst die Entscheidung, welche Tools pro Interaktion überhaupt verfügbar sind, da zu viele Optionen das Modell genauso überfordern wie Menschen.

Heute hört man weniger darüber. Die Entwicklung hat sich zugunsten von Modellen verschoben, die auch mit unordentlicherem Kontext umgehen können. Dennoch bleibt Kontextbewusstsein wichtig, insbesondere bei kleineren Modellen, tokenintensiven Tools und Agenten mit vielen verfügbaren Werkzeugen.


Der Fokus hat sich verschoben: nicht mehr nur schlechten Kontext entfernen, sondern sicherstellen, dass der richtige Kontext zur richtigen Zeit vorhanden ist. Das führt zu Stufe 4.

Stufe 4: Compounding Engineering

Context Engineering verbessert die aktuelle Sitzung. Compounding Engineering verbessert jede zukünftige Sitzung.

Es ist ein Zyklus aus: planen, delegieren, bewerten, kodifizieren.

Ihr plant eine Aufgabe mit genügend Kontext, delegiert sie an das LLM, bewertet das Ergebnis und kodifiziert anschließend, was ihr gelernt habt: was funktioniert hat, was nicht, und welches Muster beim nächsten Mal angewendet werden soll.

Der entscheidende Schritt ist das Kodifizieren. LLMs sind zustandslos. Ohne explizite Regeln wiederholen sie Fehler. Oft geschieht dies durch Aktualisierung von CLAUDE.md oder ähnlichen Regeldateien. Zu viele Regeln können jedoch kontraproduktiv sein. Besser ist es, eine Umgebung zu schaffen, in der das Modell relevanten Kontext selbstständig findet, etwa durch eine gepflegte Dokumentationsstruktur. 

Praktizierende dieses Ansatzes achten stark auf den Kontext. Wenn ein Fehler auftritt, vermuten sie zunächst fehlenden Kontext statt mangelnder Modellfähigkeit. Diese Denkweise ermöglicht die nächsten Stufen.


Stufe 5: MCP und Skills

Stufen 3 und 4 lösen Kontextprobleme. Stufe 5 erweitert die Fähigkeiten.

MCPs und benutzerdefinierte Skills geben dem LLM Zugriff auf Datenbanken, APIs, CI-Pipelines, Designsysteme, Browser-Tests und Kommunikationsplattformen. Das Modell denkt nicht mehr nur über Code nach, sondern kann aktiv handeln.

Beispiele: automatisierte PR-Review-Skills mit Subagenten für Datenbankintegration, Komplexitätsanalyse und Prompt-Qualität. Ziel ist es, den Engpass von menschlichen Reviews zu reduzieren.

Ein wichtiger Trend ist die Nutzung von CLI-Tools statt MCPs, da sie tokeneffizienter sind. Statt vollständiger Tool-Schemata wird nur relevanter Output in den Kontext geladen.

Stufen 3 bis 5 sind die Grundlage für alles Weitere. Schlechter Kontext oder schlechte Tools führen in höheren Stufen nur zu verstärktem Chaos.

Stufe 6: Harness Engineering & Automatisierte Feedback-Loops

Hier beginnt der eigentliche Durchbruch.

Harness Engineering bedeutet, die gesamte Umgebung, Toolchain und Feedback-Mechanismen so zu gestalten, dass Agenten zuverlässig arbeiten können – ohne menschliches Eingreifen.

Zentrale Idee: Backpressure. Automatisierte Mechanismen wie Tests, Linters oder Typsysteme, die Fehler erkennen und korrigieren. Zwei wichtige Prinzipien:
  • Durchsatz vor Perfektion: kleine Fehler tolerieren und später bereinigen
  • Constraints statt Anweisungen: Grenzen definieren statt Schritt-für-Schritt-Anleitungen
Auch Sicherheitsgrenzen sind Teil dieses Konzepts. Sie begrenzen, was ein Agent tun kann, wenn er sich irrt.

Zusätzlich muss der Agent in der Lage sein, sich selbstständig im Repository zu orientieren. Strukturierte Dokumentation und aktuelle Metadaten sind entscheidend.


Stufe 7: Background Agents

Mit besseren Modellen steigt die Erfolgsrate von One-Shot-Ausführungen. Planung bleibt wichtig, wird aber zunehmend vom Modell selbst übernommen.

Background Agents ermöglichen asynchrones Arbeiten: Agenten führen Aufgaben aus, während ihr euch anderen Dingen widmet.

Tools wie autonome Agent-Schleifen oder Dispatcher-Systeme koordinieren mehrere Agenten parallel. Der Entwickler wird zum Orchestrator.

Ein entscheidendes Muster:
  • unterschiedliche Modelle für unterschiedliche Aufgaben
  • klare Trennung zwischen Implementierung und Review
Agenten können auch in CI integriert werden:
  • automatische Dokumentation
  • Sicherheitsanalysen
  • Dependency-Updates mit Tests

Stufe 8: Autonome Agententeams

Noch niemand hat diese Stufe vollständig gemeistert.

Hier koordinieren sich Agenten direkt miteinander, ohne zentrale Steuerung. Sie übernehmen Aufgaben, teilen Ergebnisse und lösen Konflikte eigenständig.

Erste Ansätze zeigen Potenzial, aber auch Probleme:
  • fehlende Hierarchien führen zu Ineffizienz
  • Regressionen ohne starke CI-Kontrollen
Zudem sind Modelle aktuell noch zu langsam und teuer für breite Anwendung. Für die meisten realen Anwendungen bleibt Stufe 7 derzeit der Sweet Spot.

Nächstes Level im Agentic AI Engineering?

Die nächste Frage ist unvermeidlich.

Die Schnittstelle wird sich weiterentwickeln: von Text zu Sprache, vielleicht sogar zu direkter Gedankeninteraktion.

Der Traum vom perfekten One-Shot bleibt unrealistisch, da Anforderungen sich iterativ entwickeln. Software war schon immer ein iterativer Prozess – und wird es bleiben. Der Unterschied: Es wird schneller, intuitiver und deutlich leistungsfähiger.

Also: Auf welcher Stufe seid ihr? Und was tut ihr, um die nächste zu erreichen?