Blog · · 6 Min. Lesezeit
Agentic Coding and Developer Experience: What Really Changes
Developer experience has three core elements: feedback loops, cognitive load and flow state. Agentic coding changes all three – but differently than you might expect.
The DevEx framework as a compass
In 2023, Abi Noda, Margaret-Anne Storey, Nicole Forsgren and Michaela Greiler published the DevEx framework. Their thesis: developer productivity depends largely on three dimensions.
Feedback loops – How quickly do I get a response to my actions?
Cognitive load – How much mental capacity does a task require?
Flow state – How well can I immerse myself in the work?
These three dimensions are a useful compass for understanding what agentic coding does to the way we work. Not as theory, but as a tool for reflecting on your own practice.
Feedback loops: faster, but different
In classic development, the feedback loop looks like this: write code → compile → test → debug. Depending on the setup, one round takes minutes to hours.
With coding agents, part of that shrinks radically. Describe the intent → get code → review → next iteration. The path from idea to working code gets shorter.
But something interesting happens here. While the feedback loop for code generation gets shorter, a new loop emerges that didn’t exist in this form before: the evaluation loop.
I have to understand the generated code, evaluate it and decide whether it meets my requirements. That’s a different kind of feedback than “does it compile or not”. It takes judgment instead of a binary answer.
And this evaluation loop has a catch: the more code an agent generates, the more I have to evaluate. The bottleneck shifts – from “how fast can I write” to “how fast can I evaluate”. I wrote about this shift in “Der neue Engpass” (in German).
The consequence: if you want to use agentic coding effectively, you need fast evaluation mechanisms. Tests, linting, specialized review agents – anything that helps me reach a well-founded judgment faster. Generation is no longer the bottleneck. Evaluation is.
In my own practice, I’ve developed a pattern for this: one agent creates, a second agent reviews, I make the final decision. It sounds elaborate, but it’s faster than reviewing everything myself – because the specialized review agent spots things I miss on the first pass.
Cognitive load: less syntax, more system
The DevEx framework describes cognitive load as the mental processing capacity a task requires. In classic development, we wrestle with syntax, API details, patterns, architecture and debugging all at once. Everything competes for the same mental bandwidth.
Agentic coding fundamentally changes the composition of this load.
What decreases:
- Syntactic details and API lookups
- Writing boilerplate code
- Routine debugging and deciphering error messages
What increases:
- Agent orchestration: Which agent do I use for what? What context does it need?
- Evaluating results: Is the generated code correct? Does it fit the overall system?
- Communicating intent: Can I describe precisely enough what I want?
The total load doesn’t necessarily go down. It shifts. Away from implementation details, toward systems thinking and communication.
That has a surprising implication: agentic coding rewards exactly the skills many developers never trained systematically. Architectural thinking, clear communication, systematic quality assessment – skills often considered “soft” in classic development become the limiting factor.
In my practice, this shows clearly: the hardest moments aren’t the ones where the agent writes bad code. They’re the ones where I can’t articulate clearly enough what I want. The question isn’t “can the AI do it?” – it’s “can I communicate it so that it understands?”
Anyone working with coding agents learns quickly: your own ability to structure requirements and provide context is the lever. Not the model, not the tool – the quality of your own communication determines the quality of the output.
Flow state: a different kind of flow
Flow happens when the challenge matches your abilities exactly, when you’re neither under- nor overwhelmed, and when interruptions are minimal.
In classic development, flow is often destroyed by context switches: searching documentation, looking up API references, debugging build errors, waiting for CI pipelines. Every interruption is a potential flow killer.
Agentic coding eliminates many of these interruptions. I no longer have to leave my train of thought to look up an API signature or type boilerplate. The agent takes care of that. The barrier between idea and implementation gets thinner.
But the nature of flow changes. It’s less the “diving into the code” that many developers know and love. It becomes “thinking in systems” – flow at a higher level of abstraction.
When it works well, it feels like conducting instead of playing. You stay with the big picture, give impulses, and the system responds. You think in features rather than functions, in outcomes rather than implementations.
When it doesn’t work well – and that happens – flow is destroyed just like before. Only for different reasons: the agent doesn’t understand the context. It hallucinates an API that doesn’t exist. It solves a problem in a way that doesn’t fit the overall system. Then I have to leave the flow and correct it.
My experience: flow in agentic coding is more fragile at first. You have to learn when you can trust the agent and when you can’t. Over time, you develop a feel for it, and flow stabilizes – at a new level.
Another factor I’ve noticed: flow in agentic coding requires a different kind of preparation. In classic development, I could dive into the code and warm up by coding. Today, I invest more time in preparation – writing specifications, documenting architecture, defining guidelines. I’ve described separately why workflows are becoming increasingly important to me (in German). The work before coding determines how well flow works during coding.
What this means in practice
Three insights I take away from this perspective:
1. Invest in fast evaluation mechanisms.
Code generation is no longer the bottleneck. Evaluation is. Tests, automated reviews, specialized review agents – anything that helps me reach a well-founded judgment faster has the biggest leverage.
2. Train the new cognitive skills.
Systems thinking, communicating architecture, describing intent precisely – these are no longer nice-to-haves. They are the core competence in agentic coding. If you still fill your cognitive capacity with syntax details and API lookups, you’re not using the potential.
3. Design your workflow for flow.
That means minimizing interruptions, but also accepting that flow in agentic coding looks different than it used to. It’s less “me and the code” and more “me and the system”. Embrace this change and you’ll find a new flow – at a higher level. And if you take the groundwork seriously – specifications, architecture, guidelines – you lay the foundation for it.
The real shift
The DevEx framework shows us: agentic coding doesn’t simply solve problems. It shifts them.
Looking at agentic coding through the lens of developer experience makes it clearer where the real levers are. It’s not about generating code even faster. It’s about consciously shaping the new way of working – with fast evaluation loops, the right cognitive skills and a workflow that enables flow.
Developers who understand this don’t just work faster. They work differently. And that is the real change.