From five developers to 25: rolling Claude out to a development team
I’d been using AI in software development for somewhere between 18 months and two years by the time this happened.
In AI terms, that feels slightly like saying I’d been there since the Industrial Revolution.
I’d watched coding models go from being useful for autocomplete, boilerplate and the occasional surprisingly good answer, to being capable of understanding large chunks of a codebase, planning changes across multiple projects and implementing features that would have taken a developer a meaningful amount of time.
During a contracting role, this started coming up more and more in conversations with the development team.
There were around 25 developers across several teams and a mixture of experience levels. People knew from previous conversations that I’d spent quite a bit of time experimenting with AI-assisted development, and with AI suddenly appearing everywhere, I started getting questions.
- What did I think of it?
- Was I actually using it for real development?
- Was it any good?
- And, inevitably, was it going to replace everyone?
At the time, I was using Claude Code quite heavily. After enough conversations it became obvious there was genuine interest, so I spoke to the main decision-maker in the business and suggested something fairly simple:
Rather than everyone forming opinions about AI from LinkedIn posts, YouTube demos and screenshots of models successfully producing their 400th React todo application, why don’t we actually try it?
Starting with five developers
The business was enthusiastic about the idea, but we didn’t immediately buy licences for all 25 developers and announce that software engineering had been solved.
We started with a pilot group of five developers working on some of the smaller, more isolated projects.
The pilot ran for around two weeks. The idea was to let people use Claude on actual development work, gather feedback and see whether there was enough evidence to justify rolling it out further.
We also compared it with ChatGPT.
I’d love to say we produced a sophisticated 47-page evaluation matrix with weighted scoring criteria and a radar chart.
We didn’t.
The evaluation was deliberately practical. We used real tickets from the backlog, created smaller greenfield applications and gave both tools problems resembling the work developers were actually doing.
Claude ended up being the better fit.
Part of that was the quality of the model, but I think the larger differentiator was Claude Code and the ecosystem around it. The developer experience felt more mature and much more naturally centred around working inside a real codebase.
It felt less like asking a chatbot questions about your code and more like giving another developer access to the repository and asking them to investigate something.
Testing it against real software
One thing I wanted to avoid was evaluating AI using artificial coding problems.
Writing a function that reverses a string tells me almost nothing about whether a tool is useful inside a mature commercial codebase.
One experiment involved an existing bug that crossed several projects. We gave Claude the problem and asked it to investigate the repository, follow the relevant code paths and identify where the problem was likely coming from.
Within around 30 minutes, it had built a useful picture of the problem and taken us into the right area of the codebase. That had previously taken a developer most of the day to trace manually.
That was impressive.
Not because Claude magically knew the answer, but because of how quickly it could explore: searching unfamiliar code, following dependencies, explaining relationships between components and gradually narrowing the problem down.
We then tried something I found even more interesting.
How quickly could a developer with almost no domain knowledge of a project become capable of meaningfully contributing to it?
This is one of the areas where I think AI-assisted development gets underestimated. Writing code faster is useful, but understanding code faster can be much more valuable.
A developer joining an established project normally spends a significant amount of time figuring out why things are built the way they are, where behaviours live and which bits of code they should definitely not touch on a Friday afternoon.
Claude shortened a lot of that investigation.
There was an important limitation though.
When domain logic already existed somewhere in the repository, Claude could often find it, reason about it and work with it surprisingly well.
Fast, but sometimes a little too enthusiastic
The feedback from the pilot wasn’t universally positive.
Some developers found Claude too verbose, while others felt that generated solutions were occasionally more complicated than they needed to be.
That criticism was fair. AI has a habit of occasionally solving a relatively straightforward problem as though it has been asked to demonstrate every design pattern it learned that week.
Technically valid. Slightly terrifying.
What interested me was that these problems felt steerable.
The speed advantage was obvious. The next challenge was getting the model to produce code that looked more like our code: our architectural choices, our conventions, our testing approaches and our preferred level of complexity.
That question eventually took us towards shared skills and instructions, but at this point we were still trying to establish whether the underlying technology was useful enough to invest in.
After two weeks, we felt it was.
Setting some boundaries first
Before we expanded beyond the pilot, we also had to agree what developers were actually allowed to give the model.
We treated secrets much as we already treated source control. You wouldn’t commit an API key into Git, so don’t paste one into Claude either. Secrets remained in environment variables or whatever secret-management mechanism the application already used.
Real customer data was also off limits.
If somebody needed representative data for a scenario, we used synthetic examples.
None of that was particularly revolutionary, but establishing those expectations early mattered. Introducing an AI assistant shouldn’t suddenly cause everyone to forget the security practices they were already following.
Going from five developers to twenty-five
The rollout from the pilot group to the rest of the development team happened over roughly the next month.
We worked through the teams rather than switching everyone on simultaneously. I ran a hands-on workshop with each team as it came on board, and developers who had already been through the pilot naturally started helping people in the next group.
There was also no shortage of demand. Once the pilot developers started talking about what they were doing, the other teams wanted access too.
Of course, licences cost money, so at some point enthusiasm had to become a business case.
The justification wasn’t simply that developers liked Claude. We had early signs that it was reducing the time spent on some development tasks and changing the amount of effort going into code review and rework. We were also watching things like defect rates, although at that stage it was much too early to make strong claims about long-term quality.
There was enough of a signal, combined with positive developer feedback and the results of the pilot, to justify the licence cost and keep expanding the rollout.
I’ll go much deeper into those metrics later in the series, because measuring developer productivity is a fantastic way to accidentally convince yourself of almost anything if you choose the wrong metric.
Teaching people how to actually use it
The sessions lasted a few hours and were deliberately hands-on.
I showed people how to install and configure Claude, how projects worked and how to use both the desktop application and Claude Code from the CLI.
But the more important part was the workflow.
One of the biggest things I pushed was planning before implementation.
Don’t immediately say:
Implement this ticket.
Ask Claude to investigate first.
- Understand the existing code
- Find the relevant components
- Identify assumptions
- Produce a plan
- Developer reviews the plan
Let the developer review that plan before a line of production code gets changed.
That small change made a noticeable difference to the quality of the results.
I demonstrated test generation, refactoring, code reviews and using Claude to understand unfamiliar parts of the system. I also shared resources around prompting and gave developers things to investigate afterwards, including skills and ways of giving Claude reusable context.
The aim wasn’t to give everybody a list of magic prompts.
It was to teach them a new development workflow.
Then we let Claude tackle one of our own PRs
One workshop produced a particularly memorable moment.
A junior developer had recently implemented a reasonably large feature and had a pull request open for it.
Instead of using another artificial example, we took the same requirement and created a new branch.
We asked Claude to investigate the relevant code, produce an implementation plan and then build its own version. As a group, we reviewed its plan before allowing it to make the changes.
Then we compared the result with the existing PR.
Claude’s implementation was better.
Not because it had produced some radically more sophisticated architecture. The differences were mostly the kind of defensive details that are easy to miss while concentrating on getting a larger feature working.
It covered more edge cases, handled potential null values more carefully and included better checks around exceptions.
One specific example involved a LINQ .Single() call on a sequence that wasn’t guaranteed to contain exactly one item. The developer’s implementation had missed the case where that could throw; Claude caught it and handled it defensively.
That created a slightly awkward demonstration, particularly with junior developers already wondering what AI meant for their future.
But I didn’t think the useful conclusion was:
Claude beat a junior developer. Better start updating LinkedIn.
The interesting question was what that junior developer could now do with Claude alongside them.
They could ask why the alternative implementation was safer. They could ask exactly how .Single() behaves and under what conditions it throws. They could create examples where the original implementation failed and see why the defensive code mattered.
This was important because some of the junior developers were genuinely worried these tools were going to take their jobs.
One of them said it outright.
My argument was that they should look at Claude as a multiplier rather than a competitor.
If you’re struggling to understand async and await in C#, for example, you don’t have to read the same documentation six times and hope the seventh attempt causes enlightenment.
You can ask Claude to create an example. Then deliberately create a broken one. Explain why it breaks. Show the equivalent using something from the actual codebase. Explain it differently if the first explanation doesn’t land.
That feedback loop can massively accelerate learning.
But the same tool that can accelerate learning can also replace it if you let it.
If a junior developer asks Claude to explain the code, challenges the answer and understands what eventually gets committed, it can be an incredible teaching tool.
If they type a requirement, accept everything it generates and move the ticket to Done, they may technically be producing more code while learning almost nothing.
Senior developers were sceptical for a completely different reason
The more experienced developers generally weren’t worried that Claude would replace them.
They just didn’t trust it.
Some were convinced they were better than it.
Depending on the task, they often were. But that wasn’t really the point.
I sat down with one particularly sceptical senior developer and picked a genuine ticket they were working on.
I asked how long they expected it to take.
“About a week.”
So we gave Claude the ticket.
It investigated the repository and produced a plan. The developer and I went through that plan together, challenged assumptions and changed parts we weren’t happy with.
- By lunchtime, we had a plan the senior developer was comfortable with.
- By mid-afternoon, Claude had produced an implementation on a separate branch.
- Roughly another day went on reviewing it, testing it and making changes.
Even allowing for the fact that a one-week estimate is still an estimate, we had taken something expected to occupy most of a developer’s week and got it into a mature, reviewable state in roughly a day and a half.
That was enough to change the conversation.
It didn’t mean Claude had suddenly replaced the senior developer. Their experience was a large part of the reason the exercise worked.
They knew whether the plan made sense. They spotted assumptions. They understood the domain. They knew whether the implementation fitted with the wider architecture.
Claude could produce the work incredibly quickly, but the experienced engineer was still providing the judgement.
Some developers became increasingly pedantic as the output got better, which was mildly entertaining to watch. As the larger objections disappeared, the criticism occasionally migrated towards increasingly tiny details.
I understood it.
If you’ve spent years developing expertise and something suddenly appears capable of doing a surprising amount of your work, your first instinct probably isn’t going to be to give it a little employee-of-the-month badge.
Slowly, though, people came around.
What surprised me most
It wasn’t how quickly Claude could generate code.
I already knew it could do that.
What stood out was how quickly developers started discovering their own uses for it.
We held regular review and knowledge-sharing sessions where people showed what they had tried, what had worked and what absolutely hadn’t.
Some developers immediately started investigating MCP and skills and thinking about how Claude might interact with other internal systems. Juniors used it heavily to understand existing code. Others leaned towards refactoring, testing, investigation or using Claude as another pair of eyes during code review.
Surprisingly quickly, the rollout stopped feeling like something I was pushing.
There were downsides.
Some developers became too trusting and started accepting generated code without properly reviewing it, which reinforced the learning-versus-dependency problem.
And then we hit another consequence I hadn’t fully anticipated.
We started generating a lot more code.
That sounds like an obvious productivity win, right up until you remember that somebody still has to review it.
Code generation had become cheaper. Engineering judgement hadn’t.
We saw fewer basic questions reaching senior developers, and when juniors did need help the conversations were often much more focused because they had already used Claude to investigate the problem themselves.
But at the same time, more code was arriving in pull requests and demanding review.
In some places, we hadn’t removed the bottleneck.
We had moved it.
And I think that is where the genuinely interesting part of AI-assisted development begins.
The question is no longer simply whether AI can write useful software. It clearly can.
The harder questions are how you teach developers to use it without becoming dependent on it, how you make its output consistent with the standards of a real engineering organisation, how you give it access to useful context safely, and how you determine whether all of this activity is actually making the team better.
Coming up in this series
Those are the questions I’ll tackle in the rest of this series:
- Part 2: Teaching developers to work with AI properly. How we approached planning, investigation, prompting, reviewing generated code and avoiding the trap of letting AI do the thinking for you.
- Part 3: Turning engineering standards into shared AI skills. How we started encoding our architecture, coding conventions and development practices into reusable context instead of repeating them in prompts.
- Part 4: Giving AI real context with MCP. What happened when developers started connecting Claude to internal tools and systems, and the security questions that came with it.
- Part 5: Did it actually make us better developers? The metrics we looked at, what improved, what didn’t, and why measuring AI-driven developer productivity is much harder than counting how much code somebody produces.
Because producing more code was never really the goal.
Producing better software was.
And once AI made writing code substantially cheaper, reviewing it, understanding it and deciding whether it should exist at all became more important than ever.