An agentic development flow makes you ship much faster. It also has a side effect that gets little attention. People talk less, ask themselves fewer questions, juggle more topics at once, and end up knowing less about what they ship. Little by little, they lose their grip on the product.
I build software with Claude Code every day, and the team I work with uses the shared flow I designed and described in An agentic development flow for a whole engineering team. I have been through this side effect myself and seen it around me. I do not think it is inevitable. You can correct it by staying hands-on at a few specific points in the flow, and by running fewer things in parallel than the tool would allow.
What fades when everything moves faster
When a feature ships in a few days, people take less and less time to discuss it. The conversations that used to happen in product-facing agile ceremonies, refinement first among them, lose their substance.
During development, you also ask yourself far fewer questions. The agent already helps with the upfront thinking, then plans, implements and tests. You get used to pre-chewed work, and you start skimming what it produces to save time.
That is where understanding wears away. A study Anthropic published in January 2026 illustrates it well (How AI assistance impacts the formation of coding skills). Fifty-two developers, mostly junior, were learning a new Python library. Those who had AI assistance averaged 50% on the final quiz, against 67% for those who coded by hand. But participants who asked for explanations or posed conceptual questions, instead of delegating all the code, kept scores of 65% or more. The study is about learning a library, not about a team flow. It still shows that how you use AI matters as much as whether you use it.
Fatigue that builds up over time
The other effect is slower. Working through a long run of tickets, switching from one topic to the next, writing and sometimes repeating the same things to the agent: over time, it wears you out. It is cognitive fatigue that does not show in a single day and builds up over time. I have felt it, I have heard others talk about it, and the topic keeps coming up in what I read.
A shared development flow, like the one I set up, already takes away part of that load. You repeat yourself less, everything is more structured, there are fewer surprises and less back-and-forth that leads nowhere. The rules also get adjusted as everyone builds things, so the flow keeps improving.
Another part of the fatigue comes from a reflex. When you discover how powerful a more or less automated development harness is, you want to fill every gap. My three agents are busy, so I pick up a fourth topic and open a fourth session. The gap is gone, but it was only temporary. The agents eventually come back to you, and if you took on too many topics, they all come back at once. The mental load grows accordingly.
Fewer topics in parallel, but finished
At first, I ran three or four tasks in parallel, sometimes five. Today I usually run two or three, often including a background topic that is not urgent: some R&D, or groundwork to introduce a large technical change. I would rather finish two topics than juggle four I am not really following, where I cannot personally vouch for the quality of the code and of the result. I sometimes open one more session for a quick need, without turning it into a topic of its own.
That number is not a rule. The smaller the topics, the more you can parallelize. It also depends on the product, the complexity of the work and the current workload. I have not found any study that measures how many agent sessions one developer can follow in parallel. What matters is not adding work just because a gap appears.
Gaps are unavoidable. I fill them differently: thinking about the current topic, getting information from another team, helping a colleague or answering their questions. There is always something useful to do outside a new session.
The same logic applies to scopes. A developer stays on one scope until it is done. The agent would let you jump from topic to topic all day, but you would then keep catching up on work you never saw happen, with more cognitive load, more slowness and weaker quality guarantees.
Owning the feature before the agent writes code
Keeping your grip starts before the first line of code. The flow I designed includes a thinking phase on the PRD, the document that describes the product need, as rounds of questions and answers. They quickly surface edge cases, unknowns, vague areas and misunderstandings, and they force you to make the topic your own.
I then ask the agent about whatever remains unclear. You come out of this phase knowing the feature much better than when you started.
A joint review at plan time with the people involved (product, QA, design) extends this work. Everyone sees what is going to be built and checks that it all fits.
Testing at the very end, once the agent is done
Once the plan is approved, the agent implements and verifies its own work. It runs its end-to-end tests several times, because it finds defects early on and fixes them. Then I test too, but at the very end, once the agent is finally satisfied.
My test does not duplicate its tests. The agent checks along the way, I do the final check. I often ask it to prepare a typical test path that I then walk through myself. It limits surprises and, above all, I understand what was built and take it in. If something escapes me, I discuss it with the agent, and go back to the plan or the PRD if needed.
A joint review after development, with product, QA or design, plays the same role for the whole team. We show what was built, check that it matches what was expected, and everyone keeps owning the feature.
The goal is to stay in control of what you ship and aware of what was produced.
Handing the first review to a tool
In my earlier note, review was the bottleneck: the agent produces faster than a team can read. Review assistants such as CodeRabbit, which I also use on my personal projects, are to me the best answer to that bottleneck.
A review assistant catches what slipped through during development, bugs included. Its eye is more neutral than that of the person who followed the agent, and than that of the agent itself. The agent may have been misled by a misunderstanding in an exchange, or by a memory that made it misread something. A review takes about twenty minutes. Once wired into the flow, the assistant talks to the agent directly, so nobody has to restart either one by hand. CodeRabbit also learns from the feedback it gets in comments and adapts to a team’s habits (learnings documentation).
It is a real time saver and a last safety net before merging, which frees up valuable time for developers. A human review still makes sense for critical changes. Without a review assistant, I think every PR should still get a human read, even a quick skim. My clear preference, though, goes to a review assistant.
Replacing ceremonies instead of keeping them on principle
At this pace, several agile ceremonies lose their value. Refinement has none left. Dailies and retrospectives seem much less useful to me, and I see far less point in working in sprints. It really depends on how each organization works.
You do need to keep moments for exchange, though. Without them, information stops flowing and the link between teams weakens. There is no silver bullet. The format depends on each team, its needs and what people want: a demo of what shipped, a technical presentation or a POC walkthrough, for example.
Deciding where the agent sits, and where you sit
A developer has expertise to bring. Taking on as many topics as possible and automating everything means setting that expertise aside. And then, what are we for? What value do we add?
To me, it all comes down to placement. You have to decide where the model, the harness and the agentic flow sit, and where you sit in all of it. Expertise must stay present and be put to use: to find the grey areas in a PRD, to judge a plan, to do the final check.
The delayed cost of a product nobody knows anymore
With how powerful AI is today, it is easy to do anything and everything. The speed you feel in the moment says little about what comes next. Losing your grip on the product ends up costing time: reworking what was shipped, absorbing a change of direction, running into surprises.
It is also a matter of company policy. I am convinced a company gains far more by always drawing on its team’s expertise, and making sure it does not ship anything, anyhow, than by shipping fast and everywhere because the tool allows it. In the long run, that second choice looks disastrous to me. Its losses do not show on delivery day. They come later, when nobody really knows what was built anymore.