The Confusion Is Real
If you are trying to hire for an AI project, you will encounter a confusing landscape of job titles: AI developer, ML engineer, data scientist, AI engineer, LLM engineer, AI solutions architect. These titles overlap, are used inconsistently across companies, and mean different things in different contexts.
Getting this wrong has practical consequences: you hire someone with deep expertise in model training when you needed someone who knows how to integrate a pre-trained model into a production application, or vice versa. A six-person SaaS company in Chicago that needed a chatbot for its support portal hired an ML engineer with a PhD background in NLP model training — and after three months, had a trained classification model but no working product and no integration with their Zendesk instance. That mismatch cost them around $40,000 in fees and lost time.
This guide draws a clear line between the two most commonly confused roles and helps you identify which one your project requires.
What an ML Engineer Does
A machine learning engineer works on the model layer of AI systems. Their core skills are:
Training and fine-tuning models. Taking a dataset, selecting or designing a model architecture, running training jobs, evaluating model performance, and iterating until the model meets performance targets. A training run on a moderately complex model can take days and cost hundreds of dollars in compute — decisions made at this stage have long downstream consequences.
Feature engineering. Transforming raw data into the numerical representations that models can learn from. For a fraud detection model, this might mean deriving velocity features (how many transactions in the last 10 minutes), merchant category codes, and distance-from-home-location signals. This often represents 40–60% of the total effort on an ML project, and it is where domain knowledge is critical.
Model evaluation and experimentation. Running systematic experiments to compare model architectures, hyperparameter settings, and training data compositions. Building the infrastructure to track experiments and compare results — tools like MLflow or Weights & Biases are standard here. Without rigorous experimentation, teams end up with models that perform well in testing but badly in production.
Data pipeline engineering. Building the pipelines that collect, clean, transform, and serve data to training and inference systems. Data quality is the primary determinant of model quality, and ML engineers spend a lot of time here. A common failure mode: teams underestimate how much raw data is unusable — labelling errors, schema inconsistencies, sampling bias — and the cleanup work pushes delivery timelines significantly.
Model deployment and inference optimisation. Serving a trained model in a way that handles real traffic efficiently — model compression, quantisation, batching, hardware selection. A model that performs well in a notebook and a model that handles 10,000 inference requests per day at acceptable latency are very different engineering problems.
An ML engineer's typical output is a trained model — a set of learned weights that perform a specific task (classifying images, predicting churn, detecting fraud) on new data.
What an AI Developer Does
An AI developer works primarily at the application layer. Their core skills are:
LLM integration. Connecting to large language model APIs (OpenAI, Anthropic, Google) and building systems around them — prompt design, output parsing, error handling, retry logic, cost management. The prompt engineering piece is more substantial than it sounds: getting consistent, structured output from an LLM across varied real-world inputs requires systematic testing and iteration, not just writing a clever sentence.
Retrieval-augmented generation (RAG). Building the systems that give LLMs access to company-specific knowledge: document ingestion, chunking, embedding, vector storage, retrieval, and context assembly. A law firm with 15 years of case archives and internal precedent documents cannot just paste that into a chat window — a well-engineered RAG pipeline makes that knowledge queryable by the LLM. Getting retrieval right (chunk size, embedding model choice, re-ranking) has a large impact on answer quality.
Agent and tool development. Designing AI agents that can take actions — calling APIs, querying databases, running calculations, triggering workflows — and orchestrating multi-step reasoning. An agent that can look up a customer record, check inventory, calculate lead time, and draft a personalised response is meaningfully different from a chatbot that only answers from static FAQs.
Integration engineering. Connecting AI components to business systems: CRMs, booking platforms, databases, communication tools. This is often where the real value is created, and it is typically 30–40% of the work on any AI application project. An AI booking assistant that cannot write back to the scheduling system is not useful — the integration layer is what makes the application functional.
Evaluation and observability. Building the infrastructure to monitor AI system behaviour in production: logging, evaluation datasets, quality metrics, alert systems. LLMs can degrade silently — a prompt that worked well three months ago may perform worse after a model update or when input distributions shift. Teams that do not invest in evaluation infrastructure often do not realise this is happening.
An AI developer's typical output is an application — a chatbot, a document processor, a voice agent, a web app with embedded AI features — built using pre-trained foundation models as the intelligence layer.
The Critical Difference
The most important distinction is: does your project require training a model, or using an existing one?
You need an ML engineer if:
- You have proprietary data that is not represented in existing models and the task requires learning from that data
- You are building a recommendation engine, fraud detection system, predictive analytics model, or computer vision system that requires custom training
- You need to fine-tune a foundation model on your specific domain and data at a deeper level than API-based fine-tuning supports
- You are optimising model inference for specific hardware constraints (on-device, edge deployment)
- Your inference volume is high enough that API costs exceed the cost of running your own model — typically above several million tokens per day
You need an AI developer if:
- You are building a chatbot, document assistant, voice agent, or any application that uses existing LLMs as the intelligence layer
- You need LLM integration into a product: embedding AI features into a web application, connecting an LLM to business systems
- You are building a RAG pipeline to let an LLM answer questions from your company's documentation, contracts, or manuals
- You need an AI agent that can reason and take actions using tools and APIs
Off-the-Shelf vs Custom Model: A Practical Comparison
| Factor | AI Developer (LLM APIs) | ML Engineer (Custom Model) |
|---|---|---|
| Time to first working prototype | 1–4 weeks | 3–6 months |
| Upfront cost | Low (API subscription) | High (compute, data labelling, engineering time) |
| Ongoing inference cost | Per-token API pricing | Fixed infrastructure cost (scales differently) |
| Requires labelled training data | No | Yes — often thousands to millions of examples |
| Data privacy risk | Queries sent to third-party API | Data stays on your infrastructure |
| Performance on general tasks | Strong out of the box | Depends heavily on data quality |
| Performance on very narrow domain | Requires good RAG/prompting | Can be superior with enough data |
| Maintenance overhead | Low (provider handles model updates) | High (model retraining, pipeline monitoring) |
The Overlap
Modern AI development blurs these lines in a few ways.
Fine-tuning has become more accessible, so some AI developers do fine-tune smaller models for specific tasks — using tools like OpenAI's fine-tuning API or Hugging Face without deep ML engineering expertise. This sits in the middle: it is more than pure application development but less than training from scratch, and it is appropriate for specific scenarios like adapting a model to produce a specific output format reliably.
Many ML engineers also build production applications and have strong software engineering skills alongside their ML training expertise. At larger companies, these roles are more specialised; at smaller startups or agencies, individuals often cover both.
The most capable AI practitioners have depth in both: they understand the model layer well enough to make good architecture decisions, and they have the application engineering skills to build reliable production systems.
What Most Business AI Projects Actually Need
The vast majority of business AI projects in 2026 do not require training a model from scratch. They require:
- A well-designed LLM application using one of the existing foundation models
- A thoughtful RAG pipeline built on the company's knowledge base
- Solid integrations with existing business systems
- Reliable infrastructure, monitoring, and evaluation
This is AI developer work. The model sophistication is provided by GPT-4o, Claude 3.5, or equivalent — the engineering effort is in building the application layer around it correctly.
Custom model training becomes relevant when foundation models cannot handle your specific data type or domain, when the volume of inference makes API costs prohibitive, or when data privacy prevents sending queries to third-party providers. These are real constraints, but they apply to a minority of business AI use cases.
Consider some concrete examples: a 12-person law firm in London that wants an internal assistant to search case notes and draft first-cut contract clauses needs an AI developer, not an ML engineer. A mid-sized retail chain with three years of transaction data that wants to predict which products to restock at each location needs an ML engineer. A B2B SaaS company that wants to add a natural language interface to its dashboard for non-technical users needs an AI developer.
What to Expect in Practice
If you hire an AI developer for an LLM application project, the engagement typically looks like this: the first one to two weeks involve scoping the use case, auditing your existing data and systems, and agreeing on the architecture. The next two to four weeks are building the core application — RAG pipeline, integrations, the agent logic or chat interface. The final phase is evaluation, iteration based on real inputs, and deployment.
A realistic timeline for a functional, production-ready AI application is six to twelve weeks, depending on integration complexity. The most common reason projects run over is unclear requirements at the start — the scope of "what the AI should be able to do" expands during development without a corresponding adjustment to timeline or budget.
If you hire an ML engineer for a custom model project, the engagement looks different: weeks one to four involve data assessment and preparation. Weeks four to twelve involve training runs, evaluation cycles, and iteration. Deployment adds further weeks, and the project does not end there — models require retraining as data distributions change over time. Expect a six-month engagement before you have a model performing reliably in production, and a long-term commitment to maintaining it.
Common Mistakes When Hiring for AI Projects
Hiring for the wrong role entirely. The most common mistake — detailed above. It stems from not having a clear picture of whether the project needs model training or application development.
Hiring a generalist data scientist when you need a specialist. Data scientists often understand ML theory and can analyse data, but may lack the production engineering skills to build reliable deployed systems. The data science and ML engineering disciplines have diverged significantly.
Assuming the AI developer can also handle all the data work. If your company's data is scattered across five systems in inconsistent formats, that is a data engineering problem that exists before the AI layer. Some AI developers can handle this; many cannot efficiently. Scope the data preparation work separately.
Underspecifying the integration requirements. The number of systems the AI application needs to talk to — and the reliability requirements on those integrations — has a large impact on cost and timeline. Be specific about this upfront.
Not building an evaluation framework. Teams that skip evaluation infrastructure have no way to know if their AI application is performing well or degrading. This is not optional if you care about quality in production.
Questions to Determine Which You Need
Ask yourself these questions before hiring:
- Will you be training a model on your own data, or using a pre-trained foundation model via API?
- Is the core intelligence layer going to be a custom model or an existing LLM?
- Is the primary challenge model quality, or application design and integration quality?
- Does your use case involve image/video/audio classification, tabular prediction, or other non-text modalities that existing LLMs do not handle well?
- Do data privacy requirements prevent you from using a third-party API?
If most of your answers point toward custom models and proprietary data, you need ML engineering depth. If they point toward LLM integration and application engineering, you need an AI developer.
Related guides
- How to find the best AI developer
- What an LLM developer actually does
- What most business AI projects actually need
- How to choose an AI development company
- Our tech consulting services
What We Are at Woyce
We are AI developers. We build applications using foundation models — LLM integrations, RAG pipelines, AI agents, voice AI, and AI-powered web applications.
We do not train custom models from scratch — that is a different discipline. We use the best available foundation models for the task and focus our engineering effort on building production-quality applications around them.
Talk to us if that is what you need — tell us what you are trying to build and we will tell you whether we are the right team.
Frequently Asked Questions
What is the salary difference between an AI developer and an ML engineer?
In the US market in 2026, ML engineers typically command higher base salaries than AI developers — $160,000–$220,000 versus $120,000–$170,000 — because deep ML expertise is rarer and more specialised. In practice, if you are hiring an external agency or contractor rather than a full-time employee, the day rate difference is smaller, and the more important factor is whether you are buying the right skill set for your project.
Can one person do both the ML engineering and AI application development work?
Yes, some practitioners span both disciplines — typically senior engineers who have worked in production ML for several years before moving into application development, or vice versa. However, for a focused project, generalism often means reduced depth in one area. If your project is primarily LLM application work, hiring someone who is strong at both may mean paying for ML depth you will not use.
Do I need an ML engineer to fine-tune a model?
Not always. Fine-tuning through API-based services like OpenAI's fine-tuning endpoint requires relatively little ML depth — it is closer to AI developer work. What does require ML engineering is fine-tuning at the level of modifying model architecture, running your own training infrastructure, or working with large model weights directly. If you are fine-tuning to adjust tone or output format, an AI developer can likely handle it. If you are fine-tuning for significant domain adaptation with proprietary data, you need ML engineering skills.
How much does it cost to build a business AI application in 2026?
A straightforward LLM application — a chatbot with RAG over a document library, integrated into one or two business systems — typically runs $15,000–$40,000 for an agency build. More complex multi-agent systems with several integrations can reach $60,000–$120,000. Custom model training projects are substantially more expensive, often $100,000+ when you account for data preparation, compute, and the longer development cycle. Ongoing API costs for LLM applications are typically $200–$2,000 per month for a business-scale deployment, depending on usage volume.
What questions should I ask when evaluating an AI development agency?
Ask for the last three projects they shipped and what problems they ran into. Ask how they handle evaluation — what metrics they use and how they measure whether the AI is performing well after deployment. Ask how they approach integration with your existing systems. Agencies that struggle to answer these concretely are likely to give you a prototype that works in a demo but falls apart in production.
Is it possible to start with an AI developer and bring in an ML engineer later?
Yes, and this is often the right sequence. Build the LLM application first, get it into production, measure what it cannot do well, and then assess whether custom model training would close that gap. Many projects that initially seem to require custom training find that better RAG design or improved prompting solves the problem — without the cost and timeline of a training project.
What is a "vibe check" question to ask an AI developer candidate?
Ask them to describe the last RAG pipeline they built and where retrieval went wrong. Good AI developers will immediately talk about chunking strategy, embedding model choice, retrieval recall problems, and how they measured and fixed them. Weak candidates will describe the happy path only. Similarly, ask them how they would handle an LLM that starts producing lower-quality responses after a model update — the answer should involve evaluation datasets and monitoring, not just re-prompting manually.