What AI adoption actually looks like inside a 300+ engineer organisation

The first few months of AI adoption are, reliably, a bit of a mess.

A handful of engineers become dramatically more productive. Others stay sceptical, arms folded. Security gets nervous. And leadership starts asking, with the particular optimism of someone who wants a single tidy figure, exactly how much productivity has gone up.

Everyone wants a number. Unfortunately, the interesting questions here are rarely numerical.

The real challenge was never introducing the tools. It's changing how the organisation works around them. Having watched AI adoption spread across hundreds of engineers, I've come to think the technology is the easy part. It's the organisational change that's hard, and that's the part nobody puts on the slide.

The first mistake: treating AI as a tool rollout

Most organisations approach AI adoption like a software deployment. Pick a vendor, buy the licences, announce availability, sit back and wait for the productivity to roll in.

It rarely rolls in.

Unlike most enterprise software, AI is enormously dependent on individual behaviour. Two engineers with access to the identical model can get completely different results from it. One uses it to accelerate testing, documentation and reviews; the other barely opens it. So adoption goes lopsided almost immediately - and no amount of licences fixes that.

The organisations that get somewhere spend less energy on the tooling and more on helping teams work out where AI genuinely earns its place, because "we bought it, please use it" has never once changed how anyone works.

Where AI earns its place

The biggest gains turn up in work that's expensive to produce and relatively cheap to verify:

• Unit tests and test fixtures
• Documentation and technical summaries
• Initial implementation scaffolding
• API integrations
• Data transformation code
• Investigating unfamiliar systems

In all of these, the engineer stays responsible for the outcome and AI just knocks down the cost of the first draft. That distinction matters more than it sounds: AI is at its strongest generating options, and at its weakest making the decision.

Where AI disappoints

The hype promised AI would swallow large chunks of software engineering whole. That has not been my experience.

The work that still demands real human judgement:

• System architecture
• Domain modelling
• Technical strategy
• Production incident management
• Stakeholder communication
• Prioritisation and trade-offs

All of these lean heavily on context. The challenge in this job was never generating the code. It's working out which code should exist in the first place, and a model that has never sat in your planning meetings is in a poor position to tell you.

The productivity trap

Eventually someone asks the inevitable: "How much more productive are engineers now?"

It sounds like a reasonable question. It's also very hard to answer honestly.

Productivity in software has always been a nightmare to measure, and AI does precisely nothing to make that easier. The gains are uneven. Some engineers become substantially more effective. Others see marginal improvement. Some teams discover entirely new ways of working; others carry on much as before.

Try to flatten all of that into a single percentage and you'll generate more confusion than insight, plus a number someone will inevitably put in a board deck. The better question is:

Are engineers spending less time on low-value work and more time on high-value work?

That's where the gains that actually matter tend to hide.

Governance arrives later than expected

Early adoption is usually all enthusiasm. Governance shows up later - specifically the moment leadership realises everyone's already using the tools and has been for months.

Then the questions arrive, more or less at once:

• Intellectual property
• Data protection
• Model selection
• Security reviews
• Audit requirements
• Approved use cases

Plenty of organisations reach straight for restrictions. The ones that do better reach for guidance instead. The goal was never to prevent AI usage; that ship sailed before the meeting was booked. The goal is to help teams use it safely and well.

The most surprising outcome

The most interesting change isn't technical at all. It's cultural.

AI nudges engineers to work differently: more experimentation, faster iteration, more time spent reviewing and refining output rather than producing every line from a cold start. Over time that shifts the whole nature of the work.

The strongest engineers start to look less like code producers and more like problem solvers. The ability to ask a sharp question, judge a solution and apply context becomes worth more than the ability to type every line by hand.

What happens next

The first wave of AI adoption was about tools. The second is about workflows. The third will be about systems: AI settling into development environments, delivery pipelines, observability and operational tooling until it's just part of the furniture.

Eventually the tools themselves get boring. What'll matter is how well organisations adapt around them.

The companies that win this won't necessarily be the ones with the most advanced models. They'll be the ones that learn to combine human judgement with machine assistance in a way that actually improves things for customers, engineers and the business. That, you'll notice, is the same skill that separated good engineering organisations from mediocre ones long before any of this turned up.

Further reading

• DORA 2024 Accelerate State of DevOps Report: the canonical data showing AI lifts individual productivity while denting delivery throughput and stability, which is exactly the uneven picture this post describes.
• Measuring the Impact of Early-2025 AI on Experienced Developer Productivity (METR): the randomised study where experienced developers were 19 per cent slower with AI yet believed they were 20 per cent faster, which is the productivity trap in one chart.