Last updated: September 10, 2026
By Tom Kenaley, President and Senior Partner, KORE1
A generative AI engineer job description covers an engineer who builds product features on foundation models like GPT, Claude, and Gemini, owning retrieval, evaluation, guardrails, and inference cost, usually without training a model from scratch. Most postings under that title in 2026 describe somebody else. The template further down is written for the application seat, where base pay runs $145,000 to $195,000 at mid-level and $190,000 to $255,000 at senior. Our generative AI engineer staffing desk scopes this seat before every search, and most of what we’ve learned doing that is on this page.
Search the phrase and read the templates that come back. Several of the most visible ones still ask for experience designing and developing GANs and VAEs.
Those are real model architectures. They’re also roughly what research scientists studied in graduate school around 2018, and very few of the engineers shipping support copilots, contract search, and claims summaries this year have trained either one. Put that line in a posting and the applications come from people who want to train models. Some are brilliant. Almost none of them want to spend a quarter teaching a retrieval pipeline over a claims archive to stop quoting the wrong policy year.
A word on incentives before the details. KORE1 has placed technical people since 2005, and we’re paid when a client hires someone we found, so a posting that fills itself costs me a search. I would still rather you write a good one.

Generative AI Engineer Responsibilities, in Plain Terms
A generative AI engineer is the software engineer who turns a foundation model into working product. The job is wiring a model into an application, feeding it the right context through retrieval, measuring whether its answers are right, and keeping cost, latency, and safety inside limits the business can live with.
Training a model from nothing isn’t part of it at most companies. Fine-tuning sometimes is.
Here’s what actually fills the week on the searches we run.
- The retrieval layer eats more hours than anything else. Ingesting documents, deciding how to chunk them, picking a vector store such as pgvector, Pinecone, or Azure AI Search, and adding a reranker when the top results are close but wrong.
- Prompts and system instructions, versioned and reviewed like code, because a one-word change can move accuracy further than a model upgrade does.
- Evaluation. A test set built from real user questions, automated scoring, sometimes one model grading another, and a person reading a sample every week regardless.
- Tool calling and agents, meaning the model reads from or writes to other systems through function calls or MCP servers. This part is growing fastest. It’s also where the worst incidents start.
- Guardrails against prompt injection, leaked personal data, and answers the legal team would hate to see in a screenshot.
- Latency and cost work, which is caching and streaming and routing easy requests to a smaller model.
- Explaining to a product manager why the demo worked and the pilot didn’t. No posting lists this one.
Image, audio, and video generation sit under the same title at some companies. If yours is one, say so near the top of the posting, since those engineers are scarcer and priced higher, and our generative AI engineer salary guide prices each modality separately. Everything below assumes text, retrieval, and tools, because that’s where most of the hiring is. If you’re not yet sure the role needs generation at all, rather than a trained predictive model, our comparison of generative AI and traditional ML hiring is the better first read.
The Sentence That Separates This From an AI Engineer Posting
One line does more sorting than anything else in the document. Either “we build on foundation models and don’t train our own,” or the reverse. Candidates look for it first. When it’s missing they guess, and the research-minded ones guess in the hopeful direction.
Our broader AI engineer job description handles the umbrella title, including the classical machine learning and infrastructure profiles that share it. This page goes narrower, into the application seat where most generative hiring lands. The table below is the shortcut. Each row is a phrase I see in real postings, next to who it tends to pull.
| Phrase in the posting | Who it tends to pull | Keep it only if |
|---|---|---|
| “Design and train generative models (GANs, VAEs, diffusion)” | Research scientists, recent PhDs, people hoping for a training budget | You own GPUs, a data pipeline, and a product reason to have your own weights |
| “Fine-tune large language models” | Post-training specialists with LoRA, SFT, and DPO on the résumé | You have labeled data and a problem that prompting plus retrieval already failed to fix |
| “Build LLM-powered features with retrieval, tool calling, and evaluation” | Application engineers who have shipped to real users | This is the job. For most companies it’s the whole job |
| “Experience with LangChain required” | Nearly everyone who took an online course in 2024 | Rarely. Frameworks turn over faster than your posting will |
| “Own model serving, GPU capacity, and inference cost” | Platform and MLOps engineers | You self-host open-weight models at real volume, which usually means a second req |
| “Prompt engineering” | Generalists, plus a few prompt specialists from 2023 and 2024 | As one skill among several. The standalone role has mostly folded into this one |
A lot of the drafts that reach us stack rows one, three, and five into one document. That’s three people. Pick the row that describes the next six months and move the rest to preferred, or to a second search. For a platform or inference seat, our LLM engineer staffing page covers that profile.
Which Models, Through Which Door
“Experience with OpenAI, Anthropic, Google, Meta, and Mistral models.” I read some version of that line most weeks, and a senior candidate takes it to mean nobody has picked yet.
The model family matters less than the route to it. Most of our enterprise clients don’t call a public API directly. Security won’t allow it. The traffic goes through Azure OpenAI in Microsoft Foundry, through Amazon Bedrock, or through Google’s Vertex AI instead, and a few clients run open-weight Llama, Mistral, or Qwen models on vLLM inside their own network. Each route brings its own identity model and its own quota fight and its own content filters, plus a list of which model versions happen to be available this quarter. An engineer who built on the public OpenAI API at a twelve-person startup can learn Bedrock. Most do. It’ll cost you most of a month of IAM policies and VPC endpoints before they’re fast again.
So write the route down. “We run Claude and Llama models through Amazon Bedrock inside our AWS accounts, and customer data never goes to a public endpoint.” That sentence tells a candidate about IAM, private networking, Bedrock Guardrails, and quota requests without a single bullet. It also tells them somebody made a decision, and after a year of reading postings written by committee, that alone earns a second look.
Name the data too. Support tickets and a public help center make one job. Clinical notes or source code make a different one, with a security review before every release and a much shorter list of qualified people. Regulated teams should also say which framework their risk group works from. The NIST Generative AI Profile (AI 600-1, published July 2024) lays out twelve risk categories, confabulation (its word for hallucination) and data privacy among them, and a candidate who has worked under it will recognize the vocabulary in your policy on the first read.
Say Where the Evals Stand
OWASP’s list of LLM risks includes one it simply calls misinformation, defined as a model producing “false or misleading information that appears credible.” The second half of that definition is the expensive part. A wrong answer that reads like a right one gets pasted into a claim file or forwarded to a customer, and nobody checks it, because it looked fine.
Catching that is most of this job. Evaluation is the mechanism, and where your team stands on evaluation today changes who you should hire. The tooling varies, Ragas or promptfoo or something homegrown, and I care a lot less which one than whether it runs before a release goes out.
Last winter a specialty insurance carrier in Irvine asked us to pick up a search that had been open since the fall. A small internal team had built a claims-summary assistant on an OpenAI model inside the company’s Azure tenant in about three weeks. An executive saw the demo and funded a real version. The posting that followed asked for GAN and VAE experience, fine-tuning, eleven named frameworks, and a PhD, preferred. It drew research-leaning applicants who kept asking about GPU budgets. There were no GPUs.
The intake call found the real job in about ten minutes. The assistant was read-only. Nobody had measured whether the summaries were right, and an adjuster had already caught one that swapped two policy dates. The first quarter for whoever took the seat would be building a test set with the claims team, which is slower and more political than it sounds.
We rewrote it around that. We dropped the GAN line and the PhD line, named Azure OpenAI, said out loud that evaluation didn’t exist yet, and put a band on it. Fewer people applied. The ones who did had shipped something and could talk about what broke. The engineer they hired had built evaluation for a legal research product, and in her first interview she asked who got to decide what “correct” meant. The panel went quiet.
Listen for that question. In the posting itself one honest line covers it, either “There’s no evaluation suite yet, and you’ll build the first one” or, if it’s true, “Every prompt and model change runs against 400 labeled questions in CI before release.” Those two sentences recruit different people at different levels. Both are good postings.
Can the Model Change Anything?
A model that answers questions from a knowledge base and a model that can issue a refund are not the same hire. Postings almost never say which one they mean.
The full OWASP Top 10 for LLM Applications ranks prompt injection first and gives the agent version of the problem its own entry, “excessive agency,” meaning a model with more permissions, functions, or autonomy than the task needs. The real-world failure is mundane. A support assistant reads a customer email that happens to contain instructions, follows them, and closes forty tickets it shouldn’t have touched. Nobody notices until Monday. Gartner predicted in June 2025 that over 40% of agentic AI projects will be canceled by the end of 2027, pointing to escalating costs, unclear business value, and inadequate risk controls. I’d guess the third reason is carrying more of that number than most people admit.
So the posting should say what the model can touch. “Read-only answers over our help center” is one sentence. “The assistant creates tickets, updates CRM records, and issues account credits up to $200 without a human approving each one” is another, and it recruits someone who has designed scoped tool permissions and approval steps and audit logs before, usually after learning the hard way. If write access is on the roadmap but not live yet, say that too. For the right candidate it’s a reason to take the job.
MCP servers belong in the posting if they’re in your stack. The protocol has spread fast enough that “MCP experience” on a résumé now ranges from one weekend project to a production integration with the permission model actually thought through, and your wording is the only place you get to signal which end you need.

