From Craftsman to Supervisor


A split scene showing the same software developer in two roles: on the left, leaning forward and writing code directly at a laptop in a warm, personal workspace; on the right, leaning back in a cool office and supervising an AI agent orchestration dashboard with multiple agents assigned tasks, progress indicators, generated code, and a review queue.

Nolan Lawson is a core maintainer of PouchDB, a widely used open-source JavaScript database, and has worked as an engineer at Microsoft, Salesforce, and Squarespace over a career spent writing production software. In February 2026 he wrote a post called “We mourn our craft” that opens like this: “I didn’t ask for this and neither did you. I didn’t ask for a robot to consume every blog post and piece of code I ever wrote and parrot it back so that some hack could make money off of it. I didn’t ask for the role of a programmer to be reduced to that of a glorified TSA agent, reviewing code to make sure the AI didn’t smuggle something dangerous into production.”

That last image is the whole piece in one sentence. A TSA agent doesn’t build anything. A TSA agent inspects what other people bring through the line, watching for what shouldn’t be there. Lawson is describing his own job changing shape underneath him: from a person who produces software to a person who watches software get produced and checks it for danger. He isn’t alone in feeling it, and he isn’t hedging about why it’s happening. “The worst fact about these tools is that they work,” he writes. “They can write code better than you or I can, and if you don’t believe me, wait six months.” He goes further than describing the shift. He accepts it as final: “I don’t celebrate the new world, but I also don’t resist it. The sun rises, the sun sets, I orbit helplessly around it, and my protests can’t stop it.”

That’s worth taking seriously on its own terms before arguing with it, because the feeling underneath it is real and it isn’t confined to one writer. What’s changing for developers who hand their work to an AI agent isn’t primarily about output quality or job security, the two things most coverage of AI coding tools actually measures. It’s about whether the person doing the work still recognizes it as theirs. Writing code used to mean holding a problem in your head, shaping a solution by hand, and testing it against reality until it held. Now, for a fast-growing share of the profession, it means describing a problem to an agent, waiting, and inspecting what comes back. The verbs changed. Producing became directing. Building became reviewing.

That separation between a worker and the process and product of their own labor has a name older than software: alienation. It’s usually associated with assembly lines, not laptops, and for good reason. It describes what happened when craftsmen who once built a whole object by hand were reorganized into workers who performed one repetitive step in a process they no longer controlled or fully understood. What’s unusual about the version happening in software right now isn’t the mechanism. It’s the pace, and the fact that the people living through it are narrating it themselves, in real time, on their own blogs, while it’s still happening to them.

There is an obvious objection. Programming has always moved toward higher levels of abstraction. Most developers do not mourn the loss of hand-written machine code, and a compiler does an enormous amount of work the programmer never directly performs. But abstraction and alienation are not the same thing. A compiler remains an instrument in a process the programmer authors. An agent can receive an objective, choose an implementation, generate the code, revise it, and return a finished artifact whose construction the human never participated in. The programmer may still be responsible for the result, but responsibility and authorship are no longer necessarily the same thing.

That is why Lawson’s grief matters even if his forecast about the tools turns out to be right. Productivity and alienation are not opposites. A process can produce more while leaving the worker less connected to what is produced. The important question is not simply whether AI can generate code faster. It is what kind of work remains for the human when it does.

Lawson’s grief and Lawson’s fatalism are still two different claims, and only one of them is established. “The worst fact about these tools is that they work” treats AI code quality and productivity as settled questions. They aren’t. METR, an independent AI research organization, ran a randomized controlled trial of experienced open-source developers using AI coding tools on real tasks in their own repositories. The developers believed the tools were making them faster. The study measured them and found they were 19% slower. A separate 2026 survey by the code-quality firm Sonar found that 96% of developers don’t fully trust that AI-generated code is correct, and only 48% always verify it before committing. Those findings do not prove AI coding tools are ineffective. They do show that “they simply work” is not yet the settled empirical fact Lawson treats it as.

If the premise is shakier than Lawson allows, then “my protests can’t stop it” isn’t wisdom. It’s premature surrender to an argument that hasn’t actually won.

It also isn’t the only way to experience the identical mechanism. In March 2026, Andrej Karpathy, a founding member of OpenAI and former director of AI at Tesla, told the podcast No Priors that he hadn’t typed a single line of code since December. Instead he runs up to twenty coding agents in parallel, assigning work and reviewing what comes back, “directing them like a team lead.” He calls his own condition a “state of AI psychosis,” and describes it almost fondly: “code’s not even the right verb anymore,” he said, adding that he now has “to express my will to my agents for 16 hours a day.” He frames the change as a “phase shift,” a flip rather than a gradual slide, which is close to what Lawson is describing too.

