Picture two browser tabs, side by side. Same seniority. Same vague “competitive salary” non-answer at the bottom. Same buzzword soup in the bullet points—RAG, agents, fine-tuning, vector databases, all of it. One tab says AI Engineer. The other says LLM Engineer. Squint and they’re identical. I’d bet real money this exact scenario is happening right now, on someone’s laptop, somewhere between a coffee shop and a small crisis.

The part that makes it worse is that those two roles aren’t the same job. They’re not even close 🫠

But I don’t blame anyone for assuming they are, because a lot of the people writing those job descriptions don’t know it either. And these days, I’m not even sure “writing” is the right word. More than a few of these postings read like someone asked a chatbot for “a job description for an AI role” and pasted the first draft straight into the listing without reading it back.

If your LinkedIn headline still says “Full-Stack Developer,” I’m not coming for you. That title isn’t wrong, exactly—it’s just fossilizing. It worked for a long time, but no longer describes what’s actually happening in the industry.

The industry has quietly moved from typing code into an editor to babysitting the autonomy of systems that write a rough draft of that code for you.

Somewhere in that shift, the job market spawned about twenty new species of engineer, half of which sound like they escaped a sci-fi script, and almost nobody agrees on what any of them actually do.

This post isn’t a glossary. A glossary assumes you already know which entry to look up and just need the definition filled in. I’m assuming you don’t know that part yet, and that’s fine, because plenty of the people doing the hiring don’t either.

This is a field guide for figuring out which shelf you’re on, why your job posting and your actual day-to-day stopped matching about a year ago, and what to do about it before the title changes again, because it will.

Grab a coffee. We’ve got some taxonomy to sort through 🔍

Your Recruiter Is Just as Confused as You Are

A lot of the confusion you feel when you scroll job boards isn’t because you missed something. It’s actually due to a broken job description.

Did you hear that? It’s not you—it’s the posting.

Nobody really says that part out loud, but it’s the simplest explanation for why scrolling job boards leaves you feeling like you’re missing some baseline everyone else already has.

Open one of these postings, and you’ll usually find a twenty-five-bullet checklist of every acronym anyone on the team has ever said out loud in a Slack thread—RAG, agents, fine-tuning, evals, LangChain, vector databases—all crammed into one req as if a single human is supposed to be expert-level at each.

That’s not a job description. That’s a wish list with a salary band stapled to it.

Real quick, because I’m not assuming you walked in with these memorized:

• RAG means feeding a model relevant documents before it answers, instead of relying only on what it already “knows.” I walked you through a simple demo with my portfolio data.
• Fine-tuning means retraining a model slightly so it specializes in one specific thing.
• A vector database is a database built to find similar pieces of text fast, which is what makes RAG actually work in practice.

Explore: I Built A Free AI Chatbot For The First Time – Here’s Everything That Went Wrong (And Right)

Why “ML Engineer” and “LLM Engineer” Aren’t the Same Job

Recruiters who staff AI roles for a living point to a simple explanation for much of this confusion: job descriptions were written during what they call the “training era” and never rewritten for the “integration era” we’re actually living in now.

An ML Engineer trains a model from scratch by tuning the underlying math until it learns the pattern you want, then ships it somewhere other software can call for an answer.

An LLM Engineer doesn’t train anything. They take a model someone else already built (think GPT or Claude) and wire it into a real product by feeding it the right documents, managing how much it can “remember” in a single conversation, and ensuring it behaves once real users start talking to it.

The overlap between those two jobs is something like 15%. The resumes can look nearly identical at a glance, even though day-to-day doesn’t.

So when a company posts “ML Engineer” but actually needs someone gluing GPT calls into a customer support tool, they end up interviewing math PhDs to debug a chatbot that keeps hallucinating return policies.

The PhD is bored. The chatbot is still broken 😬

Everyone’s confused about why the hire isn’t working out, and the answer was sitting in the job title the whole time.

Tip 👀
If a posting lists “fine-tuning” and “prompt engineering” as if they’re interchangeable skills on the same line, that’s a sign the company hasn’t decided what they’re actually hiring for yet. Ask in the interview. You’re allowed to.

Explore: This Is The Free Browser Extension Your Job Search Needs

Which Phase Is Your Company Actually In?

Most companies are sitting somewhere along a three-phase curve.

1. First, employees just using AI tools day to day.
2. Then, building agents and copilots that handle real tasks inside a product.
3. And eventually, full autonomous systems that are digital employees running an entire workflow with a human only checking the exceptions.

Personally, I’m in phase two right now. My actual day-to-day has moved past just using AI tools, and a real chunk of my job has quietly turned into experimental, not-really-accounted-for work around building automated workflows, testing agentic processes inside our existing systems, and trying to make the team’s existing work less manual.

