Headcount planning has traditionally worked from a fairly stable assumption: a team of a given size and seniority mix produces roughly a predictable amount of delivery capacity, adjusted for the usual factors: domain complexity, codebase maturity, process overhead. That assumption is getting shakier, because two teams of identical size and seniority can now have meaningfully different effective capacity depending on how well they've integrated AI tooling into their actual workflow, not just whether they have access to it.
That gap is wide enough that it changes the planning question. "How many engineers do we need for this roadmap" implicitly assumes a stable capacity-per-engineer figure. A more useful question is closer to "what's our effective capacity per engineer today, and is it a tooling and process gap or a headcount gap if we're falling short," because the two have very different fixes, and hiring is the expensive, slow one.
Why this matters for hiring specifically
A team that's under-delivering because of a headcount shortfall needs more people. A team that's under-delivering because it hasn't adapted its workflow, review process, or tooling to get real leverage from AI-assisted development needs different practices, not necessarily more people. Hiring into a capacity gap that's actually a process gap tends to compound the problem rather than fix it, since new hires inherit the same under-optimized workflow.
What this looks like in practice
Before greenlighting a headcount increase, it's worth an honest look at whether the team's tooling, review cadence, and delivery process are actually capturing the capacity gains that are available, or whether the team is running meaningfully behind what a well-adapted team of the same size could produce. That diagnostic is less satisfying than approving a requisition, but it's frequently the cheaper and faster fix, and it changes what the eventual hiring plan should actually target, if hiring turns out to be the right answer after all.