Senior AI engineer doesn't exist

Published · 25 min read

Or, why I think it doesn’t exist.

This article was born from a discomfort that has been running through my head for a few months.

Everyone in this field came from somewhere else, which is not a bad thing.

My entire background is in data. Data engineering and data science, pipelines, modeling, statistics, experiments, and lots and lots of EDA. Years opening datasets, hunting outliers, side-eyeing columns, building hypotheses, optimizing my Hearthstone deck, and so on. I also built collection routines, ingestion, transformation, orchestration, stuff running on a schedule every day and feeding important decisions. And I think my engineering skills got better.

But it is engineering under a specific regime: batch, one run at a time, tolerant of delays, and if it breaks at 3am you can reprocess at 9 and nobody dies. That is a different animal from a conversational application with a queue, serving many concurrent users, where every request has someone waiting on the other end, latency is the product, and “reprocess later” does not exist because the user already left.

When I went to put my first agent in production, I found out that nothing in my toolkit had prepared me for that other part. I did not know how to design an API that survives a retry without duplicating side effects. I had never thought seriously about idempotency, connection pools, graceful shutdown, backpressure, or what happens to the queue when the LLM provider returns 429 for ten minutes with customers waiting.

I have software engineering gaps. Real gaps, the kind I still believe you do not close with a weekend course, because they are scar tissue gaps, things you only learn by breaking stuff and fixing it. And the whole market is pretending that people like me, with three years of LLMs stacked on top of other things, are “senior AI engineers”. And I am not even sure that is wrong?

But the point I want to make is that nobody is. The reason has nothing to do with a shortage of good people. The bar that defines senior in this field simply has not had time to exist yet.

Let’s take it step by step.

The hottest job title on the market is three years old

Numbers first.

LinkedIn’s Jobs on the Rise 2026 report put AI Engineer as the fastest-growing role in the United States, with 143% year-over-year growth in postings. Four of the five fastest-growing roles are AI related. Between 2023 and 2025 there were 639 thousand AI-related openings in the US alone. Market estimates point to something around 1.6 million open positions against ~518 thousand qualified candidates, a demand gap of 3.2 to 1.

Now the part that matters. The term “AI Engineer”, in its current sense, was popularized by swyx in the article The Rise of the AI Engineer, in July 2023. The title barely existed in 2022. His definition is honest about what the job is: a software engineer who builds with AI, knowing enough about model concepts and limitations to ship it in a product, without being a researcher or an ML engineer.

Do the math. If the role was born in mid-2023, the person with the longest possible track record as an AI Engineer has about three years of experience today. And still the postings ask for “5+ years of experience with LLMs in production”. The Indeed Hiring Lab documented that the share of tech postings asking for 5+ years of experience rose from 37% to 42% between 2022 and 2025, exactly the period when the most requested technology was under 3 years old. It is the old “requires 10 years of Kubernetes” meme from when Kubernetes was 4, only at industrial scale.

When the posting asks for more years of experience than the technology has years of existence, what the posting is really asking is “be senior at something else and pretend you were always from here”.

And that is what the market did. Since there is no stock of trained AI engineers, everyone filling those roles today is a convert (amen, in my case). And a convert carries the baggage and the holes of their previous life. The way I read it, there are three dominant profiles competing for the same openings, and each one arrives with a different structural gap that almost never shows up in the interview.

Which way do I go?

Which way do I go?

Profile 1: the one who came from data (hi there, buddy, nice to meet you)

Data scientist, senior analyst, ML engineer from the pre-LLM era. Knows statistics, knows what overfitting is, knows that offline evaluation guarantees nothing online, has seen a metric lie. This profile has a huge advantage the market took a while to notice: the hardest part of generative AI in production is evaluation, and evaluation is literally the trade of people who came from data. Defining metrics, designing experiments, distrusting a result that looks too good, controlling false positives. Twyman’s Law is our home turf.

The gap is everything else. And everything else is big.

