Last year a board asked a CTO I was working with whether they were investing enough in AI. Or were they investing too much? I’ve got a fairly big network, so I offered to go out and ask everyone else what they were doing. And then every time I talked to somebody, the answer was: yeah, I want to know too.
I’d promised everyone who took part an anonymised version, so I’m not going to say who’s ahead or who’s behind. What I can say is what I’d tell a finance leader asking the same question, because “what’s the ROI on AI” is mostly the wrong first question. The better one is how much to put in, where to put it, and how to tell whether it’s working.
The question boards are asking
What I asked each company was simple. How much of your effort is going into AI? Both internally, as in how much it’s changing the way you work, and in how you approach new product development. It’s a calibration exercise, to get a sense of how all-in each company is.
The reason everyone wanted the answer is that nobody has a clean ROI number. A Salesforce survey of 261 CFOs (vendor-commissioned, run by Morning Consult) found that 61% say AI agents are changing how they evaluate ROI, and 56% name long ROI timelines as a concern. That matches what I see. The normal business case doesn’t fit, so people fall back on what their peers are doing. That’s a reasonable instinct, as long as you’re clear about what you’re actually calibrating.
Invest, but not so much you look stupid
My view is that it’s absolutely a bubble. That doesn’t mean it isn’t going to have a lasting impact. It’s way up in the hype cycle, and I’m expecting a burst, like has happened with pretty much all of the previous ones. Both of those things are true at once, and that’s the whole point of the calibration: be investing, but not so much that you look stupid once it all plateaus a little.
In practice that means sizing the spend so it survives a correction, and keeping your options open. I wouldn’t lock yourself into one model for six months. By all means sign an agreement with a provider, but in a month or two there’ll be a better model, and not being able to pick it up costs you.
Watch the run-rate, too. This is a broad industry thing. Plenty of companies have the attitude that they can replace developers with AI, and the reality is that in a lot of circumstances the AI is more expensive than the developers. On a flat-rate plan I get far more value than I pay for. If you multiplied my own usage across a team at metered API rates, it would be more than the cost of the employees.
What I’d do is take the daily usage, remove the outliers, and look at the average across the month, because anomalous days skew it. Set an acceptable daily rate and work to stay within it. Train people to drop to the cheaper models when they can, and make the top models something you ask for rather than the default, because they’re an order of magnitude more expensive. And if the budget is high enough that you could be hiring more people with it, you’ve gone too far. You can’t spend unlimited money to get productivity.
The return comes from augmenting your engineers
Pretty much everyone I talked to is augmenting their existing software engineers rather than setting AI up as a separate thing that replaces them. That matches my experience. It still needs a huge amount of oversight. What’s changing is that roles are blending: product and design can now do tasks that traditionally needed a software engineer. The work also needs much stronger briefs. It’s almost waterfall in some ways, because the AI works through a brief so quickly that it almost overwhelms your ability to supply it with work.
There’s something I say to C-levels whenever replacing developers comes up. If you bring the cost of intelligence to zero, which AI does, and then make a whole heap of smart people unemployed, you end up with a whole heap more competitors. If they’ve got nothing better to do with their time, they’ll compete with you, and give it a few years and AI will build most of it for them. I can write implementations alone now that would have taken ten people. The barrier to entry that used to be employees is disappearing, and that’s a real risk for established companies.
The other reason to be careful is that the gains aren’t automatic. Last year I helped a large engineering organisation adopt AI for coding, and the point was to do it rigorously, making sure it was actually beneficial rather than just “we must use this”. The research backs up being careful. In METR’s randomised trial, 16 experienced open-source developers working on 246 real tasks were 19% slower with AI tools, while believing afterwards that they’d been 20% faster. Google’s DORA 2025 report found that AI adoption now goes with higher delivery throughput, and also with higher delivery instability: more failed changes and more rework. Feeling faster and shipping more aren’t the same as getting a return.
Expect to go backwards first
Part of the cost of picking up AI is that you go backwards before you go forwards. It has a negative performance impact at first, especially on somebody who’s already very fast. One client had a developer who was incredibly quick and producing really good work, and my advice was to leave him be for the time being rather than force the change on him mid-stream. That dip is real, and an ROI timeline that doesn’t allow for it will make a sensible investment look like a failure in the first quarter.
It also doesn’t apply evenly. It’s much easier to apply AI in a greenfield project than in a heavily regulated environment with sensitive data, and even inside a big enterprise the challenges differ from team to team. Just because you can do it in one place doesn’t mean you can apply it evenly everywhere. If a pilot team shows a big gain, don’t multiply it across the whole engineering budget.
Some companies are building it into hiring. One company I spoke to now makes it a big topic in the interview process: how willing people are to use AI and where they are in the journey. It’s not a hard no if someone isn’t far along. But if they’re completely sceptical and unwilling to engage with it, that’s probably a problem.
Old baselines and estimates are now wrong
This is the part I’d push hardest with a finance team. One of the first things I built at REA Group was an agent website builder. I know how long version one took: about six, maybe eight months, with a team of eight developers and the people around them. Earlier this year I replicated the majority of it in two days, using Claude Code and agent teams, my knowledge of the product and the ability to spec and control the work. What used to take months to years can now take weeks to months, and that fundamentally changes a bunch of the equations.
If your business cases or build-versus-buy decisions are built on estimates from before this, they’re wrong. The cheaper move now is usually to test first. A lot of ideas aren’t big pieces of work. Build it in a couple of days, and if it gets legs, spend a month reworking it to be more scalable. You don’t bother rebuilding it unless it becomes a problem.
The estimates themselves need redrawing. I tried to get one team I worked with to use AI estimates, and they insisted on estimating themselves. Beside them, I asked the AI to estimate the same work and compared how often it was right. The vast majority of the time its estimates were bang on, and at times it did a better job of breaking down the pieces than the engineers did. Spending hours estimating something as multiple days, when the AI is going to write most of the code in ten minutes, is a waste of time.
The catch is that once building is cheap, it’s not the hard part anymore. It becomes all about distribution and attention. It’s very easy to build something that nobody uses. For a CFO, that means the return question moves away from “how much did engineering cost” and towards whether the things you build so much faster actually get used.
If you’re working through how much to put into AI and where, that’s the kind of conversation I have on an advisory retainer.