Put Numbers Where the Adjectives Are
Almost every posting promises “scalable, low-latency, cost-effective” systems. None of that tells a candidate anything. Numbers do. What I want to see instead is the p95 response time the product can tolerate, the request volume now and a year out, and the monthly model bill or cost per conversation, whichever one finance actually watches. Paging, too. If somebody gets woken up when it breaks, say who. OWASP lists “unbounded consumption” among its ten risks for good reason, since a retry loop or a runaway agent can burn a month’s budget over a long weekend, and someone who has been through that will read your cost number and start designing around it before the first interview. That’s the reaction you want, and the number is what triggers it.
A Certification Line That Expired on June 30
If your posting lists the Azure AI Engineer Associate, check it against Microsoft’s certification page. It now marks that credential and its renewal assessment as retired, with the AI-102 exam behind it gone as of June 30, 2026. The newer Microsoft credential that lines up with this work is the Azure AI Apps and Agents Developer Associate, earned through exam AI-103, which centers on building generative AI apps and agents in Microsoft Foundry.
Two others are current. Amazon’s is the AWS Certified Generative AI Developer, a Professional-level exam built around integrating foundation models, retrieval, and agents into applications, and Databricks has the Databricks Certified Generative AI Engineer Associate for teams building on its platform.
All three belong under preferred. Several of the strongest generative AI engineers we’ve placed hold none of them. The field moved faster than the exams did, and the people doing the work were busy doing it.
Generative AI Engineer Salary and the Band to Post
No two public sources agree on pay for this title. Why they don’t is the useful part.
| Source | What it measures | Figure |
|---|---|---|
| ZipRecruiter, September 2026 | Pay in job postings that use the title | $115,864 average, middle half $83,000 to $151,500 |
| Glassdoor, 2026 | Self-reported pay from about 20 people | Roughly $149,000 average |
| O*NET, 2025 data | Median for computer and information research scientists, the closest federal category | $140,300 |
| KORE1 salary guide, 2026 | Base bands from our placements plus aggregator data | $145,000 to $195,000 mid-level, $190,000 to $255,000 senior |
ZipRecruiter reads low. It averages every posting that carries the title, and I’d bet a good share of those come from companies that renamed a software role in 2024 and kept the old pay. Glassdoor’s figure rests on roughly twenty self-reports. That’s a sample, not a market. The federal data has no generative AI line at all, and O*NET’s nearest category, computer and information research scientists, lands at $140,300 for 2025, salary only. For a text-and-retrieval build, our 2026 pay bands by level and modality put typical mid-to-senior base at $170,000 to $230,000, climbing once image, video, or model training enters the scope.
Post the range. Pay-transparency laws in Washington, New York, Massachusetts, Illinois, Colorado, and California make it mandatory for covered employers, and senior generative AI candidates skip postings without one wherever they live. For a number priced to your own scope, run it through the salary benchmark assistant before the budget meeting rather than after.

