AI consultant vs AI engineer: roles, differences, and when you need both
By Dean Griffiths · · Updated
An AI consultant diagnoses which problems AI should solve and how. An AI engineer designs and builds the system. For UK mid-market builds, the most effective model is a single senior engineer-consultant who does both — running the discovery diagnostic and writing the production code. Separating the roles creates handoff loss: the consultant's diagnosis gets diluted in translation and the engineer builds to a spec that was never quite right.
The two roles, plainly
An AI consultant analyses the business, diagnoses which operational problems AI can solve, and advises on strategy: build vs buy, vendor selection, risk profile, where to start. The deliverable is typically a diagnosis, a recommendation, and sometimes a programme plan. They may not write a single line of production code.
An AI engineer designs and builds the system: writes the backend code, configures the integrations, deploys to production, instruments the monitoring. The deliverable is working software. They may or may not have run the diagnostic before building.
Both roles are legitimate. The distinction matters because they fail in different ways when deployed incorrectly.
How each role fails in isolation
A consultant who cannot build gives you a diagnosis and then leaves. You walk away with a well-framed problem and no system to solve it — and then you need to brief an engineer against a written spec that was always a simplification of the conversation. The spec loses nuance in translation. The engineer builds to the spec. You get a system that solves the written version of the problem, not the real one.
An engineer without a diagnostic frame builds what they are asked to build. If the brief is correct, the output is correct. If the brief is optimising the wrong thing — solving a symptom rather than the underlying cause — the output is a well-engineered system for the wrong problem. This is more common than it sounds. Most UK mid-market operators know they have a bottleneck; fewer know exactly what shape the fix should be before the data flows are mapped.
The 5-criterion comparison
| Criterion | Lean toward consultant | Lean toward engineer |
|---|---|---|
| 1. Problem clarity | You know there is a bottleneck but cannot specify the fix. Requires diagnostic work before a build brief can be written. | You already have a well-specified system brief: exact inputs, outputs, integrations, and acceptance criteria. |
| 2. Build readiness | The right tool (voice agent vs CRM vs document automation) is not yet determined. Consultant selects the right instrument. | The tool is already selected. The work is implementation, not strategy. |
| 3. Vendor landscape | You need guidance on which model providers, APIs, and infrastructure choices fit your data-sensitivity, cost, and latency constraints. | Vendor decisions are already made. The work is integration and build, not evaluation. |
| 4. Stakeholder alignment | Multiple internal stakeholders need to be aligned before a build starts. Consultant facilitates and documents the decisions. | Stakeholders are aligned. Decision-maker is ready to commission. |
| 5. Risk profile | Build-first risk is high — wrong system, wrong integration, wrong scope. Diagnostic investment is justified by the downside of getting it wrong. | Build-first risk is low. The system is well-understood; execution is the remaining uncertainty. |
When you need both — and why the best UK mid-market builds combine them
Most UK mid-market AI builds fall into a middle category: the operator knows which part of the business is leaking time and money, but the exact shape of the fix is not yet determined. A voice agent might be right — or the problem is upstream, in the CRM data model, and the voice agent would be treating a symptom. A bespoke CRM might be right — or three of the five SaaS tools can stay and the real work is a lightweight integration layer.
The diagnostic work and the build work require different thinking modes. They do not require different people. A senior engineer who is also rigorous about discovery will run the diagnostic pass, map the actual data flows, identify the real source of the bottleneck, and then build the right system for it — without the translation loss of a brief that passed through several hands.
This is what AIMindShift's discovery call is designed to be: a working session run by Dean — the engineer who would build the thing — not a sales call run by an account manager. You get the diagnostic and the build capability in one. If a build is not the right answer, the call will say so.
Day-rate framing — what each model costs in the UK
- Advisory-only AI consultant: £600–£1,200/day. Diagnosis, strategy, vendor selection, programme planning. No production code.
- Senior AI engineer (independent / tight team): £800–£1,400/day. Production code, integrations, deployment, architecture decisions.
- Senior AI engineer-consultant (both roles, one person): £800–£1,400/day. Discovery-led, builds the system. No overhead layer.
- AI agency (senior engineer billed through agency overhead): £1,200–£2,000/day. Same engineer, plus account management and PM overhead on top.
For UK mid-market builds (typically £25k–£200k), the engineer-consultant model delivers both the diagnosis and the system at the bottom of the day-rate range — no advisory-only fee stacked before the build, no agency overhead stacked on top of it.
What to ask before engaging either role
Whether you are talking to a consultant, an engineer, or someone who claims to be both, the same five tests apply — covered in detail in the how to evaluate an AI consultant guide:
- Can you show production code from a live build?
- How would you handle data sensitivity for my specific data?
- What would you tell me NOT to build?
- What was the integration list on your last build, and what was hard about it?
- Will I own the code at the end?
A consultant who cannot answer questions 1, 4, and 5 with technical specifics is advisory-only. An engineer who cannot engage with question 3 has not run a discovery pass. The right answer to all five is a useful filter on both roles.
Common questions on this topic
An AI consultant diagnoses which problems AI should solve and advises on strategy, vendor selection, and build-vs-buy decisions. An AI engineer designs and builds the AI system — writes the code, configures the integrations, deploys to production, and maintains it. The distinction matters because many organisations hire one when they need the other: a consultant who cannot build means you still need an engineer; an engineer without a diagnostic frame means you may build the wrong thing.
Yes, and for UK mid-market builds that is usually the right model. A senior engineer-consultant combines the diagnostic depth (discovery, bottleneck mapping, scope definition) with the production capability (architecture, code, integration, deployment). The risk with separating the roles is handoff loss: the consultant's diagnosis gets diluted in translation to the engineering brief, and the engineer builds to a spec that was never quite right. When one person holds both, the system is built around the actual problem.
If you can already describe the system you want built in technical detail — exact inputs, outputs, integrations, and success criteria — you need an engineer. If you know there is a bottleneck costing you money but you do not yet know whether the fix is a voice agent, a CRM replacement, a document automation pipeline, or something else entirely, you need the diagnostic pass first. Most UK mid-market engagements start with the diagnostic because the "obvious" solution changes once the actual data flows are mapped.
Production code: backend services, API integrations, edge functions, database schemas, AI model orchestration layers, operator dashboards. Day-to-day work looks like: reading the caller's intent from a Twilio webhook and triggering the right response via an LLM; building the Postgres schema that stores lead-qualification results; writing the edge function that syncs five upstream APIs into one bespoke CRM; deploying the result to Netlify or Supabase with proper auth and logging. It is software engineering with AI as one component — not chatbot configuration.
The discovery call is a technical conversation run by the engineer who would do the work. There is no account manager, no strategist, no PM layer between diagnosis and build. The bottleneck map that comes out of discovery is written by the person who can assess whether each fix is actually engineering-feasible and at what cost. That compression — diagnostic skill and build skill in one person — means you do not pay for translation loss, and the thing we build is shaped around the actual problem, not a spec that passed through several hands.
For focused single-workflow builds (one voice agent, one automation pipeline, one document system): 3–6 weeks. For a bespoke CRM ecosystem replacing multiple SaaS tools: 8–14 weeks. For an end-to-end platform (public site + AI agents + CRM + mobile app): 16–24 weeks under a retainer. Discovery surfaces the scope and timeline before any commitment is made.
Still have a question? Book a discovery call — direct line to me, Dean.
Related capabilities
AI consultant vs AI agency →
Once you know you want a consultant model, decide between independent consultant and agency.
How to evaluate an AI consultant →
Five concrete tests that filter genuine engineers from prompt-slingers.
What is an AI consultant? →
Role definition, day-rate ranges, and what good consultancy practice looks like in the UK.
AI implementation (pillar) →
The full implementation process — discovery, scoping, build, integration, deployment.
Book a discovery call →
Technical conversation with the engineer who would do the work.
Want to apply this to your operation?
A 45–60 minute discovery call. Map the bottlenecks. Get a costed bottleneck map — whether we build or not.
Book a Discovery Call