Generative AI consulting: when to hire a consultant vs an engineer

Choose generative AI consulting when your open question is what to build, for whom, and whether it is worth it. Choose an engineer when the question is whether a defined feature can run reliably with real data, permissions, failures and costs. Many projects need both, and the order matters: decide first, then build.

The confusion is understandable. Both roles use the same vocabulary, and many people sell themselves as both. But the deliverables are different, and hiring the wrong one for your current question is an expensive way to learn the distinction.

Why the two roles get confused

Generative AI lowered the cost of a convincing demo. Anyone who can write good instructions can produce an impressive result in an afternoon. That makes it hard to tell, from a sales conversation, whether someone can shape a sound product decision, ship a production system, or neither.

Titles do not help. A consultant may write code for prototypes. An engineer may run discovery workshops. The useful question is not the title but the artifact you will have at the end: a decision you can act on, or a system you can operate.

There is also a market incentive to blur the roles. Strategy-led firms want to capture implementation budgets; engineering shops want to be involved earlier. Buyers end up with proposals that promise everything from opportunity mapping to deployment, without making clear which part is the real strength.

What teams often get wrong

The first mistake is hiring an engineer before the problem is defined. An engineer given a vague brief will build something, because that is the job. The result may work technically and still solve the wrong problem, or solve the right problem for a workflow nobody uses.

The second mistake is hiring a consultant to answer an engineering question. If you already know you need a support assistant grounded in your help center, with human handoff, a strategy engagement will mostly restate what you know. The real unknowns are retrieval quality, latency, handoff rules and evaluation, which are engineering problems.

The third mistake is assuming a strategy deliverable transfers cleanly to a build team. Recommendations written without testing against real data often miss the constraints that dominate implementation: rate limits, missing fields, permission models, and the cost of running the model at your actual volume.

Budgeting follows the same confusion. Teams sometimes spend most of their budget on discovery and leave too little to build anything reliable, or skip discovery entirely and spend the build budget on a feature nobody asked for. Decide upfront roughly how much of the effort goes to deciding and how much to delivering, and revisit that split once the first phase produces evidence.

The fourth mistake is not planning the handoff at all. If a consultant and an engineer are different people, the test cases, definitions of good and risk notes from the first phase must travel intact to the second.

A practical way to decide

Start by writing down your open question in one sentence. Then match it to the role that can answer it.

Hire generative AI consulting when:

• You have several candidate use cases and need to choose which one is worth pursuing.
• Stakeholders disagree about where AI fits, and you need an outside view grounded in evidence.
• You need to understand risk, data handling and review requirements before committing budget.
• You are deciding between building, buying, or not using generative AI for a workflow.

Hire an engineer when:

• The feature is defined: who uses it, what it reads, what it produces, and what counts as correct.
• The main risks are technical: integration, retrieval quality, latency, failure handling, cost at volume.
• You need something that runs in production with logging, permissions and monitoring.
• An existing prototype needs to become reliable, secure and maintainable.

Hire someone who can credibly do both when:

• The workflow is specific to your business and the decision depends on what is technically feasible.
• You want the person who shapes the decision to be accountable for whether it ships.

Implementation considerations

Whichever role you hire, ask for artifacts that survive the engagement. From a consultant, that means ranked use cases with evidence, a written definition of good for the chosen workflow, real test cases, a risk list, and effort drivers for implementation. From an engineer, it means working code in your repository, documented configuration, logs that let you reconstruct each run, and a way to evaluate changes before shipping them.

Check how each candidate handles failure. A consultant should be able to describe what would make the recommended project fail and how you would notice early. An engineer should be able to show how the system behaves when the model provider times out, returns malformed output, or is rate-limited.

Clarify ownership of prompts and instructions. In generative AI systems, instructions are part of the product. They should be versioned, reviewable, and changeable without an emergency deploy. If a proposal treats them as throwaway text, that is a warning sign.

Finally, agree on evaluation early. A generative AI feature without a test set drifts. Whether the first phase is consulting or engineering, it should leave you with examples and grading notes that anyone can rerun.

Trade-offs

A pure consultant is usually faster at mapping options and facilitating decisions across stakeholders, but the recommendations carry more implementation risk because they have not been tested against real systems.

A pure engineer delivers working software but may not challenge whether the software should exist. If your problem definition is weak, that is a real cost.

A person or small studio doing both reduces handoff loss and keeps accountability in one place. The trade-off is capacity: a founder-led team can only run so many projects at once, and may be less suited to coordinating a large multi-department strategy program.

Splitting the roles across two vendors can work, but only if the handoff is explicit. Budget time for the engineer to review and challenge the consultant's findings before building.

Lessons from ImadDhin work

The following are code-level observations from the portal's agent workspace. They illustrate the kind of decision that looks like strategy but can only be settled with engineering, not client results.

The agent offers several modes. The code mode is routed to a coding-agent service, while the analysis, design, management and advisory modes are routed to a general model through a separate interface, with a legacy runtime kept as a fallback path. Choosing that routing was a product decision, but it depended on engineering facts: which provider handled each task well, how each failed, and what each cost to run.

Free and paid capability are separated at the server route. Free chat is limited to a small number of prompts and stays chat-only, while research and web tools require the paid tier, and the route returns a payment-required response rather than trusting the browser. A strategy document can recommend a freemium model; only an implementation can enforce it.

Provider failures are mapped to a user-facing error message rather than to the static introduction text. That is a small detail that consulting deliverables rarely mention and production users always notice.

The public FoCoCo case study shows the combined role at product scale. The same person designed and engineered the phone app, the web app, the shared backend, real-time voice and memberships. Product questions, such as what the coach should and should not do, were decided alongside engineering questions, such as how conversations, rounds and practice data connect across both apps. Neither set of questions could have been settled well in isolation.

Common mistakes to test for

• Ask a consultant candidate for an example of a project they recommended stopping, and why.
• Ask an engineer candidate to show how their past systems log inputs, outputs and instruction versions.
• Check that recommendations include data access and review requirements, not only use cases.
• Confirm that a proposed build includes a test set and a way to compare versions.
• Look for a clear handoff plan if consulting and engineering are split.
• Verify that costs are described as drivers with stated assumptions, not as firm numbers before discovery.

When a simpler solution is better

If your use case is well understood and an off-the-shelf product covers it, you may need neither a consultant nor an engineer, only someone on your team to configure the tool and watch the results. If you have a defined feature and a small budget, a short engineering engagement with a clear brief is often better value than a discovery phase that restates what you already know. The six-step project brief is designed for exactly that case.

The same applies to prototypes. If a tool-generated prototype already proves the idea and users want it, the next step is rarely more strategy. It is an engineering review of security, data handling and reliability, which is the focus of prototype-to-production work.

Generative AI consulting earns its fee when the decision is genuinely uncertain and wrong choices are expensive. Engineering earns its fee when the decision is made and reliability matters.

Match the hire to the question

Write down your open question. If it is about what and why, start with consulting. If it is about how and whether it holds up, start with engineering. If it is both, look for someone who can answer both and is accountable for the result.

Explore AI product development for defined features, AI automation consulting for decisions still in play, or talk it through in a 30-minute call.