I get dozens of AI engineer job postings in my LinkedIn feed every day. If you're hiring for AI right now, yours probably looks a lot like them.
Experience with LLMs, RAG pipelines, prompt engineering, vector databases, fine-tuning, and one or more agent frameworks. Probably says "PyTorch" somewhere. Probably has a bullet about staying current with a fast-moving field.
Every item on that list is either a commodity or a wrapper, and most of them will be obsolete before the person finishes onboarding. You're hiring for the part of the stack that improves for free while you sleep, on someone else's roadmap, funded by someone else's capex.
None of those postings ask for the ability to make unreliable systems safe to run at scale. That's the actual job. And the people who are best at it aren't coming out of AI or ML. They're systems engineers.
The Data That Should Have Changed the Conversation
In February 2026, Can Bölük ran an experiment: take fifteen coding models, change nothing about the models, and rebuild the environment they run in. One model went from 6.7% to 68.3% on the benchmark. No fine-tuning. No new weights. An afternoon of work.
An order of magnitude of capability was sitting in the environment, not the model.
The Software Improvement Group found the same shape from the opposite direction. They analyzed three AI-built codebases using their ISO 25010-based maintainability model, the same one they benchmark across 30,000+ systems. The two built without human governance scored 1.1 and 1.9 out of 5, both in what SIG calls "legacy-like territory." The system built with governance infrastructure in place scored 3.1. The gap traced to four properties of the surrounding system: design boundaries, test strategy, dependency hygiene, and guided refactoring. None of them were model capability.
Then there's the OpenAI Codex field report from February: roughly a million lines, about 1,500 pull requests, five months, no hand-written code. Take the framing with appropriate salt, since OpenAI has an obvious interest in Codex looking good. But the team's own stated conclusion is the interesting part. Their job stopped being writing code and became designing the environment the agent worked in.
Three independent data points, one finding. The model is not the variable. The environment is the variable. "Designing environments that make unreliable processes safe to run" is systems engineering. It always has been. And your AI job posting doesn't mention it once.
Why Systems Engineers Make Better AI Engineers
Ask a candidate what they'd do about an agent that occasionally takes an action it shouldn't.
The AI engineer answers: tighten the system prompt, add a rule to AGENTS.md, add an eval that catches it, use a stronger model, add a critique step. All variations on asking the process nicely.
The systems engineer asks one question: what enforces it?
In the ML world, the model is the interesting object and everything around it is plumbing. In the systems world, a model would be classified on sight as an untrusted binary of unknown provenance. Nobody in that tradition would run one without a sandbox, a quota, and a supervisor that can kill it.
A systems engineer can learn the AI/ML layer in weeks. The model is increasingly an API call. Teaching an ML engineer to think in isolation boundaries, resource accounting, fault containment, and scheduler design takes years of production scar tissue. You can't shortcut the instinct that comes from being paged at three in the morning for a resource leak.
That asymmetry is the whole argument. AI is real. But the hard part of putting it into production was never the model. It's everything around the model, and "everything around the model" is what systems engineers have been building their entire careers.
The Skepticism Is a Feature
Most systems engineers I know think the AI space is overhyped. They're half right. The model capability claims are often inflated. The underlying engineering problems are completely real, and they're the same problems systems engineers have already solved in other domains.
Context corruption across long-running agent sessions is a memory isolation problem. A forty thousand dollar invoice nobody can attribute is a resource accounting problem. An agent with database write access it shouldn't have, scoped to the server instead of the tool, is a capability-based permissions problem. These have names in systems literature and decades of implementation experience behind them.
What makes systems engineers effective here is that they don't get swept up in the demo. They look at an agent stack and see the missing mechanisms, because they've built the infrastructure that contains these kinds of failures before. When someone says "we added a guardrail in the system prompt," a systems engineer hears "we wrote a comment at the top of the file and hoped nobody would ignore it."
Your AI team probably needs that bluntness and probably doesn't have it.
We Know Because That's Us
CogniArk started as systems engineers. Infrastructure, Kubernetes, GitOps, load testing, production operations. The work that nobody notices until it breaks. We didn't get into AI infrastructure because we were impressed by the demos. We got into it because we kept seeing teams ship agent systems with no isolation, no cost controls, no fault handling, and no plan for when the model returns confident garbage at scale.
So we did what we've always done. We went deep on how LLMs actually work, mapped the infrastructure gaps, and started building the layer that makes them safe to run in production. The environment, not the model. The part that every data point says is actually the variable.
We've written about this in detail — what agent stacks are missing, why prompt-level guardrails aren't controls, and what real enforcement looks like.
What to Do About Your Job Posting
Find a systems engineer. Maybe someone already on your platform team, maybe someone you hire. Point them at your agent infrastructure. Give them the incident list. They'll recognize every failure on sight, have opinions within ninety seconds, and be visibly annoyed. Let them build.
The catch: the instinct transfers but the domain knowledge doesn't. Knowing what a resource quota is and knowing how to implement one when the resource is nondeterministic tokens that cost ten dollars a minute are different problems. Your systems engineer will figure it out. It will take months.
Or skip the ramp. Talk to us. We've already done the translation.