How we count AI jobs

Where the data comes from

Every day we poll the public job feeds that employers run on their own applicant tracking systems: Greenhouse, Lever, Ashby, SmartRecruiters, Workable, Recruitee, Personio and Workday, plus USAJobs for United States federal roles. These are the same feeds employers publish for job boards to consume. We honour their robots directives and rate limits, and we publish aggregate counts rather than employers' verbatim listing text.

Workday matters more than the others combined, because it is what large employers outside technology use — banks, hospital systems, pharmaceutical companies, retailers, manufacturers. We read the same public JSON endpoint an employer's own careers page calls to draw its job list. Before adding a Workday employer we read that tenant's robots.txt, which names the career site it permits; if the path we would poll is not permitted, the employer is not added.

What counts as an AI role

We match on the job title only. Matching description text produces too many false positives from employers who mention AI somewhere in their boilerplate, and it is not comparable across employers who write longer or shorter postings.

Titles fall into two tiers, counted separately and never silently merged:

• Core — the role is about building or operating AI systems: AI and machine-learning engineers, applied and research scientists, data scientists, MLOps, computer vision, NLP, robotics, model training and evaluation.
• AI-adjacent — data and automation work that AI has absorbed, where reasonable people disagree about whether it counts: analytics engineers, clinical and health informatics, quantitative researchers, intelligent automation and RPA, decision scientists, data engineers.

The second tier exists because that is where a bank's and a hospital's AI staff actually sit. A bank files most of its machine-learning people under "Quantitative Researcher"; a hospital's are "Clinical Informatics Specialist". Counting those as core would overstate AI hiring, and counting them as nothing made every employer outside technology look as though it hired no one. Publishing both lets a reader who disagrees with us still use the numbers.

Titles are also excluded explicitly where a keyword match would be wrong: speech and language pathology, model risk and model validation, financial and actuarial modelling, surgical robotics, clinical and laboratory research, and recruiters hiring for AI teams. Title patterns include German, French, Spanish, Portuguese, Dutch and Italian terms, without which our European employers would report close to zero.

Who is in the panel, and who is not

Everything we measure comes from a panel of employers we poll by name. It is not a random or representative sample of the labour market, and the gaps in it are specific and worth knowing before you cite anything here.

The panel is designed rather than collected. We set a target number of employers per sector and per region first, and then look for employers to fill the empty cells — the reverse of how it worked until August 2026, when the roster was simply whichever job feeds answered. That produced 48 software companies and one government API, with no bank, hospital, retailer or manufacturer in it at all, and a geography that was mostly San Francisco and New York. The current fill rate for every cell is published on the employers page, including the cells that are still empty.

What is still thin, stated plainly: the public sector outside United States federal roles, telecommunications (most large carriers run applicant tracking systems with no public feed), universities, insurers and airlines. North America remains over-represented relative to its share of world employment. An employer can only be in the panel if it publishes a machine-readable feed whose terms permit polling, so these gaps are mechanical rather than editorial — but they are gaps, and a number drawn from a thin cell is marked as indicative rather than presented as a measurement.

Employers with no AI roles are kept in the panel and counted. Dropping them would be the easiest way to make AI hiring look universal: if an employer only enters the sample once it posts an AI job, the sample can never contain the finding that most employers post none.

The panel is public. You can see every employer in it, with their open-role counts, and where those roles are. When we add or remove an employer, the totals move for a reason that has nothing to do with hiring — so treat comparisons across a coverage change with care.

How a new role is detected

The feeds show current openings, not history. So we store a snapshot every day and compare it with the previous one. A posting ID we have not seen before is new; a posting ID that disappears has been filled or withdrawn, and we mark it closed. This means our history begins on the day we started tracking and cannot be backfilled.

When we missed a day

Days counted

19 / 31

61% of the span

Most recent

2026-08-26

Stale after 36h

Gaps

1

Runs of missing days

Feeds live

194

4 lost, 2 erroring

A day is recorded only once every employer on the panel has been polled. A partial run writes nothing, because a row built from two thirds of the panel records a drop that never happened and nothing downstream could tell it from a real one. A gap is recoverable; a wrong row is published.

That trade means outages show up as missing days rather than bad numbers, and missing days cannot be filled in afterwards — the feeds only ever show what is open now. We had a twelve-day gap in August 2026 when the collector was moved between hosts and nothing was watching it. The figures above are published so you can see the state of the series rather than take our word for it, and the tracker now fails loudly if a snapshot is more than 36 hours old.

How the headline number is calculated

The headline is an indicator, in the tradition of a debt clock or a population clock, not a census. It has two inputs.

The first is the observed rate at which AI roles are being posted across the employers we track. This is the driver: when hiring accelerates in our sample, the clock speeds up.

The second is a calibration component. Our tracked employers are a sample, not the world, so we scale that sample to a global figure using a published projection: the World Economic Forum's Future of Jobs Report 2025, which projects that AI and information-processing technology will create 11 million jobs by 2030. That is 2.2 million a year, or about 6,020 a day, and it is the anchor our observed posting rate is scaled against.

The same report projects 9 million jobs displaced by the same technology over the same period. We do not count that side, and our headline should never be read as a net figure. We publish the creation side because it is the one almost nobody is measuring directly — but the source we lean on for credibility says both things, and it would be dishonest to quote only the half that flatters us.

