Blog · · 6 Min. Lesezeit
Agentic Coding und Developer Experience: Was sich wirklich verändert
Developer Experience hat drei Kernelemente: Feedback-Schleifen, kognitive Last und Flow-Zustand. Agentic Coding verändert alle drei – aber anders, als man erwarten würde.
Das DevEx-Framework als Kompass
2023 veröffentlichten Abi Noda, Margaret-Anne Storey, Nicole Forsgren und Michaela Greiler das DevEx-Framework. Ihre These: Die Produktivität von Entwicklern hängt maßgeblich von drei Dimensionen ab.
Feedback-Schleifen – Wie schnell bekomme ich Rückmeldung auf meine Aktionen?
Kognitive Last – Wie viel mentale Kapazität brauche ich für eine Aufgabe?
Flow-Zustand – Wie gut kann ich mich in die Arbeit vertiefen?
Diese drei Dimensionen bieten einen nützlichen Kompass, um zu verstehen, was Agentic Coding mit unserer Arbeitsweise macht. Nicht als Theorie, sondern als Werkzeug für die Reflexion über die eigene Praxis.
Feedback-Schleifen: Schneller, aber anders
In der klassischen Entwicklung sieht die Feedback-Schleife so aus: Code schreiben → kompilieren → testen → debuggen. Je nach Setup dauert ein Durchlauf Minuten bis Stunden.
Mit Coding-Agenten verkürzt sich ein Teil davon radikal. Intent beschreiben → Code erhalten → Review → nächste Iteration. Der Weg von der Idee zum lauffähigen Code schrumpft.
Aber hier passiert etwas Interessantes. Während die Feedback-Schleife für die Code-Generierung kürzer wird, entsteht eine neue Schleife, die es vorher in dieser Form nicht gab: die Bewertungsschleife.
Ich muss den generierten Code verstehen, bewerten und entscheiden, ob er meinen Anforderungen entspricht. Das ist eine andere Art von Feedback als „kompiliert es oder nicht“. Es erfordert Urteilsvermögen statt binärer Rückmeldung.
Und diese Bewertungsschleife hat eine Tücke: Je mehr Code ein Agent generiert, desto mehr muss ich bewerten. Der Engpass verschiebt sich – von „wie schnell kann ich schreiben“ zu „wie schnell kann ich bewerten“.
Die Konsequenz: Wer Agentic Coding effektiv nutzen will, braucht schnelle Bewertungsmechanismen. Tests, Linting, spezialisierte Review-Agenten – alles, was mir hilft, schneller zu einem begründeten Urteil zu kommen. Die Generierung ist nicht mehr der Engpass. Die Bewertung ist es.
In meiner eigenen Praxis habe ich dafür ein Muster entwickelt: Ein Agent erstellt, ein zweiter Agent prüft, ich treffe die finale Entscheidung. Das klingt aufwendig, ist aber schneller als alles selbst zu reviewen – weil der spezialisierte Review-Agent Dinge sieht, die mir im ersten Durchlauf entgehen.
Kognitive Last: Weniger Syntax, mehr System
Das DevEx-Framework beschreibt kognitive Last als die mentale Verarbeitungskapazität, die eine Aufgabe erfordert. In der klassischen Entwicklung kämpfen wir gleichzeitig mit Syntax, API-Details, Patterns, Architektur und Debugging. Alles konkurriert um dieselbe mentale Bandbreite.
Agentic Coding verändert die Zusammensetzung dieser Last fundamental.
Was abnimmt:
- Syntaktische Details und API-Lookups
- Boilerplate-Code schreiben
- Routine-Debugging und Fehlermeldungen entschlüsseln
Was zunimmt:
- Agenten-Orchestrierung: Welchen Agenten nutze ich wofür? Welchen Kontext braucht er?
- Ergebnis-Bewertung: Ist der generierte Code korrekt? Passt er ins Gesamtsystem?
- Intent-Kommunikation: Kann ich präzise genug beschreiben, was ich will?
Die Gesamtlast sinkt nicht unbedingt. Sie verschiebt sich. Weg von Implementierungsdetails, hin zu Systemdenken und Kommunikation.
Das hat eine überraschende Implikation: Agentic Coding belohnt genau die Skills, die viele Entwickler nie systematisch trainiert haben. Architektur-Denken, klare Kommunikation, systematische Qualitätsbewertung – Fähigkeiten, die in der klassischen Entwicklung oft als „soft“ galten, werden zum limitierenden Faktor.
In meiner Praxis zeigt sich das deutlich: Die schwierigsten Momente sind nicht die, in denen der Agent schlechten Code schreibt. Es sind die, in denen ich nicht klar genug artikulieren kann, was ich will. Nicht „kann die KI das?“ ist die Frage – sondern „kann ich es so kommunizieren, dass sie es versteht?“
Wer mit Coding-Agenten arbeitet, lernt schnell: Die eigene Fähigkeit, Anforderungen zu strukturieren und Kontext bereitzustellen, ist der Hebel. Nicht das Modell, nicht das Tool – die Qualität der eigenen Kommunikation bestimmt die Qualität des Outputs.
Flow-Zustand: Ein anderes Fließen
Flow entsteht, wenn die Herausforderung genau zu den eigenen Fähigkeiten passt, wenn man weder unter- noch überfordert ist, und wenn Unterbrechungen minimal sind.
In der klassischen Entwicklung wird Flow häufig durch Kontextwechsel zerstört: Dokumentation suchen, API-Referenzen nachschlagen, Build-Fehler debuggen, auf CI-Pipelines warten. Jede Unterbrechung ist ein potenzieller Flow-Killer.
Agentic Coding eliminiert viele dieser Unterbrechungen. Ich muss nicht mehr aus meinem Gedankenfluss heraus, um eine API-Signatur nachzuschlagen oder Boilerplate zu tippen. Der Agent übernimmt das. Die Barriere zwischen Idee und Umsetzung wird dünner.
Aber die Natur des Flows verändert sich. Es ist weniger das „in-den-Code-eintauchen“, das viele Entwickler kennen und lieben. Es wird zu einem „im-System-denken“ – ein Flow auf höherer Abstraktionsebene.
Wenn es gut funktioniert, fühlt es sich an wie Dirigieren statt Spielen. Man bleibt im großen Bild, gibt Impulse, und das System reagiert. Man denkt in Funktionalitäten statt in Funktionen, in Ergebnissen statt in Implementierungen.
Wenn es nicht gut funktioniert – und das passiert – wird der Flow genauso zerstört wie früher. Nur aus anderen Gründen: Der Agent versteht den Kontext nicht. Er halluziniert eine API, die es nicht gibt. Er löst ein Problem auf eine Weise, die nicht ins Gesamtsystem passt. Dann muss ich raus aus dem Flow und korrigieren.
Meine Erfahrung: Der Flow in Agentic Coding ist anfangs fragiler. Man muss lernen, wann man dem Agenten vertrauen kann und wann nicht. Mit der Zeit entwickelt sich ein Gespür dafür, und der Flow stabilisiert sich – auf einem neuen Niveau.
Ein weiterer Faktor, den ich beobachte: Flow in Agentic Coding erfordert eine andere Art der Vorbereitung. In der klassischen Entwicklung konnte ich mich in den Code stürzen und mich „warmcoden“. Heute investiere ich mehr Zeit in Vorbereitung – Spezifikationen schreiben, Architektur dokumentieren, Guidelines definieren. Warum mir dabei Workflows immer wichtiger werden, habe ich separat beschrieben. Die Arbeit vor dem Coding bestimmt, wie gut der Flow während des Codings funktioniert.
Was das für die Praxis bedeutet
Drei Erkenntnisse, die ich aus dieser Perspektive mitnehme:
1. Investiere in schnelle Bewertungsmechanismen.
Die Generierung von Code ist nicht mehr der Engpass. Die Bewertung ist es. Tests, automatisierte Reviews, spezialisierte Prüf-Agenten – alles, was mir hilft, schneller zu einem fundierten Urteil zu kommen, hat den größten Hebel.
2. Trainiere die neuen kognitiven Skills.
Systemdenken, Architektur-Kommunikation, präzise Intent-Beschreibung – das sind keine Nice-to-haves mehr. Sie sind die Kernkompetenz im Agentic Coding. Wer seine kognitive Kapazität noch mit Syntax-Details und API-Lookups füllt, nutzt das Potenzial nicht aus.
3. Gestalte deinen Workflow für Flow.
Das bedeutet: Unterbrechungen minimieren, aber auch akzeptieren, dass Flow in Agentic Coding anders aussieht als früher. Es ist weniger „ich und der Code“ und mehr „ich und das System“. Wer diesen Wechsel annimmt, findet einen neuen Flow – auf einer höheren Ebene. Und wer die Vorarbeit ernst nimmt – Spezifikationen, Architektur, Guidelines – schafft die Grundlage dafür.
Die eigentliche Verschiebung
Das DevEx-Framework zeigt uns: Agentic Coding löst nicht einfach Probleme. Es verschiebt sie.
Wer Agentic Coding durch die Brille von Developer Experience betrachtet, sieht klarer, wo die echten Hebel liegen. Es geht nicht darum, noch schneller Code zu generieren. Es geht darum, die neue Art zu arbeiten bewusst zu gestalten – mit schnellen Bewertungsschleifen, den richtigen kognitiven Skills und einem Workflow, der Flow ermöglicht.
Die Entwickler, die das verstehen, arbeiten nicht einfach schneller. Sie arbeiten anders. Und genau darin liegt der eigentliche Wandel.