Why coding-agent adoption stalls after the first month

Stefan-Iulian Tesoi · 9 September 2026 · 6 min read

Coding-agent adoption stalls because the first month spends a backlog that was written over the previous year. Once those well-understood items are gone, the team is specifying work at the speed agents consume it for the first time, and nobody planned for that.

Throughput drops back towards where it started. It reads like the agents getting worse. Nothing about the agents changed — which is why the usual question, why AI coding tools stall, has an answer that is not about the tools.

What happens in month one?

Something that looks like a step change and is partly an inventory clearance.

Most of an AI coding agent rollout is over by the end of week two, and it goes well. Every team carries a backlog of work that is well understood and never quite urgent enough: the refactor everyone agrees on, the settings page nobody had a week for, the four small fixes that keep getting deferred. Those items are unusually well specified, because they have been discussed repeatedly over months and the ambiguity got argued out of them long ago.

Point Claude Code or Cursor at that pile and it empties fast. The work was ready; only capacity was missing. The numbers from those weeks are real and they are not a baseline, because the input was a year of accumulated specification rather than this week's.

Why does coding agent adoption stall?

Because the supply of specified work is the constraint, and it was invisible while a different constraint was binding.

For twenty years the slow step was building. Specification happened at whatever pace was convenient and still arrived early, so nobody measured how fast a team can produce executable items — there was never a reason to know. The number turns out to be low, and it is low for an unglamorous reason: writing an item well enough to be executed without a follow-up question takes most of an hour, and nobody's calendar has four of those.

So the picture at week five is agents idle, an engineer who has stopped being the bottleneck, and a queue in front of one person's attention. Sprint planning stops being a capacity negotiation and quietly becomes a readiness check, usually before anyone renames the meeting. That is a product-ownership gap, and it is the opposite of a tooling problem.

Three fixes teams try first

All three are reasonable, and all three address something other than the constraint.

The third is the most expensive, because a migration takes weeks and produces a tidier list of items that still do not say which repository to build in. Agent adoption problems mostly look like tool problems from the inside, which is why the tool gets changed first.

How do you tell which phase you are in?

Four numbers, an hour of work, and they are comparable next month:

1. Specification lead time. For the last ten items shipped, the time from "prioritised" to "ready to start". Compare it to the build time. The larger one is your constraint.
2. Clarification rate. How many of the last twenty items needed a question answered before work could begin. Above a third is a backlog problem, not an inquisitive team.
3. Agent idle time. How long agents wait for work, as opposed to waiting for review.
4. Rework cause. For work sent back last month, label each as bad code or bad criterion. The ratio is the number almost nobody has looked at.

If specification lead time exceeds build time, you are past month one whatever the calendar says. Teams that never had much written down hit this almost immediately and often mistake it for the agents underperforming — the stall is not really about time, it is about when the inventory runs out.

What restarts throughput?

Making specified work arrive at the rate it is consumed, which means changing where the work happens rather than how hard anyone tries.

Three things, in the order they pay:

• Specify per item, not per meeting. Weekly grooming was sized for weekly consumption. At forty minutes an item, Monday's batch is gone by Tuesday and the queue grows for three days.
• Make refusals cheap. An item that cannot be made executable should come back naming the missing fact, in a minute, rather than being guessed at and rebuilt later.
• Verify against criteria written in advance. Rework is a large fraction of the apparent slowdown, and about half of it is a specification defect rather than an implementation one. Sending those back unchanged produces the same failure twice.

None of that is glamorous and none of it involves the agents at all. That is the point, and it is why Laimonade exists as a product rather than a checklist — an AI product owner is a product rather than a habit because the work is repetitive, and repetitive work is exactly what decays on a busy week. The four defects in a backlog an agent can actually read are what this actually consists of, item by item, and getting started is where to begin if you want to try it against your own next twenty items.

For the wider pattern — a constraint moving rather than disappearing when you remove it — the theory of constraints has described this since the 1980s in factories. Nothing about it is new except which step was slow.

Frequently asked questions

Is the stall a sign the agents are not good enough?

Almost never, and the timing gives it away. Model quality does not change between week four and week five, but throughput does — which points at the input rather than the tool. The check that settles it is agent idle time: if agents are waiting for work rather than producing poor work, the constraint has moved upstream of them.

Does adding more agents help?

Only if agents were the constraint, and by week five they usually are not. Adding a third agent to a team that cannot specify work for two produces a third idle agent and more review surface. The ceiling on useful parallel agents is set by specification and review capacity, which is a human number and not a compute one.

How long does the stall usually last?

As long as the specification rate stays below the consumption rate, which means indefinitely if nothing changes. It is not a phase that passes on its own — there is no point at which a team gets used to it and throughput recovers. What ends it is either producing executable items faster or accepting the lower number as the real one.

We never had a big backlog. Does this still apply?

More sharply, and sooner. A team with three weeks of written-down work hits the wall in the first fortnight and often concludes the agents were oversold, because there was no month-one boost to compare against. The diagnosis is identical; only the timeline is shorter.