It’s serious work, though, not phase three. Nothing here is fully autonomous, and I don’t think it’s close 😅

Most mid-market companies in 2026 are stuck somewhere in that same phase-one-to-phase-two gap, whether their job posting admits it or not, which means most of them don’t actually need a researcher. They need a builder.

You can usually tell which phase a company is actually in from the second paragraph of the posting.

• If it describes a specific thing they want built—an agent that does X, a tool that automates Y—that’s phase-two language, and that’s where most of the open roles actually sit right now.
• If it reads instead like a list of credentials and prior expertise you’re supposed to have, that’s leftover phase-one language from a job description nobody updated.

Find Your Shade: The 2026 Engineering Taxonomy

Once you stop trying to match titles and start looking at what people actually do all day, the chaos sorts itself into something closer to a map.

Picture two axes. One runs from Code Doers on the left to Vibe Wranglers on the right based on how much of your job is typing into an editor versus typing into a chat window and negotiating with a model.

The other axis runs from Building the Dream at the top to Babysitting the Nightmare at the bottom based on how much of your day is spent shipping new things versus stopping the new things from breaking everything else.

A few stops on that map, translated out of the acronym soup:

The Context Engineer

The Context Engineer sits in the quadrant of careful, deliberate building. Their job is to ensure an agent has the right information at the right moment, instead of working from a context window stuffed with everything and nothing.

You’ve probably heard the myth that goldfish only remember things for a few seconds; it’s not even true for goldfish, but it’s painfully true for an AI agent with no memory system behind it.

Context engineering isn’t the same job as prompt engineering, even though people use the words interchangeably.

Prompt engineering is what you say to the model in a single moment.

Context engineering is the discipline of architecting everything the model sees before it ever answers. This includes system instructions, retrieved documents, memory, tool outputs, and conversation history.

If you’ve ever set up an AGENTS.md or CLAUDE.md file to tell a coding assistant how your project actually works before letting it touch any code, you’ve already done a tiny version of this job yourself.

One is a sentence. The other is an information-supply system. Prompt engineering didn’t die; it just became one ingredient inside a much bigger job.

Related: All You Need To Know About AI Workflow Files And How To Use Them

The Eval Engineer

The Eval Engineer is the person nobody invites to the launch party because their entire job is asking, “But is it actually getting worse over time?” while everyone else is celebrating the demo.

Production AI doesn’t fail loudly. It degrades quietly.

A model that answered correctly in March can drift into confidently wrong answers by June, and “it looked fine yesterday” isn’t a monitoring strategy.

This role exists because someone has to measure that drift instead of assuming the green checkmark from last week still means anything.

The Platform Engineer

The Platform Engineer is solving an old problem with a new name. For years, “shift left” meant pushing security and testing earlier into the development cycle with the mantra “catch it sooner, fix it cheaper”.

The trouble is that shift left buries developers under responsibilities that were never really theirs to carry.

So, the 2026 correction is “shift down”. Instead of pushing more work onto individual developers, you push the complexity down into a shared internal platform so a developer doesn’t need to become a Kubernetes expert to ship a feature.

In practice, that means instead of filing a ticket and waiting three days for someone on the infrastructure team to spin up a new database by hand, a developer clicks a button on an internal tool, and it appears in two minutes, already configured the way the company likes it.

That second version, the “paved road”, is what a Platform Engineer builds.

Note: Gartner expects roughly 80% of large engineering orgs to have a dedicated platform team by the end of 2026, up from under half just a couple of years ago.

If your job has quietly turned into building tools for other developers instead of building a product for users, you’re already doing this work even if you don’t have the title yet.

The Design Engineer

The Design Engineer is the person standing between Figma and production code, making sure the thing that ships still looks like it was designed by a human who cared, rather than assembled by a model optimizing for looks like every other AI-generated app.

But that’s only half the job 💁‍♀️

The bigger half is maintaining the actual design system behind a real product, such as all the specific colors, components, and patterns that make it look like your product instead of a generic template, and making sure every new feature stays compliant with this brand identity.

AI-generated code makes this harder, not easier, because when shipping a new feature takes an afternoon instead of a sprint, the rate of new screens and components quickly increases, and without someone actively maintaining the system, it falls apart just as fast.

As more of the boilerplate gets auto-generated, taste and consistency become the scarce skill, not syntax.

The Forward Deployed Engineer

The Forward Deployed Engineer might be the single fastest-growing title on this entire map. Palantir built the role over a decade ago with engineers who embedded directly inside a customer’s environment, writing production code shoulder-to-shoulder with the people who’ll actually use it, rather than handing off a deck and hoping it works.

And no, this isn’t just a fancier name for a contractor. A contractor brought in for a specific, well-defined piece of work usually delivers it and leaves once that piece is done.

