Four Questions Every Technology Leader Is Asking About AI

Nearly every conversation I have with a technology leader at the moment converges on the same four questions. They are rarely asked this plainly — they arrive buried in a procurement document or halfway through a scoping call — but underneath, this is what people want to know.

They are good questions. They are also, all four, questions about control rather than capability. Nobody seriously doubts that AI can generate code any more. What people doubt is whether they will still recognise their own architecture in six months, and whether they will be able to explain to a board, an auditor or their own client what actually happened.

Here is how we answer them.

1. How do we ship faster without quality slipping?

The instinct is to treat this as a tooling question. It isn't. Generating code quickly is the easy part, and it is not where projects go wrong.

The speed comes from somewhere less exciting: a sharper specification. We spend more time up front getting scope genuinely nailed down, because AI-assisted build amplifies whatever you point it at. Point it at a vague requirement and you get a large volume of confidently wrong code, very quickly.

The second half is review. AI-generated code can look right while being subtly wrong — plausible structure, clean syntax, and a misunderstanding buried three functions deep. We treat that as a first-order risk rather than a footnote: every substantive output is reviewed by a second senior engineer, and that review is structural to how our pods are staffed, not something that happens if there is time left.

Speed that comes from skipping review isn't speed. It's deferred cost, and it lands later with interest.

2. How do we let engineers use AI without losing control of the architecture?

This is the one I get asked most often, usually by someone who has already watched it happen somewhere.

The failure mode is well understood by now. Individual engineers each become materially more productive, output goes up across the board, and nobody is holding the shape of the system in their head any more. Six months on, the codebase has four different ways of doing the same thing, because four people asked a model to solve the same problem in four separate sessions and each answer was reasonable on its own.

The control point is not the tool. It is whether someone senior owns technical direction and reviews what ships against it. On our engagements that is a named Lead Orchestrator who sets direction and owns what goes out — a specific person, not a rota.

The other half is making AI involvement visible during review. When the team can see what was AI-assisted and how it was checked, architectural drift gets caught in a pull request instead of in a post-mortem.

3. What is AI actually costing us — and what is it doing with our data?

The cost question is real, and it is usually the one asked out loud.

The data question matters more, and it tends to surface later — often because a client, an auditor or a procurement team asked it first. Which model saw our source code? Which saw customer data? Where did that data go, and who can attest to any of it?

That is a governance question, and it cannot be answered retrospectively. Either you documented your data-boundary controls before the work started, or you are reconstructing them under pressure with someone waiting. This is precisely what ISO 42001 gave us a framework for: approved tools, defined contexts, documented data handling, and human oversight recorded as it happens rather than assembled afterwards.

4. How do we make our teams AI-native without it becoming a free-for-all?

"AI-native" is doing a lot of unexamined work in most conversations. In practice it tends to mean two things at once: our people use these tools fluently, and we can still explain what they did.

Most organisations are thin on the second half. Fluency spreads on its own — engineers are motivated and the tools are genuinely good. What does not spread on its own is the unglamorous scaffolding around it: which tools are approved for which contexts, what data may go where, what must be reviewed by a human before it reaches a client codebase, and what happens when something goes wrong.

That is substantially what certification required us to build. Much of it was formalising what we already did informally; the rest was closing gaps we had not noticed we had. The useful outcome was never the certificate on the wall. It was that when a client asks how AI is being used on their project, there is a documented answer rather than a reassuring one.

All four are the same question

Read them together and they collapse into one: can you show me?

Not can you tell me — can you show me. That distinction is why we put our delivery data into a client-facing view rather than a monthly slide deck. Release history, health and uptime, what shipped and when, what is awaiting your approval. The same numbers our own teams work from, filtered to your project. Reporting written by the people being measured is not really reporting.

What I'm not going to tell you

I could quote you a multiplier. A lot of people are at the moment, and some of the figures are impressive.

I'm not going to, because the honest answer is that it depends almost entirely on scope, on the maturity of the codebase, and on how well the problem was specified before anyone opened an editor. A well-scoped greenfield feature and a change deep inside a fifteen-year-old system are not the same exercise. Any single headline number is averaging across cases that should not be averaged, and you would be right to discount it.

What we will do instead is scope your actual work and tell you what we think it takes. If that turns out to be faster than your current baseline, it is a result you can verify rather than a number you have to take on trust.

If any of these four questions are live for you right now, I'm happy to talk them through — including the parts where our answer is "it depends". Get in touch.