The Takeoff Is Jagged: What AI Automating Code Actually Tells You

Software engineering was the first kind of skilled knowledge work that AI automated at scale. Not customer support scripts, not data entry, not the low-status tasks everyone assumed would go first. It came for the six-figure job that requires years of training, the one people held up as proof that machines could never do the interesting parts. And it came fast.

The obvious lesson people draw from this is a countdown. If AI can write code today, then law is next, then medicine, then management, then everything, on roughly the same schedule with a lag of a few years. Coding was just the first domino. Watch it fall and you can read the timeline for your own job off the clock.

That reading is wrong, and getting it wrong will cost you. Coding did not go first because it previews everyone else’s timeline. It went first because code has a set of rare properties that most work does not have. What actually generalizes from the coding story is not the schedule. It is the pattern that decides the schedule.

Why code fell first

Start with the thing everyone notices and then keep going, because the interesting reason is the one people skip.

Code is text. A language model is a machine for predicting and generating sequences of tokens. Source code is exactly that: sequences of tokens with a grammar. There is no perception gap to cross, no sensor to build, no world to physically touch. The model’s native format and the job’s native format are the same thing. That lowers the barrier, but on its own it does not explain much. Legal briefs are text too. Marketing copy is text. Most of them have not been automated to anywhere near the same degree.

Code has abundant public training data. Decades of open source sit on GitHub. Millions of solved problems sit on Stack Overflow, each one a question paired with a verified answer and a discussion of why. Documentation, tutorials, bug reports, code review threads. Very few professions have externalized their entire working corpus into public, structured, machine-readable text the way programmers have. A surgeon’s judgment lives in their hands and their head. A programmer’s judgment has been getting typed into public repositories for twenty years.

That matters, but it still is not the deep reason. The deep reason is the third one, and it is the one that carries all the weight.

Code is cheaply and automatically verifiable. You can run it. You write a function, and a test suite tells you in milliseconds whether it does what it claims. A compiler tells you whether it is even valid before it runs. A type checker catches a whole class of mistakes without executing a line. When the program crashes, the stack trace points at the wound. The feedback is fast, it is objective, and crucially it does not require a human to sit there and grade every attempt.

“

You can tell whether code is right without asking a person. That single fact is why coding fell first, and it is the fact that most other jobs do not share.

”

This is what makes code special, and it is worth being precise about why. Verification is what turns a language model from a plausible-sounding guesser into something you can actually trust with a task. A model that generates code and a test suite that checks it form a loop. The model proposes, the tests dispose, and the model tries again on the ones that failed. The signal that says “wrong, here is how” is free and instant. You can run that loop a thousand times a day and never pay a human to judge a single iteration.

That same loop is what makes coding agents trainable in the first place. When you can score an output automatically, you can generate mountains of practice, reward the outputs that pass, and improve the model against a ground truth that never gets tired or inconsistent. Cheap verification is not just a nice property for the user. It is the fuel for the whole training and reliability flywheel. It is the same reason reliability in agents climbs one nine at a time: you can only grind toward reliable when you can measure failure automatically.

The trap of one data point

Here is where the countdown reasoning breaks. You have one dramatic example of AI automating a skilled profession, and you are drawing a curve through it. But you cannot fit a curve to a single point. Any line you draw is a story you brought with you, not a trend the data supports.

The countdown assumes coding is representative, an ordinary knowledge job that happened to go first. It is closer to the opposite. Coding is the extreme case, the profession that scores highest on exactly the property that makes automation work. Extrapolating everyone else’s timeline from the most automatable job on the board is like measuring the fastest sprinter in the world and concluding that humans can all run a hundred meters in under ten seconds. You did not sample the average. You sampled the outlier.

So the honest question is not “when does the wave reach my job.” It is “how much does my job actually resemble code on the dimension that mattered.” And that dimension was verification.

The real predictor: how cheap is the feedback

Here is the claim the whole piece is built to defend. The single best predictor of whether AI automates a task soon is not how hard the task is for a human, how prestigious it is, or how much it pays. It is how cheap and automatic the feedback signal is. How easily, and how objectively, can you tell whether the output was good, without a human grading it.

