Not Every AI Expert Is Actually One. Here's How to Tell.

Let me share something that’s been coming up a lot in our community lately.

At a recent networking event, I noticed something that’s probably familiar if you’ve been in any business room recently — physical or virtual. Almost every single person introducing themselves mentioned AI. “I use AI in my business now.” “I’ve been building with AI.” “I’m an AI consultant.”

There’s nothing wrong with that. AI tools are genuinely useful, and more people adopting them is a good thing.

But here’s what concerns me. When you’re an SME owner looking to hire someone to help you build or use AI in your business, how do you tell apart the person who installed a tool last month from the person who has been architecting systems for years? Right now, they’re using the same words. And the price gap between them can be enormous — in both directions.

This isn’t about gatekeeping. It’s about helping you spend your budget on the right thing.

The landscape right now

There’s a term in the developer community: vibe coding. It refers to using AI tools — typically large language models — to generate code or build simple automations without deeply understanding the underlying systems. Type a prompt, get an output, deploy it. Sometimes it works brilliantly for simple tasks.

The explosion of accessible tools like local AI models, no-code AI builders, and plug-and-play automation platforms has meant that a lot of people can now produce something that looks like an AI solution. Fast. Cheaply. Sometimes impressively.

But looking like an AI solution and being a reliable, scalable business system are two very different things.

What the difference actually looks like

I work alongside Alan Law, V8 Global’s co-founder, who has spent fifteen years building commercial systems — long before the current AI wave. The five questions below come from watching what separates the work he does from the work that goes wrong elsewhere.

When someone builds you an AI solution, they’re making a set of decisions that either compound into a stable system or compound into a fragile one. The difference usually comes down to things you can actually ask about.

Do they design before they build? A vibe coder reaches for the tool first. They start prompting, see what comes out, and iterate from there. An AI architect designs the system before writing a line of code — what data flows where, what happens when something fails, how the different parts talk to each other. If someone can’t explain the structure of what they’re building before they build it, that’s a flag.

Do they understand the problem, or just the tool? There’s a meaningful difference between someone who has learned a specific AI tool and someone who understands the business problem underneath. The tool changes — what works on one platform today may be deprecated in six months. A practitioner who understands your actual business objective can adapt. Someone who only knows the tool has to start over.

Can they explain their decisions — and their tradeoffs? Every architecture decision involves a tradeoff. Why store data this way and not that way? Why use this model for this task? Why is the system built to pause at this point and ask for a human decision? A competent practitioner answers these in plain English, without jargon fog. If the answer is “that’s just how the tool works,” that’s worth probing.

Do they think about failure? What happens when the AI gets it wrong? What’s the fallback? What does the audit trail look like? These questions tend to separate people who have shipped things that break in production from people who haven’t. Anyone who’s been through a system failure has strong opinions about this. Anyone who hasn’t tends to look surprised when you bring it up.

Is there a methodology, or just outputs? This is a subtle one. Some practitioners have developed a repeatable methodology — a way of approaching AI projects that transfers across clients and contexts. That methodology is where the real value sits, because you can hold them accountable to it. Others produce outputs and call it a process. Ask them to walk you through how they typically approach a project from start to finish. The answer will tell you a lot.

Why this matters for your budget

The pricing problem right now is real. When every person in a networking room is calling themselves an AI expert, it creates pressure to drive prices down toward the least experienced operator. That’s bad for everyone — including you, because you end up paying less for something that doesn’t work and then paying again to fix it.

A well-architected AI system, built by someone who understands both the technology and your business context, should save you time, reduce errors, and scale with you. A poorly-built one creates technical debt, fragile dependencies, and the sinking feeling six months later that you need to start over.

The questions above aren’t designed to catch anyone out. They’re designed to help you have a more useful conversation — one that gets past the buzzwords and into the actual capability underneath.

The shift worth making

You’re not looking for perfect answers. You’re looking for someone who clearly thinks in systems, not just outputs.

The AI wave is real and it’s not slowing down. The opportunity for SME owners to genuinely transform how they operate is significant. But that opportunity is better realised with someone who has built the infrastructure of their own thinking around this — not just someone who has downloaded the same tools everyone else has.

The good news: the difference is visible, if you know what to look for.

---

Gina Cheng leads V8 Nexus — a curated executive community for London’s business leaders integrating AI into how they actually work. She writes about what she sees in the field.