Working with Agentic AI in Agile Development

This isn’t a how-to guide. These are my observations from working with agentic AI in a product development context — and what I think it means for the way we work.

1. Agentic AI: What’s new — and why now?

Software development has evolved in waves — each time new tools took over parts of human work and shifted focus to higher levels of abstraction. From assembler to high-level languages, from manual builds to CI/CD pipelines, from local codebases to the cloud. Each wave didn’t replace developers — it shifted their work away from mechanical execution toward decision-making, design, and context. AI-assisted development tools are the next evolutionary step, and the current generation goes far beyond autocomplete: Agentic AI.

1.1 What is Agentic AI?

An AI agent is not the same as a chatbot or an autocomplete system. The decisive difference lies in autonomy across multiple steps.

While a chatbot responds to a question and waits, an agent can:

• Break a task down into subtasks independently
• Use tools (run code, start tests, read and write files, call APIs)
• Decide between steps which path makes sense next
• Detect errors and iterate without human interruption

The spectrum ranges from assisted work — the human decides, the agent executes — to fully autonomous delivery, where the agent takes on a task and returns the result for human review.¹

Forrester Research describes this shift as the beginning of the Agentic Software Development Life Cycle (ASDLC): AI agents actively participate in the entire process chain — from requirements analysis through implementation to testing.²

This development follows a logic as old as programming itself:

Assembler      → We talk to the machine in its language
High languages → We talk to the machine in our logic
IDEs           → We talk to the machine in our syntax
Agents         → We talk to the machine in our language

Each level took over part of the mechanical work — and lifted humans to a higher level of abstraction. The agent is the logical continuation of that: a tool. Nothing more, nothing less.

2. What I’m observing

2.1 Delivery accelerates — and Discovery falls behind

Observation B1: Agentic AI makes product discovery visible as the bottleneck.

AI agents can today independently write code, test, and iterate — in hours instead of days. According to Anthropic’s 2026 Agentic Coding Trends Report, development teams can already handle 60% of their tasks collaboratively with agents, and the share of fully delegatable tasks is growing continuously.³

This leads to a critical point: delivery becomes faster and more visible. The concern that drove many organizations toward classical project management — “Can we even deliver on time?” — is losing weight.

But speed alone doesn’t explain everything. The delivery bottleneck also had a psychological dimension that’s rarely spoken aloud: releases were anxiety-laden. Mostly because the question “Is this good enough?” could rarely be answered with confidence. Testing was expensive, manual, incomplete.

Agentic AI can change this — more iterations in the same time, potentially more confidence. But this speed gain comes with a new risk: building faster in the wrong direction is just as easy and just as expensive as building faster in the right one.

The evidence is clear: most failures in agent-assisted development don’t come from model weaknesses. They come from context failures — missing, contradictory, or unclear information that the agent has to work with.⁴

That’s the core of the paradigm shift:

Before:  Delivery was the visible bottleneck.
         "Can we build it in time?"

Today:   Agentic AI makes discovery visible as the bottleneck.
         "Do we actually know what the right thing to build is?"

Why agile — and why it often fails

Agile ways of working didn’t succeed because they introduced cool practices. Their real value: they made transparent that building products for real users is not a complicated problem — it’s a complex one. Complex problems need iteration, feedback, and the willingness to course-correct — not a fixed playbook.

Many organizations still fail at this today — not because agile is wrong, but because they maintain a command-and-control structure that undermines core principles like user proximity through hierarchical distance. 97% of C-suite members believe they model agile leadership — only 2% of delivery teams agree.⁵

Agentic AI doesn’t improve this pattern. In complex domains, it makes it more expensive.

2.2 Responsibility drifts toward the agent

Observation B2: Uncontrolled delegation of ownership is THE systemic risk.

We’ve reached an important moment in the evolution of software development: we now speak to agents the way we speak to humans. And our brains do exactly what they’ve been doing for millions of years when faced with a human-like interlocutor: they attribute intent, understanding, and responsibility.