A Forward Deployed Engineer (FDE) stays embedded through the messy part of getting the thing live, watching it break in ways nobody predicted, and fixing it on the spot. The job gets measured by whether the thing still works in production, not by whether a deliverable was shipped on schedule.

To make this messier, some FDEs are technically contractors on paper now, too, since the title has started to outgrow the employment type it was originally tied to. What actually makes someone an FDE has less to do with the paperwork behind their paycheck and more to do with whether they own the outcome past the handoff.

Note: FDE job postings grew over 700% between April 2025 and April 2026 alone, and companies from OpenAI to Salesforce to Databricks have built dedicated FDE functions since.

Also, keep in mind that an FDE isn’t a Solutions Engineer. While an FDE writes and owns production code, a Solutions Engineer demos and configures, then moves on once the deal closes. They get confused for each other constantly, and if you’re interviewing for one while expecting the other, you’re in for an uncomfortable first quarter.

There’s a clean way to see how we got here, if you zoom out far enough.

1. Start with traditional software engineers, writing code by hand, focused on syntax and logic—that’s the past.
2. Slide over to ML engineers and researchers, training models, focused on math and parameters—that was the pivot.
3. Keep sliding, and you land on context and AI agent engineers, orchestrating what a model sees and does, focused on APIs and memory—that’s where most of us actually are right now.
4. Keep going, and you hit harness and eval engineers, governing autonomy, focused on guardrails and outcomes—that’s where this is all headed.

Most of the job titles confusing you at this very moment are just different stops on that same slide, dressed up as entirely separate species.

The Veteran’s Rebrand: Three Paths Out of the Title You’ve Outgrown

This section is for anyone who’s been writing code professionally for a few years, whether your role has been slowly drifting under your feet or whether that decision got made for you.

Microsoft, Salesforce, and Amazon have all cut traditional engineering and support roles since mid-2025 while simultaneously hiring for AI-specific ones. Overall, software development job postings are still down in the double digits from where they were a few years back.

If you’re reading this after a layoff instead of in the middle of a slow burn, the destination below is largely the same one.

Here’s where that drift is most likely taking you, depending on where you started 👇

You’re a Bored Software Engineer

You’re shipping features, the work is fine, and “fine” is exactly the problem. The natural move here is toward an AI Engineer role, not because the title is trendy, but because the actual skill shift fits.

Stop measuring your contribution by syntax correctness and start measuring it by whether the system you built behaves reliably across a thousand edge cases you didn’t think to test by hand.

That means building evaluation frameworks, not just features. It’s a way to prove the agent or RAG pipeline you shipped is actually doing what it claims, consistently, not just in the one demo you ran for your manager.

What most engineers do here: ship the integration, watch the demo go well, move to the next ticket.

The better way: ship the integration, then build the eval suite that tells you six weeks from now whether it’s still working because it probably won’t be, quietly, and you want to be the one who notices first.

If you’re not bored, exactly, but drifting somewhere close to it, or if your actual week looks less like shipping the roadmap and more like:

• building an internal dashboard nobody asked for
• wiring up a custom MCP server to remove some annoying friction
• or quietly automating a process that used to take three people

That’s a different kind of drift, and it’s not really pointing toward an AI Engineer.

Instead, it’s pointing toward Platform Engineering territory where you’re building the tools and infrastructure that make everyone else’s work easier, even if nobody’s put a name on it yet.

Tip 👀
The eval-focused version of AI Engineer above is the right call if you’re the one shipping the AI feature itself. But if you’re the one building the workflow and tooling around how features get built and shipped, you’re already doing platform work.

You’re a Frustrated Solutions Engineer

You’re tired of building demos that get a customer excited, then handing the real work off to an engineering team you’ll never talk to again.

Some recruiters call this the “60-day path” to Forward Deployed Engineer, and honestly, the exact number matters less than the shift it points at.

Stop building pre-sale proofs of concept designed to disappear after the contract is signed, and start writing the production code that’s still standing six months later when the customer’s actual workflow depends on it.

This is the difference between being the person who sells the magic trick and being the person who has to make the trick work backstage, every day, under a real SLA. (That’s a service-level agreement—the contract clause spelling out exactly how reliable your system has to be, with money on the line if it isn’t.)

What most Solutions Engineers do here: perfect the demo, hand off, never see the production consequences.

The better way: ask to stick around past the signature, even unofficially, and own the first stretch of the rollout. That’s the FDE muscle, and it’s the part of the resume that actually gets you hired into the role later.

You’re a DevOps Survivor

You’ve spent years answering pages at 2 AM and writing YAML you’ll forget by Friday. Platform Engineering is where this skill set is headed, whether you choose it or not, and it’s more than a costume change for DevOps—it’s a shift in who you’re actually serving.

