Upskilling Reality

    What Even Is an 'AI Engineer'? — 425 JDs and One Reader's Comment Later

    Updated August 17, 2026·10 min read

    TL;DR

    49% of Software Engineer JDs already mention AI/ML — half the market is hiring for what an “AI Engineer” does day-to-day. Across 425 fresh AI Engineer JDs the role splits: every posting wants LLM integration, but only 36% require agentic systems on top. The label is doing more work than the boundary deserves — and less than 5% of AI Engineer JDs even disclose salary.

    Summarize with AIChatGPTClaude

    What "AI Engineer" actually means — banner

    What is an AI engineer in 2026?

    In practice, mostly a software engineer who builds on top of LLMs. Across 425 fresh AI-engineer JDs, every role requires LLM integration but only 36% require agentic systems on top — and 49% of software-engineer JDs already mention AI. The title is doing more work than the boundary deserves; here's what the data actually shows.

    Key facts

    • In Dexity's scan of 425 fresh US AI Engineer JDs, only 36% require agentic systems on top of the baseline LLM-integration foundation every role shares.
    • Across Dexity's dataset, 49% of US Software Engineer job descriptions already mention AI/ML — half the SWE market is hiring for what an AI Engineer does day-to-day.
    • In Dexity's analysis of 425 AI Engineer JDs, 73% require Python and 22% require AWS — the profile of a backend engineer with LLM bullet points on top.
    • Fewer than 5% of AI Engineer JDs in Dexity's scan disclose salary, versus 72% of Software Engineer postings — a category hiring managers are still defining on the fly.
    • 155 of the 425 AI Engineer JDs in Dexity's scan explicitly require agentic AI work such as autonomous agents, multi-agent orchestration, and tool-using agents.
    • In Dexity's contrast scan of 247 Machine Learning Engineer JDs, deep-learning frameworks (PyTorch, TensorFlow) appear in 244 of 247 postings, versus minimal presence in AI Engineer roles.

    What do AI engineers actually do?

    An AI engineer is a software engineer who builds product features on top of large language models. Day to day, that means calling LLM APIs cleanly, building retrieval (RAG) endpoints, wiring up agent workflows, and adding eval and guardrail systems so those features stay reliable in production. Roughly a third also build agentic systems on top.

    What AI engineers actually build

    The work is more concrete than the title suggests. The things that show up again and again across the 425 JDs:

    • Customer-support RAG assistant. A chatbot grounded in your own docs and tickets — retrieval over a vector store, then an LLM that answers with citations instead of hallucinating.
    • Internal knowledge search. Semantic search across wikis, code, and docs so employees ask questions in plain language and get grounded answers back.
    • Agent workflows. Tool-using agents that take a goal, call APIs, and chain multi-step actions — the additive layer only about a third of postings ask for.
    • Eval and guardrail systems. Regression suites for prompts, quality scoring, and input/output guardrails so a shipped feature doesn't silently degrade or go off the rails.
    • LLM feature integration. Bolting generative AI into an existing product — summarization, drafting, classification, extraction — without breaking the codebase around it.
    • Inference plumbing. Retry and fallback chains, caching, cost and latency budgets, observability — the engineering that keeps the above three from falling over under real traffic.

    Calling an LLM is the entry. The engineering around it is what stays hard.


    A reader left a comment on my AI-vs-ML Engineer breakdown last week that I couldn't stop thinking about:

    "For over 50% of the market, 'AI Engineer' just means a backend engineer with an LLM API key."

    Reader comment pull-quote

    It was a throwaway line. It was also doing more work than the entire 2,000-word post above it.

    The reason it bothered me: I'd just published a comparison framing AI Engineer as a distinct role with a distinct salary band and a distinct skill stack. And here was a working engineer saying — quietly, in a comment — no, it's mostly just SWE who learned the OpenAI SDK.

    So I went back to the source.

    This week I pulled 1,101 fresh LinkedIn JDs in the US — 429 Software Engineer, 425 AI Engineer, 247 Machine Learning Engineer postings, all from the last 30 days. I wanted to know what "AI Engineer" actually means in the market that's currently hiring it.

    The commenter was more right than wrong.

    ℹ️**July 2026 re-scan (independent, ATS boards).** A fresh scan across public ATS boards — a *different method* than the May LinkedIn pull, so exact percentages aren't directly comparable — points the same way on the two signals that matter here. AI/ML now appears in the clear majority of Software Engineer postings (the "49% problem" has only widened), and the agentic requirement inside AI-Engineer roles has risen from about a third toward **roughly half**. The core finding holds — the skill stack, not the title, is the line, and it's moving toward agentic depth.

    Why do 49% of software engineer jobs already mention AI?

    Start with what's happening on the SWE side.

    49% of Software Engineer JDs in the dataset mention AI/ML in some form. 41% explicitly require AI/ML competence. And the GenAI-specific signals — Claude Code, Codex, OpenCode, "LLM-powered features," "RAG-based systems" — aren't aspirational mentions from forward-looking companies anymore. They're showing up as baseline expectations across a meaningful share of SWE roles being posted right now.

    In other words: half the SWE market is already hiring for AI/ML — and the GenAI-specific subset is doing what an AI Engineer does in their day-to-day. Which raises the obvious question.

    If half of all SWE postings already ask for AI/ML, where exactly does the SWE role end and the AI Engineer role begin?

    The answer in the JD data is uncomfortable for anyone who's bought a $5,000 course to make the jump.

    💡Half the SWE market is already hiring for what an AI Engineer does day-to-day. The label "AI Engineer" is doing more work than the boundary deserves. The skill stack is the durable signal — the title is catching up to it.

    What do AI Engineer job descriptions actually ask for?

    I read through 425 AI Engineer JDs and pulled out what employers explicitly require, what they assume as baseline, and what they ask candidates to add.

    The pattern:

    • 73% require Python
    • 22% require AWS
    • The most common ICP description in the JD bodies: "software developers transitioning into machine learning and AI model deployment, often with experience in programming and cloud infrastructure"
    • The top three "skills to add" called out across the dataset: prompt engineering, LLM integration, GenAI techniques

    AI engineer skills, by frequency

    Consolidating the numbers scattered through this analysis into one view — what share of the 425 AI Engineer JDs asks for each:

    Skill / tool % of AI Engineer JDs
    LLM integration (call APIs, ship LLM features) every posting
    Python 73%
    RAG / LLM-feature integration (the baseline job) 64%
    Agentic systems (autonomous, multi-agent, tool-using) 36%
    AWS 22%

    Prompt engineering, LLM integration, and GenAI techniques are the top "skills to add" called out in the JD bodies — named repeatedly but not as a clean percentage, so they sit alongside the table rather than in it.

    If you read that list and squint, what you're looking at is a backend engineer's resume with three new bullet points on top.

    That's not a takedown — it's the actual hiring profile. And it lines up with what 64% of the JDs in the dataset are asking for: someone who can call LLM APIs cleanly, build RAG endpoints, ship LLM-powered features, integrate generative AI into existing software products.

    That work is harder than the framing makes it sound. Production LLM features carry their own difficulty — eval pipelines, observability, prompt and cost management, retry and fallback chains, latency budgets. Calling an LLM is the entry. The engineering around it is what stays hard. The 64% job isn't trivial — it's just a different category of hard than the next 36%.

    The other 36% is a different story. We'll get to it.


    What is the 64/36 split in AI engineer jobs?

    Pull out the agentic AI signal and the role visibly splits in two.

    Important to be precise about how the data is structured: the 36% isn't a separate population. All 425 JDs require LLM/AI integration at the baseline. The 36% is an additive layer on top — postings asking for agentic depth in addition to the LLM-integration foundation. So it's not 64% vs 36% as opposing groups. It's: every AI Engineer role in this dataset needs LLM work; about a third want it WITH agentic systems on top.

    That distinction matters for how you read the rest.

    The 64% block — what the title usually means: Backend engineer + LLM API + RAG. Python and AWS as foundation. Prompt engineering and LLM integration as the additive layer. The job is mostly: take a working software product and add an LLM-powered feature without breaking it. Hard, but a known shape of hard.

    The 36% block — where the title earns extra weight: 155 of the 425 JDs explicitly require agentic AI work — autonomous agents, multi-agent orchestration, tool-using agents, agent-based architectures. This is systems work on top of the LLM-integration baseline. It involves designing how agents communicate, how they fail safely, how state flows across tool calls, how multi-step reasoning gets evaluated. There's no SDK that abstracts it away yet.

    Both populations sit under the same job title. Both compete for the same career advice articles, the same bootcamps, the same LinkedIn feed.

    They are not the same job, even though the boundary between them is one skill stack, not a clean wall.

    What "AI Engineer" actually means — 64/36 split


    How do you know the AI engineer role hasn't solidified?

    If you're not sure which version of "AI Engineer" a posting is actually asking for, the JD itself usually won't tell you. Three signals will.

    Signal 1 — Less than 5% of AI Engineer JDs disclose salary. For comparison, 72% of SWE JDs in the same dataset disclose salary. Markets disclose comp when the market has agreed on what the role is worth. When the disclosure rate is this low, what you're looking at is a category that hiring managers are still defining on the fly.

    Signal 2 — The largest single hirer in the dataset is Prolific. $80/hour. Contract. 20 of the 425 JDs are from Prolific alone, all paying up to $80/hour, all contract. The next-largest hirer, Catalyst Labs, is also contract-flavored. Compare that to MLE, where General Motors leads with $170K–$300K full-time bands. When a category leans this heavily on contract and gig structures, the work is mostly project-shaped: ship a feature, evaluate a prompt, integrate a model. Real but bounded.

    Signal 3 — Only 36% of AI Engineer JDs require agentic AI work. That's the sliver where the title earns its weight. The other 64% is API integration with extra steps — important work, valuable work, but not categorically different from "backend engineer who learned the OpenAI SDK."

    ℹ️Less than 5% of AI Engineer JDs disclose salary, vs 72% for SWE. Markets disclose comp when they've agreed on what a role is worth. The number tells you the category hasn't settled.

    How does machine learning engineer compare to AI engineer?

    To make the 64/36 split visible, contrast it with a role that has solidified — Machine Learning Engineer.

    In the same scan, 247 MLE JDs:

    Signal AI Engineer MLE
    Python required 73% 82%
    AWS required 22% 34%
    Deep-learning frameworks (PyTorch, TensorFlow) minimal 244 of 247 JDs
    MLOps required rare 34%
    Salary disclosure rate <5% 16%

    MLE hasn't been absorbed into the GenAI wave. The math, the training loops, the lifecycle management — these still gate on a different skill stack than "engineer who can call an LLM." It's the part of ML that didn't get commoditized when foundation models showed up.

    That's why the salary band stretches to $300K at the high end. Markets pay for skill stacks that haven't been easily reproduced. They underprice categories that any senior backend engineer can plausibly add to their resume in three months.

    AI Engineer vs ML Engineer

    The two roles get blended constantly. They fork on the skill stack, not the title. A side-by-side of where they actually diverge:

    AI Engineer ML Engineer
    Focus Building product features on top of pretrained LLMs Training, deploying, and maintaining models across their lifecycle
    Primary output LLM-powered features, RAG endpoints, agent workflows Trained/fine-tuned models, training pipelines, deployed MLOps systems
    Languages Python (73% of JDs) Python (82% of JDs)
    Math / research depth Table stakes — absorbed through the work Gating skill — linear algebra, training loops, model math up front
    Typical tools LLM APIs, LangChain, vector databases, eval harnesses, AWS PyTorch, TensorFlow, MLOps tooling, AWS

    The short version: an AI engineer wires a pretrained model into a product; an ML engineer builds and trains the model. That's a fork you commit to, not a slope you drift along.


    Dexity Intel · free newsletter

    Liking this? Get the next one in your inbox.

    JD-backed career reads, AI market signals, and field-tested tool guides — a few times a month. No fluff, no spam.

    What does this mean if you're upskilling?

    If you are a backend engineer already shipping LLM features at work — building a RAG endpoint, fine-tuning a prompt for a customer-support flow, integrating an LLM API into your product — you are already what 64% of the AI Engineer market is hiring for. You don't need a title change to confirm it. You need a portfolio that documents what you've shipped.

    If you're earlier in your career — CS undergrad, recent bootcamp grad, career switcher from a non-coding role — this analysis is still useful as a market read, but the realistic next step is landing any SWE role first. The JD data confirms it: of the 425 AI Engineer postings, only ~4% are entry-level. This is a senior-tilted market. You can't shortcut the engineering muscle.

    A note on math while we're here. Math is not absent from this role; it's table stakes. AI Engineer JDs don't list "linear algebra" the same way SWE JDs don't list "Big-O" — both assume you already have it at a foundational level. Where it surfaces: when retrieval scores look wrong, when an eval distribution doesn't match what users see, when fine-tuning won't converge. The point isn't to skip math. The point is to absorb it through the work, not to front-load six weeks of Khan Academy with no project to attach it to.

    The mistake I see most often, working with people in the middle of this transition: paying $3,000–$5,000 for a course that teaches the OpenAI SDK, RAG basics, and a LangChain walkthrough. By the time the course ends, you have a certificate verifying skills you could have demonstrated by shipping one production feature.

    The market isn't paying for the certificate. The market is paying for evidence that you can ship reliably under the constraints of a real codebase.

    How to become an AI engineer

    There's no single credential that unlocks the role — the market reads shipped work, not certificates. A practical sequence, given a senior-tilted market where only ~4% of postings are entry-level:

    1. Get solid as a software engineer first. Backend fundamentals, APIs, and cloud (Python and AWS show up in most JDs). This is the foundation the role assumes, not a step you skip.
    2. Learn LLM integration. Call an LLM API cleanly, then build a working RAG endpoint over your own documents. Retrieval commonly uses chunked text (a few hundred tokens per chunk is a typical starting point) plus a vector store — tune from there.
    3. Add the production engineering. Wrap it in evals, guardrails, retries and fallbacks, cost and latency budgets, and observability. This is the part that separates a demo from something shippable.
    4. Build something agentic and ship it. A tool-using agent or multi-agent workflow, deployed where you can watch it break. This is the 36% signal that reproduces in no weekend project.
    5. Document and publish. A portfolio of shipped features is the durable signal. One public production feature beats a certificate.

    For a deeper, JD-backed breakdown of skills, interview loops, and comp, see the AI engineer career path in 2026.


    Where should you invest your upskilling time?

    If you want to differentiate — to land in the 36% rather than the 64% — three real frontiers, in order of how legibly they signal "this person is past the SDK layer":

    1. Agentic systems and multi-agent orchestration. Tool-using agents. Multi-agent workflows where state has to flow across calls. Failure modes — when does a tool call need a retry, when should an agent escalate, when does the system halt. This is where the JD market is starting to draw a real line, and the skill stack here doesn't reproduce in a weekend project. It takes shipping something agentic into production and watching it break.

    2. Evals and inference-time engineering. Most LLM features in production today have no rigorous eval pipeline. Hiring managers know this and are increasingly explicit in JDs about wanting candidates who can build one. Quantitative eval frameworks, regression suites for prompts, benchmark harnesses. Closer to test-engineering than to ML research, and a real differentiator.

    3. Fine-tuning and MLOps depth. Not because every AI Engineer needs to fine-tune a model, but because the engineers who can fine-tune are also the engineers who understand inference cost, latency, deployment pipelines, and observability. This is the skill stack that bridges into MLE territory if you ever want to make that jump.

    The common thread: they involve owning a system end-to-end, not just calling an API. That's the part the 64% job mostly doesn't ask for. That's why the 36% job is what most working professionals should actually be optimizing toward.


    What mistakes do engineers make on this transition?

    ⚠️"AI Engineer" on your LinkedIn does not currently mean what it meant 18 months ago. The skill stack is the durable signal. The title catches up later. Pay for evidence of shipping, not for credentials.

    Chasing the title instead of the skill stack. "AI Engineer" means a different thing depending on which JD you're looking at. The skill stack is the durable signal. The title catches up later.

    Buying generalist AI courses to reproduce skills you already have. If you're a backend engineer with three years of API integration experience, a $4,000 LLM-Engineering course teaching you how to call an API is selling you something you can do already. Audit the syllabus before paying — if it stops at RAG basics, it's not where the gap is.

    Optimizing for "AI Engineer" pay numbers from inflated comp surveys. The actual disclosed salaries in the JD market are not the $200K+ figures you'll see in viral hiring infographics. The disclosure rate is 5%. The largest hirer is paying $80/hour contract. The pay band at the top of the market exists, but it's narrow, it's at the agentic-systems end, and it's gated on demonstrable systems work — not titles.

    Treating MLE and AI Engineer as a slope when they're a fork. A SWE doesn't gradually become an MLE by writing more LLM features. The math, training loops, and MLOps are gating skills, not optional ones. If you want MLE comp, you need to commit to that path. If you want AI Engineer access, you've probably already qualified.


    Where this leaves us

    The label "AI Engineer" is doing too much work right now. It's covering a fat 64% of API-integration work that any competent backend engineer can ramp into in 3–6 months, and a smaller 36% of agentic-systems work that requires deeper investment.

    The market hasn't agreed on which one the title points to. Until it does, the working professional's move is to ignore the label and pick the underlying skill stack.

    If you're already shipping LLM features, you're already inside the 64%. Document it, ship one more thing publicly, move on.

    If you want to be in the 36%, build something agentic and watch it break in production.

    The label is doing too much work. The work underneath is what gets paid.

    What an AI Engineer is NOT

    Not an ML Engineer. The math, training loops, and MLOps are gating skills, not optional ones — MLE is a fork you commit to, not a slope you drift into by writing more LLM features.

    Not, for most postings, more than a backend engineer with an LLM API key. 64% of the role is API integration with extra steps — Python and AWS as foundation, prompt engineering and LLM integration bolted on top.

    Not ML research. The evals and inference-time work that differentiates the role sits closer to test-engineering — regression suites, benchmark harnesses, eval pipelines — than to model research.

    Not a settled, salaried category. Less than 5% of AI Engineer JDs disclose salary — hiring managers are still defining the role on the fly, and it skews senior, with only ~4% of postings entry-level.

    ⚠️"AI Engineer" on your LinkedIn does not mean what it meant 18 months ago. Chasing the title is chasing a moving label; the skill stack is the durable signal, and it's the thing the market actually pays for.

    Why is the window for AI engineers closing?

    The label is young and still unsettled. "AI Engineer" does not currently mean what it meant 18 months ago — the category hasn't hardened, and the working professional's edge is picking the underlying skill stack before the title catches up.

    Demand is moving from signal to requirement. 49% of Software Engineer JDs already mention AI/ML, and the GenAI-specific asks — Claude Code, RAG-based systems, LLM-powered features — aren't aspirational anymore; they're baseline expectations. AI competence is becoming table stakes for SWE, not a differentiator you can claim later.

    The premium is still pricing in. With less than 5% of AI Engineer JDs disclosing salary, the market hasn't agreed on what the role is worth — the pattern of a premium still being set, not one already compressed.

    💡Agentic systems are the next multiplier. Only 36% of AI Engineer JDs require agentic work today — but that's the sliver where the title earns its weight, and there's no SDK that abstracts it away yet. Ship something agentic into production now, while the boundary is still one skill stack thick.

    Frequently asked questions

    What does an AI engineer actually do in 2026?

    In practice, mostly a software engineer who builds on top of LLMs. Across 425 fresh AI Engineer JDs every role requires LLM integration, and about 64% of the work is calling LLM APIs cleanly, building RAG endpoints, and shipping LLM-powered features into existing products.

    What do AI engineers actually build?

    Concretely: customer-support RAG assistants grounded in your own docs, internal knowledge search over wikis and code, agent workflows that chain tool calls, eval and guardrail systems that keep features reliable, and general LLM feature integration (summarization, drafting, extraction) into existing products — plus the inference plumbing of retries, caching, and cost and latency budgets around all of it.

    Is an AI engineer just a backend engineer with an LLM API key?

    For most postings, largely yes. A reader summed it up as "for over 50% of the market, 'AI Engineer' just means a backend engineer with an LLM API key," and the JD data backs that: 73% require Python, 22% require AWS, and the top skills to add are prompt engineering, LLM integration, and GenAI techniques.

    What is the difference between the 64% and 36% of AI engineer jobs?

    All 425 JDs need LLM integration at the baseline; the 36% is an additive layer on top. 155 of the 425 JDs explicitly require agentic AI work such as autonomous agents, multi-agent orchestration, and tool-using agents, which is systems work with no SDK that abstracts it away yet.

    How do I become an AI engineer?

    Get solid as a software engineer first (only ~4% of these postings are entry-level), then learn LLM integration and build a working RAG endpoint, wrap it in evals, guardrails, and observability, and finally build something agentic and ship it. A documented portfolio of shipped features signals more than any certificate. See the AI engineer career path in 2026 for the JD-backed detail.

    How much do AI engineers make?

    Few AI Engineer JDs disclose salary (under 5% here, versus 72% for SWE), so the market hasn't fully settled. External aggregators bracket it: entry-level ~$80–90K, median ~$113K base / ~$159K total comp (Levels.fyi, Salary.com), and AI skills carry a ~28% pay premium (Lightcast). Full by-source breakdown in our AI engineer career data.

    Is an AI engineer the same as a machine learning engineer?

    No, they are a fork rather than a slope. An AI engineer wires pretrained LLMs into products (RAG endpoints, agent workflows); an ML engineer trains and deploys models across their lifecycle. MLE gates on math, training loops, and MLOps, with deep-learning frameworks in 244 of 247 MLE JDs and a salary band stretching to $300K, none of which you drift into by writing more LLM features.

    Should I pay for a $5,000 AI engineering course?

    Probably not if you already ship LLM features. If a syllabus stops at the OpenAI SDK, RAG basics, and a LangChain walkthrough, it sells skills you can already demonstrate. The market pays for evidence you can ship reliably in a real codebase, not for the certificate.


    Source: LinkedIn JD scan — May 2026 (1,101 postings: 429 Software Engineer, 425 AI Engineer, 247 Machine Learning Engineer, US market, last 30 days). Cluster categorisation is LLM-assisted with mechanical re-counting on headline figures — treat percent shares as directional, not precise. · JD dataset for this role · Dexity.com

    Go from reading to doing · Dexity Sprint

    Ship Production Code with AI

    Most senior engineers have tried Cursor or Claude Code and ended up with larger PRs, more review cycles, and hidden technical debt. The problem isn't the tools — it's that nobody taught the system design and reasoning control behind them.

    5 Weeks
    Live instruction
    3 Projects
    Real deliverables
    30 Seats
    Per cohort, capped
    Nahid Farady, PhD
    Nahid Farady, PhD
    Principal Tech Lead · Microsoft
    Explore the sprint
    Anmol Gulwani

    Anmol Gulwani

    Dexity

    Connect on LinkedIn
    Questions or suggestions?hello@dexity.com