Seit dem Release von Claude Code sind mittlerweile 18 Monate vergangen (Stand September 2026) und die Coding-Arbeit hat sich bei einigen Entwickler:innen sicherlich sehr verändert. Wenn man allerdings seine KI-Bubble etwas verlässt, stehen viele Teams noch vor der Herausforderung, wie sie Claude und Konsorten in ihrem Entwicklungs-Alltag effizient einsetzen können.

Dieser Blog-Beitrag soll meine Erfahrungen aus den letzten 1 1/2 Jahren Agentic Coding in der täglichen Projektarbeit und aus Kunden-Trainings zusammenfassen.

Ende letzten Jahres habe ich bereits einen Blogpost zum Thema KI in der Softwareentwicklung geschrieben. Die Leistungsfähigkeit der Modelle hat sich seitdem weiter verbessert und es lassen sich mehr Aufgaben generativ umsetzen. Meine Schlussfolgerung bleibt aber weiterhin die gleiche: Coding ist nicht das Bottleneck

Agentic Coding

KI-unterstützte Softwareentwicklung ist kein Agentic Coding. KI Agenten zielen darauf ab, eine Aufgabe autonom abzuarbeiten. Dies können unterschiedliche Arten von digitalen Aufgaben sein, beim Agentic Coding betrifft es die Softwareentwicklung bzw. das Erstellen eines Artefakts.

Agentische KI-Systeme bestehen dabei neben dem eigentlichen KI-Modell aus einem Harness. Der Harness ist die Software-Umgebung, in der Anfragen an das Modell gesendet und der Response empfangen wird. Der Harness stellt Tools zur Verfügung und setzt eine Agentic Loop um, in der das KI-System in mehreren Durchgängen über ein Ergebnis iteriert, z.B. um mehrere Tasks nacheinander abzuarbeiten oder fehlschlagende Tests zu beheben. Auch Guardrails und Anweisungen, die wir einem KI-Modell geben, sind Teil des Harnesses (z.B. AGENTS.md bzw. CLAUDE.md).

Kein Pair Programming mit der KI

Solange man einen Coding-Agent als einen in die IDE integrierten KI-Chatbot betrachtet, erzielt man keine großen Effizienzgewinne. Das ständige Ping-Pong-Spielen kann mir zwar Fragen beantworten oder einzelne Code-Blöcke oder Methoden generieren, ich muss meine Aufmerksamkeit aber ständig bei dem aktuellen Chatverlauf belassen.

Der Vorteil, den ein agentisches Vorgehen mit sich bringt, besteht darin, dass eine KI selbstständig arbeitet, bis ein gefordertes oder als gefordert interpretiertes Ergebnis vorliegt. Dabei muss ich der KI nicht über die Schulter schauen und kann mich parallel weiteren Aufgaben zuwenden.

Wichtig bei der Definition des Endzustandes ist dessen Beschreibung. Damit eine KI das von mir erwartete Ergebnis liefert, muss ich mir dessen zuerst selber bewusst sein. Je genauer ich eine Aufgabe beschreibe, desto besser wird das generierte Ergebnis. Die Beschreibung kann dabei auf mehreren Abstraktions-Ebenen erfolgen:

  • Informationen über das System sowie den Kontext, in dem das Feature entwickelt wird
  • Beschreibung von Benutzer-Personas und Zielgruppe
  • Genaue Definition des Features z.B. aus der entsprechenden User-Story
  • Akzeptanzkriterien
  • Technische Details und Vorgaben
  • Geforderte Klassen- oder Methoden-Namen

Wenn das Ergebnis, das mir die KI liefert, von meinem mentalen Modell, wie ich mir das Ergebnis in etwa vorgestellt habe, abweicht, besteht Handlungsbedarf. Möglicherweise war mein initialer Prompt nicht spezifisch genug oder implizite Annahmen wurden der KI nicht mitgeteilt. Vielleicht war die Aufgabe aber auch zu groß für einen einzelnen Prompt und einen einzelnen Agenten-Run.

Das Schneiden von Anforderungen in kleine abgeschlossene Tasks ist keine neue Erkenntnis und bleibt auch beim Agentic Coding ein gutes Werkzeug, die gewünschten Resultate in kurzer Zeit zu erreichen.

Learning: KI nicht babysitten

Implizite Entscheidungen explizit machen

In der Nutzung von KI für die Entwicklung von Software sehen wir häufig, dass Entwickler:innen nicht zufrieden mit dem Ergebnis sind, das ihnen die KI liefert. Zumeist liegt dies nicht an der Leistungsfähigkeit des Modells, diese ist für die meisten Coding-Tasks ausreichend gut. Das Problem ist fehlender Kontext.

Bei der händischen Entwicklung trifft man während der Umsetzung eines Features oder eines Tasks fortlaufend Entscheidungen: Wo platziere ich diese Klasse, wie benenne ich diese Methode, wie baue ich die Tests für diesen Code auf. All diese Entscheidungen erfolgen implizit und häufig unreflektiert. Weil man es schon immer so gemacht hat, oder “weil das doch klar ist”. Diese Informationen sind einer KI aber nicht klar, solange man sie ihr nicht mitteilt.

Um ein gutes Ergebnis von einem Agent zu erhalten, muss man all diese Entscheidungen explizit machen. Einige Dinge lassen sich aus der bestehenden Codebasis ableiten. Sagt eurer KI, sie soll sich an einer speziellen vorhandenen Klasse orientieren. Andere Dinge gelten für das gesamte Projekt und können daher gut über ein AGENTS.md-File behandelt werden. Alles, was für die Umsetzung des aktuellen Tasks relevant ist, gehört in den Prompt oder muss der KI anderweitig zugänglich gemacht werden (z.B. Zugriff auf die User Story).

