In January of this year I was on a call with a CEO, their CTO and their Head of Engineering. Partway through, the CEO asked a straight question: does AI mean we’ll need fewer engineers?
None of us could answer it with much confidence. We talked about it being relatively early days, which was true, but not much use to a CEO.
Since then, most of my daily calls have included the topic of how AI is impacting tech teams. I’ve asked some variant of that CEO’s question to CTOs, heads of engineering and principal engineers.
In the spring the answers were “it’s a hot mess”. But by the autumn things had started to line up. And today I can answer the question properly, at least for the kind of firms I work with.
You’ll need fewer people whose job is writing code. But that doesn’t mean fewer good engineers.
Building software has always been about more than writing code, and the value of a good engineer is in seeing the solution end to end, using judgement, and being outcome focussed. AI doesn’t kill those qualities - if anything, it makes them worth more.
What I’ve been hearing.
The conversation has moved on fast. Early in the year it was about whether engineers should be using AI to write code at all. That’s more or less settled. One engineering leader I spoke to recently put it simply: there’ll be limits on where AI goes in critical systems, but nobody is going to stop people using it to write code. He’s already got AI in his delivery pipeline and is shipping into production.
The question now is what sits around the AI, and that’s where harness engineering comes in. The model is the generic part (someone described it to me as ‘feral’!), and everyone can buy the same one. The harness is what you build around it: what work it’s given, what it’s allowed to touch, how you check what it produces, and how you stop it shipping something that looks right and isn’t.
One of the people in my network furthest along with this is a Chief AI Officer, who’s now hiring people to focus on harness work more than on writing code. For her, harness engineering is a full time job performed by an experienced engineer.
When I discussed this with another engineering leader, he agreed and went a step further, viewing AI adoption in stages: prompting came first, then orchestration, then harnesses. He sees the next stage as the ‘software factory’, where the business describes a feature in plain English and the machinery delivers it.
Building and running these harnesses and factories is complex engineering in its own right. Someone has to design the system, decide what good looks like, build the checks, and own what comes out the other end, every day, because the AI never stops producing.
This isn’t for everyone, and I can understand why some engineers are feeling bleak about the whole thing. Some people have built their entire career - their identity even - on the craft of hand-writing code. One principal engineer recently told me that he wants to keep writing code above everything else. When I asked what he’ll do if opportunities to do that disappear, he replied: “that’s when I’ll leave the industry”.
So where are organisations on this journey?
My clients are at varying stages of adoption, but I can safely say that all have made significant strides this year. In some, one squad is well ahead of the rest. Others are shipping AI generated code straight to production. All have strict guardrails.
Looking more broadly across the market, I’ve recently reviewed a file of over 60 engineering leadership job specs, including principal engineers, tech leads and engineering managers. I hand picked the specs, so treat it as a sample rather than a survey.
About half have a real AI requirement rather than a token mention. One in five name specific tools: Copilot, Claude Code, Cursor, Windsurf. But not many truly get into the detail on what success looks like when leading a team that’s using AI every day - that’s where we need to go next.
Evident added some rigour to this.
I read the Evident AI Index last month, which ranks the 50 biggest banks on how far they’ve got with AI. They use public information, so how relevant it is to a mid-sized firm is open to debate (JPMorgan’s $2bn a year AI budget isn’t a template for anyone reading this). But a couple of the findings aligned with what I’d been hearing.
First, nobody has ROI nailed. Evident counted 1,107 bank AI use cases since 2021 that report some kind of impact, and about 1% show a hard financial result. CommBank, ranked fourth, says it spent more on AI than it got back over the last two years and expects that to change in 2027. So if you can’t put a pound figure on your AI work yet, you’re in decent company.
Second, the time saved is being put back into the business rather than cut. Wells Fargo says engineers using AI tools write 35% more code, and it hasn’t reduced headcount. Bank of America reports developer productivity up more than 20% “without a corresponding increase in headcount”. So no cuts at the banks, but no extra hires either.
What it means for who you hire.
Hire for judgement. The Chief AI Officer’s headline point was autonomous judgement: people who know what good looks like without being told, and decide well without checking back. Close behind that comes:
being able to say exactly what “done” means, and tell when it’s been met
seeing the knock-on effects across the whole system, rather than only the task in front of them
spotting where something plausible-looking is wrong
being happy to direct the machine rather than hand-craft every line (sadly, this one rules out some brilliant engineers).
None of it shows up on a CV. You hear it in how people talk about their past work: “I decided”, “I knew it was right when”, “I caught that it was wrong”.
Look in the right places. Very few people have “harness engineer” on their CV yet, so searching for the title finds almost nobody. The people who can do this mostly sit in platform engineering, MLOps, developer experience and tooling, and SRE. Some are senior engineers already shipping LLM features under a generic title. You have to recognise the capability, because the label won’t help you.
Treat tooling as part of the offer. If the engineers you want find out at interview that they can’t use (for example) Claude Code, they’ll be weighing you against firms where they can.
Hire managers who are ready to lead a team that builds with AI. Ask them where the new bottlenecks are. If AI doubles the pull requests, but review works the same way it always has, the bottleneck has just moved. A good manager will already be thinking about that.
Say what success looks like. If the banks are learning to measure AI by what it changes, the least we can do is tell a new hire what we want them to change.
So, back to that CEO. You still need engineers. And the best ones see the whole solution, decide what good looks like, build the systems that check the machine got there, and own the outcome.
Source: Evident AI Index: Key Findings Report, October 2026.