Neither man is wrong about the mechanism. Writing code and directing agents that write code really are becoming different jobs. What’s different is how each of them experiences losing the first one. For Karpathy it reads as something close to euphoric. For Lawson it reads as grief. The mechanism is identical. The valence is opposite. That gap is worth explaining, and the explanation isn’t the technology.

It’s power. Karpathy chose this shift, sets his own direction, and answers to no roadmap but his own. Most working developers don’t have that. Lawson says as much himself, more plainly than any outside critique could put it: junior engineers are “wearing bazooka-powered jetpacks” while a senior who abstains is “still riding around on a fixie bike,” and a boss will eventually start “asking why you’re getting paid twice your zoomer colleagues’ salary to produce a tenth of the code.” His conclusion: “if you have a mortgage and a car payment and a family you love, you’re going to make your decision.” That’s not a description of a free choice. It’s economic compulsion masquerading as technological inevitability. This publication has covered the mechanics of that pressure in more detail elsewhere: companies raising output quotas to a level unreachable without AI assistance, then holding the human responsible for whatever the AI got wrong. Karpathy’s psychosis is optional. Lawson’s mourning isn’t, and neither is the mourning of the developers with less standing than either of them to simply decide otherwise.

The shift is also becoming harder to reverse once a workplace reorganizes itself around it. In February 2026, METR tried to repeat its own study and couldn’t because developers were no longer willing to work without AI assistance, even for the length of a research study. Separately, engineers surveyed by the developer research group Evil Martians reported an average burnout score of 7.4 out of 10, with “pressure to do more because of AI” identified as a burnout factor that didn’t exist in comparable surveys two years earlier. The extra work of prompting, checking, correcting, and re-explaining doesn’t register as work from the outside. It just makes the engineer look faster while carrying a heavier, uncredited load. Distrust of the output can rise at the same time the ability to work without the tool falls. That is not evidence of a simple productivity story. It is evidence that the surrounding system is changing too.

Lawson isn’t the only one describing what is being lost. Peter Rukavina, a Prince Edward Island writer and printer who spent 15 years as a freelance programmer and designer before running his own web development company, Reinvented Inc., from 1995 to 2023, read Lawson’s post and answered it directly on his own blog. “I wrote millions of lines of code, from scratch,” Rukavina writes. “I know the power, and the frustration, oh the frustration, of code, test, iterate, test, iterate, test. It’s how I learned my craft, it’s how I developed an intimate relationship with the machine.” He goes on: “Like Lawson, I will miss the ‘feeling of holding code in our hands,’ both as a trade and as a sort of spiritual practice.”

That phrase, “an intimate relationship with the machine,” gets closer to the issue than arguments about whether a benchmark moved ten or twenty percent. The loss being described is not simply that the programmer now uses a more powerful tool. It is that the act through which expertise, judgment, and authorship were expressed is being moved somewhere else. The engineer remains accountable for the artifact while becoming less involved in its construction.

Lawson’s own best writing is the craft passage, and it deserves to be read in full rather than summarized: “We’ll miss the feeling of holding code in our hands and molding it like clay in the caress of a master sculptor. We’ll miss the sleepless wrangling of some odd bug that eventually relents to the debugger at 2 AM. We’ll miss creating something we feel proud of, something true and right and good. We’ll miss the satisfaction of the artist’s signature at the bottom of the oil painting, the GitHub repo saying ‘I made this.’” He closes the essay further out still: “We are the last of our kind, and those who follow us won’t understand our sorrow. Our craft, as we have practiced it, will end up like some blacksmith’s tool in an archeological dig, a curio for future generations. It cannot be helped, it is the nature of all things to pass to dust, and yet still we can mourn.”

The mourning is earned. Something real is being lost: the generative relationship between a person and the thing they build, replaced by a supervisory one, often on terms set by someone else. But “it cannot be helped” is not a fact sitting next to that grief. It is a separate argument, and one that should not be smuggled in under the banner of technological progress.

The unresolved question is not whether AI will make developers more productive. It may. The more important question is what remains of authorship when the person responsible for the software no longer experiences its construction as their own work. Lawson’s most revealing line is not the one about blacksmiths or even the one about the TSA agent. It is the smallest one: the GitHub repository saying, “I made this.”

At what point does that sentence stop feeling true?