Evidence at a glance
An Obituary for an Experience, Not a Profession
On October 8, 2026, Jeremy Scheff published “My obituary for programming,” a personal essay about how AI coding agents have changed his experience of programming. Simon Willison linked to and commented on the essay on October 19. Scheff is not asking the abstract question of whether code can still be written. He is asking what remains of the job when agents begin taking on engineering tasks programmers once solved themselves.
Scheff remembers programming as a series of logical puzzles that produced real things: a client brought a problem, and the programmer chose the strategy, timeline, and boundaries of the solution. The “obituary” is therefore better read as mourning a particular experience of work than as declaring the programming profession dead. Technical leaders should pay attention because faster delivery and reduced satisfaction can coexist, and may do so at the same time.
The Division of Work Changes, Not Just the Typing Speed
Scheff describes concrete uses for agents: giving them a bug report or error log so they can locate and fix a problem, asking them to optimize performance, or assigning a large refactor that had been put off. The material does not identify the models involved, explain how they reason internally, or provide a technical recipe that others can reproduce. What the essay can show is a shift in the division of work, not the specific mechanism by which an agent completes each task.
When agents take on debugging, optimization, and refactoring, programmers still need to decide what problem to solve and judge whether the result is acceptable. But there may be less of the step-by-step reasoning that used to produce the solution. The change is not simply “less handwritten code”; the center of the work moves from solving problems directly toward defining them, choosing targets, and evaluating outcomes. For engineering teams, that means an agent’s value cannot be described only by code output. It also matters which tasks it takes over from people.
What the Speedups Do—and Do Not—Prove
Scheff uses his own projects to illustrate the engineering gains agents may deliver. In tests of four ZenGM game simulations, he reports speeds of 1.84, 1.98, 1.88, and 1.98 times their previous rates—roughly a twofold improvement overall. Another example is a JSON streaming library whose release notes report about a threefold speedup for typical use. These figures make the claim that agents can help with optimization more concrete than a general promise would be.
The limits of the evidence are just as clear: these are cases from the author’s projects, not a general result across codebases, tasks, and teams. A speedup also says nothing about whether programmers enjoy their work more, or whether the profession will disappear. The essay provides no employment data and no independent evaluation of the agent-assisted tasks, so local performance gains cannot be extended into a claim about the industry’s future. For a technical leader, the figures are leads to test in a particular team, not guaranteed returns.
The Same Efficiency Can Mean Two Different Things
Scheff was initially in no hurry to use coding agents because he enjoyed programming by hand. He began trying them after seeing peers stop writing code line by line and non-programmers complete projects that had previously been difficult for them. Willison’s comment adds a different preference: for developers who care more about building usable systems than about personally solving every problem along the way, LLMs can be a continuing source of help. These reactions do not contradict each other; they reflect different sources of reward in the work.
For people focused on delivery, an agent that handles a neglected refactor, fixes a bug, or improves performance can free up effort for other goals. For people who enjoy the puzzle itself, the same automation may remove one of the most appealing parts of the job. This is not simply a choice between embracing and resisting technology. It depends on who is doing which work, and what they value most about it. If managers track only completion speed, they may see higher output while missing a change in the experience of doing the work.
Before Delegating, Decide What You Want to Preserve
This essay is not a deployment guide for coding agents. It points to a blind spot in evaluation: handing off the same task can clear a backlog while also reducing engineers’ opportunities to solve problems themselves. Teams can identify debugging, performance optimization, and overdue refactoring as candidate uses, then observe whether delivery improves while discussing which work they still want engineers to do directly. The question is not a single switch labeled “use agents or not.” It is which parts are worth automating, and which are also where the team develops judgment and finds satisfaction.
The material cannot tell us how widespread these reactions are, or whether any particular team will become more productive or more satisfied as a result. It supports a narrower conclusion: local speedups are documented cases, but they do not prove the profession is ending; automated handoffs may also change how the pleasures of work are distributed. Technical leaders can evaluate agent gains alongside people’s experience, rather than treating “faster” as a complete answer.