agentnative

The last engineering roles standing before humans largely disappear from software development. x.com/i/article/2111…

Agent engineer ads require agent experience in 49% of roles. Another 30% list it only as a preference.

We read the requirement lines of 242 agent engineer roles on our board and counted each skill once. A skill was required when any hard requirement line named it, and preferred only when nothing but the preferred lines did. Python, TypeScript and backend engineering behave like filters whenever they appear. Building agents splits: a filter for some teams and a tiebreaker for many others.

We read that split as a sign of how young the work is. Our reading is that engineers with long agent experience in production are still scarce, so a team that makes it a hard line risks a small pool, while many teams hire strong engineers who can learn the loop and keep agent work as what moves one of them ahead. LLM evals sit the same way, required in 36% of these roles and preferred only in 19%.

So one application has two jobs. In our reading, the requirements decide whether the person screening keeps reading, and the preferences decide who stands out once several applicants clear the bar. An application that answers only the requirements reads like the rest of the pile, and one that opens with a clever side project while skipping a stated requirement risks never being read to the end.

Hiring teams face the same choice from the other side. Moving agent experience into the requirements screens out the backend engineer who could learn the loop on the job, and leaving it among the preferences works best when the ad says what would count as evidence.

Three things the ads on our board say to look for and show:
- Check whether the ad names agents among its requirements or its preferences, because that decides what leads your application.
- Answer every stated requirement first, in the ad's own words, with one line of evidence for each.
- Show one small agent you built for the preference, such as a loop of about 100 lines with stop rules, a dollar cap and a log of every request, which Chapter 2 of Harness Engineering walks through for free.

A requirement line is the ad's wording on paper, so these shares count what teams ask for in writing and say nothing about whom they end up hiring.

We would write every agent application as two answers, one to the filter and one to the preference, because the ads on our board use agent experience as both and a single answer leaves one of them unmet.

Same model, strongest harness. Same model, weakest harness. On Terminal-Bench 2.0, 18.4 points separate the two scores.

The free Chapter 1 of our book Harness Engineering, The Harness Is What You Ship, gathers one model's published results on that benchmark across the agent harnesses built around it. The model stays the same throughout. What changes is the tools it can call, what goes into its context and the checks on its output, and those choices move the score on their own.

The chapter is careful about how far that goes. Counted on verified results alone, the spread shrinks to 4.9 points; the benchmark's own authors write that choosing the model usually matters more, and METR found that product harnesses did not beat simple scaffolds. Even on that cautious reading, a team holding its model fixed still has points to win or lose in the code around it.

We read this as the reason agent teams hire the way they do. Our reading is that a team building on a model it did not train owns the harness and little else: which tools the agent gets and how those tools fail, what the window holds, when a run gets checked and when it stops. In our view, that is the code its engineers write, review and debug week after week.

The chapter's sharpest example is how quickly that work dates. It records that Anthropic cut Claude Code's system prompt by more than 80% for Opus 5. In our reading, instructions written around one model's weaknesses had become clutter for the next, so every component in a harness carries an assumption someone has to revisit.

That gives an engineer moving into agent work something specific to build and show. Hold one model fixed, change one thing around it, a tool description, a retrieval step or a verification pass, and report the score before and after on the same tasks. A project like that answers the question we expect an agent interview to ask sooner or later: what did you change, and how do you know it helped.

In a hiring manager's seat, we would test the same skill directly: hand the candidate a fixed model, a failing agent and its traces, and ask what they would change around the model first. Our view is that an ad listing model names and frameworks draws people who have used them, while an ad naming tool design, context and checks draws the people who build them.

We think candidates should prepare for the harness and teams should hire for it, because on any given model it is the part of the score a team controls.

20% of inference roles on our board involve Triton. Across all AI roles, 3% do.

That gap is one of the clearest signs in the roles we track that inference engineering has become a job of its own. Of the 97 inference roles open on our board, 66% involve GPU optimization, a skill most AI ads leave alone. The work these teams describe sits beneath the model API: how requests are batched, how memory is spent on a GPU, how fast a kernel runs.

We read the reason as cost. A team serving open models pays for every token in GPU hours, so a kernel that wastes memory bandwidth turns into a bigger bill and a slower product. Our book GPU Architecture and Programming argues that most performance problems in deep learning are memory problems in disguise, because the chip does arithmetic far faster than it can fetch the numbers. An engineer who can tell whether a workload is bound by compute or by memory is the one who can make it cheaper.

The ordinary platform work stays in these ads too. Inference roles ask for LLM app infrastructure about as often as AI roles in general, so in our reading the kernel skills arrive on top of it.

Say you are three years into backend work and have built products on hosted model APIs. That experience counts, and the ads we read ask for more beneath it. What sets an application apart is one piece of work below the API: a fused kernel written in Triton, a profile showing where a serving path stalled on memory, a throughput figure before and after a change. In the interview, expect to be asked why a model server runs out of memory before it runs out of compute, and answer with numbers.

Teams hiring for inference face a thin pool for the same reason. In our reading, many engineers who have written kernels come from graphics, high-performance computing or compiler work, and an ad that asks for years of LLM experience first screens them out. Naming Triton or kernel work in the requirements tells those engineers the role is for them.

The inference group is small, 97 roles, and an ad that names Triton says nothing about how deep the kernel work goes. Even so, these ads point the same way, below the API, where general AI ads rarely go.

If we were aiming at inference work, we would put one measured kernel or serving change at the top of the CV, because it is the evidence these ads ask for and, in our reading, few applicants can show.

If you have spent years shipping backend or infrastructure systems, AI platform roles are asking for what you already have.

On our board, 2 of 53 AI platform roles that state a minimum accept 2 years or fewer. Across all the AI roles we track that state one, 11% do. Platform ads open to juniors far less often than AI ads as a whole, and 79% of the platform ads that state a minimum set the bar at 5 years or more.

We read the reason in the job itself. In our view, a platform team runs the shared systems that model teams build on, so a mistake there reaches many people at once. A team hiring for that seat, as we read it, wants someone who has already carried a pager for a system people relied on, migrated it without losing data and paid for a bad capacity guess. Those lessons come from time in production, and an ad can only ask for them as years.

We read this as good news for engineers who assume the way into AI work runs through a research credential. The years these ads count are years of experience, and a backend or infrastructure engineer has been collecting them all along. Our view is that outside research roles, a record of systems that stayed up tells an AI hiring team more than a degree does.

What that engineer needs is translation. Say you have spent most of a decade on payments infrastructure: the queue you scaled, the deploy pipeline you hardened and the cost review you led all have counterparts in platform work. In our reading, an application that leaves those links for the reader to draw is weaker than one that draws them, so put the platform vocabulary next to the systems you ran.

Hiring managers face the same gap from the other side. In our reading, an AI platform ad that leads with model names draws candidates who know the models and quietly screens out the infrastructure engineers the job needs. Leading with the systems the role will own, and stating the years plainly, keeps the strongest pool reading to the end.

The sample is small: 53 of 76 AI platform roles on our board state a minimum, so the ones that stay silent may be more flexible than this suggests.

A backend engineer with years of production behind them should apply to AI platform roles now, because the requirement that filters most applicants out is the one they already meet.