People who came from data typically built their whole career in environments where the code ends when the insight comes out or when the pipeline runs. Notebooks, batch DAGs, dashboards. And even those who built a decent pipeline, like me, built it for the wrong regime, because a batch pipeline forgives in a way an online system does not. The software engineering discipline that turns code into a system serving people in real time, automated tests, CI/CD, API design, observability, error handling as a first-class citizen, capacity under concurrency, was usually never demanded of them. The classic account of moving from data science to AI engineering on Towards Data Science points to exactly this. The main hole is production engineering (APIs, containers, queues), and only after that comes the AI layer on top.

My own self-critique, from my own list:

The danger of this profile is hiding behind statistics. Since evaluation became the fashionable skill, it is tempting to settle into the “evals person” role and never touch the part of the system that hurts. But an AI engineer who cannot stand up their own service is an analyst with a new title.

Profile 2: the one who came from software

The frontend/backend/full-stack dev who rode the wave. This profile arrives with what the first one lacks. They know how to ship to production, ideally know the cost of keeping a system alive, think about API contracts, about rollback, and are held to a higher standard on testing. swyx’s definition was written practically for them, and Pragmatic Engineer with Chip Huyen reinforces that the AI Engineer sits much closer to software engineering than to research.

Their gap is the inverse of mine, and it is more subtle, because it does not show up as a missing skill. It shows up as the wrong mindset about correctness and, in some cases, a lack of depth.

Classic software engineering is built on determinism. Same input, same output, test passes or fails. LLMs broke that, never mind the extra pieces like RAG and friends. Same question, two different answers, both possibly good. The dev who arrives in AI trying to write unit tests for model output discovers the tool has no teeth. Academic research on integrating LLMs into products documents exactly this pain. Evaluating LLMs demands a research mindset, forming hypotheses, defining custom metrics, iterating over variations, and none of that is taught or practiced in traditional software engineering training.

In practice, the symptoms of this gap are easy to spot:

The dev has the right foundation for half the job. The other half is epistemological, “how do I know this is good, and how much wrong do I tolerate?”, and it is exactly the half they never needed to develop.

Profile 3: the one who arrived through automation platforms

This is the new profile, and the fastest growing at the base of the pyramid. It is the person who came in through n8n, Make, Zapier, Dify, Flowise, or straight through visual agent builders. Sometimes they come from business, from customer success, from administration. Formal job titles like n8n Automation Engineer and AI Automation Engineer have already appeared, the no-code automation market is valued at US$ 13.8 billion, and three of the five most starred agent repositories on GitHub are visual builders, Langflow, Dify and Flowise. That is no accident. That is where the volume is.

I will give credit where it is due before delivering the bad news. This profile has a real virtue: closeness to the business problem and speed of POC delivery. While the data person is calibrating the eval and the dev is designing the architecture, this person has already built the prototype, already put it in front of the user, already checked whether the idea has traction. In a market where MIT measured that 95% of corporate generative AI pilots fail to generate impact, largely for lack of integration with the real workflow, validating fast is worth a lot.

Now the bad news, and here I will be blunt because I think the course industry is lying to these people. This is the weakest profile of the three, and by a margin that does not close quickly. The other two arrive with a decade of foundation in one of the two halves of the job and need to build the other half. This profile arrives with neither. It lacks the statistics and evaluation base of the first, it lacks the engineering base of the second, and what it does have, fluency in a visual tool, is exactly the part that commoditizes fastest. The gap goes well beyond a list of missing skills. It is the entire foundation:

And the time problem is structural. The data person closes the engineering gap in one or two years of production because they already know how to program, already think in systems, and were simply never held to rigor. The dev closes the evaluation gap in months, because methodological rigor is learnable for someone who already has technical discipline. The automation person needs to build what the other two spent a decade building: programming logic, systems fundamentals, statistical grounding. There is no shortcut for that, and the platform that abstracts everything is actively an obstacle, because every hour in it is an hour learning a product’s interface instead of the fundamentals underneath.