Generative AI Engineer Job Description Template
Swap anything in square brackets for your own details. A few lines end with a note in parentheses, and those notes are for your hiring team. Delete them before anyone outside the company sees the page.
Job Title
[Generative AI Engineer / Senior Generative AI Engineer / Generative AI Engineer, Applied] (Keep “generative AI” in the title when the work is building on foundation models. Most job-board search matches on the title first, and “AI Engineer” alone also pulls computer vision and forecasting applicants.)
About the Team and the Product
[Company] builds [what the product does, in one sentence a customer would recognize]. We’re hiring a generative AI engineer to [the outcome, such as taking our support assistant from a 200-person internal pilot to 40,000 customers, or building search across 1.2 million contracts]. You’ll join [team], report to [role], and work most days with [product, design, data engineering, security].
Where the System Stands Today
- Models: [primary model family] through [Azure OpenAI in Microsoft Foundry / Amazon Bedrock / Vertex AI / a direct API / open-weight models self-hosted on vLLM]. [Say whether a model switch is planned.]
- Data it reads: [support tickets / contracts / clinical notes / source code], [with or without PII or PHI].
- Evaluation: [none yet, and you’ll build the first suite / manual review before each release / an automated suite that gates every prompt, model, and retrieval change].
- What it can change: [nothing; it only answers questions / it calls tools that create tickets, update records, or issue credits up to $X, with human approval above that].
- Stage: [prototype / pilot with N internal users / production at roughly N requests a day].
Responsibilities
- Build and ship generative AI features on [model family] that [who] rely on, from prompt and retrieval design through release, monitoring, and the fixes after
- Own the retrieval pipeline over [sources], including ingestion, chunking, embeddings, [vector store], and reranking
- Build and run the evaluation suite, meaning a labeled test set drawn from real user questions plus automated scoring and a regular human review, before every prompt, model, or retrieval change
- Put guardrails in place for prompt injection, sensitive data, and off-policy output, aligned with [the OWASP Top 10 for LLM Applications / our internal AI policy]
- [If agents are in scope: design tool-calling workflows with scoped permissions, human approval above [threshold], and complete audit logs]
- Keep p95 latency under [target] and model spend under [budget] through caching, streaming, and routing simple requests to smaller models
- Instrument the system with tracing and user feedback capture in [LangSmith / Langfuse / Arize Phoenix / Datadog], so failures surface on a dashboard before they surface in a customer email
- Tell product, early and in plain language, when a feature doesn’t need a model at all
Required Qualifications
- [3+] years building production software in Python or TypeScript, with real testing and CI habits
- At least one generative AI feature shipped to actual users, not only a demo or a notebook, and a specific story about something that broke after launch
- Hands-on retrieval work with embeddings, a vector database, and a reason for the chunking strategy you picked
- Evaluation experience beyond trying some prompts. Test sets, metrics, and ideally a release you held back because the numbers said to
- Working knowledge of prompt injection and data leakage, plus at least one control you’ve built against them
- [Only if it matters: experience with your model route, such as IAM and private networking for Bedrock on AWS, or Entra ID and private endpoints for Azure OpenAI]
Preferred Qualifications
- Tool calling or agent workflows in production with write access to other systems
- Fine-tuning with LoRA or a similar method, in a case where prompting and retrieval weren’t enough (cut this if you’ll never fine-tune)
- Serving open-weight models on vLLM or a comparable stack
- [Industry] experience with [HIPAA / SOC 2 / PCI] data
- AWS Certified Generative AI Developer (Professional), Microsoft Certified Azure AI Apps and Agents Developer Associate, or Databricks Certified Generative AI Engineer Associate
Constraints Worth Knowing Before You Apply
[Latency target. Current and expected request volume. Monthly model spend. The on-call rotation, and how many pages it produced last quarter. Release cadence, and any legal or security review a release has to clear.] (Candidates ask about all of this by the second interview. Answering it here saves both sides a round.)
Compensation and Location
Base salary: [$X to $Y], plus [bonus target], [equity], and [benefits]. [Fully remote across [time zones] / [N] office days a week in [city] / on site in [city].] (Post a real range. If the scope reaches into agents with write access or fine-tuning, say so here, since that scope is what justifies the upper end of the range.)
Asked on Intake Calls This Year
Popular templates online still ask for GANs and VAEs. Should ours?
Only if the job trains generative models from scratch, which is rare outside research labs, media and gaming studios, and the few product teams building their own image or audio models.
For an application seat the line mostly attracts people hoping for a training budget. You probably don’t have one. Replace it with what the job does. If you really do train diffusion or audio models, list them along with the GPUs you run them on, and expect a smaller and pricier pool.
Does the title need the word “generative,” or will “AI engineer” bring in the same people?
Different people, in our experience, because “AI engineer” also draws computer vision, forecasting, and classical machine learning applicants, while “generative AI engineer” narrows the pool to people building on foundation models.
Neither title is wrong. When the work is mostly features on hosted models, keep “generative” and put the model family in the first line of the body. When the seat is half classical ML, the broader title fits and the posting should explain the split.
We haven’t built any evals yet. Is it a mistake to admit that?
Saying so is the opposite of a mistake, because it draws engineers who want to build evaluation from nothing and filters out the ones who would leave in month three after finding out.
It also moves the level. Building the first test set means sitting with product and legal and whoever handles customer complaints to decide what “correct” means, and that’s senior work even when the code is simple. Hand it to a mid-level engineer and you tend to get a hundred easy questions the model already passes, which feels like progress for about a month.
How much of our security and data setup can go in a public posting?
More than most security teams assume, since naming the cloud, the model provider, and the kind of data involved reveals very little, while network layouts, contract terms, and specific control settings should stay out.
A line like “customer PHI, processed only inside our Azure tenant” tells a qualified candidate what they need. People from regulated shops recognize it immediately. People who haven’t worked under those rules ask what it means, and that’s worth knowing early.
Can one hire own both the product features and the model platform?
Often, at a startup with one or two generative features, but once you self-host open-weight models at real volume the platform half turns into its own full-time job.
On-call is the tell. If the same person gets paged about a GPU node pool at 2 a.m. and is expected to ship a product feature by 10, one of those jobs is slipping, and in my experience it’s the feature. When we hear that pattern at intake we suggest splitting the req, even though it means running two searches.
The first build is a pilot. Contract, or straight to a permanent hire?
Contract usually fits a pilot better, since it buys a working system and an honest read on whether the feature deserves a permanent owner before you commit to a salary.
The risk is the handoff. A contractor who builds the pilot and leaves takes the reasoning behind every prompt and retrieval choice with them unless it’s written down, so write it into the agreement that prompts, evaluation sets, and decision notes live in your repository. Contract-to-hire is the middle path when you already suspect the pilot will stick.
Write the System Down Before the Skills
The skills list gets most of the drafting time in most postings I read. Candidates trust it least. Move that effort to a short paragraph near the top describing the system this person inherits. Which models, reached how. What data they touch. Whether anyone measures quality today, and whether the model can change anything outside itself. Someone who has done this work reads that paragraph and knows inside a minute whether it’s their job.
The loop is the next place these searches slow down. The interview questions for generative AI engineers we published show how to test evaluation judgment and injection defense without assembling a research panel, and the guide to hiring a generative AI engineer covers sourcing, timelines, and closing.
We run these as contract staffing engagements and direct hire searches, depending on how settled the scope is. If you’d like someone who works these searches every week to read your draft before it posts, talk to our team. A year after we place someone, the chance they’re still there is about 92%, and the average search closes in 17 days. I’d credit scoping for more of both numbers than sourcing.

