The Task Supply Problem

Until recently, the constraint on AI coding agents was capability. Could they understand the codebase? Could they write code that actually worked? Could they handle ambiguity without going off the rails? Those problems are rapidly being solved. The emerging bottleneck is having enough work to give them.

This sounds backwards. How could we possibly run out of work? Software projects have infinite backlogs. There’s always more to build.

However, there’s a difference between “work that exists” and “work that’s ready for an agent.” The latter requires someone to think through what needs to happen, write it down clearly enough that an agent can execute it, and prioritize it against everything else. That takes time. Human time.

The way that this becomes a problem is structural. Agent execution scales infinitely. Human task generation doesn’t.

We can spin up more agents. We can run them in parallel. We can run them overnight, over weekends, across time zones. But we can only think of and specify work at human speed. One person, one brain, maybe eight productive hours a day.

…we can only think of and specify work at human speed. One person, one brain, maybe eight productive hours a day.

We’re already seeing this. Teams adopting coding agents report the same pattern: initial excitement as agents chew through well-written and tightly-scoped issues, followed by a strange new pressure—the pressure to feed the machine. The agents are waiting. What should they work on next?

The obvious response? “Just write more specs.” This may suffice as a temporary fix, but it misses why the problem is hard.

Before agents, specification cost was amortized over implementation time. You’d spend an hour writing a spec, then an engineer would spend a week building it. The spec was 5% of the effort.

Now implementation takes minutes. The spec can spike to upwards of 50% of the effort. The economics have inverted, but the work required hasn’t decreased. This creates a ceiling.

Even with perfect trust in your agents, even with infinite compute budget, you hit a point where you simply cannot generate work fast enough to utilize them. The gap between “what agents could do” and “what we can ask them to do” widens every time agents get faster.

The only way to break this ceiling is for agents to participate in task generation, not just task execution.

The only way to break this ceiling is for agents to participate in task generation, not just task execution.

Now things get interesting. Agents are already capable of proposing their own work. They can scan a codebase and find dead code, test gaps, documentation drift, dependency issues. They can identify refactoring opportunities, surface potential bugs, and suggest improvements.

So why isn’t this already happening everywhere?

Because code is only half the picture. Agents can read your repository perfectly—it’s version controlled, structured, fully accessible. But they can’t read your product intent. They don’t know why you’re building what you’re building, what you tried before and abandoned, what the CEO said in last week’s all-hands, or which customers are screaming about which problems.

Agents can read your repository perfectly—it’s version controlled, structured, fully accessible. But they can’t read your product intent.

That context lives in Slack threads, meeting recordings, scattered docs, Linear comments, and the heads of people who’ve been around long enough to know where the bodies are buried. It’s illegible to agents in a way that code isn’t.

This is why agent-proposed work tends toward the low-value end of the spectrum. “Delete dead code” and “add test coverage” are safe suggestions because they require only code context. “We should refactor the auth flow before the enterprise launch” requires understanding conversations the agent never saw.

The unlock is making product context as accessible as code.

This is more tractable than it sounds. LLMs are remarkably good at synthesizing unstructured information. The hard part isn’t interpretation—it’s access. If you can get meeting transcripts, Slack history, issue discussions, and decision logs into a searchable form, agents can connect the dots.

The progression looks something like this: agents start with code-only analysis, proposing maintenance work. As they gain access to more context—public channels, issue trackers, meeting transcripts—they move up the value chain. Bug discovery. Feature proposals. Eventually, with enough context, project planning.

We’re not predicting this. We’re watching it happen.

The industry is still focused on capability: making agents smarter, faster, and more reliable. That work matters—but it’s solving yesterday’s bottleneck.

The teams getting disproportionate value from agents aren’t the ones with the smartest models. They’re the ones who’ve figured out how to keep their agents busy with valuable work.

The next wave of productivity gains won’t come from agents that can do more. It’ll come from agents that know what to do.