Part one of a three-part series on the actual work inside artificial intelligence. Part two covers what philosophers do in AI; part three, the philosophy engineers do without calling it that. The public conversation about artificial intelligence and work has a flaw at its root: it talks about “AI companies” as if they were a single place where everyone does more or less the same thing. Every other simplification is built on top of that one. Programmers are about to disappear, the humanities are back in fashion, labs are hiring philosophers while universities stop training them. Each of those sentences may hold some truth, but none of them can be assessed until someone opens the side door and looks at what is going on inside the shed. What you see when you open it is that there is not one shed but two, with different logics of work, different profiles and different risks. One is a factory. The other is a research lab. Confusing them produces almost every misunderstanding about who is needed, who is redundant and what a university ought to teach.

The factory

A large language model is, first of all, an industrial product. Its manufacture follows a recognizable chain, and every link in it is a trade. The first link is data. Before training, someone has to gather, deduplicate, filter and clean quantities of text, code and images measured in trillions of words. Someone has to document where each item came from, what license it carries, what content must be excluded and what biases it brings along. This is data engineering at a scale few industries know, and it is less visible than it is decisive: much of a model’s quality is settled here, long before any algorithm comes into play. The second is pretraining. A frontier model is trained for weeks or months on clusters of thousands of graphics processors that work as a single machine. The everyday problem in this work is not theoretical. In a cluster that size something breaks every day: a processor, a network link, a disk. The craft consists in making the training run survive those failures, making sure checkpoints allow it to resume without losing weeks of compute, and making every machine hour earn what it costs. It looks more like running a power grid than writing an application. The third is post-training. The model that comes out of pretraining predicts text, but it does not yet know how to behave like an assistant. For that, it is fine-tuned on human preferences or on those of other models, reward models are trained, and labeling operations are organized that often involve thousands of contractors. This is the stage where the system’s behavior is shaped most directly, which is why it is also where normative decisions, about what it should and should not do, are turned into data. The fourth is evaluation. Someone has to measure what the model can do, where it fails, what dangerous capabilities it might have and how it reacts to someone trying to break it. Test batteries, adversarial testing and risk evaluations form a discipline of their own, with an underlying epistemological problem I return to in part three: measuring well is much harder than it looks. The fifth is inference, that is, serving the model to millions of users with acceptable latency and at a cost that does not sink the company. Quantization, batching, caching, routing, monitoring, safety classifiers that filter inputs and outputs, incident response. And after that, integration into products: document search, agents that use tools, interfaces, information security.