The honest path for this profile, as I read it, has little to do with “become an AI engineer”. It is one of two options. Use the closeness to the business as a springboard into product, where understanding the problem and prototyping fast is the core competency and the lack of technical foundation is not fatal. Or accept that closing the technical gap is a multi-year project starting from zero, with no platform in the middle. What does not exist is the third option the courses sell, six months of n8n and a certification putting you on the same shelf as someone carrying ten years of foundation. The market might even hire that way during the hype. It corrects on the first round of mass layoffs.

The same chasm, three different banks

Side by side, the picture looks like this:

 Profile    |  Brings from home            |  Gap             |  Time to close
-----------------+----------------------------------+------------------+--------------------
 Data       |  evaluation, statistics,     |  production      |  1-2 years
            |  methodological skepticism   |  engineering     |  in production
-----------------+----------------------------------+------------------+--------------------
 Software   |  systems, production,        |  probabilistic   |  months, with
            |  engineering discipline      |  mindset         |  discipline (evals only)
-----------------+----------------------------------+------------------+--------------------
 Automation |  POC speed,                  |  the entire      |  years, starting
            |  business context            |  foundation      |  from zero

Notice the symmetry only holds between the first two. The data person has the rigor the dev lacks, the dev has the production the data person lacks, and each can cross to the other side because they already have half the bridge built. The third profile is not part of that exchange. They have a legitimate skill, validating ideas fast, but they hold neither bank of the bridge.

If you could merge the first two, then yes, you would have a senior AI engineer. But that person does not exist in statistically relevant numbers, because there has not been time. The field is three years old. The “senior” openings are being filled by people who are senior in one column of the table and intern in the others, me included.

And the production numbers confirm the whole market is operating in that regime. The 2026 studies from Gartner, Forrester, McKinsey and MIT put the failure rate of agentic AI initiatives between 77% and 95%. There is a calculation in that material worth memorizing: an agent with 95% reliability per step, running a 20-step workflow, delivers 36% end-to-end success (0.95²⁰). The model has nothing to do with it. It is a problem of people who know how to evaluate but cannot operate, plus people who know how to operate but cannot evaluate, plus people who shipped fast without knowing either.

How each profile closes its own gap

The general rule is the same for all three, your study plan is your neighbor’s column, and the way to study is by taking on more responsibility in production, which courses alone will never give you.

If you came from data (again, hi there, buddy), the path is to take on the systems side instead of volunteering for the analysis side yet again. Take the service you already evaluate and become the owner of its deployment. Learn Docker, a CI pipeline, an API framework, and an observability stack, in your own service rather than in the abstract. Do the exercise of estimating cost per request before shipping and checking it afterwards. And resist the temptation to accept the “evals person” role as a permanent identity, because it is far too comfortable.

If you came from software, the path is to acquire the measurement discipline before any more architecture. No prompt, model or pipeline change without an evaluation set running before and after, even if it is 50 hand-labeled examples, because 50 labeled examples beat any vibe check. Learn the basics of applied statistics, sample size, confidence intervals, false positives, at the level of someone who uses them rather than someone who proves theorems. Reading Kohavi’s Trustworthy Online Controlled Experiments hurts less than it looks and solves half of this.

If you came from automation, the first step is a decision rather than a course.

What I recommend against is the non-decision, stacking platform certifications thinking you are stacking seniority.

What the paths have in common is that none of them is “learn framework X”. And that brings me to the provocative part of the article.

It is not about the tool

There is a whole industry of courses, threads and bootcamps selling the idea that the difference between you and an AI engineer job is mastering the framework of the moment. LangChain in 2023, CrewAI in 2024, now this agent, that SDK. Job postings list frameworks as if they were competencies.

So let’s run a test. A dumb implementation of a support agent that looks up an order’s status via a tool, in the five most famous libraries on the market. Pay attention to what changes from one to the next.

OpenAI Agents SDK

from agents import Agent, Runner, function_tool

@function_tool
def buscar_pedido(pedido_id: str) -> str:
    """Looks up the status of an order."""
    return db.get(pedido_id)

agent = Agent(
    name="suporte",
    instructions="You answer with the status of orders.",
    tools=[buscar_pedido],
)
resultado = Runner.run_sync(agent, "Where's my order 123?")

