Moving Beyond Execution-Based Engineering Scaling
Because AI types faster than you and doesn’t need a lunch break
We used to scale engineering teams based on execution capacity. With AI, we’ll scale them based on cognitive load.
In the old model, if an inventory feature needed six engineers’ worth of work and you only had three, you hired three more (four, if you’d been burned by attrition before). More work meant more humans because humans were the execution layer.
In the AI model, agents handle most of the execution. You still need a small number of engineers who deeply understand the feature—at least two, to avoid bus factor—but if you need more execution throughput, you buy it as tokens, not headcount.
By cognitive load, I mean something very specific: deep ownership of a system. Understanding how it works technically, how it serves the customer, where it can fail, and which invariants actually matter. This has to live with an engineer. If secrets leak or data is corrupted, you can’t reasonably hold a PM—or today’s app-builder tools—responsible. It’s possible those tools eventually get good enough to own this kind of accountability, but they’re not there yet. You still need a throat to choke, and it needs to belong to someone who actually understands the system.
That’s the real limit. Not how much code can be written, but how many systems an engineer can accurately hold in their head and be accountable for at once.
A few corollaries fall out of this.
First, the more AI reduces cognitive load, the smaller engineering teams can be without breaking. Execution is cheap; understanding is not.
Second, for agents to act like real execution engineers, we need to be far better at sharing context with them. They need to know the codebase, the invariants, and the “why,” not just generate plausible diffs. That implies documentation living with the code. Engineers won’t reliably do this, but agents can—if we make auto-updating docs part of the workflow.
Third, engineers are going to write far less code. Possibly none. Their primary job becomes reviewing generated code submitted by PMs or other non-engineers, or handing designs to agents and letting them implement. Even when engineers make major changes, they’ll often do it by directing an agent rather than typing everything themselves.
The underlying AI is probably good enough already. What’s missing are the tools: context management, infra automation, and guardrails that reduce supervision overhead instead of adding to it.
In the AI era, teams won’t scale with how much work needs to get done. They’ll scale with how much responsibility a human can realistically carry.