After Burying My Talent in Yesterday: How Developers Become AI Mecha Pilots
An evidence-backed reading of DeepSeek engineer Liu Shengyu's essay on hand-written kernels, AI agents and the engineering judgment developers will need next.
On this page
On September 14, Liu Shengyu, a machine-learning systems engineer at DeepSeek, published an essay titled I Had to Bury My Talent in Yesterday. It was quickly read as a warning about programmers losing their jobs. In a later clarification, he made the center of the essay clearer: he was saying goodbye to the pleasure of writing, tuning and optimizing kernels by hand while learning to work with AI agents. That distinction is where the useful conversation begins.
The sharpest part is not the fear of unemployment
The public version of this story is easy to summarize. A DeepSeek engineer wrote the main Attention operator for V4.1, then predicted that AI-written operators might catch up with him — or even surpass him — within six to twelve months. It sounds like a top engineer announcing that his own profession is over.
That summary is not completely wrong, but it is too small. In his clarification, Liu said the original purpose was to say goodbye to the period when he wrote and optimized operators by hand. The loss is not only a paycheck question. It is the loss of a way of concentrating, a way of enjoying precise work and a way of feeling that every variable name and instruction belongs to you.
That is why the essay travels beyond GPU engineers. Almost every developer has a version of hand-written kernels, even if it is a React component, a SQL query, a deployment script or a carefully designed API. We do not only worry that a tool can do the task. We worry that it may take away the part of the task we loved.
Section sources: Huxiu — Liu Shengyu's clarification · EET China — analysis of Liu Shengyu's essay
Hand-written kernels were a craft, not just an implementation detail
An operator is a small unit of computation — here, a highly optimized kernel — but the work around it is anything but small. You read the hardware, reason about memory movement, inspect instruction stalls, test a schedule and keep shaving away whatever still feels wasteful. The final code may be short. The accumulated judgment behind it is not.
Public coverage of the essay reports that Liu wrote the main Attention operator for V4.1 himself. A footnote in the original narrows that description to an MQA Attention path with a head dimension of 512. That detail matters because it keeps the story technical instead of turning one contribution into a vague claim about an entire model.
The hand-knitted sweater metaphor works because it includes the rhythm. A machine can make the sweater faster and just as well, but it cannot give the craftsperson the same quiet afternoon. The uncomfortable question is not whether the machine is useful. It is whether rising efficiency leaves any room for the old way of paying attention.
Section sources: Reddit — transcript of Liu Shengyu's essay · EET China — analysis of Liu Shengyu's essay
A mecha pilot is not someone who is simply better at pressing Tab
The phrase mecha pilot sounds cool until you look at the job. The pilot does not manually turn every gear. The pilot decides where the machine should go, what it is allowed to touch, how to read the instruments and when to eject a bad plan.
Tools such as Claude Code, Codex, Cursor and Windsurf can read a repository, change files, run commands and return a patch. A DSH-style harness can make that loop more repeatable. The human role moves up the stack, but it does not disappear. Someone still has to define the boundary, choose the evidence and notice when a locally elegant patch damages the system around it.
| Work stage | What an agent can accelerate | What remains the human's responsibility |
|---|---|---|
| Explore | Read docs, map files and generate candidate approaches | The question, constraints and success criteria |
| Build | Draft code, commands, tests and repetitive edits | The interface, data assumptions and allowed scope |
| Verify | Run checks, compare outputs and identify likely failures | Whether the evidence is sufficient to accept the change |
| Release | Prepare notes, migrations and a reversible plan | Credentials, approval, rollback and production risk |
AI can industrialize bad engineering too
The essay's most practical warning is not that AI occasionally writes buggy code. Every tool does that. The warning is that a person with weak engineering habits can now produce more code, more quickly, and spread the missing judgment across a much larger system.
Liu worries about students using AI to complete practical labs without learning how to organize code, design for future requirements or understand the whole path from software to hardware. The same problem appears in production repositories. A polished function can still sit inside a broken permission boundary, an untestable data flow or a deployment nobody can roll back.
This is the part that deserves a slower reading. The scarce skill is not typing speed. It is seeing the boundary around the task before the agent starts working.
- Ask for a plan and the touched files before asking for a large patch.
- Make the agent state assumptions, unknowns and failure modes in plain language.
- Run the repository's real tests and inspect the diff instead of accepting a confident summary.
- Keep changes small enough to revert when the output is locally correct but globally wrong.
Section sources: Reddit — transcript of Liu Shengyu's essay · Huxiu — Liu Shengyu's clarification
So how do we stay steady in the cockpit
I do not think the answer is to stop writing code, nor to hand every judgment to an agent. The more useful middle ground is harder: keep enough technical depth to challenge the machine while using it to explore more options than one person could ever hand-write.
That changes how we practice. Read the generated patch. Reproduce the failure. Learn the subsystem the agent is touching. Write the acceptance check before the prompt turns into a pile of wishes. These habits may slow down the first few tasks, but they save time once the repository becomes difficult.
| Before the task | During the task | After the task |
|---|---|---|
| Write the boundary, acceptance check and rollback condition | Give the agent only the context and permissions it needs | Run tests, review the diff and record what remains uncertain |
| Choose the smallest useful unit of work | Stop when the same failure repeats instead of adding more prompts | Keep a human decision for security and production changes |
Burying yesterday does not mean throwing yesterday away
The follow-up is what keeps this story from becoming a simple replacement narrative. Liu said he would continue writing operators while bringing AI agents into that work. The old craft is not suddenly worthless. It becomes a reference point, a source of taste and sometimes a form of practice rather than the only production path.
That, to me, is what a mecha pilot is. Not somebody who forgot how the gears work, and not somebody who worships the gears. Someone who knows enough about the machine to take responsibility for where it goes.
Yesterday's rhythm is worth remembering. Tomorrow's cockpit still needs people who can hear when the engine sounds wrong.
In your recent work, which part did an AI agent take over first, and which part do you still refuse to delegate?
Section sources: Huxiu — Liu Shengyu's clarification
Huxiu — Liu Shengyu's clarification · EET China — analysis of Liu Shengyu's essay · Reddit — transcript of Liu Shengyu's essay