WIP limits for humans and AI
Finishing more with better quality means limiting work in progress across the whole human-and-agent system.
We recently noticed a familiar problem at work: too many tasks and pull requests were open at the same time. Then I looked at my own AI-assisted development workflow and realized I was doing exactly the same thing.
I had six projects in motion, all at different stages. Each one had agents producing code, changes waiting for review, builds to test, and decisions that only I could make. The agents were fast. The overall system was not.
The bottleneck moved
AI can generate implementation work quickly, but it does not remove the rest of the delivery system. Human review, product judgment, context switching, device testing, and release decisions still take time. Agents also compete for shared resources: environments, files, branches, CI capacity, and, in game development, the Unity editor itself.
That means the useful WIP limit is not “how many agents can run?” It is how many pieces of work the entire human-and-AI system can carry without losing clarity or quality.
A practical limit
I returned to a simple rule:
- One or two active items at a time
- Three only as a deliberate exception
- No more than two projects in active development
The effect was immediate. Reviews became more thorough. Context stayed fresh. Fewer changes waited half-finished while I chased the novelty of starting something else.
Stop starting, start finishing
AI makes starting almost frictionless, which makes WIP discipline more important, not less. The goal is not to keep every agent busy. The goal is to move valuable work all the way to done.
When throughput feels slow, adding another agent or opening another task may be the least helpful response. Look at the whole system, find the actual constraint, and protect the attention required to finish.
Adapted from a post originally published on LinkedIn.