After AI Takes Everything

Over the past month I’ve received three letters in a row from strangers — all software engineers I’ve never met. One was a frontend developer in infrastructure, another did data ops, the third was somewhere in between. The three letters look different, but they ask the same question. The first one asked me: “Do you think one day all of it will be handed over to AI? If so, do code reviews even still need humans?” My answer: soon. By the end of this year or next, the year after at the very latest. The second was more direct: “Is our future job going to be building AI and then letting it replace ourselves?” The third was the longest. The writer listed every reason he was embracing AI-assisted coding — fewer rewrites, less communication overhead, more output — and then admitted at the end: if things keep going like this, what happens to my own growth? He hadn’t figured that part out. These three questions are, fundamentally, the same question. On the surface it looks like an engineering question, or a career planning question, but underneath it is an existential question: once execution is fully taken over by machines, where does the human stand? Or more bluntly — once AI takes everything it can take, what is left for us? I gave fragmented answers in my replies, but I knew they weren’t enough. The question deserved a more complete answer, so I wrote this essay. It’s a shared question and one I’ve been turning over in my own mind lately. Writing my thoughts down may help others who are wrestling with the same thing. I. The Spinning Jenny The blue mountains cannot hold it back — the river still flows east. — Xin Qiji, Pusa Man · Inscribed on the Wall at Zaokou, Jiangxi A little over two hundred years ago in England, a spinning frame called the Spinning Jenny came into the world. One person could now do the work of several. Yarn got cheap, and the hand-spinners who had made their living with a pair of hands and an old wheel saw their livelihoods collapse in a matter of months. Later, some of them went out at night and smashed the machines.

History calls them the Luddites. People usually treat them as fools who hated technology, but that’s a misreading — what they wanted to smash was never the machine itself, but the position they suddenly occupied in front of it: a position that had become worthless overnight. They weren’t blind to the technology; on the contrary, they saw what was happening earlier than anyone. The day Meituan announced 30%–50% layoffs, a friend texted me asking what to do. I replied: we should not be the spinners replaced by the Jenny — we should be the operators who use the Jenny well. He may have remembered that line for a long time. Today I want to correct it. It was only half right. Because the next page of history reads like this: the skilled Jenny operators didn’t have it easy for long either. Faster machines were built, and the Jenny — along with all its skilled operators — was sent to the museum. Every machine is waiting for the next machine. “Learn to use the new tool” has never been an amnesty. It’s just a stay of execution. So the real question is not “do you know how to use AI.” People who know how to use it today do hold an advantage over those who don’t, but the half-life of that advantage is maybe a year or two — and at the top of the field, possibly only one or two months. The pressure from each new model generation is mounting; the window for exploration and adaptation gets shorter every time. Every new model release brings another paradigm shift, and the workflow you painstakingly built, the prompting tricks you collected, the engineering scaffolding you accumulated — any of it can become a Spinning Jenny overnight. My only method for dealing with this is what I call end-state thinking: don’t spend yourself on intermediate-state problems. Think and act with the endpoint as the premise. An example. A while back I had a serious argument with a few peers about a question: as AI writes more and more of the code, do engineers still need to understand it line by line? There are plenty of partial answers — better documentation, better visualization, mandatory code walkthroughs. But from the end-state view, this isn’t the core question at all.

Once intent can be translated directly and reliably into a working system, “humans reading the intermediate artifact line by line” loses its meaning — just as today, no one asks engineers to read every line of the assembly the compiler produces. Getting stuck on a question that is destined to disappear is the most invisible kind of waste this era inflicts on us. What does the end-state look like? My take is simple — a single line: PRD is Code. Or in more general terms: intent is implementation. A sufficiently clear expression of intent becomes a runnable system directly. All the redundant connective tissue in between — scheduling, integration, cross-team review, back-and-forth translation — disappears. To my eye, this isn’t ten years away. It’s well within reach this year. The Fable 5 release a few days ago made the point: anyone who has actually used it knows the gap to Opus 4.8 — it’s confident and powerful enough that I momentarily wondered whether the questions I was asking it were just dumb. This gives us the first corollary of end-state thinking — cold but honest: every step that sits between intent and implementation will, by default, disappear. So the remaining question is: where does the human stand? II. The Bottleneck Has Moved to Us Aim at the highest, you reach the middle. Aim at the middle, you fall to the low. — Li Shimin, The Emperor’s Plan Let me start with what’s been happening to me. Over the past year, every piece of my work that I could hand off, I handed off to AI, piece by piece. The design doc — it wrote. The code — it wrote. The first drafts of documents and review comments — it wrote. What I can now run in parallel in one evening would have taken a full quarter two years ago. By rights I should be idle, but the truth is the opposite — I am busier than I have ever been. The content of “busy” has simply changed: I almost never produce anything with my own hands now. I spend the whole day reviewing what it produces. This is the embryo of the end-state workflow. In it, there are only two things left for humans to do: review the design, and verify the result. Notice what these two have in common: neither of them is production.

They are gatekeeping. Ninety years ago in Modern Times, Chaplin stood at the conveyor belt tightening bolts, fell behind the belt’s pace, and got pulled into the gears. That image became iconic because it captured the industrial-era human condition exactly: machines set the rhythm, humans chase the machines. Ninety years later, the belt is moving in a new direction — now the machine produces and the human inspects. AI’s production speed is effectively unlimited; the cost of starting a new task is approaching zero. But the cost of verifying its output hasn’t dropped a cent, because verification requires a human in the loop. So for the first time in human history, the production bottleneck has shifted, wholesale, from the machine to the human. This shift brings a quiet, lethal corollary: you can run 6 or 7 sessions concurrently, dancing across different worktrees, frantically switching context, multitasking with elegance. But on this new assembly line, you’ll find that there is only one way to push your throughput further — lower your own standards. Read one fewer line of code. Skip one step of reasoning. Don’t ask one of the “whys.” When the little voice in your head says “eh, probably fine,” nod and let it pass. Project this forward and you can already predict the next few years: nearly every collapse in engineering quality will not be because one specific person was lazy — it will be structural. When production is infinitely fast, the verification standard becomes the only compressible variable in the system, and every incentive in sight pushes you to compress it: the boss’s expectations, your peers’ speed, the performance-review whip — they’re all telling you to let go. But think clearly about what letting go means. The reason you have not yet been optimized away from the verification step is precisely that your standard is higher than the machine’s. A gatekeeper who keeps lowering the standard is personally building the case for their own replaceability. My stance on this has never moved: slower is fine. The standard, not one inch. III. The Disappearing Moat Do not rely on the enemy not coming. Rely on having the means to receive him. — Sun Tzu, The Nine Variations But there’s a question one layer earlier: not everyone gets to retreat safely to the gatekeeping role. Some jobs will be submerged earlier than others — they won’t even get the chance to retreat.