The first mistake in thinking about AI and jobs is to imagine that machines climb the labour market in order of difficulty. Simple work first. Complex work later. Manual work before professional work. Routine jobs before skilled ones.
That is not how the current wave of AI has moved. The surprise is that some difficult white-collar tasks became exposed earlier than many supposedly more routine physical tasks. Coding is one of the clearest examples. Driving a truck through weather, traffic, loading yards, broken signage, roadworks and human unpredictability is not obviously more intellectually demanding than writing software. But it is harder to turn into the kind of training problem that large language models can learn from.
This article is built mainly around one strand of analysis, not a universal prediction about every developer or every driver. The World Economic Forum’s 2023 white paper Jobs of Tomorrow: Large Language Models and Jobs, produced with Accenture, examined the likely impact of large language models on work. The important lesson is not that AI neatly replaces one occupation and leaves another alone. It is that exposure depends on the fit between a job’s tasks and the material AI systems can observe, imitate and produce.
That is why coding appears vulnerable in a way that feels backwards. It is not because software engineering is easy. It is because code is unusually available as data.
The wrong question is whether the work is hard
We often talk about automation as if difficulty were the main barrier. If a job is skilled, creative or well paid, it must be protected. If a job looks repetitive, it must be exposed. That older instinct came from a world where machines were best at standardised physical or clerical routines.
Large language models changed the sorting mechanism. They are strongest where work leaves behind large amounts of text-like material: documents, tickets, emails, transcripts, code repositories, examples, logs, answers and revisions. They do not need a job to be simple. They need the job’s outputs and intermediate steps to be visible enough to learn patterns from them.
Software has that visibility. Code is written in formal languages. It is stored in repositories. It comes with comments, documentation, tests, issue threads, pull requests and examples of how one version became another. Much of that material is public or semi-public, especially through open-source projects. That gives AI models a vast record of how programmers solve problems, name things, fix errors and assemble working systems.
Truck driving has data too, but it is a different kind of data. It is sensor data, road context, weather, maps, vehicle dynamics, logistics rules, safety obligations and real-world edge cases. It is expensive to collect, hard to label, and dangerous to test badly. The work happens in physical space, where a wrong answer can put people at risk. That does not make truck driving intellectually superior to coding. It makes it less available to a language model trained mostly on text and code.
Code became unusually legible to machines
The OpenAI paper Evaluating Large Language Models Trained on Code introduced Codex as a GPT model fine-tuned on publicly available code from GitHub. The production version powered GitHub Copilot. That detail is central to the current labour-market debate. Coders did not merely create software. They also created a public archive of software work.
For a model, code has another advantage. It is text, but it can also be checked. A paragraph can sound plausible while being wrong. Code can be run, tested, linted and compared against expected behaviour. That makes feedback loops easier to construct. A model can be trained or evaluated not only on whether its answer resembles code, but whether the program works under given conditions.
This helps explain why programming tasks became a natural target for AI assistants. A model can suggest a function, translate between languages, write a boilerplate component, explain an error, draft a test or refactor a small block. None of that is the whole job of a software engineer. But it touches enough of the visible surface of programming to matter.
By contrast, a truck driver does not leave behind a neat public trail of labelled decisions: here is the moment the driver noticed the van drifting, here is the slight brake pressure, here is the glance at the mirror, here is the judgement about whether the warehouse gate is wide enough, here is the informal call to a dispatcher, here is the decision not to trust the satnav. Some of that can be instrumented. Much of it cannot be collected as cheaply or safely as code.
Exposure is not the same as replacement
This is where the language needs discipline. AI exposure does not mean a job disappears. It means some tasks inside that job overlap with what a model can plausibly assist, accelerate or automate. The World Economic Forum’s framing is about the impact of large language models on jobs and the choices businesses, workers and policy-makers face. It is not a calendar for layoffs.
The OpenAI and University of Pennsylvania working paper GPTs are GPTs makes a similar distinction. The authors measured exposure as a proxy for potential economic impact, not as proof of labour replacement. They found that programming and writing skills were positively associated with exposure to LLMs, while manual routineness and robotics exposure showed negative correlations.
That is the twist. The jobs most exposed to LLMs are not necessarily the jobs people once imagined as easiest to automate. Many exposed roles are well paid, educated and computer-based. Their tasks are often complex, but they are performed through language, symbols and software interfaces. That makes them reachable by models whose native territory is language and code.
Driving is different. Autonomous vehicle systems are not just language models with wheels. They require perception, mapping, control, hardware, regulation, liability frameworks, fleet operations and a tolerance for rare but serious edge cases. Progress in autonomous trucking is real, but it is constrained by the road, not just by the quality of the next model release.
The training-data economy has a strange politics
The coding example also exposes a deeper power question. The work most easily learned from is often the work most completely recorded. Developers created open repositories, tutorials, Stack Overflow answers, documentation and issue histories because that made software culture faster and more collaborative. Those same records later became material for systems that can perform parts of software work.
This does not mean open source was a mistake. It does mean that data-rich professions may face a different kind of automation pressure. The more a field turns its practice into searchable examples, the easier it becomes for models to learn the surface patterns of that practice.
There is an irony here. Coders spent decades building tools, habits and platforms that made their work legible. Version control preserved every change. Public repositories made knowledge reusable. Q&A sites turned mistakes into indexed lessons. Documentation translated specialised work into text. That culture helped humans learn faster. It also gave machines something to learn from.
Truck drivers have no equivalent public archive of expert driving judgement. Their skill is embodied, local and situational. It is partly in the hands and eyes, partly in the vehicle, partly in the road, partly in the weather, partly in tacit knowledge of routes and depots. There are datasets for autonomous driving, but they are expensive and incomplete compared with the ordinary public abundance of code.
Why this matters for workers
For software workers, the lesson is not that coding is finished. That is too crude. The more plausible change is a shift in what employers value. If models can generate routine code, explain common errors and produce first drafts, the scarce human work moves toward problem framing, system design, judgement, review, security, product understanding, coordination and responsibility for consequences.
That shift can still be painful. Entry-level work often contains the tasks that tools can now imitate most easily. Junior developers learn by doing small fixes, writing tests, reading errors and turning clear requirements into code. If companies automate too much of that layer, they may weaken the training path that creates experienced engineers later.
For truck drivers, the exposure pattern is different. Automation may still reshape the occupation, especially on long highway routes or controlled logistics corridors. But the barrier is not only whether AI can “understand” driving. It is whether a whole physical and regulatory system can operate safely, economically and legally without the driver in the cab.
That is a higher deployment burden than asking a model to draft code inside an editor while a human reviews it. The software tool can be wrong, corrected and rerun. A heavy vehicle has much less tolerance for a bad guess.
The broader lesson is about data, not status
The coding-versus-trucking comparison is useful because it breaks a comfortable assumption. AI does not move through the economy by respecting status, pay or professional identity. It moves where tasks are digitised, recorded, repeatable enough to model, and connected to software channels where output can be delivered.
That makes some highly skilled workers more exposed than they expected. It also leaves some manual workers less exposed than old automation stories suggested, at least to language models. The line is not between smart work and simple work. It is between work that has become data and work that remains embedded in the physical world.
The World Economic Forum’s report is useful because it pushes the debate away from a single dramatic question: will AI take jobs? The better question is which parts of which jobs are visible to the machine, and why. Coding is visible because generations of developers made it so. Truck driving is harder to capture because the world does not present itself as a clean repository.
But that gap may not hold. Cameras are getting cheaper, sensors are spreading into vehicles and warehouses, and every delivery route, forklift movement and depot manoeuvre is slowly being logged somewhere. So what happens when the physical world starts producing the same dense, public trail of recorded behaviour that code has produced for decades? Does the current shape of AI exposure look like a permanent feature of the economy, or like an accident of which professions happened to document themselves first?
Maybe the safer question is not which jobs AI can read today, but which jobs are quietly becoming readable next — and whether the workers inside them know it yet.
