Wo der Mensch bleibt: Agentic Coding in der Praxis
Was ich bei der KI-unterstützten Softwareentwicklung gelernt habe und wie ich es heute angehe
Agentic Coding: Was ich gelernt habe und wie ich es heute angehe
Die Diskussion um Agentic Coding schwankt zwischen zwei Extremen: “AI wird alles lösen” auf der einen Seite, “Alles nur Hype” auf der anderen.
Beide Positionen greifen zu kurz. Nach Monaten intensiver Arbeit mit Coding-Agents möchte ich mit euch teilen, was ich dabei gelernt habe – und wie sich meine Arbeitsweise verändert hat.
Der aktuelle Stand: 7 Thesen
Bevor ich zu meinen konkreten, eigenen Erfahrungen komme, hier 7 Kernthesen, zu denen Simon Wardley geschrieben hat und die ich durch meine Perspektive ergänzt habe:
Entwicklung ist noch kein Engineering. Während Testing durch Praktiken wie TDD zu einer systematischen Disziplin geworden ist, bleibt die Entwicklung zum größten Teil intuitions-getrieben. Es gibt Patterns, aber keine durchgängige Systematik. Agentic Coding könnte ein Katalysator für diese Transformation sein – wenn wir es richtig angehen.
Kleine, kontextuelle Tools schlagen Monolithen mit aufgesetztem LLM. Der vorherrschende Ansatz, bestehende Systeme einfach mit LLM-Fähigkeiten anzureichern, nutzt das Potenzial nicht aus. Effektiver sind kombinierbare Tools mit klaren Inputs, Outputs und spezifischem Anwendungskontext.
LLMs sind Kohärenz-Maschinen, keine Wahrheits-Maschinen. Sie optimieren auf Plausibilität, nicht auf Korrektheit. Das macht sie wertvoll für Entwürfe und Exploration, aber unzuverlässig für finale Entscheidungen ohne menschliche Validierung.
Code ist mehr als Funktionalität – Struktur ist die eigentliche Entscheidung. Architektonische Entscheidungen manifestieren sich im Code. LLMs können Funktionalität generieren, aber strukturelle Entscheidungen erfordern Systemverständnis.
Die Kernfrage: Wo stehen Menschen im Entscheidungsprozess? Es geht nicht darum, ob AI eingesetzt wird, sondern wo menschliches Urteil unverzichtbar bleibt. Diese Grenzziehung muss bewusst getroffen werden.
Die Praktiken sind noch im Entstehen. Was heute als State of the Art gilt, kann morgen überholt sein. Vorsicht vor vorschnellen Best Practices.
Experimentieren ja, aber mit Bewusstsein für das Terrain. Geschwindigkeit ohne Richtung ist nur schnelles Verirren.
Wie ich es heute angehe
Diese Thesen decken sich gut mit meinen Erfahrungen. Aber Theorie ist das eine, die tägliche Praxis das andere. Hier ist, was bei mir funktioniert.
Ein bewusst modulares Setup
Ich arbeite ungern mit komplett integrierten Lösungen. Nicht aus Prinzip, sondern weil sie nicht optimal für meinen Workflow funktionieren.
Mein Setup besteht aus drei Komponenten:
Eine IDE wie IntelliJ IDEA, weil ich hier den Überblick über den Code behalten kann. Schnell prüfen, wo was untergebracht ist. Die Git-Integration ist dabei eminent wichtig – sie macht Änderungen nachvollziehbar und reversibel. IntelliJ kann nahezu alles (inkl. Datenbanken inspizieren), was ich brauche. Leider kommt mit Mächtigkeit eine gewisse Unübersichtlichkeit. Für kleinere Projekte nutze ich gerne den ZED-Editor, der schlanker und übersichtlicher ist.
Das Terminal (am liebsten Ghostty) mit meinem Coding-Agent, aktuell hauptsächlich Claude Code. Hier gebe ich Anweisungen, beobachte und steuere.
Ein LLM-Chat-Fenster für die konzeptionelle Arbeit. Gerade am Anfang eines Projekts nutze ich es, um Ideen durchzuarbeiten und in ein Dokument zu bringen, bevor Code entsteht.
Diese Dreiteilung ist kein Zufall. Sie entspricht dem Prinzip der spezialisierten Tools: Jede Komponente hat ihre Stärke, keine versucht alles zu sein.
Hier und da nutze ich noch andere spezialisierte Tools, wie die GitHub Desktop App. Aber im Kern sind es diese drei, die ich benutze.
Sub-Agents als Schlüssel
Das vielleicht wichtigste Learning der letzten Monate: Spezialisierte Sub-Agents liefern deutlich bessere Ergebnisse als ein General-Purpose-Agent für alle Aufgaben. Der Grund ist simpel – der zugeschnittene Kontext macht den Unterschied.
Zwei Beispiele aus meiner Praxis:
Qualitätssicherung: Ein Sub-Agent, der ausschließlich für QA zuständig ist, prüft gegen vorgegebene Richtlinien und Dokumentationen. Er rät nicht, er validiert. Das ist im Grunde TDD-Denken auf Agent-Ebene – explizite Standards statt Intuition.
UI-Design: Bei der Gestaltung von Benutzeroberflächen erziele ich mit einem spezialisierten Design-Sub-Agent wesentlich bessere Ergebnisse. Ich kann Vorgaben machen, in welche Richtung das Design gehen soll, welche Designprinzipien gelten. Der Agent generiert innerhalb dieser Leitplanken, statt im luftleeren Raum zu arbeiten.
In beiden Fällen ist der spezialisierte Kontext und der fokussierte Systemprompt des Sub-Agents der Hebel, nicht die allgemeine Intelligenz des Modells.
Kohärenz validieren
Ja, LLM-Output hat mich schon in die Irre geführt. Tatsächlich gerade weil er plausibel klang. Die Kohärenz war da, die Wahrheit nicht.
Meine Validierung läuft zweistufig: Ich prüfe erst einmal selbst, was ich prüfen kann. Für alles andere nutze ich spezialisierte Sub-Agents mit Internetzugriff, die Fakten verifizieren können. Aber – und das ist entscheidend – schlussendlich bleibt der Mensch verantwortlich. Die Sub-Agents sind Hilfsmittel, keine Entscheider.
Und Halluzinationen bleiben nicht gerne allein. Da, wo eine Sache nicht stimmt, sind oft andere Dinge nicht valide.
Struktur im Blick behalten
Wann wird generierter Code zum Problem? Am offensichtlichsten, wenn Source-Code-Files einfach zu groß werden. Zu viele Zeilen. Zu viel Funktionalität in einzelnen Funktionen.
Mein Ansatz: Ich lasse fast alles generieren. Wenn ich Änderungen will, lasse ich die Agent anpassen und überprüfe anschließend. Die Erfahrung zeigt, dass das schneller geht als selbst zu schreiben – es sei denn, es sind kleinere Umstrukturierungen oder Korrekturen. Da greife ich direkt ein.
Die Struktur aber bleibt meine Verantwortung. Ich entscheide, wann ein File zu groß wird, wann Funktionalität aufgeteilt werden muss, wie Refactorings aussehen sollen und die Architektur sein soll. Gerade die Architektur lege ich meist fest, bevor das Codieren beginnt, und dokumentiere sie in Markdown-Dateien.
Das eigentliche Problem ist Kommunikation
Schlussendlich muss der Mensch die Entscheidung treffen, ob das Generierte gut genug ist. Das menschliche Urteil bleibt unverzichtbar, weil nur der Mensch beurteilen kann, ob er bekommen hat, was er wollte.
Und hier liegt eine unbequeme Wahrheit: Auch mit KI ist das Problem häufig die Kommunikation. Nicht “kann die KI das?”, sondern “kann ich artikulieren, was ich will?”. Das ist keine neue Erkenntnis – jeder, der je Requirements geschrieben hat, kennt das. Aber mit Agentic Coding wird es unmittelbar spürbar.
Keine Balance, sondern ein Pendel
Gibt es eine perfekte Balance zwischen schnell ausprobieren und verstehen, was ich tue? Ich glaube nicht. Es ist eher ein Hin- und Herschwingen.
Manche Ideen probiere ich einfach aus, um zu sehen, ob sie zu einem vernünftigen Ergebnis führen. Verstehen, was ich tue, muss ich spätestens dann, wenn ich von der Richtung überzeugt bin – und prüfen will, ob sie tragfähig für die Zukunft ist.
Das ist ehrlicher als jede Best Practice. Die Praktiken entwickeln sich noch. Wer heute behauptet, den optimalen Workflow gefunden zu haben, wird in sechs Monaten anders arbeiten.
Die offene Frage
Die architektonische Kernfrage unserer Zeit bleibt: Wo platzieren wir Menschen im Entscheidungsprozess?
Das ist keine technische Frage. Es ist eine Frage der Organisation, der Verantwortung, des Designs. Jede Organisation muss sie für sich beantworten – bewusst, nicht durch Tool-Adoption implizit.
Meine Antwort, Stand heute: Der Mensch entscheidet über Struktur, validiert Ergebnisse, trägt Verantwortung. Die Agents generieren, spezialisieren, beschleunigen. Die Grenze ist nicht fix, sie verschiebt sich mit jedem Learning.
Und genau das macht diese Zeit so interessant.