Should You Hire Developers in the AI Era?

Back in March 2024 I wrote a post asking should you hire developers? My answer then was “probably not as many as you think”. Hiring for speed was usually a red flag for a broken delivery process, every extra hire brought diminishing returns, and I’d always favour a small but mighty team.

Two and a half years later, I’ve been working with AI coding agents every day for about a year, and I’ve been rereading that post. I don’t think I was wrong. If anything, I didn’t go far enough. So rather than rewrite the old one, here’s where my thinking has got to now.

The old SaaS playbook was always “hire more people”

For a long time, the default way to grow a software company was simple: raise money, hire more people, ship more features, raise more money. Headcount was treated as progress. A bigger engineering team was something to announce, not something to justify.

To be honest, it never worked as well as the pitch decks suggested. Everything I wrote in 2024 about diminishing returns, busy work and concurrent workstreams was a description of that model failing. More people meant more communication overhead, more forward planning, more half-finished features nobody heard about, and a product that got harder to change.

What’s different now is that even the big players are saying it out loud. In April 2025, Shopify’s CEO Tobi Lütke told his teams that before asking for more headcount and resources they “must demonstrate why they cannot get what they want done using AI” (TechCrunch). Whatever you think of that memo, it’s a big public company admitting that “hire more people” is no longer the automatic answer.

Execution has never mattered more

When anyone can produce a working prototype in an afternoon, the code itself stops being the moat. What’s left is execution: deciding what to build, building it well, getting it in front of the right people and listening to what comes back.

That’s the bit I underplayed in 2024. I said the first question should always be “what to build”, not “how to build” or “how quickly to build”. With agents, the “how quickly” question has more or less answered itself. Output is cheap. Good decisions aren’t.

And the faster you can build, the more damage a bad decision does. An agent will happily build the wrong feature, fully tested and nicely structured, in a fraction of the time it used to take. A team of ten people each running agents can build ten wrong features in parallel. That’s not a productivity gain, that’s a backlog of things you’ll have to maintain or rip out.

Deep pockets aren’t the advantage they used to be

If the old model was “whoever can burn the most cash wins”, you’d expect the biggest companies in the world to be launching the best products. Some of the most visible examples of the last few years suggest otherwise.

• Apple and Siri. Apple showed off a far more personal Siri at WWDC in June 2024. In March 2025 it told Daring Fireball that “it’s going to take us longer than we thought to deliver on these features”, and The Verge reported Bloomberg’s account that senior executives had concerns the features didn’t work as advertised in their own testing. The new Siri finally started rolling out in beta in September 2026, and Apple says it was built in collaboration with Google and its Gemini models (Apple Newsroom). One of the richest companies on the planet took over two years and a partner’s models to ship what it demoed.
• Google and Bard. In February 2023, a promotional demo of Bard confidently gave a wrong answer about the James Webb Space Telescope. Alphabet lost $100 billion in market value the day the error was reported (Reuters). Google invented a lot of the technology behind these models and still got caught rushing a launch.
• Meta and Reality Labs. Meta’s Reality Labs division, home of its metaverse bet, reported an operating loss of $19.2 billion in 2025, on top of $17.7 billion in 2024 and $16.1 billion in 2023 (Meta 10-K segment data, SEC). That’s what being able to burn the most cash looks like, and it hasn’t bought a hit product.

Don’t get me wrong, none of these companies are going anywhere. But if money and headcount were what produced great products, these would be the easiest launches in the world. They clearly aren’t. Meanwhile, small teams and solo founders are shipping genuinely useful software with a fraction of the resources, because they can make decisions quickly and stay close to their users.

Hiring in 2026 is harder than ever

Even if you decide you do need to hire, the process itself has got worse.

Candidates are using AI throughout their applications. In a Gartner survey of 3,290 job candidates at the end of 2024, 39% said they’d used AI during the application process, including 29% who used it to generate answers to assessment questions (Gartner). In a later survey, 6% admitted to interview fraud, either posing as someone else or having someone pose as them, and Gartner predicts that by 2028 one in four candidate profiles worldwide will be fake (same source).

Employers are doing the same thing from the other side, screening CVs with AI and running automated interviews. So you end up with AI-written applications being filtered by AI-powered screening, and it’s not obvious that anybody learns much about anybody in the process.

I was hiring at the end of last year and I was shocked by how much it had changed. I felt we did everything right - dedicated talent partner to sift candidates, thoughtful interview process, no easily gamed assessment. I joined one call to a candidate that couldn’t speak English. Another aced our interview with answers that were a bit too perfect. I asked for a face to face and they disappeared. In the end I hired somebody I already knew, having lost all faith in the process.

The death of assessment

In 2024 I wrote about testing developers and why take-home projects were a poor way to judge a candidate. Back then, my objection was that they were unpaid, artificial and favoured people with lots of free time.

Now there’s a simpler problem: an agent can complete a typical take-home test in minutes. The same goes for most online coding tests and a lot of the classic “reverse a linked list on a whiteboard” questions. If the assessment can be passed by the tool the candidate will use on the job anyway, it isn’t measuring the candidate.

What it can’t easily fake is how someone thinks. How they break a problem down, which questions they ask, what they push back on, whether they notice when an agent has produced something that looks right and isn’t. The only test I still trust is the one I recommended in 2024: pair with them on a real problem. The difference now is that the pairing session should include an agent, because that’s how the work actually gets done.

That’s also why I care far more about approach than skills. Knowing a particular framework is exactly the thing agents commoditise. Judgement and taste are what you’re paying for.

The big unknown: how far can one person go?

In the 2024 post I mentioned Sam Altman’s prediction of the first billion-dollar solo company. It sounded like a stretch then. It sounds less like one now, but the honest answer is that nobody knows yet how far one person can scale as a manager of agents.

What I can say from my own experience is that the bottleneck moves. When agents do most of the typing, I’m no longer limited by how much code I can write. I’m limited by how many things I can hold in my head at once, how quickly I can review what comes back, and how good the standards in the codebase are for the agents to copy. Start a project with sloppy patterns and the agents will scale the sloppiness faster than any team of juniors ever could.

Then there is the tool adoption. In a year I’ve gone from tentatively using Claude Code to having many concurrent agents running in herdr and recently running Cursor agents via Grok Bot. I’ve gone from one issue at a time to multiple projects at a time. The biggest challenge now though moves from time to execute to context switching in pursuit of a defensible moat.

Interestingly, the same problems I described in 2024 turn up again, just in a different shape. Run too many agents on too many workstreams and you get the agent version of busy work: lots of small changes, context spread thin, and nobody (including you) really understanding what each piece is for. The two-pizza team rule might simply become a “how many agents can one person genuinely supervise” rule. I don’t know where that line is yet. I suspect it’s lower than the hype suggests.

So, should you hire developers?

Most of the checklist from 2024 still stands, with a couple of additions:

• Why are we hiring, and is it really just to go faster?
• Do we know what we’re building, and have customers validated it?
• Could one person with agents do this, if the codebase gave them good patterns to copy?
• Are we hiring for judgement and approach, or for a skill an agent already has?
• How will we actually assess them, now that most tests can be passed by AI?
• Can the rest of the business cope with more output, or will features just pile up unseen?

And the most important question is the same one I asked last time: do I need to scale the team, or do I just need to prioritise better? In 2026, the answer is even more likely to be the second one.

As before, I’d genuinely love to hear from anyone who sees it differently. If you’ve grown a team recently and it’s made you faster and better, drop me a message, as I’d love to know what I’m missing.