AI Engineer Job Description: What to Put In It

A good AI engineer job description names the production problem, separates required from nice-to-have, and avoids the keyword pile that repels your best builders.

A good AI engineer job description does three things: it names the production problem you are hiring someone to own, it separates the handful of skills you actually require from the long list that would be nice to have, and it states the seniority and pay honestly. Everything else is decoration. If your JD reads like a pile of frameworks and acronyms, you have written a filter that screens out the builders you want and lets through the people who are good at matching keywords. A usable copy-pasteable template is further down this page; first, the parts that decide whether it works.

I am an engineer who moved into a CRO seat, and part of my job is writing the reqs and then living with whoever they attract. I have hired and deployed senior AI engineers into products that touch real customers, and I have also written a few job descriptions early on that I am not proud of. The bad ones all failed the same way: they described a person, not a job, and listed twenty tools with zero outcomes. They asked for a researcher and a full-stack engineer and an MLOps owner in one hire, at a salary pegged to last year, and the good candidates read that and kept scrolling.

This piece is the practical version, written from the side of the table that pays for the mis-hire. It sits under my guide to hiring AI engineers; read that for the whole process. Read this for the document itself: what the role owns, the responsibilities that matter, required versus nice-to-have skills, how the JD shifts by seniority and sub-role, the mistakes that quietly kill your pipeline, and a template you can paste and edit today.

• Write the production problem first, the JD second. If you cannot name what breaks in production when this hire fails, your JD will become a keyword pile.
• Required versus nice-to-have is the whole game. Twenty "required" tools signals you do not know what you need, and it repels the people who do.
• "AI engineer" is four different jobs. Application engineer, ML engineer, platform engineer, and researcher need different reqs; one JD for all of them gets you none of them well.
• Seniority changes the verbs, not the keywords. Junior owns execution, senior owns design and the decision; a JD that only lists tools cannot tell the difference.
• Stale pay is a silent disqualifier. If your band is a year behind the market, the best people self-select out before you ever see them.

Write what the role actually owns before you write the JD

Before you type a single bullet, answer one question: what production problem does this person own? Not what tools they touch. What breaks, in front of a customer or a P&L, when this role is empty or filled badly. That answer is the spine of the whole document.

An AI engineer in 2026 is, in practice, a production-oriented engineer who builds, evaluates, and operates systems on top of foundation models. Analysis of more than a thousand live postings found employers prioritize RAG, LLM integration, Python, cloud infrastructure, and deployment far above fine-tuning or research depth (AI Shipping Labs). The job is shipping and keeping things alive, not publishing.

So write the ownership statement first. Something like: "You own our document-extraction feature end to end: retrieval quality, latency, the eval suite that gates releases, and what happens when the model is wrong in front of a customer." That one sentence does more filtering than a list of fifty technologies, because it tells a strong candidate exactly what they would be responsible for and lets them decide if it excites them.

If you cannot write that sentence, you are not ready to hire yet, and no template will save you. The teams I see struggle most are the ones who open a req because "we need AI" and expect the candidate to figure out the scope. That is not a job description. That is an admission that you have not done the work. And if you would rather not do that work at all, you can skip writing the JD and the three-month search and hire a pre-vetted senior AI engineer who has already shipped this exact shape of feature.

AI engineer roles and responsibilities: the section that does the work

The roles and responsibilities section is where most JDs go soft. They write verbs like "leverage," "utilize," and "collaborate" that describe nobody and commit to nothing. Strong candidates read vague responsibilities as a vague team. Write the ones that show real ownership instead.

A production AI engineer's responsibilities, written honestly, look like this: build and integrate LLM and retrieval features into the product, including the unglamorous parts, auth, permissions, streaming states, error handling. Design and maintain the eval suite that decides whether a change ships. Own latency and cost per request as product metrics, not afterthoughts. Instrument monitoring so you find out the model is failing before a customer does. Iterate after launch, because the first version is never the last.

Notice what is missing: "train models from scratch," "publish research," "achieve state-of-the-art." Unless you are a frontier lab, those belong in a different JD entirely. Putting them in an application-engineering req is how you attract people who want to do research and resent the integration work that is actually 90% of the job. The mismatch surfaces in month two, and it is expensive.

One pattern I keep relearning: the responsibilities that look boring on paper are the ones that separate a good hire from an expensive one. "Owns the eval suite" and "owns what happens when the model is wrong" sound dull next to "builds cutting-edge AI." They are also the entire job. Write them anyway. The right candidate reads "owns what happens when the model is wrong" and thinks, finally, a team that gets it. For the deeper version of which abilities actually matter here, see the skills that actually separate the good ones.

Required versus nice-to-have skills, and why the line matters

This is the section that decides who applies. Get the required-versus-nice-to-have split right and you attract builders; get it wrong and you attract resume-matchers. The single most common mistake is listing twenty tools as "required," which signals to a strong engineer that you do not actually know what you need.

The genuine required floor for a production AI engineer is short. Working fluency with LLM APIs and RAG. Enough eval discipline to know when a model is wrong and when "good enough" is actually good enough. Real software engineering, usually Python. Enough MLOps or LLMOps to ship and operate without the system falling over. That is roughly it. Everything else is nice-to-have, and you should label it that way.

Here is the mental model I use. A required skill is one where, if the candidate lacks it, they cannot do the job on day thirty. A nice-to-have is one they can learn on the job or that only matters for a fraction of the work. Specific vector databases, a particular orchestration library, a named cloud provider, those are almost always nice-to-have, because a strong engineer learns a new vector DB in a week. Judgment under production pressure, they cannot acquire in a week, so that is the bar.