Run real jobs through that filter and the jagged shape appears immediately.

Fast, cheap, automatic feedback. Code that must pass tests. A chess or Go move, judged by a win. A protein structure prediction, checked against a crystallized ground truth. A math proof a checker can verify. A trading strategy scored by profit and loss. These are the domains where AI has moved fastest and most convincingly, and it is not a coincidence. They all share code’s defining feature: a machine can score the answer.

Slow, expensive, or human-judgment feedback. Whether a legal strategy was the right one, which you may only learn after a verdict years later, if ever. Whether a diagnosis was correct, which can take months and sometimes is never cleanly resolved. Whether a management decision was good, which is tangled up with a hundred other variables and a counterfactual you never get to run. Whether an ad campaign built the brand, whether a novel is good, whether a therapy session helped. In these domains the feedback is slow, contested, expensive to obtain, and often requires exactly the expert judgment you were hoping to automate. There is no test suite for a courtroom.

Notice that this cuts across the usual “cognitive versus physical” line and the “high skill versus low skill” line. Both of those are the wrong axis. Plenty of physical tasks have cheap verification: did the part come off the line within tolerance, yes or no. Plenty of prestigious cognitive tasks have terrible verification: was that the right acquisition. The axis that predicts the takeoff is the cost of the feedback loop, and almost nothing else you might reach for first.

What actually generalizes

So the thing to carry from the coding story into every other domain is not “you have three years.” It is a lens. Look at any task and ask: what is the loop that tells the machine it was wrong, and how much does one turn of that loop cost. If the answer is milliseconds and a script, that task is on the fast track whether it is coding or not. If the answer is months and a panel of experts, it is durably harder to automate, no matter how routine it looks from outside.

This reframes the whole anxiety. The question was never “is my field intellectual enough to be safe.” Intellectual difficulty was never the moat. The moat was always the absence of a cheap, objective grader.

“

What generalizes from coding is the mechanism, not the calendar. Cheap verification is the accelerant. Find it and you find the fast track.

”

What to do with this

This is not a piece about waiting to find out. The lens tells you where to push.

If you want to speed a task’s automation, build the verification. This is the counterintuitive move. If part of your work is genuinely repetitive and you would happily hand it off, the highest-leverage thing you can do is create the automatic grader for it. Define what “correct” means precisely enough that a machine can check it. The moment a task has a cheap objective test, it becomes trainable, delegable, and eventually automatable. Programmers accidentally did this to themselves over twenty years by writing tests and compilers. You can do it on purpose. A task with a crisp success check is a task an agent can own.

Where verification stays human, that is where you stay. The flip side is the more valuable career insight. In domains where the feedback is irreducibly slow, contested, and dependent on judgment, the human sits at the center of the loop for a long time. Not because AI cannot generate a plausible legal argument or a plausible diagnosis, it can, but because someone accountable has to decide whether the plausible thing is the right thing, and that judgment is the actual job. The work moves from producing the output to verifying it, which is why the bottleneck in software already moved from writing to review. Get very good at being the judgment in loops that machines cannot close on their own.

Stop reading one timeline off another. When you plan a career, a team, or a company around AI, do not import coding’s schedule wholesale. Score each task on its own verification cost. Some of what you do is code-like and will move fast. Some of it is courtroom-like and will not. Most jobs are a bundle of both, which is why “my job” is the wrong unit. The task is the unit. The bundle gets unpicked one task at a time, fastest where the grader is cheapest.

The honest middle

There are two lazy positions on this and the truth sits between them.

One says it changes everything by next quarter, because look, it already writes code. That position mistakes the outlier for the average and draws a vertical line through a single point.

The other says it is just fancy autocomplete and the professions are safe, because the demos are unreliable and the hype is exhausting. That position ignores that in every domain with a cheap grader, the systems are already past “toy” and compounding, one nine of reliability at a time.

The real shape is jagged. Fast and deep where verification is cheap. Slow and shallow where it is expensive. Not one wave with a fixed arrival time, but a tide that reaches different tasks at wildly different rates, sorted almost entirely by how easy it is to tell the machine it was wrong. Read the coding story for the mechanism, not the calendar, and you will predict the next decade far better than anyone holding a countdown.