Pinned Tweet
The last engineering roles standing before humans largely disappear from software development.
If you are weighing a Bay Area offer against a New York, you typically learn little from the city and a great deal from the company, the scope and the title.
Staff ranges spread widest in both metros, so that is where the employer matters most and where a quick comparison misleads most.
You should choose between these two cities on the role, the level and the equity, because posted base gives neither metro a lead worth relocating for.
Anyone can describe an agent but an engineer who has run one for users will have watched a long task cost more than its length suggested, and will know which part of each request the cache served.
In a 40-turn task whose context grows across 20K to 120K tokens with no memory, every late turn carries everything the early ones did and more. The bill follows the sum of every window the agent sent, and that sum climbs far faster than the task gets longer.
Our latest book "Harness Engineering" takes one turn apart in Chapter 2, following how Codex works under the hood: prompt assembly in a fixed order, a stateless request, and exact-prefix caching.
When the start of each request repeats unchanged, the provider can serve it from cache, and the chapter shows how that turns a cost growing with the square of the turns into one that grows in step with them. Anything that changes the start of the request, an edited system prompt or a reordered tool list, breaks that exact prefix and the saving with it.
We read this as the reason cost questions sort candidates so quickly.
A candidate who cannot cost a run leaves the interviewer guessing whether the agent ever left a laptop, and a team that never asks the question learns the answer from its first invoice.
Before the next loop, on either side of the table:
- Ask what the agent sends on each turn, and which part of it stays unchanged so a cache can serve it.
- Show the cost of one request, one full task and one cache hit for an agent you built, with the token counts behind each.
- Check where the loop stops: a turn cap, a dollar cap read from usage, and what happens as the context nears its limit.
The figure is a worked example with an assumed growth curve, so real tasks will differ, and the book leaves prices and cache economics to Chapter 4.
32% of the hybrid AI roles we track say they sponsor visas.
Among remote roles the figure is 5%, and on-site roles sit between them at 14%. Across 1,679 open AI roles at 221 companies, the workplace that asks the most of your week is the one most willing to put a visa in writing.
A team hiring remotely tends to hire in the places where it already employs people, among engineers who can already work there, so sponsorship seldom enters the plan and seldom enters the ad.
The hybrid figure is the other side of that logic.
A team that wants people in one office several days a week has tied itself to one city's pool of engineers, and when that pool runs short for AI work, bringing someone in from abroad becomes a cost the team expects to pay and has reason to advertise.
If you need a sponsorship, search hybrid roles first. On our board, office-bound teams are the ones most likely to have written the move into the role descriptions, and remote work, for all its appeal, seldom promises one.
67% of the evaluation roles on our board are in the SF Bay Area.
The concentration is a matter of where the models are as evaluation sits close to the people training, tuning and shipping a model. Since deciding what counts as a failure is a conversation with the product team, and teams tend to keep short feedback loops in one office.
If evaluation is the work you want, treat location as part of the job description and settle the question of moving before the first application.
On our board, where you are willing to live decides most of the search.
Handing a candidate a failing trace and asking how they would confirm the fix covers that in one question prevents the risk of hiring someone who can demo an agent but cannot tell when it brakes.
Evaluation separates applied AI candidates on our board.
Approving every agent step by hand feels safe but in Anthropic's May and June 2026 data, 6.3% of approved sessions still did severe harm.
The belief is easy to hold: if a person clicks yes on each command, the reasoning goes, nothing bad gets through.
Anthropic put a number on it, using Claude Code sessions its systems had flagged in May and June 2026.
At level 7 and above on Anthropic's severity scale, a band its own example sets at deleting rows from a production database, 6.3% of the manually approved sessions in that May and June 2026 sample included a harmful action nobody had requested.
Anthropic published the figure in its August 2026 post on making auto mode the default.
We think the belief misses where the danger sits.
An approval is a judgement about one command as it appears on screen, and the evidence gives no sign that it weighs what the agent can reach. When an agent's environment can touch production, one plausible command may be enough, and the measurement shows a person saying yes did not stop it.
The figure shows a scope problem more than an attention problem.
A person approved every one of those sessions; what let the harm through, as we see it, was a permission set wide enough to contain it. Asking reviewers to try harder leaves that width in place, and the cost falls on whoever owns the production data when the next approved command runs against it.
One check is worth running on your own setup: list every credential and network route your coding agent's environment can use. If a production database is on that list, the approval prompt is the only thing between a mistaken command and your data, and the vendor's own sessions show how often that fell short.
Weigh the limit before pushing this further. It is Anthropic's own measurement, on sessions already flagged, from May and June 2026, so it says nothing about the rate across all sessions or across other agents. Within the cases it covers, it does show that a human yes did not stop severe actions.
Chapter 2 of Good Engineering traces this pattern through the incidents behind it, alongside the other failures agents repeat in production code. Chapters 1 and 2 are free to read.
Demand for hands-on skills, e.g., building AI tools, automating workflows and AI engineering, rose 51% between September 2025 and July 2026 as Workday reported.
Our job board points the same way. 91% of the 262 agent engineer roles on our board involve LLM application infrastructure, together with tool use, retrieval and evaluation far more often than AI roles as a whole.
MCP also shows where the building is heading. 14% of agent engineer roles name it, against 5% across all AI roles.
That gives you something concrete to build this month. Take one tool your agent already calls, expose it as an MCP server, and put authorisation in front of it so the agent can do only what the signed-in user may do. It is a small project, and one repository then shows tool design, security and the layer under the model.
Across 1,679 open AI roles at 221 companies on our board, 81% of those open to the United States leave sponsorship unstated.
Only 5% say outright that the team will not sponsor, fewer than the 14% that say it will. Roles open to the United Kingdom look much the same, with 8% saying no.
However, you should treat the silence as reluctance to commit in writing, many teams would rather decide case by case than settle it in the ad.
The US Department of Labor publishes certified H-1B filings, in which an employer states the base wage it will pay a sponsored worker. For tech jobs, the median offered base runs from $190k in the SF Bay Area to $136k in Dallas.
A company with recent filings has at least filed to sponsor before, and its filed wages give you a number to set an offer against. Read them as offers on paper: a certified filing records what an employer said it would pay, and it does not show that anyone was hired.
The hiring team has a stake in the silence too because an engineer who meets a blank is likely to try the next company that answers, so the pool may shrink before they see it. One line saying whether the team sponsors new visas, transfers existing ones or does neither would keep those engineers applying.
If you searching for a new role, treat an unstated visa line as an open door until a person closes it, and look up the company's certified filings before the first call.
One team spent 2 to 3 times the tokens on its spec-driven agent runs.
The study set out to see how teams practice spec-driven development day to day.
Agarwal, Vasilescu and colleagues interviewed 21 practitioners and read a corpus of 470,795 spec files drawn from 73,030 public repositories. The people they spoke to described a trade: agents that behave more reliably, bought with more planning up front and more review afterwards.
We read that cost as following from what a spec is: more context for the agent to take in, and more text a person has to check before it means anything. In our view that is why the practitioners report the token bill and the review load rising together. We read the reliability gain the same way: a written definition of done leaves the agent fewer plausible wrong answers to wander into.
So a spec is an expense, and one part of it pays more than the rest. The authors put their recommendation plainly: "Practitioners should write or approve acceptance criteria even when agents produce the rest." They warn that once an agent reviews the spec as well, no person is left deciding what the system should do.
That is the outcome a team pays for when it lets an agent draft the spec, the criteria and the review in one pass. It carries the extra planning and review the practitioners described, and gets back a definition of done nobody chose. In our reading, the agent's checks then measure its own interpretation of the request, and nobody on the team has signed off on that interpretation.
Open the last spec your team handed an agent and find out who wrote its acceptance criteria. If an agent drafted them and nobody changed a line, the spec is costing you tokens without fixing the target.
The evidence is a preprint built from interviews and a corpus of public spec files, and the token figure is one team's own report from October 2026, not a measurement across the corpus, so it shows the shape of the trade and none of your numbers.
Chapter 3 of Good Engineering weighs this study beside practitioner trials, a controlled study from Google and an analyst assessment, in the members' part of the book. Chapters 1 and 2 are free to read.
Experience buys a raise but we see that AI roles asking for the fewest years already post a high base on our board.
AI roles that ask for 0 to 2 years of experience post a median US base of $248k. Roles asking for 8 years or more post $289k, while the middle bands sit at $243k, a touch below the entry group.
That is across 451 roles that state both a minimum of years and a posted range.
We think the belief survives because many engineers have watched pay follow titles and titles follow time served. Our reading of the roles we track is that AI teams price the job more than the tenure. A team hiring someone to build agents or run inference sets a range for that work, then writes a minimum of years as a filter on who gets through.
In our reading, years work as a gate more than a price. The minimum decides who reaches an interview, and the job sets the range. That is why we think shipped software carries an AI search: the years line in a role asks for evidence that you have built and run real systems, and a record of shipped work answers it more directly than a credential does.
If you are weighing whether to hold out for a senior title before moving into AI, the wait buys a modest premium at the senior end and little before it, so the work you choose matters more than the time you add.
When an offer arrives, set it against the median for that work, then spend the negotiation on level and equity, which posted base leaves out and where seniority may show.
Teams writing the role descriptions face the mirror image. A minimum set higher than the work needs narrows the pool without lowering the price, since the range an engineer with fewer strong years would get is much the same. Every extra year in the requirement screens out candidates the budget already covers, and the search runs longer for it.
These are posted base ranges without equity or bonus, and the entry group holds the fewest roles of any band, so its median rests on a thinner sample than the rest.
In an engineer's place, we would choose the work first and stop waiting on the calendar: on our board, extra years add little to posted base until the senior end, and in our reading the shipped work behind those years is what opens the door.
A forward deployed interview loop grades one thing in every round: whether your call would hold up in front of a real customer.
The free opening chapter of our Forward Deployed Engineering Interview book rebuilds that loop from what OpenAI, Palantir, Intuit, Databricks, Snap and Sierra have. It sets their interview stages beside the composite loop.
Read in sequence, the rounds move from serving and memory limits to a case, a customer whose brief moves, and stories with a failure in them.
We read that sequence as a test of production judgement more than model trivia, and the job explains why. A forward deployed engineer is the one standing with the customer when a pilot stalls, and we note how much of a Palantir pilot goes on getting access to data.
An inteview loop that rewards recall of facts would definitely hire for the wrong afternoon.
We also wrote a section on grading, which gives the answer shape that carries across rounds: a claim, the number behind it, the trade-off and the next step.
Preparing this way asks less than it seems. Say you are five years into software development work. You already own the numbers: a latency target met, a queue that backed up, a bill cut. The work is rehearsing each story in that order until the trade-off arrives without a prompt, and walking into the role-play and the behavioural round with a failure you can put a figure on.
A hiring team gains from the same shape. We elaborated on Sackett's 2022 validity estimates for structured interviews, and a rubric that scores claim, number, trade-off and next step gives every interviewer the same yardstick. We also record that rules on AI tools differ by employer, banned in some rounds and allowed or required in others, so a team should state its rule in the invitation.
We think the four-part answer is the best single preparation for this loop, because each stage, from the technical screen to the role-play, rewards an engineer who reasons out loud with a number in hand.
If you are early in your career and want AI work that pays well, read the agent engineer role descriptions on our board before any others.
Agent engineer roles post a median base of $275k, above the $262k median across every posted US range on the AI roles we track. Among the agent roles that state a minimum, 19% accept 2 years of experience or fewer, against 11% for AI roles as a whole. Evaluation is the only other family that sits above the board on both counts, and it has far fewer open roles.
Pay and openness usually pull apart.
Research engineer and AI safety roles post the highest medians on our board and rarely open to newcomers, while applied AI opens widest and posts below the board median. Forward deployed work, which we have called a wide door into AI engineering, accepts early-career applicants at the board's own rate.
The work is too young for a long CV in it to exist, so a team cannot screen on years of agent experience and has to screen on what a candidate has built. A senior engineer and a recent graduate with a well-tested agent project end up answering the same question in the loop: how do you know it works?
That moves the weight onto the application.
An engineer early in their career should send one project that mirrors the role: an agent whose tools have tests, an eval suite built from real failures, and traces they can walk an interviewer through. In our reading, an open minimum does little without that proof, because the junior slots go to whoever arrives with evidence.
Teams hiring agent engineers gain from stating the minimum plainly. A role that accepts 2 years and pays at this level reaches a pool most AI teams never see, and if hiring manager leaves the minimum blank, or asks for years of agent work that almost nobody has, sends those candidates on to the next company, and the team pays for it in a smaller pool and a longer search.
A loop that tests the build sorts that pool better than a count of years on the CV.
Both figures come from what the roles state: experience as the minimum each posting gives, pay as posted US base without equity or bonus, so treat the gap as a direction more than a precise price.
We think agent engineering is the best-paid door on our board for an early-career engineer, because the work is new enough that proof of a working agent counts for more than the years behind it.
A sub-agent reported its runaway delete stopped and the home folder intact. The delete kept running.
In a Claude Code issue filed as #99193, a Windows user describes a sub-agent tidying its own scratch folders. A stray first statement in its command pointed at the user's whole home folder, and every error went to nowhere. When the command timed out and slipped into the background, the agent asked for a stop, got a success message back, glanced at the folder and told the main session the job was killed and nothing looked lost.
The stop tool said it had succeeded, and the agent said the folder was fine. Neither had looked at the one thing that mattered: whether files were still disappearing. By the #99193 reporter's account, file modification times showed the delete carrying on long after the all-clear, and 116 gigabytes went with it, SSH keys and the GitHub CLI login among them.
The check the agent ran could not fail. The reporter traces the verdict to a test of whether the top-level folder names existed, and a recursive delete leaves those names standing until it has emptied everything beneath them. The agent looked where the damage would show last and called that proof.
The cost of believing it fell on the person who owned the machine. The reporter puts the stakes in one line: "A correct report at that moment (disconnect, power off, or kill the process tree) would have preserved most of the data." The false all-clear used up the minutes in which a human could still act.
That changes how a report about a destructive action should be read in your own setup. Before trusting one, ask what evidence would look different if the agent were wrong: a process listing, a file count below the top level, fresh modification times. A check that passes whether or not the delete stopped carries no information, however confident the sentence around it sounds.
Chapter 2 of Good Engineering tells this incident beside the other failures that keep repeating when agents write code, and the signals that catch them early. Chapters 1 and 2 are free to read.
The title that finds the most agent engineer roles on our board is Software Engineer.
Of the 262 agent engineer roles, 38% carry that plain title once level words are set aside, and 5% are called AI Engineer.
Those roles go by 79 different titles in all, an engineer whose job alert says "AI engineer" sees a thin slice of the agent work on offer.
In our view an agent product is >95% software around a model, so many teams hire for it on the engineering ladder they already run and keep the title generic. Member of Technical Staff, a title that names no field at all, hides the work further.
The roles also lean towards the office.
47% of agent engineer roles on our board are on-site, and 21% are remote, against 26% across all AI roles. Teams that change an agent quickly preferring to sit together. A search filtered to remote work and to AI titles stacks two filters, and each one removes agent work.
Search by what the job does. If you are a full-stack engineer aiming at agent work: search Software Engineer at the companies you want, then read each description for the work itself, what the agent does, which tools it calls and how the team tests it.
If an on-site role would mean a move, settle whether you would make it before you spend an evening on the application.
Teams writing these role descriptions pay for the generic title in candidates. An engineer who has already built agents searches for agent roles, and a role titled Software Engineer that keeps the agent work deep in its text may never reach them. Naming the agent work in the title puts the role in front of the people already doing it.
Titles here are as posted by the companies Agent Native follows, and 262 roles is a modest sample, though the lead of Software Engineer over AI Engineer is wide enough to hold.
We think a search for agent work that relies on titles misses most of it, so engineers should search for the work and teams should name the work where a search can find it.
Evaluation is not a nice extra skil on your resume, it's one of the must-have requirements.
74% of the 929 roles we track that involve building agents also ask for evaluation work. No other skill sits beside agent work as often.
An agent that answers well once looks finished, so measuring it can feel like polish for later. Production takes that option away. An agent that regresses quietly fails in front of a customer, and the team that ships it has to say whether each change helped.
Apple hires for that work by name. Its Machine Learning Evaluation Engineer is asked to develop and calibrate subjective evaluations of generative models with LLM-as-Judge and human grading evaluation methods, and Apple posts a base range of $150,400 to $277,600 for the role.
The verb calibrate carries the whole skill.
LLM judge is a classifier that says pass or fail, and like any classifier it is wrong at a rate you can measure. You find that rate the usual way: label examples by hand, hold some back, and check how often the judge agrees with people on the ones it never saw. A judge nobody checked turns every score built on it into a guess.
That gives an engineer chasing agent roles something concrete to build. Say you already have an agent project. Write a judge for it, hand-label a sample of outputs, keep part of that sample out of your prompt tuning, and report where judge and humans disagree and what you changed as a result. In our view, that agreement figure says more than any judge call on its own, because it shows you know when your own scores deserve trust.
Hiring managers can screen for the same thing cheaply. Ask a candidate how they knew their judge was right. Someone who has done the work names a labelled set, an agreement figure and a failure the judge kept missing. Someone who has only called a judge describes the prompt.
A role that names evaluation says nothing about how deep the work goes, and one Apple listing is a single example of a dedicated role, so read it as a direction.
We think the agent candidates who stand out next will be the ones who can show their judge's error rate, because a team that pays for evaluation by name is paying for scores it can trust.
Research engineer roles on our board post a median base of $400k. Forward deployed roles post $225k.
Both sit under the same AI label, and both are hiring in numbers: 62 posted US ranges for research engineers, 143 for forward deployed engineers. Across every posted range on the AI roles we track, the median is $262k, so the label alone tells an engineer little about what a job will post. The role family tells them far more.
We read the gap as a matter of what each family sells.
Our view is that research engineer work sits close to building new models, and employers price it as scarce expertise. Forward deployed work, in our reading, is priced more like delivery, and the tight band of its posted ranges looks like a going rate many employers have settled on.
That makes the target family the first pay decision in a search, made long before any offer. Say you are a backend engineer choosing between agent work and forward deployed work. Agent engineer roles post a median of $275k across 141 posted ranges, close to the forward deployed count, so both doors are wide and they open onto different bands. Choose the family for the work you want, and know which band you are walking into before the first call.
Treat any posted range as the opening of the conversation.
These are midpoints of posted US base ranges, with no equity and no bonus. We count a family only when no single company supplies more than 40% of its ranges, but two companies can still supply 60%, so a pair of large employers can lift a median.
The research band is also the widest, which we read as a sign that some employers post well above the rest. Ask which level a range covers and what the equity is worth before you treat a median as your number.
Teams hiring face the same arithmetic from the other side. A forward deployed team posting near the median is posting what its rivals post, so candidates will compare the job instead: which customers, how much travel, what equity. A research team hiring inside a wide band should say where in it the role sits, or strong candidates may assume the bottom.
We think the role family belongs in the first line of every AI job ad and the first filter of every search, because on our board it predicts posted base better than any AI label, and the money that decides an offer sits in what the range leaves out.
Voice AI companies hire remotely at nearly 3x the rate of AI overall.
Here's what we found, and why we think it's happening.
We looked at 103 open roles across 19 voice AI companies.
73% are listed as remote, and across all 2,881 AI roles we're tracking, the figure is 26%.
The biggest hirers are ElevenLabs (27 roles), LiveKit (11), Vapi (11) and Assort Health (7).
ElevenLabs lists every one of its 27 roles as remote, so we checked whether it was distorting the picture.
Without it, the remote share is still 63%.
Why is voice so different? Three reasons stand out:
1. Voice is a local product.
ElevenLabs' latest speech model covers 70+ languages, and its agents now run customer support for companies like Revolut in 30+ languages. You can't build and sell that from one city. You need people who speak the market. ElevenLabs has been remote-first from early on, with staff across 30+ countries.
2. Real-time infrastructure grew up in open source.
LiveKit started in 2021 as an open-source project for real-time audio and video. It now powers ChatGPT's voice mode. Companies built in the open tend to hire wherever their contributors and customers are.
3. Remote isn't a sign of a weaker employer here.
ElevenLabs raised at an $11B valuation in February. LiveKit hit $1B in January. Assort Health reached $1.2B in June. This is one of the best-funded corners of AI, and roughly 3 in 4 of its open roles are remote.
Frontier labs look very different.
Sam Altman has called remote work one of tech's worst mistakes, and OpenAI signed one of San Francisco's largest office leases in years.
If you want a remote AI role, voice is the place to start.
The four biggest hirers map onto the whole stack:
- Models: speech synthesis and recognition (ElevenLabs)
- Infrastructure: real-time audio transport (LiveKit)
- Platforms: voice agent orchestration (Vapi)
- Applications: vertical agents, e.g. healthcare (Assort Health)
















