Why Your AI Consultant Should Write Code

Here's a pattern I see constantly: a business hires an AI consultant. The consultant produces a beautiful strategy deck — frameworks, roadmaps, vendor comparisons, ROI projections. The business gets excited. Then nothing happens.

The deck sits in a shared drive. Nobody knows how to implement it. The consultant moves on to the next engagement. The business is back to square one, except now they're out $15,000 and a month of leadership attention.

This is the fundamental problem with AI consulting as it exists today — and not just in South Africa: most AI consultants can't build the things they recommend. In fact, 67% of organisations lack the internal expertise to implement AI effectively (IDC). The consultants they hire often have the same gap.

The strategy-execution gap

Traditional consulting follows a model that works for strategy: analyse the situation, recommend a course of action, hand off to specialists for execution. That model works when execution is well-understood — hiring a team, restructuring a department, entering a new market. These are complex, but they follow known playbooks.

AI implementation is different. 80% of AI projects fail — twice the rate of non-AI IT projects (RAND Corporation) — and the strategy-execution handoff is where most of the damage happens. The gap between "what to do" and "how to do it" is where all the risk lives. A recommendation to "deploy an AI-powered customer triage system" sounds straightforward until you hit reality:

• —Which AI model should you use?
• —How do you integrate it with your existing CRM?
• —What happens when the model gives a wrong answer?
• —How do you handle edge cases the AI can't resolve?
• —What does the monitoring look like?
• —How do you update the system as your processes change?

These aren't strategy questions. They're engineering questions. And if the person who recommended the solution can't answer them, you're going to find out the hard way that the recommendation was incomplete.

What "writes code" actually means

I'm not saying every AI consultant needs to be a senior software engineer. But they should be able to:

Build a working prototype. Not a mockup. Not a wireframe. Actual software that demonstrates the solution working with real data. This is the difference between "here's what we recommend" and "here's what it looks like when it works."

Evaluate technical feasibility honestly. If you can build it, you know what's easy and what's hard. You know which parts of the recommendation are straightforward and which ones will take three times longer than expected. Consultants who can't build consistently underestimate implementation complexity.

Integrate with your existing systems. API connections, data pipelines, authentication flows — these are the unglamorous parts that make or break a project. If your consultant has never written an API integration, their architecture recommendations will be theoretical at best.

Debug when things go wrong. And things will go wrong. Models will give unexpected outputs. Integrations will break. Edge cases will appear that nobody anticipated. You need someone who can roll up their sleeves and fix problems, not just document them.

The new model: strategy plus execution

The AI consultants who deliver results are the ones who combine business understanding with technical capability. They can sit in a boardroom and discuss ROI with the CFO, then sit at a terminal and build the solution that delivers it.

This isn't a new idea. It's how the best engineering leaders have always worked. They understand the business context, they can communicate with non-technical stakeholders, and they can build.

What's new is that AI tools have made this combination more powerful than ever. A technical consultant using AI-assisted development tools can build in weeks what used to take teams months. The economics have shifted — you no longer need a large team to execute on an AI strategy. You need one person who can do both.

My approach

I'll tell you how I work, because it illustrates the point. As a CA(SA) with KPMG experience who also writes production Python, I sit in an unusual intersection — I can model the business case and build the solution.

When I do an AI Readiness Audit, I'm not just identifying opportunities — I'm mentally prototyping the solutions. When I write "deploy an AI triage system for customer inquiries," I already know which model I'd use, how I'd connect it to your email system, what the fallback logic would look like, and approximately how long the build would take. Because I've built systems like that before.

When I move to an Implementation Sprint, I build the thing. Not manage a team that builds it. I write the code, deploy the solution, test it with real data, and hand it over with documentation. You deal with one person from strategy through to working software.

That continuity matters. I've built trading bots, habit tracking apps, portfolio trackers, personal assistant bots, iOS apps, and automated newsletter systems. Each one taught me something about what works in production versus what works in theory. That knowledge directly informs my consulting work.

How to evaluate your AI consultant

Next time someone pitches you on AI consulting, ask three questions:

"Can you show me something you've built?" Not a case study. Not a client testimonial. An actual product, tool, or system they personally built. If they can't show you working software, they're selling strategy, not capability.

"Will you be the one building the solution?" If the answer involves "our team" or "our implementation partner," you're in traditional consulting territory. That's fine — just understand you're paying for advice, not delivery.

"What happens when things break?" Every production system breaks eventually. The consultant who built it can fix it. The consultant who only recommended it will write another report about why it broke.

The bottom line

AI consulting is going through the same shift that happened in web development 15 years ago. Early on, you hired a "web strategy consultant" to tell you what to build, then a separate team to build it. Eventually, the market realised that the people who could do both were far more valuable.

We're at that inflection point with AI. The strategy-only model produces expensive documents and slow execution. The build-first model produces working software and measurable results.

Frequently Asked Questions

Why do AI consulting projects fail?

Most failures happen at the handoff between strategy and execution. A consultant recommends a solution, hands off a slide deck, and the business can't implement it. 80% of AI projects fail (RAND Corporation) — and the majority of those failures are scoping and execution problems, not technology problems.

What should I look for in an AI consultant?

Ask to see something they've built — not a case study, but working software. Ask whether they'll be the one building the solution. And ask what happens when things break. The best AI consultants combine business understanding with hands-on technical capability.

How is AI consulting different from traditional IT consulting?

Traditional IT consulting follows well-established playbooks — CRM implementations, ERP migrations, cloud infrastructure. AI implementation is less predictable. Models behave unexpectedly, integration complexity is high, and the gap between a strategy deck and working software is where most risk lives. Your consultant needs to bridge that gap personally.

Can one person handle both AI strategy and implementation?

For mid-market businesses, absolutely. AI-assisted development tools have made it possible for a single technical consultant to deliver what used to require a team. One person who understands your business and can build the solution delivers faster, cheaper, and with less communication overhead than a strategy firm handing off to a dev shop.

If you want someone who can tell you what to build and then actually build it, let's talk. That's exactly what Auto Alpha Advisory does.