This doesn’t happen out of naivety. It happens because our brains don’t distinguish: “something responds in my language” gets processed as “someone” — and with someone, you share responsibility. Knowing this doesn’t protect you. Even those who understand that an agent is a tool experience this reflex.

The consequence: whoever gives up ownership loses the ability to judge quality. No quality judgment means no learning loop. No learning loop means no intrinsic responsibility — neither for the output nor the outcome. This isn’t a theoretical risk. It’s already observable in practice: teams saying things like “That wasn’t me — that was my agent.”

2.3 Discovery competence becomes the differentiator

Observation B3: Roles that improve discovery quality become more critical, not more redundant.

Discovery describes the part of the iterative process in which loose ideas are generated and formed into concrete working items — the thinking that happens before the first line of code is written. When delivery is no longer a bottleneck, the quality of this thinking becomes the decisive variable.

These skills aren’t new. But they were long invisible, because delivery was the more visible constraint. Teams that shipped fast appeared competent — regardless of whether they built the right thing. That effect is increasingly disappearing.

What I observe: teams with a strong discovery culture adapt agent-assisted development quickly and with good results. Teams without it experience the opposite — not because the tools are weaker, but because the weakness lies in the input. Bad context produces bad output — and with agents, that happens at a pace that leaves little room for quiet corrections.

The consequence: roles that can improve discovery quality — Team Coaches, Product Managers, UX — are gaining strategic importance. Not because they operate agents, but because they own the quality of the input those agents work with. The leverage isn’t in the prompting. It’s in the thinking that comes before it.

2.3.1 The role of the Team Coach

If discovery quality is the decisive lever, then the person who builds discovery competence within a team becomes strategically more important.

The Team Coach takes on a concrete task in this context: actively teaching and facilitating discovery techniques — not as a one-time training, but as continuous accompaniment in everyday operations. The goal is team enablement: teams that can sharpen hypotheses, build user understanding, and structure context — without the coach as a bottleneck.

This has a consequence that’s rarely made explicit: the Team Coach must master these techniques themselves. Not just as theoretical knowledge, but in practice. Anyone who wants to facilitate hypothesis framing, user research, scope design, or context engineering needs to know what it feels like to do it well — and where the typical mistakes lie.

At the same time, the Team Coach is also the person who designs and anchors structures against uncontrolled ownership delegation. B2 isn’t an attitude problem solvable through awareness — it requires concrete formats, roles, and rituals that explicitly keep ownership with humans. The Team Coach designs exactly that: Who reviews agent output against the team’s own hypothesis? Who writes the scenarios against which validation happens? Who leads the pivot-or-persevere conversation? These structures don’t emerge on their own. They need to be introduced, explained, and kept alive.

The Team Coach addresses both observations simultaneously: enabling better discovery (B3) — and protecting teams from the reflex to hand off ownership (B2). Not as a gatekeeper, but as a multiplier and structure-builder.

3. My take

From these three observations, here’s what I believe:

Agentic development does not make agile ways of working and the people who shape them obsolete in complex domains. It makes them more important than ever.

What this means concretely:

If B1 holds — that Agentic AI makes discovery the bottleneck — then investing in discovery competence is no longer a culture question. It’s an effectiveness question. Anyone building teams and designing processes today would do well not to treat discovery as a precursor to “the real work.” It is the real work.

If B2 holds — that ownership delegation is a systemic risk — then Agentic AI without ownership structures isn’t an efficiency gain. It’s a slow-motion quality loss. If you don’t know who owns the result, you can’t improve it. The question “who is responsible?” isn’t a formality — it’s the mechanism through which teams learn.

If B3 holds — that discovery-competent roles become more critical — then the value of Team Coaches and UX roles shifts not despite Agentic AI, but because of it. Not because these roles operate agents, but because they determine the quality of the context agents work with.

This is not a universal truth. It comes from my own work — and is therefore testable.