GPTs are GPTs: An Early Look at the Labor Market Impact Potential of Large Language Models

This OpenAI-led working paper asks which kinds of work large language models could affect, without predicting when or whether it happens. The unit is the task. O*NET, the US Department of Labor's occupational database, lists 1,016 occupations with 19,265 occupation-specific tasks and 2,087 broader "detailed work activities", such as "Study scripts to determine project requirements."

Each task gets one of three labels. E0: no meaningful time saving. E1: using a model like GPT-4 through a chat interface could cut the time to do the task by at least half at equal quality, meaning the recipient would not notice or care. E2: the model alone would not halve the time, but software built on top of it could, for example tools that read documents or generate images. Annotators familiar with model capabilities labeled activities and a sample of tasks, and GPT-4 labeled them with the same rubric. Occupations are scored by averaging their tasks, with core tasks counting double.

Three measures combine the labels. Alpha counts only E1. Beta counts E1 plus half of E2, reflecting that software has to be built. Zeta counts E1 and E2 fully. At the task level, alpha is about 15% and zeta 47% to 56%. Using beta, 80% of workers are in occupations with at least 10% of tasks exposed and 19% in occupations with at least half.

Exposure rises with income and with the preparation a job requires, peaking in jobs needing a bachelor's degree and staying high for advanced degrees. Programming and writing skills predict exposure; science and critical thinking skills predict lower exposure. The authors argue that LLMs look like a general-purpose technology, with effects that depend on complementary software and organizational change. They are explicit that exposure is not automation or job loss, that labels are subjective and from a narrow group, and that GPT-4 labeling is sensitive to prompt wording.

Find use cases at the task level, the way this paper does. Break a customer's workflow into tasks, ask for each whether a model alone could halve the time at the same quality, or whether it needs software around it. That gives a defensible list of candidates instead of "AI for the claims department".

The software layer is where most of the opportunity sits. Direct exposure was about 15% of tasks; with tools and integrations, up to roughly half. That gap is FDE work: retrieval over the customer's data, connectors to their systems, review interfaces and evaluation.

Quote the right number. "80% of workers", "19% of workers" and "47% to 56% of tasks" come from different measures and thresholds. In a customer conversation or a business case, say which one, and say it is technical exposure, not adoption or headcount.

Quality has to be defined by the recipient. The rubric counts a time saving only if the person receiving the output would not notice or care. That is a useful acceptance criterion for a pilot: define who receives the output and what they will check.

LLM labels need checking too. The authors used GPT-4 to label tasks and found agreement with humans around 80%, which is only modestly better than chance when most tasks are unexposed. When you use a model to classify a customer's process at scale, measure agreement against a human sample and correct for chance.