First a little about me. I truly believe that AI can help organisations produce better things faster when used well. The big question is - what does “Used Well” look like ?

Personally I think it’s just too early for any opinion to be more than a well-educated guess. There are no right or wrong answers to the problems of AI adoption and anyone who tells you there are is almost certainly trying to sell something. This article is a collection of my own experiences, conversations I’ve had with others and things that I have read that feel like they’re improving our knowledge of solid AI practices.

It’s fair to say that almost every conversation I have with organisations that employ software engineers seems to tip-toe around the subject of AI adoption. I say tip-toe because in most cases no-one can articulate what they want from AI other than a fear of missing out or pressure from investors or CEOs.

I don’t see this as a problem. It’s early days and we’re all making this up as we go along. What doesn’t help is the constant claim, counter-claim and irresponsible hype from the big tech competitors as they vie with each other to grab AI market share by the throat. One day AI is going to make software developers redundant the next we’ll need more of them so long as they’ve made that unspecified “AI adjustment”.

For most companies reality is an awareness that some of their developers use AI tools a lot, some use it a bit whilst others are pushing back. No-one seems able to measure effective usage or the benefits that usage brings only the sure knowledge that these wonder tools come with ever-increasing costs.

So what does AI adoption even mean ?

#

AI tooling doesn’t just make development faster, it can also change the process by which software is developed. Let’s take a quick look at each.

Speed of Development

#

This is so difficult to pin down. Vendors such as Microsoft Co-Pilot often claim to have benchmarked 55% increases in development speed but these are usually under ’lab’ conditions. Working with AI tools on a new system that isn’t yet in production is very, very different to working on an existing one in production with real end-users.

At the other end of the scale a study on Open Source development demonstrated that AI slowed developers by about 19% when, interestingly, the developers subjectively felt they were 20% faster.

Generally independent studies seem to benchmark increases in productivity about 20-40%

It’s worth noting that AI tooling and models have evolved significantly since these studies were made.

As for my own experiences just pure code crunching with AI tools I’d summarise them as:

• Building a working prototype from scratch - weeks become days as long as I have domain knowledge or good access to someone that has.
• The bulk of my coding experience is python and ruby. If I’m writing backend code in either of these languages the 30-40% uplift in output feels about right.
• Much greater gains can be had on less familiar parts of the tech stack. I’m not that excited by front end tools like React and find this kind of tasks to be a chore. Not only is AI coding way faster than me I’m sure it does a much better job.
• I have significant devops experience, especially with Terraform, so I know what good looks like but I don’t use Terraform every day. Claude has built me several Terraform setups for things like static websites and lambda based applications in minutes that would typically take me a day by the time I get them to work.
• Similarly AI tools frequently save me small amounts of time here and there by asking them to commit working files, deploy something, merge a branch etc. All those chores that typically suck-up my time and sap my energy.
• Lastly debugging. All developers hit that wall where we just can’t get the f*cking thing to work. For me it’s usually something so trivial I just can’t see it any more or something that isn’t that well explained in the documentation. The number of times I’ve turned to Claude in total frustration to ask it why something isn’t working only to get a simple breakdown of “why” I’d completely overlooked something quite obvious with hindsight has been worth the token spend.

These alone are sufficient to make me believe that AI coding tools are worth it. I was always proud of my code and felt it was clean, well structured and readable but in all honesty I’d still rather focus on specifying the problem rather than crafting lines of code. I don’t miss coding at all.

Changing the Process

#

So I’ve given plenty of anecdotal evidence of why I like coding tools but my feeling is that the real benefits for any organisation are when they both change and formalise the way they work with AI tools. Formalisation makes the process measurable and removes the constant question of who is using the tools, who isn’t and why.

In my experience there are two opportunities to change process, not just within the engineering team but also the entire lifecycle.

Changing the Developer Process

#

At developer level, the worst thing you can do is hand out AI tools and then measure success by how much each developer is spending on tokens. Spend tells you who’s using the tools, not who’s using them well. The two are easily confused and rarely the same thing.

A better approach is to adopt some flavour of spec-driven development: before a developer turns an agent loose on a problem, they write down what they actually want it to do. Not a novel—just enough structure that the intent is unambiguous. The constraints, the edge cases, the definition of done. The better the plan, the better the outcome, and, counterintuitively to anyone watching the bill, the lower the token spend. A vague prompt sends the agent off in three wrong directions before it stumbles onto the right one; a tight spec gets there first time.

This is the part I enjoy most. Sitting with stakeholders and product managers to pin down a plan that solves a real problem is more satisfying than any amount of clever code. Once you get the taste for it, crafting lines by hand starts to feel like a chore you’ve been freed from.

There’s a measurement benefit that organisations often miss. Specs and the plans they produce are artefacts. They can be reviewed, version-controlled, compared and improved, exactly like code. That makes them a far healthier signal of AI maturity than token usage ever could be. A team producing clear, reusable specs is adopting AI well, regardless of what they’re spending. A team burning tokens with nothing to show for it isn’t, no matter how enthusiastic the dashboard looks. If you want to improve adoption, improve the specs—and now you have something concrete to improve.

Changing the Software Development Lifecycle

#

Some of the biggest gains come from changing the lifecycle around the engineering team.

As a culture, we’ve never been good at specifying things. Stakeholders and customers not fully understanding what they need—or understanding it perfectly but being unable to articulate it—is the most persistent, expensive problem in building anything. Traditionally getting a requirement wrong was costly: weeks of work, code people have grown attached to, and an awkward conversation about why it all has to change.

Agentic coding changes that. I can now stand up a functioning prototype fast enough that it becomes a conversation tool rather than a finished product. And because I didn’t spend days hand-crafting it, I’ve no emotional attachment to it—throwing it away costs me nothing.

That changes the shape of the whole process. Twice now I’ve written a specification, had an agent build it, demoed the result, and watched the stakeholders realise that wasn’t what they meant—or that I’d misunderstood them in the first place. In the old world, that just drained energy and enthusiasm. In this one I was already familiar with the spec, I was now familiar enough with version 2 of the problem, and I had a working V2 ready to demonstrate a couple of hours later. The misunderstanding got caught and corrected in an afternoon instead of festering for a sprint.

Prototyping is no longer the expensive last step before commitment. Now it’s the cheap first step in figuring out what to build. You discover what people actually want by showing them something and watching them react, not by interrogating them in a requirements meeting and hoping you’ve understood. AI doesn’t just make us faster at building the thing—it makes us faster at finding out which thing to build, which is where most projects go wrong in the first place. Hard to benchmark but I’ll wager good money that outcomes are significantly better.

So what does ‘Used Well’ actually look like ?

#

After all this, I’ll offer something deliberately modest: it isn’t a tool you buy or a seat-count you monitor. Used well means changing how you work, not just what you work with.

The companies still measuring AI adoption by token spend are asking the wrong question—it’s like measuring a writer by how much ink they use. The better question is whether your teams are planning before they prompt. A good spec produces better code, lower costs, and—almost as a side effect—an artefact you can actually point to. That’s your real adoption metric: not how much your developers are spending, but how well they’re specifying.

None of this is set in stone but the organisations that win won’t be the ones who adopted AI fastest. They’ll be the ones who got better at saying what they wanted—because the hardest part of building software with AI is the same as it always was: knowing what and how to build.