AI consultant vs AI engineer: roles, differences, and when you need both
By Dean Griffiths ·
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
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