Two résumés land in the same morning. Both say “AI Engineer.” One belongs to someone who fine-tunes models and reads arXiv papers on the weekend. The other belongs to someone who wired a chatbot to an API on a Saturday and pushed it live. Same two words. Not the same skillset.
So here’s a working definition, the kind you can actually screen against: an AI engineer applies software-engineering discipline to building with and for AI. They own the path from a model to a feature real users depend on, they direct AI agents rather than just prompting and hoping, and they make the result survive production — load, integration, security, the edge cases a demo never hits. Not a researcher who builds the model. Not a coder who pasted in an API call and shipped the vibe.
That distinction carries more weight than the title does, because the title has quietly stopped meaning anything.
Nobody agrees on what “AI engineer” means — and that’s the actual problem
The instinct is to call “AI engineer” the least-defined role in tech. It’s the reverse. Everyone is defining it, all at once, and no two definitions line up.
Andrej Karpathy has argued that AI coding is splitting engineers into two camps — the people who got into this because they liked coding, and the people who liked building. Those camps are pulling apart fast. The data backs the split. A poll of roughly 5,000 developers came back bimodal rather than a tidy bell curve: about 44% now write less than 10% of their code by hand, while about 20% still write more than 90% of it themselves (reported via Karpathy; see ACM, The End of the Coder?). Two populations, same job title, almost no overlap in how they work.
Carnegie Mellon’s James Ivers draws the line in a way that’s useful for hiring: coders operate within bounds that other people define, while engineers operate in the ambiguous space where the bounds get discovered and set in the first place. “Coding is often the easy part,” as he puts it — the engineering is everything around it. Hold onto that, because it’s the thread running through every rung of what comes next.
The ladder: from vibe coder to AI engineer
The cleanest way to define the role isn’t a tool list. It’s a ladder — a sliding scale of how much engineering discipline someone brings to building with AI. Three rungs, roughly.
Vibe coder. Prompts, intuition, trial-and-error. Describe the feature, let the model generate it, and if it runs and the screen looks right, ship it. It’s a real skill for moving fast and exploring an idea — and it’s where “AI coder” usually lands. The ceiling is reliability: a vibe-coded app does great in the demo and falls over the first time a thousand real users hit it.
AI developer. A step up in control. This person integrates models into actual applications — wiring a RAG pipeline, turning a pile of company PDFs into a vector store, getting the feature working inside a real product. They’re writing the logic around the model, not just the prompt. Solid, and sometimes what a team needs.
AI engineer. The top rung, and the one this whole piece is about. Here the work moves to the systems level: designing how the thing behaves under load, building evaluation frameworks to catch when a model update quietly makes the product worse, managing memory and cost and failure modes, and orchestrating agentic workflows that go well beyond a single prompt. The defining move is control. A 2025 study of professional developers — titled, pointedly, Professional Software Developers Don’t Vibe, They Control — found that experienced engineers specifically don’t hand the keyboard to the agent. They plan, they supervise, they verify incrementally, because they care how the code behaves after it ships. That’s the tell. An AI engineer uses the same agents a vibe coder does. The difference is who’s driving.
The boundaries between these rungs are blurry, and reasonable people argue about where an AI developer ends and an AI engineer begins. That argument probably won’t settle soon. Treat the ladder as a lens for locating someone, not a certification for labeling them.
What an AI engineer actually owns: the model-to-user stack
If the ladder tells you how disciplined someone is, the stack tells you what they own. And for anyone doing the hiring, the stack is the screening rubric — five capabilities you can probe one at a time.
It starts with model selection and adaptation — picking the right model for the task’s difficulty, latency, and cost, and knowing when to leave it alone versus when to fine-tune. Most “the AI gave a confident wrong answer” failures aren’t prompt problems, which leads to the second piece: retrieval and context, designing the system that feeds the model the right information at the right moment. Then product integration — the model becomes a feature inside a real application, with all the plumbing that implies.
The fourth capability is where the demo-builders fall away: evaluation and guardrails. Not eyeballing the output and nodding. Real tests that encode expected behavior, structured review, checks that block a bad change before it merges. Eyeballing catches the obvious errors and misses exactly the subtle, edge-case regressions where AI-generated systems break.
And fifth, the one that separates a project from a product: shipping and operating it under load. Keeping it reliable when traffic spikes, when an upstream model changes, when a user does something nobody planned for.
Each rung up the ladder owns more of that stack, with more control. A vibe coder touches the first three on a good day. An AI engineer owns all five and can tell you why each decision went the way it did. When you’re evaluating a candidate, that’s the difference between “I built a thing with AI” and “I own this system and I know how it fails.”
AI engineer vs. ML engineer vs. ML researcher
One more source of confusion, and it’s worth clearing because half the job posts get it wrong. The ladder above runs along one axis: building with models. There’s a second, separate axis — building the models themselves — and the roles on it are not just “more senior” versions of an AI engineer. Different job.
Role
Builds
Core Work
Hire when you need
Vibe coder / AI coder
With models
Prompt-driven prototypes
Speed and exploration, not reliability
AI engineer
With models
Model-to-user stack, agentic systems, production reliability
A model-powered feature that ships and holds up
ML engineer
The models
Training, optimizing, and serving models in production
Custom models or heavy performance tuning
ML researcher
The models
Novel architectures, frontier work
Original research — roughly 4% of the AI talent pool (InterviewStack, 2026)
The position to take, plainly: most teams writing “AI engineer” on a req actually want the disciplined builder-on-existing-models, not a researcher. Hiring a frontier researcher to ship a support chatbot is a mismatch in both directions. And the compensation tracks the work, not the buzzword — AI engineers run a median base around $145K against roughly $165K for ML engineers (InterviewStack, 2026), a gap that reflects how much model-building the role actually involves. Salary follows capability. (More on that in the AI engineer salary breakdown, and on the underlying skills here.)
What to look for when you hire
So you’ve got two résumés with the same title. How do you tell the rung?
Not from the credential. A degree, a certificate, a course list — these tell you what someone was taught, not what they can ship and operate. The strong signal is the opposite direction: systems they’ve actually put in front of real users and kept running. Ask a candidate to walk through one. Where did it break? What did the evals catch that a manual check missed? When the model changed underneath them, what happened? A production-builder has answers with scar tissue on them. A demo-builder has a story that ends at “and then it worked.”
This is why interviews alone are important but cannot be the only filter for the role — they test what someone can describe, not what they can build under real conditions. The more reliable read is observed output: watch what someone ships when the work is real. It’s the logic behind how Gauntlet’s hiring partners evaluate engineers — on systems built and operated under observation, not on whiteboard answers. Different mechanism, same principle: the title is noise, the shipped work is signal.
Place the candidate on the ladder, place them on the stack, and ask for the production scars. That’s the whole evaluation. The two words at the top of the résumé were never going to tell you — but now you know what to read instead.
If you’re hiring engineers who can own the model-to-user stack, here’s how Gauntlet approaches it.