LangGraph

from langgraph.prebuilt import create_react_agent

def buscar_pedido(pedido_id: str) -> str:
    """Looks up the status of an order."""
    return db.get(pedido_id)

agent = create_react_agent(
    model="anthropic:claude-sonnet-4-5",
    tools=[buscar_pedido],
    prompt="You answer with the status of orders.",
)
agent.invoke({"messages": [{"role": "user", "content": "Where's my order 123?"}]})

CrewAI

from crewai import Agent, Task, Crew
from crewai.tools import tool

@tool("buscar_pedido")
def buscar_pedido(pedido_id: str) -> str:
    """Looks up the status of an order."""
    return db.get(pedido_id)

suporte = Agent(role="Support", goal="Answer with the status of orders",
                backstory="E-commerce support rep.", tools=[buscar_pedido])
tarefa = Task(description="Where's my order 123?",
              expected_output="Order status", agent=suporte)
Crew(agents=[suporte], tasks=[tarefa]).kickoff()

Pydantic AI

from pydantic_ai import Agent

agent = Agent("anthropic:claude-sonnet-4-5",
              system_prompt="You answer with the status of orders.")

@agent.tool_plain
def buscar_pedido(pedido_id: str) -> str:
    """Looks up the status of an order."""
    return db.get(pedido_id)

resultado = agent.run_sync("Where's my order 123?")

LlamaIndex

from llama_index.core.agent.workflow import FunctionAgent
from llama_index.llms.anthropic import Anthropic

def buscar_pedido(pedido_id: str) -> str:
    """Looks up the status of an order."""
    return db.get(pedido_id)

agent = FunctionAgent(tools=[buscar_pedido], llm=Anthropic(),
                      system_prompt="You answer with the status of orders.")
resposta = await agent.run("Where's my order 123?")

It is the same program.

A function with a docstring, an agent object, a system prompt, an invoke. The differences are cosmetic, a decorator here, a mandatory backstory there (CrewAI requires you to write fiction about your support rep, which says more about the framework than about the problem), an await over there. A reasonable dev migrates from any one to any other in an afternoon with the docs open. Underneath, all five do exactly the same thing. They assemble a list of messages, describe the tool in JSON, call the same chat completion API in a while loop, and parse the response. By the way, that raw loop, with no framework at all, is about 30 lines of Python. It would be the sixth implementation and would fit here just the same.

Now the provocative question, if the difference between the five frameworks is the name of the import, how can “masters LangChain” be a seniority criterion? Making a framework the central requirement of an AI job posting is like hiring a writer by keyboard brand. And the reverse is just as bitter. If your competitive advantage is knowing the syntax of one of these libraries, your competitive advantage is an afternoon of reading documentation. Call that a puddle, because it is certainly no moat.

What none of the five blocks shows is the real work, and it is identical across all five:

That work has no framework. That work is the job. And notice it demands exactly the fusion of the three profiles: the eval question belongs to the data people, the timeout question belongs to the dev, and the question “will the customer accept receiving this?” belongs to whoever is close to the business. The tool is the part any of the three learns in the first week.

A framework is what you use. Judgment is what you have. A posting that asks for a framework is hiring for what you learn in an afternoon and ignoring what you learn over time.

AI Enablers, the role that is not competing for the job

Before the classic closing section, recommendations from my own head, it is worth making room for a role that was left out of the three profiles on purpose, because it is not competing for the AI engineer job. And precisely because of that almost nobody talks about it properly, the AI Enabler.

The enabler is the person whose job is to make the rest of the company able to use and build, rather than building the AI system themselves. The market has already formalized variations of this, AI enablement lead, adoption specialist, AI training manager, the owner of the “center of excellence”. The definition of AI enablement I find most honest is: adoption is signing the tool’s contract, enablement is everything that turns the tool into results, clean data feeding it, trained people using it, governance holding it, operations catching the drift.