Concretely, we take the average daily inflow of new AI postings over a recent window, divide it by the long-run average across all our history, and apply that ratio to the calibrated daily rate. The result is clamped to between half and one and a half times the calibrated rate, so a feed outage or a single employer publishing hundreds of roles at once cannot distort the number.

Why the number never goes backwards

Each day's rate is frozen once derived, and applied from the following day onward. A rate revision therefore changes how fast the counter runs from now on, never the total already displayed. Without that one-day lag a downward revision could make the public counter appear to lose jobs, which would be wrong and would look broken.

What this measures, and what it does not

• It counts postings, not hires. A posted role is an employer's intent to hire, and some postings are never filled.
• It is calibrated, not a raw count. Anyone can reverse-engineer the arithmetic, so we would rather state this plainly than be caught implying otherwise.
• It covers the employers in our tracked set, scaled up. It is not a survey of the whole labour market.
• It reports both directions, and they are not equally solid. The creation rate moves with AI postings we count on a real panel of employers. The displacement figure is a flat projection from the same WEF report: no employer publishes a feed of the jobs their AI replaced, so we observe nothing about it and label it projected rather than modelled.
• The net figure can fall. Creation is clamped to between half and one and a half times the calibrated rate while displacement runs flat, so a sustained hiring slowdown drives net downward. That is the instrument working, not breaking — a disruption clock that can only rise is not measuring disruption.

Using our data

The daily series is free to download as CSV and free to reuse with attribution under a Creative Commons Attribution 4.0 licence. The live counter is available as a free embeddable widget. If you are citing the figure, please link to the tracker and describe it as counted from job listings and calibrated to the World Economic Forum's Future of Jobs Report 2025.

The measured series, and when its method changes

The CSV above is the modelled clock. The like-for-like series is the counted one: open AI roles across the employers we have tracked continuously since the first day we observed, so a change in it is hiring rather than coverage. It carries no index column on purpose — rebasing to 100 needs a base period, ours would be a single day over a small cohort, and that choice belongs to whoever cites it. A day we did not poll the whole panel is published empty, never interpolated.

Two things in that file can move and both are disclosed in it. A feed that fails for a fortnight is retired, and from that day its employer leaves the series — days before the step are never restated, but the level either side of it is measured over different numbers of employers, which the cohort_employers column shows. And the day after a gap absorbs the churn of every day inside it, because closures we did not watch happen are all stamped on the day we resumed.

Method changes

• v1.2 2026-08-24 — Postings-closed restated upward, by 673 across the series to date. Version 1.1 applied the joining-backlog exclusion to closures as well as openings, on the reasoning that the two are read as a pair. That was wrong in a way worth stating: the exclusion keys on when a role was first seen against when we first read its employer, both properties of the ROLE, and neither expires. A role that was already on an employer's board when we started reading it was therefore never counted as closed — not on the joining day, correctly, but not months later either, in periods when nothing about the panel changed. On this panel that was most roles: 3,641 of the 4,113 open on 2026-08-21 arrived that way. Closures now count whenever they happen; openings are unchanged, and the joining board is still not published as hiring. Opened minus closed now reconciles with the change in open roles for every period in which the panel held still, which is what 1.1 claimed and could not do. Where the panel did move, no change figure is published for that period anyway. This changes the daily digest, the monthly report, the quarterly research report and the momentum chart for past periods. The open-roles series in this file is NOT affected: it is derived from postings directly and has never read those columns, so base_day, base_employers and base_open_roles are unchanged.
• v1.1 2026-08-20 — Postings-opened and postings-closed counts restated. The daily opened figure counted every role first seen that day, which on the day an employer joined the panel meant their entire existing job board — coverage published as hiring. Both flows now count only roles that appeared at an employer we were already reading, matching the definition the reconstructed half of the same chart always used. Both, because the two are always read as a pair: correcting openings alone would have made every period in which the panel grew read as net contraction. Across any window in which the panel did not change these equal the old figures exactly, and opened minus closed still reconciles with the change in open roles; where it does not, no change figure is published for that period anyway. This changes the daily digest, the monthly report and the quarterly research report for past periods. The open-roles series in this file is NOT affected: it is derived from postings directly and never read those columns, so base_day, base_employers and base_open_roles are unchanged.
• v1.0 2026-08-19 — First publication of the like-for-like series. Open AI roles across the employers tracked continuously since the first observed day. Days with no complete panel poll are published empty and are never interpolated. Not seasonally adjusted: the series is too short to estimate a seasonal factor, and saying so is better than implying one.

What we cannot reconstruct

A published series should say not only how it is built but what about it can never be checked. Three things here cannot, and we would rather write them down than be found out by someone who works it out.

We keep only the roles that matched. A job title that does not look like an AI role is never stored, so we cannot re-run an older definition over older data — the roles it would have caught were never written down. That has a consequence worth stating plainly: if we tighten what counts as an AI role, the change arrives in the data looking like roles closing, and if we loosen it, like roles opening. Any such change is listed above, and it is the reason that list exists.

The core / AI-adjacent split is current, not historical. Each posting carries one label and it is rewritten every time we poll, so we cannot tell you how a role was classified last month — only how it is classified now.

Role families and locations are worked out when you ask, not when we collect. They are derived from the job title and the location string each time a page is built, so improving either changes every past figure as well as today's. It has happened: adding one role family moved about 62% of postings out of “Other”, including in a report we had already published. The daily counts do not have this problem — they are counted from the postings themselves — which is why the series we publish carries no role or location breakdown.