DevOps is mostly about you and your team getting your own code into production smoothly.

Platform Engineering is about building the internal product that lets every other team get their own code into production without needing you in the room each time.

Instead of a developer pinging you on Slack for a new staging environment (a copy of the app to test changes safely before they go live) and waiting half a day for you to set it up, they click a button on a tool you built, and it shows up already configured the way the company needs it.

That’s the self-service golden path.

Instead of disappearing into a black box of infrastructure, you’re building the road so the next ten developers don’t have to learn what you had to learn the hard way.

What most DevOps teams do here: keep firefighting incidents one at a time, forever.

The better way: build the self-service tool that prevents the incident category entirely, then measure your value in incidents that never happened. That’s the metric platform teams are increasingly judged on in 2026.

Explore: Why LinkedIn’s Quiet AI Overhaul Makes It Suddenly Feel Broken

The Newbie Manifesto: How to Get In Without Drowning

If you’re starting out, and every one of those role names made your stomach drop a little, I have semi-good news: Python plus basic LLM API skills are the floor now, not the differentiator. Everyone applying next to you already has that. It stopped being impressive a while ago.

So what actually sets you apart? A GitHub repo with a real agentic workflow and real evaluations attached. Not a polished tutorial clone, but something where you can point to a specific failure you found and fixed. That’s the muscle every role on the taxonomy map above actually needs, no matter which quadrant it’s in.

Tip: A project that fails honestly and gets measured beats a credential that just promises competence on paper!

The “LangChain + Pinecone + ChatGPT API wrapper” project that signaled AI readiness back in 2024 (Pinecone’s a vector database) is now a yellow flag instead of a green one. It’s table stakes, not a differentiator.

So go one step past the wrapper. Show what happened when the API call failed in a way that actually mattered, and what you did about it 😬

And if you don’t have a specific failure sitting around waiting to be fixed, that’s okay. You don’t need to dig through open-source issue trackers hunting for one. There’s another way in: build a proof of concept around an idea you actually believe in, not just a “look how pretty this is” demo.

I built one recently that’s less “here’s a chatbot” and more a small thought experiment made real. My premise was a question: What would hiring look like if AI agents had to build a reputation, the way people build on LinkedIn? Followed by: Could you actually evaluate an agent’s track record before “hiring” it for a task?

See it in practice here: taskra-a304.onrender.com. GitHub repo: thehelpfultipper/taskra

That’s the kind of project that shows how you think, not just that you can wire up an API call.

Tip 🔥
Pick an idea you actually believe in, even a weird one. Build a small, working version of it.

I’ll also gently push back on staying a generalist too long. That agent-reputation idea (Taskra) wasn’t really about chatbots. It was me picking one specific question (i.e., how do you evaluate trust in an autonomous system) to go deep on, instead of trying to stay decent at everything AI-related.

Pick a niche early, even a slightly odd one. Sustainability data engineering. Spatial computing. Domain-specific evals for an industry you already understand from a previous job or degree. Go deep enough that nobody can swap you out for the next bootcamp grad who watched the same RAG tutorial.

The premium in 2026 isn’t for knowing a little about agents in general. It’s for being the one person in the room who actually went somewhere with it.

Explore: Developer Job Market 2026: Why JDs are Broken & How to Win with AI

It’s a Wrap

Before I let you go, know that the headline statistic everyone quotes is true, but it’s not measuring what you think.

“AI will displace 92 million jobs while creating 170 million new ones by 2030” comes from the World Economic Forum’s 2025 Future of Jobs report. That’s a global, all-industries number ranging from cashiers and factory workers to accountants and everyone. Not just programmers. Don’t read it as 92 million coding jobs vanishing.

Inside the “AI and information processing” category specifically, that same report points to something much smaller: about 11 million new roles against 9 million displaced. A real gain, just a far less dramatic one than the scary version that gets passed around on LinkedIn.

Even the data about this confusion is a little confusing 🙃

And remember that the titles in this post will have shifted again within six months. They always do. It’s not a contradiction of the “pick a niche” advice from earlier because the niche is the actual problem you go deep on (things like trust in autonomous systems, sustainability data, whatever it is for you).

Titles are just the label. Labels are cheap to swap.

So don’t memorize today’s taxonomy like it’s permanent. Build the habit underneath it instead. Care about outcomes over tech stack, protect your actual flow state instead of chasing every framework that trends for a week, and whatever you do, don’t let the thing you shipped go rogue before lunch!

Which shade are you? A Code Doer quietly drifting toward Vibe Wrangler, or the other way around? I’d love to know. Drop it in the comments.

That’s it for today. I’ll catch ya on the next one.

Bye 🦎