Why does this role matter more than the title suggests? Go back to the number that runs through this whole text, 95% of corporate generative AI pilots fail, and the dominant cause has little to do with bad models. It is lack of integration with the real workflow and lack of operational visibility. Read that again. Most of the industry’s failure sits outside the layer the AI engineer solves. It sits in the layer between the system and the people. That layer is the enabler’s territory. There is field data showing the size of the lever, enablement programs based on champions and per-role use cases nearly tripled weekly AI usage in 60 days. No prompt improvement delivers 3x adoption.

What the enabler does, concretely:

There is a thesis that holds for data infrastructure and holds twice over here. The good kind disappears from in front of people and lets them solve things on their own. The enabler is that thesis embodied in a job, their value lives in how many people they unblock, far more than in anything they build. The AI engineer multiplies the capacity of a system. The enabler multiplies the capacity of an organization. They are different levers, and the second is frequently bigger, because the bottleneck in companies in 2026 is the shortage of people who know how to fit the model into real work, long before any shortage of good models.

And here a circuit closes with the third profile from above. I was hard on the people who arrived through automation platforms wanting the engineering job, and I stand by it. But notice, closeness to the business, POC speed, ease of showing value to non-technical people, that is literally the enabler’s kit.

The automation profile that accepts it will not close the engineering gap quickly and moves into enablement is not demoting their career. They are moving to the role where their strengths are the core competency instead of compensation for a weakness. With one warning, a real enabler needs to understand enough engineering to avoid selling miracles, and enough evaluation to refuse a demo as proof. The fundamentals still charge admission, just in a smaller dose.

The symmetric mistake also exists, and I see companies making it, hiring an enabler and demanding engineering deliverables from them, or hiring an engineer and demanding organizational adoption, or hiring devs and expecting data science projects. They are distinct roles with distinct metrics.

Recommendations from my own head

What I take from these thoughts, right now, in order of importance.

  1. Stop describing yourself by your origin and start mapping the gap. “I’m from data”, “I’m a dev”, “I’m from automation” describes where you have been and says nothing about your value. The market has a surplus of what you already are and a shortage of what you are not yet.
  2. Study your neighbor’s column, in production. Courses fill in vocabulary. Scar tissue comes from somewhere else. The data person takes on a deployment. The dev takes on an eval. The automation person rewrites a workflow without the platform. One of each already changes the level of conversation you can have.
  3. Distrust any self-declared seniority in this field, including your own. The job is three years old. Whoever presents themselves as senior in AI is senior in something else, which is great, as long as the person can say in what. In the interview, ask “tell me what you don’t know how to do”. Whoever answers fast and specifically is the one who understood the moment.
  4. Tools go in the footer of the resume. Keep them out of the headline. If five frameworks produce the same program with different imports, listing a framework as your main skill communicates that you do not know where the value lives. List what does not commoditize, evaluation, operations, cost, security, business domain.
  5. Take advantage of the missing bar to build your own in public. That is the good part of the mess. Since there are no seniors, the cost of entry is the lowest it will ever be. Document what you broke and fixed. In a field without a bar, public evidence of learning is worth more than a title.
  6. If you hire, pair data with software and stop looking for the unicorn. The “senior AI Engineer, 5 years of LLMs” opening will stay open, because it describes a person who does not exist. One data person and one dev, with forced overlap in their work, cover today what the unicorn would cover in 2030. Hiring platform fluency as if it were engineering is what hiring an “Excel specialist” as a financial analyst used to be. It works until the first question the tool cannot answer.

Conclusion

A senior AI engineer does not exist because seniority is a function of time exposed to failure, and the field has not accumulated the time. What exists are three diasporas converging on the same job.

The 95% of pilots that fail do not fail for lack of people who memorized a framework. They fail at the border between the three profiles, in the slice of the work that none of the five libraries above solves, because it was never a library problem. While the market publishes postings asking for five years of experience in a three-year-old technology, the real advantage belongs to whoever looks at their own gap without embarrassment and crosses to the missing bank.

Senior, in this field, for now, is just the junior who knows exactly what they are junior at.

#career#applied-ai