There is a planning conversation happening in teams everywhere right now that would have been impossible three years ago. The question on the table is no longer “how many developers do we need to hire for this.” It is “do we need to hire at all, or can the current team plus agents carry it.” That is a new kind of conversation, and I have been in versions of it more than once, so let me share how I think about it.
The old math is broken
For decades, capacity planning in software was simple in a brutal way. More scope means more people. Want to go faster, add a team. We all knew the warning from Brooks that adding people to a late project makes it later, but companies kept doing the headcount math anyway, because there was no other lever to pull.
Now there is another lever. One developer working with agents delivers what used to need two or three people, at least for the building part. I see this in my own week. Work that I would have split with a teammate, I now finish alone, because the agent does the mechanical part and I do the thinking part.
So the obvious conclusion appears in every budget meeting. Smaller teams, same output, lower cost. And honestly, part of that conclusion is right. But only part. The interesting question is which part.
Coding load went down, ownership load did not
The book Team Topologies gave us a useful idea, cognitive load. A team can only hold so much in its head. The systems it owns, the domains it serves, the tools it runs. When the load passes the limit, quality drops, people burn out, and everything slows down even with great engineers.
Here is what I learned watching agents enter our work. Agents lower the coding load a lot. They do not lower the ownership load almost at all.
Writing the integration code for a new data feed, the agent does that. But someone still has to own the questions around it. Should we depend on this provider? What happens to the downstream reports when the feed is late? Who do we call when the numbers look wrong? What is the plan when we deprecate it in two years? That is ownership, and no agent carries it. When something breaks at a bad hour, a human answers for it.
So when a company cuts a team from eight people to three because “AI makes everyone more productive,” the coding capacity may survive the cut. The ownership capacity may not. Three people can produce the code of eight, but can they hold in their heads everything eight people held? Can they be on call for it, answer audits about it, mentor on it, remember why decision X was made in 2024? Sometimes yes. Often no. And the failure shows up months later, as incidents and slow decisions, far from the budget meeting where the cut looked smart.
Small empowered teams still beat big slow ones
Do not read me wrong, I am not defending big teams. My best professional memories are from small teams with real power to decide. I lived this in my own company in Brazil. When we were tiny, just a few of us, we talked to the client directly and shipped every week, and that closeness was our superpower. As we grew, I watched it change. More people meant more coordination, more meetings, more distance between the person with the problem and the person solving it. The lesson stuck with me. A small team that owns the problem end to end will beat a big team waiting for three committees, in any era, with or without AI.
Agents actually make the small empowered team model stronger. The classic limit of a small team was hands. Not enough hands to build everything they could imagine. Agents are extra hands. So the small team can now match the output of the big one while keeping the speed of decision that made it great.
But notice the word empowered. It carries the whole sentence. A small team without authority to decide is just a cheap team. The output of agents has to be pointed somewhere, and pointing is a decision, and decisions need owners. If your org cuts headcount but keeps every decision in slow committees above the team, you bought a faster engine for a car with the brakes on.
What I would actually do
If I were planning headcount this year, my checklist would be something like this.
- Count ownership, not output. List the systems, domains, and stakeholder relationships the team must hold. That number changed much less than coding speed did.
- Keep teams small but never below the on call and bus factor line. Two people owning a critical system is not efficiency, it is risk with a nice spreadsheet.
- Spend part of the saved money on the team you keep. Better tools, training, slack time to think. A smaller team with high judgment is the whole strategy, so invest in the judgment.
- Keep hiring juniors. I wrote about this before and I did not change my mind. A small senior team with no pipeline is a slowly closing door.
The money story here is real, I will not pretend otherwise. Payroll is the biggest cost in software and AI genuinely changed how much building you get per salary. Leaders would be irresponsible to ignore it. But the teams that win will be the ones who understand what they are buying with each salary now. Not typing. Typing is cheap. They are buying ownership, judgment, and someone who answers when the system asks a hard question at 2 am.
Small team, big output is possible now. Small team, no owners is also possible, and it looks identical for about six months.
Pax et bonum.