FDE, LLMOps, Vibe Coder: Where These Roles Actually Land
The job titles mutated fast. Two years ago most AI-adjacent engineers just called themselves software engineers. Now job posts list FDE, LLM Engineer, LLMOps Engineer, GenAI Software Engineer, and vibe coder, sometimes in the same paragraph.
They're not marketing noise. Each one points at a genuinely different kind of work that only became full-time once LLMs moved from demos into production systems.
The confusion runs deepest with ML Engineer and AI Engineer. People use them interchangeably. They shouldn't.
FDE: The Engineer Who Ships in Your Environment
FDE stands for Forward Deployed Engineer. The concept came from Palantir, but it's found a new home in GenAI teams. The job is to embed with the customer, in their environment, under their constraints, and make the system actually work there.
For GenAI, that environment is often the hard kind. Air-gapped clusters. Legacy data centers. Regulated infrastructure where data can't leave the building, let alone hit an external API. You can't hand someone an API key and call it a deployment. The FDE's job is closing the gap between "the model works in our cloud demo" and "the system works in their production."
The work is less about building new things and more about adapting existing ones to survive contact with real infrastructure. Security requirements, compliance constraints, latency budgets that no cloud benchmark ever measured. You learn to love a good config file.
If you've ever stood up an air-gapped vLLM deployment or spent an afternoon wiring a LiteLLM gateway into someone else's SSO, you've done FDE-style work.
LLM Engineer: The Model-First Engineer
An LLM Engineer treats large language models as the primary building block, not just a dependency. The difference matters in practice.
Where a typical backend engineer asks "how do I add AI to this feature," an LLM Engineer asks "what's the right model for this task, what's the right prompting strategy, and how do I evaluate whether it's working." They think in tokens, latency targets, and hallucination patterns. They pick between a fine-tuned 7B and a prompted 70B and can tell you exactly why.
The role exists because calling an API and building around an API as a product layer are two different jobs. One is a function call. The other is a discipline.
LLMOps Engineer: The Person Who Keeps It Running
Classic MLOps applied to LLMs, but weirder. LLMs introduce cost that varies per request, errors that look non-deterministic, and failure modes that only show up at scale. Standard monitoring catches none of that.
An LLMOps Engineer owns the layer that keeps LLM deployments measurable and maintainable. Token and latency tracking, CI/CD pipelines that validate model updates, quota management, caching strategies, fail-safe fallbacks. They're the ones who set up the Prometheus dashboards and then actually watch them.
It's also the thing standing between a working demo and a production system that stays working three months later.
GenAI Software Engineer: The Builder
This is the role closest to traditional software engineering, with LLMs as a first-class layer of the stack. They design the APIs and agents that sit between users and models. They handle auth, rate limiting, logging, and context management. They ship production-grade features, not notebooks that work on their laptop.
If you've built a Next.js app wired to a LiteLLM backend and deployed it on Vercel, this is roughly the role you were playing. The code is mostly familiar. The constraints are new.
Vibe Coder: The Natural Language Engineer
Vibe coding isn't a formal title. It's a label for engineers who use AI tools as the primary interface to writing code. You describe the behavior in natural language, let Claude Code or Cursor generate the scaffolding, then review, test, and correct.
The bottleneck shifts from writing code to describing the right behavior precisely. That's harder than it sounds. Vague descriptions produce vague code. The skill is knowing exactly what you want before you ask for it.
Most engineers who've spent time with these tools find they're both faster and more opinionated about their own code. You ship more and understand what you're shipping better, because you had to explain it clearly enough for a model to build it.
ML Engineer vs. AI Engineer: The One That Trips People Up
These two get conflated constantly. They're not the same job.
An ML Engineer builds and trains models. They own the data pipeline, the training loop, the evaluation harness. They think in loss functions, learning rates, and dataset quality. When something goes wrong with model performance, they're the ones who go back to the data. The output of their work is a trained model artifact. Tools: PyTorch, TensorFlow, MLflow, Kubeflow, feature stores. Often comes from a math or research background.
An AI Engineer builds with models. They take a model that already exists, trained by someone else, and integrate it into a product. They care about latency, cost per call, prompt design, and fallback behavior. The output is a working feature. Tools: AI APIs, vector databases, orchestration frameworks, LangChain, LlamaIndex.
The distinction collapsed because companies started calling both roles "AI Engineer" without being specific. A job post that says "AI Engineer" could mean either one. Read the responsibilities section, not the title.
In most companies, ML Engineers sit closer to research and infrastructure. AI Engineers sit closer to product. In a GenAI-native company building on top of foundation models, you might not have any ML Engineers at all. In a company training its own models, you might have a dozen ML Engineers and no one with "AI Engineer" in their title.
The practical difference: if the job requires you to understand backpropagation and write training loops, it's an ML Engineer role. If it requires you to know how to wire a model into an application reliably and cheaply, it's an AI Engineer role. Both are real disciplines. Neither is easier than the other.
Full-Stack AI Engineer: The Generalist Who Ships End-to-End
This one is exactly what it sounds like. A Full-Stack AI Engineer can build the frontend, the backend, the AI integration layer, and the deployment pipeline. They don't specialize in any one tier. They own the whole thing from the user's browser to the model's response.
The role exists because most AI-powered products at the early stage don't need a six-person team. They need one person who can move fast across all of it. Prompt logic, API design, database schema, UI, infrastructure. All of it.
The tradeoff is depth. A Full-Stack AI Engineer is rarely the best ML Engineer in the room, or the best LLMOps engineer, or the best frontend engineer. They're the person who can do all of those things well enough to ship a working product without waiting on anyone else. At a startup or in the early stages of a project, that's often more valuable than deep specialization.
As teams grow, Full-Stack AI Engineers tend to either narrow into one of the specialized roles or move into technical leadership. The generalist skill set is most powerful when speed matters more than optimization.
How They Fit Together
In a small team, one person wears several of these hats. In a larger organization they tend to split:
| Role | Owns |
|---|---|
| ML Engineer | Data pipelines, model training, evaluation |
| AI Engineer | Model integration, application layer, cost/latency |
| LLM Engineer | LLM-specific: prompt design, model selection, evals |
| LLMOps Engineer | Monitoring, CI/CD, reliability, cost at scale |
| GenAI Software Engineer | User-facing features, APIs, full product layer |
| Full-Stack AI Engineer | End-to-end ownership: UI through model integration |
| FDE | Customer-site deployments, real-world constraints |
Vibe coder isn't a separate role. It's a working style that cuts across all of them.
The titles emerged because the work diverged. Once LLMs moved into production, "AI Engineer" stopped being specific enough to describe what someone actually does all day.
Wrapping Up
Each of these roles is a response to a specific problem that showed up once AI stopped being a research project and started being a production dependency.
Most engineers I know are some combination of three or four of these depending on the day. The titles just give you a vocabulary for the kind of work you're already doing more of.
Have questions or ran into something I didn't cover? Feel free to reach out.