For a long time the question about coding agents was whether they could actually do the work. That question is quietly closing. On well-scoped tasks, with the repository in front of them and the ability to run the tests, good agents ship real changes that pass review. And the moment you trust that, you run into a problem nobody warned you about: you cannot come up with work fast enough to keep them busy.
Execution stopped being the constraint
There is always infinite work to do on a software product. The backlog is never empty; the list of things that could be better is endless. So it feels strange to say a team could run out of work for an agent. But "infinite work exists" and "work exists in a form an agent can pick up and finish" are two very different statements, and the gap between them is where teams get stuck.
An agent can execute a clear task in minutes. Writing that clear task — the one with enough context, the right scope, and a definition of done — still takes a person the same twenty minutes it always did. When execution was the slow part, that was fine; the spec was five percent of the effort and the work was the other ninety-five. Flip the execution cost toward zero and the ratio inverts. Now the spec is the expensive half, and a team that could keep one agent fed finds it cannot keep three.
The bottleneck moved upstream, to you
This is the task supply problem: the constraint on agent-driven development is no longer the agent's ability to do things, it is the organisation's ability to produce well-formed things to do. And that constraint lands on the scarcest people you have — the ones with enough context to say what should happen next and why.
You feel it as a strange kind of pressure. The agent is fast and reliable, so the queue drains faster than you can refill it, and the refilling is the part that needs judgement, product sense, and knowledge of where the system is going. The bottleneck did not disappear. It moved from the keyboard to the head of the person who knows what the keyboard should be doing.
The agent has to help supply the work
The only way past a supply problem is to increase supply, and the person who defines tasks does not scale. So the agent that executes the work has to start helping generate it — not by inventing busywork, but by turning the signals already flowing through your systems into concrete, ready-to-run tasks.
TaskGoblin does a version of this today, in two places you may not have thought of as "task generation":
- Review findings become work. Every merge request the agent reviews produces specific, located findings — this function has a correctness bug, this path isn't covered, this is a security smell. Each one is, in effect, a pre-written task with a definition of done. Reply
@taskgoblin fixand the finding turns into a change. Nobody had to sit down and write that ticket; the review supplied it. - Standing loops become work. A loop is a task generator that runs on a clock: "every weekday, find merged work whose issues are still open and close them," "watch for CI that has been red too long." The instruction is written once, and it keeps producing concrete work — or correctly producing nothing when there is nothing to do — without anyone refilling the queue by hand.
In both cases the agent is not waiting to be told what to do. It is reading the state of the system and proposing the specific, finishable next thing.
Why context is the whole game
The reason agent-proposed work is usually low-value is not that the model is not smart enough. It is that the agent does not know what matters to you. Left blind to product intent, an agent will happily suggest the twenty refactors it can see and none of the one change that actually moves the business — because the code tells it what is possible, not what is important.
That is why the useful task-generation surfaces are the ones anchored to real intent. A review finding matters because it sits on a change someone chose to make. A scheduled loop matters because a human decided that keeping issues and merges in sync is worth doing every day. The context that makes a proposed task worth doing is not in the code alone; it is in the issues, the discussions, and the decisions around the code — and an agent that lives in those systems, as ours does, can read that intent instead of guessing at it.
Where the value is now
It is worth being clear about where this leaves the advantage. As models converge on being able to execute almost anything, the disproportionate value stops accruing to whoever has the smartest agent and starts accruing to whoever can keep good agents supplied with work that matters. The winning move is not a cleverer model. It is closing the loop between the intent scattered across your tools and the agent that can act on it, so that "what should we do next" stops being a bottleneck you personally are.
That is the problem we are actually building against. Making the agent able to code was the first half. Making sure it always knows what is worth doing — and can turn your context into the next concrete task without waiting on you — is the half that decides how much the first half was worth.
