How many engineers should you have?
The answer? Fewer, more and different.
After the block announcement, I’m pretty sure you got a call from the CFO asking whether they could assume similar efficiencies in next year’s headcount budget. If you didn’t, it’s coming . . .
But there is a real question, assuming that eventually you can digitize the tacit knowledge, rework your delivery pipeline and build a high quality agentic SDLC, how many engineers will you need?
The answer is some combination of fewer, more and different - depending on your positioning and your ambitions.
You need fewer engineers
The timeline for this will vary greatly. The cruftier your code, the more archaic your infrastructure, the more human centric your processes and the more of your knowledge that still requires someone to “ask Samantha”, the longer it will take. But one day, you will have sufficient context appropriately wrangled to be able to agentically KTLO and ship new features.
When that day comes, if your current velocity is acceptable, you will need (substantially) fewer engineers.
You need more engineers
Joel Spolsky built an entire business out of finding and attracting great developers. Historically the math was pretty easy. Even in SF, you could get a great engineer for ~$300-$400k loaded. If they could deliver sufficient value through the software they shipped to deliver enough of a multiple on that to cover corporate overheads, you should hire them all day long until you run out of candidates, cash or ideas.
If an engineer can deliver 10x the functionality with substantially less management and coordination overhead, you should probably be hiring more than ever (assuming you can still capture sufficient economic value from the code that they ship).
In addition, pretty much your entire company needs to be restructured and rebuilt to be agentic first. Lots of low hanging, high value opportunities for your dev team to transform the efficiency and effectiveness of your business ops.
WHOOP is taking a page out of the Dorsey and Lutke playbooks and doubling down on both AI and hiring. The bull case for software engineers is that they just got ~10x more capable so you should hire as many of them as you can afford!
You need different engineers
Whatever happens, you will definitely need different engineers. The role is fundamentally changing from one where software engineers bring deep knowledge of syntax and APIs to pulling and shipping tickets to one where they build the systems that write the code.
For curious, flexible engineers who care about solving business problems efficiently, it’s an upgrade. For anyone who sees themself as a <language-of-choice> developer, it’s going to be a big shift.
I’ll be talking a lot more in the future about emerging good practices for hiring and retaining great AI forward engineers. The best engineering teams in two years won’t look anything like they did in 2024. The question is how many people on your team are curious enough to make the transition.
How are you thinking about the potential staffing implications of agentic engineering?