Six questions about AI adoption that we're regularly asked

We’ve noticed a few questions that keep coming up in relation to AI adoption and the right next steps. Same questions, wildly different conclusions being reached, depending on who you’re talking to. We’ve been giving these questions some thought and have shared our considered opinions here.

These are the 6 questions we answer in this blog:

1. “AI has made software development more accessible. Do you even need a development partner?”

2. "AI makes every developer equally capable now. So does it matter who you use?"

3. “Won’t AI tools be significantly cheaper in a year? Why commit now?” and “If AI is going to replace developers anyway, why sign any long-term engagement?”

4. “Surely we should take the AI efficiency gains as a cost saving, rather than spending the same and getting more output?”

5. “We're thinking of bringing development in-house. Why wouldn't we?”

6. "What are we actually locked into?" And: "How do we know it's really working?"

Question 1: “AI has made software development more accessible. Do you even need a development partner?”

We’ve been hearing this one (and variations) a lot lately. It’s completely reasonable, and obviously we have an interest in the answer being ‘yes’.

The answer is ‘yes’ :)

What AI has genuinely changed is the speed at which code can be written. We see it at three rocks every day - code generation has become commoditised.
But writing code has always been the most commoditised part of what a development partner does. A strong junior developer has always been able to write a lot of code quickly. That was never really the point.

The harder things - unchanged by AI - are the judgment about what to build, whether the brief is solving the right problem, and who’s accountable when an architectural decision from two years ago causes a problem at 2am. Those responsibilities don’t get easier when code gets cheaper. They get more important, because faster code generation means more code, more decisions, and more things that can go wrong.

An agency with genuine platform depth isn’t competing on writing speed. It’s competing on judgment, context, and accountability. The right AI application - one trained on your specific platform, not the internet - compounds that advantage rather than eroding it.

The question worth asking isn’t “do we still need a development partner?” It’s “what outcomes should we be paying for?” – and from that, choices become clearer.

Question 2: "AI makes every developer equally capable now. So does it matter who you use?"

This is something we hear regularly from CTOs and digital leads - right at the moment when AI genuinely should be boosting development output.
There’s something seductive about this argument. And it’s being used - consciously or not - to justify decisions that may look very different in 18 months.

There’s some truth in it too - AI has compressed the capability gap between developers, in terms of generating code that works as specified. Routine stuff that used to take days now take hours.

The part that tends to get left out is that speed without governance is a liability, not an advantage.

AI generates code faster than most teams can properly review it. Vulnerabilities, bad architectural decisions, integration failures - these don’t disappear with AI. They accumulate at higher velocity if the right oversight isn’t in place. The organisations that have genuinely benefited from AI are the ones that maintained governance while accelerating, not the ones that removed it.

There’s also a meaningful difference between “AI-enabled” development and platform-trained AI. Most suppliers who claim AI capability mean their developers use useful AI tools, but they produce generic code with no awareness of your platform’s history, integration constraints, or architecture decisions made over years. That’s fundamentally different to an AI trained specifically on your codebase.

At three rocks, we built XMS AI ourselves - not as a marketing claim, but because the distinction is important and verifiable. Generic AI tools make average developers code faster. Platform-trained AI makes the team working on your specific platform faster, more accurate, and more aware of exactly what can go wrong.

So yes, AI has changed capability. The right question is – which capabilities matter now, more than ever?

Question 3: “Won’t AI tools be significantly cheaper in a year? Why commit now?” and “If AI is going to replace developers anyway, why sign any long-term engagement?”

This is technically two questions. They seem different, but come from similar places. Both may encourage you to take a ’wait and see’ stance. We think that would be a mistake.

On timing: the premise is partly right. AI is improving and costs are falling - we’re not disputing that. But what the ‘let’s wait’ argument misses is what waiting actually means in practice. The value of a well-run AI-augmented development engagement isn’t in the model you’re using today. It’s in the platform context the AI builds over time - every architectural decision, every resolved bug, every requirements conversation. That depth compounds. Better AI amplifies a rich context. It can’t shortcut building one from nothing.

The speedboat doesn’t come to the dock. It meets you on the river. The further along you are, the further, and faster, it takes you.

On AI replacing developers: this confuses the act of writing code with responsibility for what the code does. AI is getting good at well-specified, routine tasks. But someone still decides what to build, reviews what AI produces, makes the deployment call, and is accountable when something goes wrong at 2am. That role becomes more important as AI improves.

The organisations we see falling behind aren’t the ones who chose the wrong AI tool. They’re the ones who used ‘let’s wait and see how AI develops’ as a reason to defer decisions that needed making now.

