Execution got cheap this year.
The models write the parser, draft the config, generate the test suite, and stand up the scaffolding in the time it used to take to describe the problem. A junior with a microphone and a good prompt can produce, in an afternoon, working code that would have taken a week to write by hand. The means of production collapsed in cost, and most of the conversation since has been about what that gives us. Faster teams. Smaller teams. More shipped per person.
That conversation has the wrong subject. The interesting question is not what cheap execution gives us. It is what it quietly takes away, and from whom.
I have spent about thirty years in this. I climbed the rungs that are now being compressed, from the bottom, and I have watched more than one generation of tools arrive to do work people believed defined the profession. So this is not a lament for a lost craft. It is an argument about what the cheap part was hiding, and what happens to the people who come next if we do not notice it in time.
Because the thing that got cheap was never the hard part.
Create, specify, repair
Break the work into three capabilities and it gets clearer.
The first is creation: producing the artifact from nothing. Writing the parser. This is the part the models have largely absorbed. Not perfectly, not for everything, but for a widening range of ordinary work, the model produces a first draft faster and often better than a person starting from a blank file.
The second is specification: knowing what artifact is actually needed. Which parser, handling which inputs, failing how, under what constraints. The model can participate in this, sometimes well. It may even challenge the request. What it cannot be is the only source of judgment about whether the request was right in the first place.
The third is repair: recognizing that what came back is wrong, understanding why, and fixing it. The model can participate here too, and often produces a good correction. What it cannot reliably supply is the independent judgment that the repair actually resolves the underlying problem, rather than a plausible one it generated with the same confidence it brought to the original.
Creation was the visible labor. It was what filled the day, what the job appeared to be. Specification and repair were the judgment underneath it. And here is the part worth sitting with: specification and repair are made of judgment that was historically acquired through creation. You learned what a good parser required by writing bad ones. You learned to see the break by having built the thing that broke.
Which means the capability the model absorbed is the same capability that used to build the judgment now required to direct and repair it.
The paradox
State it plainly. AI raises the value of expert judgment and, at the same time, compresses the path that produced it.
The judgment is more valuable because execution is now abundant and specification and repair are the scarce inputs that make abundant execution worth anything. And the path is compressed because that judgment was built by doing the execution work that the model now does instead.
This is not a story about value migrating up a stack. That story is comfortable, and it is told constantly: the mechanical work moves to the machine, the humans move to higher-value work, everyone is more productive. It assumes the higher-value work is reachable from where the junior now stands. It is not obviously reachable, because the rungs that used to lead there were the mechanical work.
The senior developer reading this has the judgment. The question is where the next one comes from, when the work that built the senior's judgment is the work we just handed to the model.
The load-bearing skill
Here is where it gets concrete, because the abstraction has a specific shape and the shape is testable.
The skill that carries all of this is the ability to read code. Not to write it from scratch, necessarily. To read it. To look at code you did not produce and understand what it does. To trace an output back to the line that produced it. To find the break point. To look at a function and say, this is right, this is wrong, this is where it starts to go wrong.
That skill does not stand on its own. It rests on a foundation: an understanding of how code actually works underneath. Regular expressions. Shell scripts. Control flow. What happens behind the syntax. You may write a regular expression by hand twice a year. But if you never understood how one works, you cannot read the ones the model writes, and you cannot tell when it wrote one that looks right and matches the wrong thing.
The foundation is what transfers. Understand how code works in one language and you can begin to read another you have never seen, because you are no longer reading syntax, you are reading behavior. Miss the foundation and every future artifact is opaque. You can produce output. You cannot read it. You can build that foundation later, but only by going back and deliberately learning what the old apprenticeship used to force you to learn along the way, against every incentive to keep shipping without it.
This is the whole game. Even if you never write another line, even if the model does all the creation forever, you have to be able to look at what it produced and know what it does and where it fails. Put unfamiliar code in front of someone and ask what it will do. That is not a trivia question. It is a test of the one competency that survives everything else being automated: can you read code you did not write and know what it does.
The trap in the loop
The new apprenticeship is supposed to be the loop. The junior specifies what they need, the model produces it, the junior evaluates the result, finds what is wrong, repairs it, and understands what the correction changed. Run properly, that loop could build judgment, possibly faster than writing a thousand parsers by hand ever did.
Run improperly, it builds nothing, and it is very easy to run improperly.
A kid can now build a game by speaking requests to a model, no typing required. The model produces something. It breaks. They say, this is not working, fix it. The model produces something else. It works, or it works enough. At no point in that loop did anyone read what the model wrote, understand why it broke, or learn anything transferable about how the thing works. The shape of specify, evaluate, repair was there. A request went out, a failure was observed, a repair was requested. The comprehension step, the step that turns the loop into transferable judgment, was hollow.
That is the trap. The old apprenticeship forced comprehension, because you could not produce the artifact without understanding it. You had to know how the parser worked to write the parser. The foundation got built as a byproduct of having no other way to get the output.
The new tools remove that. They let you produce the output without the understanding. Which means the understanding no longer builds itself. It has to be built on purpose and deliberately required, because the workflow no longer guarantees it will happen. And a loop that produces working code while skipping comprehension does not just fail to build judgment. It produces someone who can summon plausible artifacts and cannot judge them, cannot repair them beyond asking for another try, and has laid none of the base that reading later would require.
Whether the loop builds a competent engineer or a fluent requester is not a property of the loop. It is a decision about how the loop is run.
The human in the loop, correctly understood
The phrase gets used constantly and almost always means the wrong thing. Keep a human in the loop, it says, as though the human's job is to approve the consequential output. A person signs off before the model acts. That is oversight, and it is fine as far as it goes, but it is not the load-bearing role.
The load-bearing role is that the human supplies the competence the system cannot supply itself. At the level of the work, the human provides the specification the workflow cannot safely assume the model has framed correctly, and the independent diagnosis required to establish whether the output is actually right. Because a model will defend a wrong answer with the same fluency it brings to a correct one, and cannot be its own check on which it produced. The human is not the approver. The human is the part of the system that must be able to tell.
The same structure holds one level up, at the level of the profession. Automation used to guarantee that routine work would teach judgment, because routine work could not be done without it. It no longer does. So the senior practitioner becomes the part of the system that supplies what the automated path no longer produces: the deliberate building of comprehension in the person who would otherwise never build it.
It is a choice, and here is who makes it
None of this is what the technology does to us. It is what we decide to do with it. The model compresses the path. Whether the path closes is a set of decisions made by people, and calling the outcome inevitable is how those people avoid owning the decision they are actually making.
Blaming the model is the lazy version. It is the robots-took-the-jobs alibi, comfortable because it locates the cause in a machine that cannot be held responsible and lets the responsible parties off. The model did not decide whether organizations eliminate junior positions, accept output nobody can read, or stop teaching the foundations. People decided that, at three control points, each one a reasonable choice with a cost that does not show up until later.
The first control point is who gets an apprenticeship at all. A hiring manager under real budget pressure looks at a model that can perform a large share of junior-level execution work and concludes the junior hire is no longer necessary. It is a defensible read of this quarter. Later, the same organization cannot find mid-level engineers and describes it as a talent shortage, as though the talent evaporated on its own. It did not. The entry point where that talent used to form was closed, deliberately, by people now surprised at the consequence. You cannot remove the rung that builds the skill and then treat the scarcity of the skill as a market condition you had no part in.
The second control point is what gets shipped. A team lead with a real deadline accepts a junior's model-generated output because it passes the tests and shipping it is faster than sitting with the junior to check whether they can read what they are shipping. Also a defensible read of this quarter. The cost arrives later, when the team is staffed with people who can produce working artifacts and cannot debug anything the model did not write, because comprehension was never once required of them and so was never built.
The third control point is how people are taught. A senior, genuinely trying to do right by the juniors, takes the comfort of a familiar line: the model removes the mechanical work, so now the juniors can focus on the interesting, higher-level problems. It sounds like a gift. It skips a question. The mechanical work is where the senior's own comprehension was built. If the model does it instead, what builds the junior's? The line is comfortable precisely for the person who already has the foundation, because for them the mechanical work really is unnecessary now. They have forgotten that it was never the work that mattered. It was what the work built.
Each of these is a locally rational choice. None of them is villainy. That is exactly why it is a design decision and not a moral failing, and exactly why the outcome is not inevitable. The path stays healthy only if all three are treated as control points. Weakness at any one of them makes the apprenticeship narrower, more accidental, and easier to lose, and which happens is decided by people who could decide otherwise.
The vantage
I said at the start that I climbed the rungs now being compressed. Here is why that history matters for the argument rather than just the credentials.
Every time a tool arrived that was supposed to end the work, the work reorganized. The field survived by moving the judgment up a level and building new ways for people to learn it. This transition is faster than the ones before it, and the compression is sharper, but the shape is one I have seen resolve before, and it resolved because people made it resolve. Not because the technology was kind.
The dismal outcome is available. It is just not required. The difference between the two is whether the people at the three control points do the harder thing, and the harder thing is real: it costs a quarter's velocity, a headcount that does not obviously pay for itself yet, an hour spent making a junior explain what the model wrote instead of shipping it. The comfortable choice and the correct choice diverge, and the correct one is not free.
The carpenter
Picture the trade updated.
The machine manufactures the materials now. It drafts the frame. It is starting to drive the nails. The carpenter's hands are freed from most of what used to fill the day.
And the carpenter is still the one who knows whether the structure belongs on this ground, which walls carry load, whether the frame has gone out of square, and whether the blueprint itself is wrong. The machine can help reason about those things, but it cannot safely be the only judge of them. It builds what it is told, confidently, including when what it is told is a mistake.
Seeing that the frame is out of square is not a separate magic. It rests on knowing how frames work. Load paths. Joints. What square means and what throws it off. The carpenter learned all of that by building, because there was no other way to learn it. Now the machine builds. So the apprentice has to learn to read the frame some other way, deliberately, as its own discipline, or the trade ends with a generation that can ask for a house and cannot tell when the house is built wrong.
The nails were never the point. Seeing that the frame is out of square was the point. And that sight rests on knowing how frames are built, which we now have to teach on purpose, because the building no longer teaches it for free.