Statt während der Umsetzung implizit zu entscheiden, muss der Prozess, diese Entscheidungen zu treffen, nun vorher geschehen. Nehmt euch Zeit, den Prompt zu verfassen. Macht euch über alle Eventualitäten, die bei der Umsetzung auftauchen werden, Gedanken. Prompts, die mehrere Dutzend Zeilen lang werden, sind dabei keine Seltenheit. Die Arbeit von Entwickler:innen besteht nun darin, einer KI eine Aufgabe so genau zu beschreiben, dass sie bei der Umsetzung nicht mehr dabei sein müssen.

Learning: Implizite Entscheidungen explizit machen

Feedback

Gebt der KI Feedback, wenn das Ergebnis nicht euren Erwartungen entspricht. Dies kann direkt im nächsten Prompt sein, während man sich in die richtige Richtung iteriert. Wenn ein Problem wiederholt auftritt, ist dies ein guter Kandidat für einen Eintrag in eurer AGENTS.md-Datei.

Feedback heißt aber auch, dass eine KI selbständig prüfen kann, ob der generierte Code gewisse Qualitätsanforderungen erfüllt. Statische Code-Analyse, Linter und vor allem eine gute Testabdeckung sind eine effiziente Grundlage, um nicht nur syntaktisch, sondern auch semantisch korrekten Code zu erhalten. Die wertvollsten Tests sind seit jeher End-to-End-Tests. Dies gilt auch für Agentic Coding. Und ein Agent kann euch sehr gute End-to-End-Tests direkt mit der Feature-Implementierung liefern, die für eine händische Umsetzung vielleicht zu aufwendig gewesen wären.

Falls ihr Test-First entwickelt, auch das könnt ihr einer KI mitgeben. Lasst euch vor der Implementierung eines Features oder des Fixes eines Bugs einen Test generieren, der zunächst rot anschlägt und nach der erfolgreichen Umsetzung grün wird.

Learning: Eine gute Testabdeckung ist die Grundlage für Agentic Coding

Review

Wir hören immer wieder, das Review von Code sei das neue Bottleneck. Manche Teams fragen sich, ob ein Review überhaupt noch notwendig ist oder dies auch von einer KI übernommen werden soll.

Die Frage ist nicht, ob das Ergebnis von einem Menschen gereviewed wird, sondern wann. Wenn ich keine Code-Reviews durchführe, landet mein KI-generierter Code auf einer Staging-Umgebung (oder direkt in Production) und mein Product Owner, Product Manager oder sonstige Projekt-Verantwortliche führen das Review und das Testing des ausgerollten Artefakts durch. Wenn ich an diesem Punkt Fehler ausmache, muss ich die gesamte Umsetzungs-Pipeline von neuem durchlaufen: Erwartetes Verhalten definieren, Fix umsetzen, Pull-Request erstellen, Continuous Integration Run und Deployment.

Auch wenn das Coding von einer KI übernommen wird, dauert es je nach Deployment-Setup dennoch einige Minuten, Stunden oder Tage, bis der Fix ausgerollt ist und erneut getestet werden kann.

Auch in Zeiten von Agentic Coding gilt: Je früher ich einen potenziellen Fehler finde, desto billiger ist der Fix.

Auch vor Zeiten der KI wurden Code-Reviews von vielen als zeit- und kräfteraubend empfunden. KI verstärkt diesen Umstand nur. Das Problem ist auch nicht die KI, sondern der Umgang mit Code-Reviews. Große Pull-Requests mit Dutzenden geänderten Dateien, die keiner klaren Linie folgen, sind schlichtweg nicht sinnvoll reviewbar.

Auch beim Review von KI-generiertem Code gilt daher:

  • Schneidet Stories so klein, dass die Pull-Requests überschaubar bleiben.
  • Brecht Stories auf umsetzbare Tasks runter
  • Ein PR ändert nur eine Sache
  • Führt Reviews synchron mit Kolleg:innen gemeinsam durch
  • Führt Reviews zeitnah und in Batches durch. Lasst PRs nicht stunden- oder gar tagelang liegen

Ein weiterer Vorteil von synchronen Reviews: Es gibt mehrere Personen im Team, die den betroffenen Code gelesen und ein Verständnis dafür entwickelt haben und das Projekt-Wissen wird breiter geteilt.

Learning: Code-Reviews so angenehm und effizient wie möglich gestalten

Nicht-Determinismus als Chance

Sprachmodelle arbeiten nicht deterministisch. Der gleiche Prompt liefert bei wiederholtem Abschicken leicht bis stark unterschiedliche Ergebnisse. Dies ist kein Bug, sondern ein Feature von LLMs und wird über die Temperature gesteuert. Die Temperature erlaubt einen gewissen Grad an Zufälligkeit in der Ausgabe.

Für Software-Entwickler:innen ist es mitunter nicht leicht, dies zu akzeptieren; schließlich arbeiten die Programme, mit denen wir sonst arbeiten, ja auch deterministisch. Für den Entwicklungs-Prozess wiederum sieht es anders aus. Je nachdem, welche Person ein Feature umsetzt, wird das Ergebnis anders aussehen. Selbst die gleiche Person wird zu unterschiedlichen Zeiten zu einer im Detail anderen Lösung kommen. Die Lösungen werden sich häufig nicht fundamental unterscheiden, mitunter aber doch und die eine Variante ist tatsächlich deutlich besser für das konkrete Problem geeignet als die andere.

Etwas Ähnliches geschieht mit dem von einem LLM generierten Programmcode. Die Lösungen variieren etwas und mitunter ist eine dabei, an die ihr selber gar nicht gedacht hättet. Und für den einmal erzeugten Code greift das Versprechen des deterministischen Verhaltens natürlich wieder.

Learning: Macht euch Nicht-Determinismus zunutze