I once reviewed a req a founder had written that listed eleven "required" frameworks and libraries. I asked him which three he would actually fire someone for not knowing. He could only name one. The other ten were aspirational, copied from other postings, and every one of them was shrinking his applicant pool for no reason. We cut the list to four real requirements and moved the rest to "bonus." Applications from senior people went up, because senior people read a short, confident requirements list as a sign of a team that knows its own stack.

How the JD changes by seniority and sub-role

One JD cannot serve every level or every flavor of the role, and trying to make it do so is why so many reqs read as a catch-all. Two axes matter: seniority and sub-role. Get explicit about both.

On seniority, the verbs change, not just the years. A junior AI engineer owns execution: building against APIs, integrating models, writing tests, shipping under guidance. A senior owns design and the decision: choosing the approach, defining what "good enough" means, deciding what ships. A staff or lead owns the strategy and the other engineers. A JD that only lists tools cannot express this difference, which is why level-less reqs attract a confusing mix and convert almost nobody. Note too that the entry-level market is thin; only about 2.5% of AI engineering postings target candidates with under two years of experience, while two-to-six years is the common band (365 Data Science). If you write a "junior" req, expect a small and inexperienced pool, and price accordingly.

On sub-role, "AI engineer" is a catch-all for at least four different jobs. An AI application engineer integrates models into product features and owns the user-facing surface, an ML engineer owns models, training, and pipelines, a platform or infra engineer owns the serving and tooling underneath, and a researcher owns novel methods. These need genuinely different JDs. The most expensive hiring mistake I see is a manager opening one "AI engineer" req and silently expecting one person to cover all four, which is exactly the trap the market warns about (KORE1). Pick the sub-role, name it in the title, and write the req for that one job.

The AI engineer job description mistakes that repel the good ones

Most job descriptions do not fail by being too strict. They fail by being incoherent in ways that strong candidates read instantly. Here are the four that do the most damage.

The keyword pile. Twenty tools, no outcomes. A strong builder reads this as a team that hires by buzzword and will manage by buzzword too. The fix is the ownership statement from earlier: name the problem, list four real requirements, and let the tools be implementation details.

The catch-all title. "AI Engineer" with no sub-role, expecting researcher plus full-stack plus on-call in one hire. Candidates cannot tell what the job is, so the strong ones, who have options, pass. The fix is to name the sub-role in the title.

Stale compensation. This one is quiet and lethal. Senior AI engineer pay has re-priced hard; market guidance now treats a base near $200K as a floor for senior roles, with total comp frequently climbing past $300K (KORE1 salary guide). If your band was set last year, the best people see the number, do the math, and never apply. You will conclude "there is no talent" when the truth is your offer is a year behind.

Research cosplay. Asking for a PhD and publications for what is, in reality, an integration and operations job. It does not raise your bar; it just attracts people who will be unhappy doing the actual work. Match the requirements to the job you have, not the job that sounds impressive.

A copy-pasteable AI engineer job description template

Here is a template you can paste and edit. It is written for an AI application engineer, the most common production hire; swap the ownership line and requirements if you are hiring a different sub-role. Keep it short, keep the required list to four or five real items, and fill in a current pay band.

That is the whole thing. Notice it commits to outcomes, keeps the required list honest, separates nice-to-have explicitly, names the sub-role in the title, and forces you to put a real number in. If you fill it out and the pay band makes you wince, that is the market talking, and it is better to hear it now than after a three-month empty search.

One table: what to put in each section, and what to avoid

The same advice, section by section, in one place you can scan while you write.

If you want the full hiring picture around this document, the funnel, the vetting, the cost in-house versus outsourced, that is what my guide to hiring AI engineers covers, and the playbook for building the team around the hire is in Building an AI-Native Team.

Frequently asked questions

What should an AI engineer job description include?

An ownership line naming the production problem the hire owns, concrete responsibilities written as real verbs, a short required-skills list of four to five day-30 must-haves, an explicit nice-to-have list, the seniority level expressed as the verbs for that level, and a current market-rate pay band. The template above gives you all of these in a structure you can paste and edit.

What are an AI engineer's main roles and responsibilities?

For the common production role: build and integrate LLM and RAG features including the unglamorous auth, permissions, and error-handling work; design and maintain the eval suite that gates releases; own latency and cost per request as product metrics; instrument monitoring to catch failures before customers do; and iterate after launch. Training models from scratch and publishing research belong in a researcher's JD, not an application engineer's.

What skills should be required versus nice-to-have?

Require only what the candidate must have by day thirty: working fluency with LLM APIs and RAG, eval discipline, strong software engineering and Python, and enough MLOps to ship and operate. Mark specific vector databases, orchestration libraries, cloud providers, and fine-tuning as nice-to-have, because a strong engineer learns those in a week. Judgment under production pressure is the real bar, and it cannot be learned in a week.

Why does my AI engineer job posting not attract good candidates?

Usually one of four reasons: the JD is a keyword pile with no stated outcome, the title is a catch-all that means four different jobs, the compensation band is pegged to last year and the best people quietly self-select out, or it asks for research credentials for what is really an integration job. Fix the ownership line, name the sub-role, refresh the pay band, and match the requirements to the actual work.

If writing the JD, posting it, and running a three-month search is not how you want to spend the next quarter, you can skip the search and hire a pre-vetted senior AI engineer who has already shipped production features of this exact shape. Either way, the principle holds: name the problem, keep the requirements honest, and the right people will recognize the team that gets it.