Get told when a verified record lands on this occupation → · Mark which of these tasks are yours (VOLO Pro, free) → · For a team or a graduating class →
Machine learning engineer
Ships systems whose behaviour is learned rather than written — which means nobody can say line by line why they do what they do, and someone still has to decide whether they are good enough to use on people.
Take the benchmark your team quotes and find out whether its data could have been in the model's training set. If you cannot rule it out, the number means less than the team thinks.
This is not a probability of losing your job. It combines how much of the role's task load is exposed to automation with how far adoption has actually gone — useful for comparing occupations on one consistent basis, and for nothing else.
Written for engineers who build, evaluate and run learned systems — recommendation, ranking, vision, speech, fraud, forecasting, and increasingly applications built on a bought model. It sits apart from the other computing pages on a different axis: those cut by layer or seniority, this one by what you ship. Research scientists producing new methods, and the people responsible for rolling AI out across a company, are different jobs with their own pages — `ai-researcher` and `ai-implementation-lead`.
What is actually changing#
The unit of analysis is the task, not the job title. A role is not replaced — its task mix shifts.
Each tile is one task. Its size is how much of the job it is; its colour is where the task is heading. Click a tile to see what the judgement does not establish.
This site's four directions cannot tell those two mechanisms apart, and the difference matters to anyone planning around this page: a task that became purchasable can become unpurchasable again when the vendor's price, licence or capability moves, in a way that a task a machine learned to do does not. It also says nothing about the domains where a bought model is not an option — narrow, proprietary, latency-bound or regulated ones — which are not rare.
A judgement about the nature of the work, not a measurement of how it is staffed. Plenty of teams do not do this at all and ship on a vendor's published benchmark, which is the failure this describes rather than evidence against it — but how many is not counted anywhere.
Nothing here measures how much of a given team's time this takes, and the answer differs by an order of magnitude between a team with an existing data asset and one starting from nothing. Using a model to label data that trains a model also has known failure modes this judgement does not weigh.
The count here covers only the federal systems that chose to answer, and it describes processes, not how well they work. A model running unwatched for a year is common — where nobody watches, this task is not done at all.
The evidence is individual companies describing their own systems, not a measurement across the field. Domain-specific feature design is also still load-bearing in some regulated settings where an unexplainable input is not allowed, which this judgement does not separate out.
A rule on the books that does not yet apply, and it names the organisation, not the individual engineer; requirements differ sharply by market and by what the system is used for, and nothing here shows who inside a company has been told the work is theirs.
Is this your job? Say so and this page narrows to your share of it.
A job title is a bundle of tasks bought together, and no two people hold the same bundle. Nothing is sent anywhere — it stays in this browser.
Read all 6 tasks in full — direction, reasoning and limits →
Recent changes#
Computed here from the individually-reported CSV, the way this site treats a statistics series: the whole file was pulled and the counts were taken locally, so a reader can repeat them. Filter: development_stage is Deployed and is_high_impact is High-impact, which gives 227 of 1,040 deployed rows. The hi_testing_conducted field then reads Yes for 44, In-progress for 81 and is empty for 102. The impact-assessment field reads Yes for 36, In-progress for 90 and is empty for 101. The independent-review field never reads complete as such: 31 name a Chief AI Officer review, 4 an internal independent review, 1 an oversight board, 89 say in progress and 102 are empty. Authority to operate reads Yes for 69, No for 60 and is empty for 98. Federal agencies, not this site, chose the high-impact label and filled these fields, under EO 13960, the Advancing American AI Act and OMB Memorandum M-25-21. What the counts establish is what the agencies wrote down about their own gate before deployment; an empty field is an empty field, not a No, and a Yes is a self-report that no one here has checked. The date is the day OMB published the consolidated file (summary as of 13 April 2026; the repository itself was created on 28 January 2026); the underlying deployments span many years and the file does not give one date for the set.
An employer has put it into production. Can move the baseline — weighted by scale and how similar the setting is.
Five named Instacart engineers describing their own search system. They say Instacart historically trained and maintained multiple independent models for individual query-understanding tasks, each bespoke solution with its own data pipeline, training and serving architecture; that replacing these specialised models with a single LLM handling multiple language tasks removes the complexity of maintaining separate models; that the system is now live, serving millions of cold-start queries weekly; and that it has shifted their core challenge from feature engineering to productionising these backbones while managing latency and cost. One company and one system, described by the team that built it; it says nothing about how many ML engineers Instacart employs or whether their number changed.
An employer has put it into production. Can move the baseline — weighted by scale and how similar the setting is.
The US government's own inventory of AI use across agencies, 2,133 entries. It asks whether there is a process to monitor an AI system's performance after deployment, with four answer options. Counted here from the file: of the 874 entries in Operation and Maintenance, 76 chose one of the four — 47 'Intermittent and Manually Updated' (data science teams work with DevOps engineers to manually update models at scheduled intervals and create metrics to detect distribution shift), 15 'Automated and Regularly Scheduled Updates' (some monitoring and retraining automated, but data science teams still significantly involved), 5 'Established Process of Machine Learning Operations' (automated testing, drift detection and pipeline-driven retraining), and 9 with no monitoring protocols. The other 798 left the question blank or wrote not applicable, and the answers were largely voluntary and skewed towards a few agencies, so this describes the systems that answered, not federal AI as a whole.
An employer has put it into production. Can move the baseline — weighted by scale and how similar the setting is.
Seventy-five ML-engineering Kaggle competitions - training models, preparing datasets, running experiments - graded against the human baselines on each competition's own public leaderboard, so the comparison is with the people who actually entered. The best-performing setup at the time of writing (o1-preview with the AIDE scaffold) reached at least bronze in 16.9% of competitions; the authors also report that resource scaling and pre-training contamination both change the number, and the benchmark is open-sourced so anyone can rerun it on a newer model. Two limits are structural rather than incidental: a Kaggle competition arrives with the problem already framed, the metric already chosen and the data already collected, which is the part of this job the benchmark cannot test at all; and OpenAI built the benchmark and sells models measured on it.
A demo, benchmark or paper shows the task can be done. Updates what the technology can do — not what employers will do.
The EU market, and only for high-risk systems that are trained on data — the duty falls on the provider, which is the organisation, not the individual engineer. It is recorded against answering for what the system does to people rather than against the data-preparation task itself: Article 10 governs how that data work must be done, not how much of it a machine now does. What it establishes is that showing the data was suitable for the purpose, examined for possible biases and checked for gaps moves from professional practice to a documented legal duty. Regulation (EU) 2026/1744 (the Digital Omnibus on AI, published 24 July 2026) moved the application of these obligations from 2 August 2026 to 2 December 2027 for systems that are high-risk under Annex III, and to 2 August 2028 for those that are high-risk under Article 6(1) and Annex I; so this is a rule on the books that does not yet apply. The article says nothing about how many teams already work this way, what it costs, or what applies outside the EU.
Failure, rollback, regulation or cost is suppressing adoption. Can lower an assessment or widen its uncertainty.
Four Microsoft researchers describing Bing's own labelling practice in a peer-reviewed conference paper. They write that Bing has been using LLMs, in conjunction with expert human labellers, for most of its offline metrics since late 2022; that in their experience LLM labels proved more accurate than any third-party labeller, including staff, much faster and many times cheaper; and that they have found it necessary to build harder gold sets over time to keep telling labellers and prompts apart. The labels mostly feed evaluation metrics rather than training data, and Microsoft builds and sells the models used, so it has a stake. It says nothing about how many labellers or engineers the work employs.
An employer has put it into production. Can move the baseline — weighted by scale and how similar the setting is.
What this means for you#
Most of what a course teaches — architectures, tuning, feature design — is the part this page marks as displaced, and one of those was displaced before you started studying. The part that is scarce is the one courses cannot easily set homework for: constructing a test that a model has not already seen, and saying out loud that something is not good enough yet. Get near a system that is running on real people, even a small one, sooner than feels reasonable.
If your value was knowing which model to reach for, that knowledge depreciated fast and keeps depreciating. If it is knowing how this domain breaks — what a wrong answer costs here, which inputs are missing, what a plausible number means when the population changed — that is the half that got scarcer, because the thing being judged got harder to judge. The uncomfortable version: much of the field's recent hiring has been for people who can call an API well, which is a different job with a different ceiling.
Your options#
Four directions, each with its real constraints and one thing you can test this week. Continuing as you are is a legitimate choice — it just has to be a chosen one.
Own the measuring instrument
When the model is bought, the evaluation is the only thing left that is yours — and a test set built from your own failures is not something a vendor can supply.
It is adversarial work aimed at your own team's product, which is socially costly in a company that measures progress by launches.
Take the benchmark your team quotes and find out whether its data could have been in the model's training set. If you cannot rule it out, the number means less than the team thinks.
Go where a model cannot be bought
Narrow domains, proprietary data, hard latency budgets, and settings where an unexplainable input is not permitted — in all of them the purchasable substitute does not exist, and the classical skill set is still the skill set.
These domains reward depth in something that is not machine learning — physics, medicine, markets, hardware — and that depth takes years you cannot shortcut.
Find one problem in your industry where a general model measurably underperforms a small specific one, and write down why. If you cannot find one, that is also an answer.
Take the obligation before it is assigned
Duties are attaching to learned systems used on people, and they require someone who can show what the model consumed and why that was fit for the purpose. In most teams that person does not exist yet.
It is accountability before it is a title, and the requirements differ by market — taking it means reading the actual text of an obligation, not a summary of it.
Pick one model your company runs on real people and write down, in one page, what data it was trained on and who decided that was appropriate. Notice how long the blanks take.
Common questions#
The parts move in opposite directions here, which a single number would hide. Training a bespoke model has been displaced for a large share of problems, and not by a machine learning to do it — by the product becoming purchasable, which is a reversible kind of displacement. Judging whether a learned system is good enough has become harder and scarcer at the same time. A signal you can check yourself: of your last three pieces of work, how many ended in a trained model and how many ended in a judgement about one somebody else trained. The second number is the direction the job is moving.
Part of it, and it is worth being precise about which part, because the mechanism is unusual. What went away is the bespoke artefact, not a human capability: your problem now has a purchasable substitute. That kind of loss reverses — a vendor's price, licence, rate limit or capability shifts and the work comes back — which is not true of work a machine genuinely learned to perform. What did not go away is knowing how to tell whether the substitute is actually working on your problem, and that got harder in exactly the same move.
Asking it as a choice between two skill sets is what makes it hard to answer. The durable position in both is the same one: being the person whose judgement about whether the thing works is trusted. What differs is the price of entry — building on top has almost none right now, which is why that lane is crowded and why the ceiling in it is set by whether you can tell a good result from a plausible one. If you can only do one thing well, do the judging.
Demand and exposure are different questions and this page only answers the second, which is worth saying because they are routinely confused. The honest observation is that the title now covers two jobs with different ceilings — one that trains and evaluates systems, and one that assembles applications on a bought model — and postings rarely distinguish them. Before taking a role, ask what the team shipped last quarter and whether anyone built a test set for it. The answer tells you which of the two jobs the title means there.
Studying towards this?
These majors lead here. Their pages break down which of their competencies transfer and what graduates typically lack.
What these judgements rest on#
6 of 6 task judgements on this page are backed by a verified event and 0 are platform inference, each labelled where it appears. Behind them sit 2 technology dimensions, a reconstructed trajectory since language models reached the public, and 6 verified events.
See which technologies, how it got here, and the method →
Where it sits in the official classification: skills, knowledge, related jobs →
Other roles in the same function#
A company divides its work into functions before it divides it into jobs. These sit in Technology & data alongside this one — a fact about org charts, not a judgement that they are similar or that they are changing in the same direction.
Junior software developer · Experienced software engineer · Frontend developer · Backend developer · Data engineer · AI researcher · Software tester / QA engineer · Data analyst · Data scientist · Statistician · Economist · Business analyst · Business systems owner · IT support specialist / helpdesk · Security analyst (SOC) · DevOps engineer / platform engineer / SRE · Network engineer · Technical writer / documentation engineer · Grant writer / grants officer