Question 4: “Surely we should take the AI efficiency gains as a cost saving, rather than spending the same and getting more output?”

It’s a rational choice. It’s also the one that, in three years, will separate the organisations that accelerated from the ones that stood still. (It’s also not a particularly AI one; you always had the option to do less and pocket the saving).

A cost saving is realised once, in a single budget cycle. Platform investment compounds. A better user experience, a cleared backlog, faster time-to-market - these deliver value in the year they’re built and in every year after. Every improvement becomes the foundation for the next one. The organisations that reinvest the AI dividend will have a meaningfully better platform in three years than those that pocketed it. The gap opens slowly, then quickly.

There’s a connected point worth making on cost models. The time-and-materials model has a structural flaw that tends not to get discussed: the supplier’s revenue is maximised by more hours spent - the exact opposite of the client’s interest. Both parties manage this professionally, but the tension never goes away. Fixed-price or subscription models eliminate it entirely. When we’re paid the same regardless of how long delivery takes, every incentive points toward using AI to compress the work, not expand it.

The right question AI makes possible isn’t “how do we reduce the development budget?” It’s “what should we build that we previously couldn’t afford to?”

Those are very different approaches – only one will keep you competitive.

Question 5: “We're thinking of bringing development in-house. Why wouldn't we?”

We're hearing this one a lot, and it often comes alongside a decision that's already half made.

The advantages are real: full-time availability, platform knowledge that accumulates, someone embedded in the culture and aligned with the business. We're not dismissing any of that.

But the decision tends to get made on the theoretical version of in-house. The practical one looks a bit different.

The first thing that tends to get underestimated is ramp-up. A new developer - good developer, right skills - still needs months before they're genuinely useful on a specific platform. Every codebase carries decisions whose rationale was never written down, integrations that behave unexpectedly, patterns that took years to develop. You pay for that learning period and absorb the risk that comes with it. With XMS AI, we reach full platform depth in days. That gap is close to zero.

The second is the shape of the work. Employment comes in 40-hour-a-week chunks. Development work doesn't. There are sprint peaks, quiet patches, a critical incident at 2am, then nothing for a week. A headcount model pays for the flat line while struggling with the peaks - or staffs for the peaks and wastes money on the troughs. An external engagement scales to what the work actually requires.

The third is exposure. An in-house developer sees one platform, one set of problems, one internal culture. A specialist working across multiple clients and sectors encounters the same class of problem in a dozen different contexts - and that breadth is genuinely valuable. It's how you get a recommendation that comes from seeing the same architectural mistake in six different businesses, not just yours.

There's also the independence question. Someone internal is shaped by the same pressures as everyone else, the pull of decisions already made, the difficulty of pushing back on a senior stakeholder. An external partner can challenge a brief before it gets built and say things that internal teams find difficult to say.

None of which means in-house is wrong. It means the smart combination is usually someone internal, representing the business, embedded in the brand, close to its needs - working alongside a specialist externally who brings varied, relevant experience and hasn't been shaped by the same internal pressures. That's the mix that tends to get the best of both.

Question 6: "What are we actually locked into?" And: "How do we know it's really working?"

Both questions tend to come up late, after the decision to use an external partner, not before it. They're the right questions. And they're both about the same underlying thing.

The fear is control. When a supplier knows your platform better than your internal team does what happens if this goes wrong? How would you even know if it was?

On lock-in: the IP question is the straightforward one. Every line of code built belongs to the client. What the concern is really about is knowledge. If the agency understands the architecture and your team doesn't, leaving is genuinely difficult, not because of contracts, but because you've become dependent. The answer to that isn't to avoid depth. It's to make sure the engagement progressively transfers knowledge rather than concentrating it. Good documentation, clear reporting, a platform your team understands better at the end of year two than they did at the start.

The right development partner makes your platform more legible over time, not less. That's a useful test.

On measurement: the question is what you're actually measuring. Hours logged tells you what was spent. It doesn't tell you whether the right things were built, whether the platform is in better shape, or whether the recommendations you're getting are proactive rather than reactive. Those are output measures and they're what the investment is actually for.

We report monthly on what was delivered against plan, how platform quality is trending, where the roadmap stands, and what we recommended, including months where delivery fell short, and why.

If a development partner can't tell you clearly what they built and why it mattered, that's the thing to worry about. Not the contract.

The best protection against dependency is a relationship that demonstrably delivers. Not one that just continues.

That's the six questions. If any of them are relevant to a decision you're currently making, we’d be happy to continue the conversation, get in touch.