When Your Developers Start Asking for More Work, Something Fundamental Has Changed

We have a monthly developer team AI update meeting at Eebz. It's informal - talking about what's working, what's not, and what we should try next. Last week, one of our developers said something that stopped me mid-sentence.

"Can I just take the whole Epic instead of a single Feature?"

We use Aha for project management, and typically break work down into Epics, each containing around five Features. A developer normally picks up one Feature at a time, works through it, ships it, picks up the next. That's been the rhythm for years. And here was someone asking to take on five times that scope in one go - not because they wanted to prove something, but because it genuinely made more sense to them now.

That's when I knew something had actually shifted.

We didn't start here

Like many dev teams, we started our AI coding journey with CoPilot. The team initially used this to autocomplete code but it was more painful and often suggested wrong stuff and did not make much difference. We then got it to review code and that was more useful. It felt incremental. A nice tailwind, not a new engine.

Then three months ago we played around with Claude Code: the difference was immediate. This wasn't autocomplete anymore. This was a tool that could hold context across an entire problem space, understand what you were trying to build, and work alongside you at a level that felt collaborative rather than assistive. The gap between CoPilot and Claude Code isn't a step - it's a floor change. We faffed around for a few weeks, deciding on the best approach but have been consistently working with it across all devs, now, for four weeks.

Getting here wasn't frictionless.

The honest barriers

Two things nearly slowed us down, and I think both are worth talking about because every engineering team considering this will face them.

The first was cost and clarity. When we initially looked at Claude Code, the pricing model was confusing and the cost felt steep for a seven-person team. This has changed significantly - at roughly £20 per seat it's now a straightforward decision. But early on, it wasn't obvious, and most of our developers were conscious of the expense. If you're evaluating this today, the economics are dramatically better than they were even a few months ago.

The second was fear. Not dramatic, hand-wringing fear, but the quiet, reasonable kind. If AI makes developers massively more productive, does the company need fewer developers? It's a fair question and I think it deserves a direct answer rather than vague reassurance.

My message to the team has been simple and I believe it completely: this is about making each of you more productive, more valuable, and ultimately better paid. A developer who can think and deliver at the Epic level instead of the Feature level isn't at risk - they're the person every company is going to be competing to hire. The threat isn't AI. The threat is being the team that doesn't adopt it while your competitors do.

Four weeks in: what we're actually seeing

I want to be careful here because the tech industry loves inflated productivity claims and I don't want to add to the noise. So here's what I can say honestly.

In four weeks of the team working with Claude Code, the increase in output has been significant. Not marginal, not incremental - a genuine step change. The Epic anecdote gives you a rough proxy: if our Epics typically contain five Features, and a developer is now comfortable taking on a full Epic, you can do the maths. But I'd rather let the behavioural shift speak for itself than attach a precise multiplier to it.

What I find more interesting than the raw output is what's changed about how the team works. The cognitive load has shifted. Developers are spending less time on implementation mechanics and more time on architecture, on thinking about the right way to solve a problem rather than grinding through the syntax of the solution. The work hasn't disappeared - it's moved up the value chain.

What this means if you're building a product company

Here's the bit that keeps me up at night - in a good way.

Eebz competes in digital shelf analytics. We're not the biggest company in this space. We don't have the largest engineering team or the deepest pockets. What we do have, now, is a seven-person dev team operating at a velocity that would have required a significantly larger team twelve months ago.

For any founder or CTO running a product-led business: this changes the economics of what you can build and how fast you can build it. Features that would have sat in the backlog for a quarter are getting shipped in weeks. The constraint is shifting from "how much can we build?" to "what should we build?" - and that's a fundamentally better problem to have.

We started with CoPilot. The real revolution was Claude Code. But the actual breakthrough wasn't the tool - it was the moment a developer looked at their workload differently and said, "Give me more."

I'll be writing more about how we're implementing AI across Eebz - not just in development, but in marketing, data engineering, and operations. If you're on a similar journey or thinking about starting one, I would like to hear what's working for you.