A red jobs map. What does AI actually change?

You open a labor-market map. Rectangles fill the screen. Some are large; some are strongly colored. An immediate thought is that especially many jobs will disappear there. But the color would have to measure something else for that conclusion.

Andrej Karpathy’s US Job Market Visualizer shows 342 US occupational categories. Area represents employment in the dataset. Color represents the chosen layer: for example pay, employment outlook or “Digital AI Exposure.” You can recolor the same area without a single job appearing or disappearing. The map explores data and estimates; it does not announce layoffs.

The tool processes occupational descriptions and structured data from the US Bureau of Labor Statistics, or BLS. Its Occupational Outlook Handbook contains tasks, education requirements, pay and employment outlooks. BLS occupational profiles. This provides a US context; it is not a direct measurement of your company or another country’s labor market.

For the additional AI layer, a language model receives an occupational description and a scoring instruction. It rates the expected change from digital AI on a 0–10 scale and returns a short rationale. The pipeline combines that rating with the BLS data; the browser draws the rectangles. This makes the map easy to explore. The added score remains a model estimate. Data pipeline, scoring instruction and code.

A 9/10 score on this scale means neither “90% of positions will disappear” nor “there is a 90% chance this occupation will vanish.” The score asks how strongly digital AI could reshape the occupation. Its code embeds assumptions: work done on a computer receives high expected exposure. Those assumptions help determine the color. Scoring rubric.

Karpathy explicitly describes the scores as rough estimates. Demand for additional services, regulatory limits and preferences for human workers are not modeled. Map explanation. The useful next question is: Which parts of the work change — and what happens to the resulting capacity?

Take our own example: a customer writes that a parcel arrived damaged. A support worker reads the order history, checks the refund policy, composes a reply and decides which resolution is permitted in this case. Then she documents it. “Customer service” is an occupational label; here we can see the work inside it.

An AI tool could receive the order history and the applicable policy. It summarizes the case, suggests a reply and identifies the relevant policy passage. The initial output is a reviewable draft. Actually issuing a refund would be a separate action requiring different permissions. Missing order information or a policy that does not apply can leave a fluent reply wrong.

We might make reading and drafting easier while introducing more checking. Difficult exceptions, conversations with upset customers and responsibility do not automatically disappear because a paragraph is written faster. Which steps can be automated in a particular organization needs checking against its actual workflow.

Make an assumed example calculation, not a measurement: a team handles 200 cases per week. Each takes 20 minutes of human work on average, including checking and documentation. That is 200 × 20 = 4,000 minutes, about 66.7 hours.

Suppose a changed workflow brings the total to 10 minutes per equally well resolved case. With the same 200 cases, it requires 2,000 minutes, about 33.3 hours. That creates 33.3 hours of calculated capacity. Whether the company uses it to handle more cases, reduce a backlog, improve advice or change staffing is not contained in the multiplication.

A second company now receives 400 cases. At the same 10 minutes each, it needs 400 × 10 = 4,000 minutes. Time per case has halved; total work is the same again. Headcount cannot be inferred from this alone. The assumed reduction to 10 minutes must also be measured first: additional investigation and review count towards it.

Choose a frequent, clearly bounded assignment. Write down what goes in, what work happens and how you recognize a good result. For the support example: approved order data and current policies go in; a summary and reply draft come out; a correct resolution and correct policy application are the checks.

Compare similar cases with and without the tool. Measure total human time per successfully resolved case, including corrections. Track errors, unresolved exceptions and quality separately. A faster draft with more unnoticed incorrect refunds would not establish success. Then examine demand: does case volume stay the same? Are other assignments waiting? Does additional demand appear? This is a proposal for a local experiment, not a finding from Karpathy’s map.

The map is a useful invitation to examine occupations more closely. Its most useful effect is a change in perspective: from a large label such as “software development” or “customer service” to concrete tasks, data, outputs and decisions.

When you see the next red rectangle, ask: What can the tool actually change? How will we check it? Who decides what the freed capacity is used for? You have learned more than an apparent percentage for your job. You have a way to investigate changes to your work yourself.

Sources checked on 13 October 2026. The map describes US data and a particular scoring instruction; this article’s examples and calculations explicitly use our own assumptions.