AI didn't replace our engineers.  It changed what they do.

AI coding tools have earned a permanent place in how we build software, but they will never remove the need for experienced engineers who understand the problem, the codebase and the consequences of getting it wrong.

Two years ago, the debate was whether AI belonged in the development lifecycle at all. That debate is over. Inside Better Outcomz, AI tooling now touches most of what our engineers do - drafting boilerplate, writing tests, reviewing pull requests, investigating incidents. Industry data suggests this is the norm: 84% of developers now use AI tools or plan to, with over two-thirds using them daily or weekly. Adoption has moved from early-adopter curiosity to standard practice.

None of that means the software engineer's role is shrinking. If anything, the opposite is happening. We've gone from occasional experimentation to running a dedicated engineering function whose entire remit is building and maintaining the tooling, guardrails and workflows that let our developers use AI safely and effectively. It's a recognition that AI-assisted development is now infrastructure, and infrastructure needs owners. This isn't a hedge against AI; it's a commitment to using it properly.

The productivity gain is real, but uneven

Any claim that AI makes developers X% faster, without specifying the type of work, should raise an eyebrow. Flatten 'engineering work' into a single percentage and it rarely survives contact with a real codebase. McKinsey's lab study found time savings of 45-50% for code documentation, 35-45% for code generation, and 20-30% for refactoring. On tasks developers rated highly complex, the saving dropped below 10% - and developers with under a year's experience sometimes took 7-10% longer with the tools.

METR's controlled research told an even more sobering story. Its 2025 randomised controlled trial found that experienced open-source developers took 19% longer to complete real tasks with early-2025 AI tools, despite reporting that they believed the tools had made them faster. A February 2026 follow-up suggested performance may have improved since, but METR was explicit that selection effects in the newer sample made the size of that improvement unreliable.

That caveat is more useful than any headline number: the result depends on the task, the engineer, the codebase and how the tool is used. That gap between routine and complex work is exactly where I'd expect experienced engineers to matter most. AI tools shrink the distance between 'I know what I want' and 'there is working code on screen'. They do almost nothing to shrink the distance between 'I understand this business problem, this codebase's history and what will break in production' and 'I know what I want'. That second distance is judgement - and judgement doesn't ship in a model update.

Trust has to be earned, not assumed

Developers have become more cautious about AI output over time, not less. Stack Overflow's 2025 developer survey found that only 33% of respondents trusted the accuracy of AI-tool output, down from 43% in 2024, even as 84% said they used or planned to use AI tools. That isn't a contradiction. It's what a maturing engineering discipline looks like: more use, paired with more scrutiny.

That scrutiny has evidence behind it. CodeRabbit analysed 470 open-source pull requests and found AI-co-authored ones contained roughly 1.7 times more issues overall - with some security categories up to 2.74 times higher. That's not a reason to stop using AI to write code. It's a reason to make sure someone who understands security, architecture and the specific system is the one reviewing what it produces.

That scrutiny shows up in how engineering time actually gets spent, too. In Sonar's 2026 developer survey, 38% of respondents said reviewing AI-generated code takes more effort than reviewing code written by a human colleague. That's not AI doing less work - it's a signal of where the genuinely hard, valuable part of the job has moved.

What AI tooling is actually good at

None of this is an argument against AI in the development lifecycle, quite the opposite. Used well, it strips out a huge amount of routine work that used to eat into senior engineers' time without testing their expertise: boilerplate, test scaffolding, documentation, first-draft implementations of well-understood patterns, and the kind of research and code search that used to burn hours.

One example from our own delivery: an engineer used AI assistance to scaffold a new integration against a third-party API in an afternoon, work that would have previously taken two or three days. What the tool couldn't know was that the third party's sandbox environment behaved differently from production for a specific edge case, something the engineer only caught because they remembered a similar integration that had failed the same way eighteen months earlier.

That's the real shape of the gain: genuine time back on the mechanical part, and the judgement still sitting exactly where it should - with the person who has the context. The benefit compounds from there. When AI handles the mechanical parts of a task, the engineer has more time for the parts that require experience. Does this design still hold under load? Does this change interact badly with something three services away? Is this even the right problem to be solving?

That's the shift I want for our engineers - less time on the parts of the job a model can do adequately, more time on the parts only a person with real context can do well.

Why we built a team around the tooling, not just the output

Here's where I think a lot of organisations go wrong. They treat AI coding assistants as a procurement decision: buy a licence, roll it out, done. We saw it differently from the start. AI-assisted development needs the same engineering discipline as anything else we ship internally. So we built a dedicated function. Its job isn't to write product code, it's to build and maintain the tooling, prompts, guardrails, evaluation and integration our developers rely on every day.

That team owns four things:

• which models and tools are approved for which work;
• how AI-assisted code meets the same engineering standards, with extra controls where provenance, security or data handling raises the risk;
• what gets tested before AI-touched changes reach production; and
• how we retire or replace tools as the models underneath them change.

That's the gap between 'our developers happen to use some AI tools' and 'AI-assisted development is a controlled, understood part of how we build software'. It's worth the investment.

My test for AI in engineering: If a model changed or a tool disappeared tomorrow, would our engineers still understand the system, the decisions behind it and how to keep building it safely? If not, we haven't outsourced typing, we've outsourced understanding.

The engineering gap is wider than code generation

I don't believe the gap between AI assistance and full engineering capability is temporary. Better models won't close it. Writing code was never the hardest part of software delivery - it was understanding the problem, the domain, the failure modes and the people who depend on the system. It still is.

AI tools are extraordinary at producing plausible code quickly. What they don't carry is accountability for what happens when that code meets real customers, real data and real regulatory consequences. That accountability has to sit with people - and people need deep, current expertise to carry it responsibly.

This matters more, not less, in regulated financial services. A vulnerability introduced by an AI suggestion and missed in review doesn't stay a technical problem. It becomes a customer-outcome problem, a data-protection problem and potentially a regulatory one. The organisations that get the most value from AI-assisted development over the next few years will be the ones that treat it as a powerful addition to a strong engineering function - not a substitute for one.

What next for AI?

I expect AI tooling's share of the mechanical work to keep growing - and I want it to. I don't expect it to reduce our need for experienced engineers. I expect it to change what we hire and train for. Less reward for producing code quickly, more reward for judgement: architecture, security thinking, understanding the business and the customer, and knowing when AI output is right, nearly right or dangerously wrong.

At Better Outcomz, that's the balance we've built our engineering organisation around: AI tooling as core infrastructure, a dedicated team responsible for that infrastructure and a development function whose expertise is more valuable, not less, because of it.