A Programming Obituary: How AI Coding Agents Took the Fun Out of Puzzle-Solving

When Programming Goes from Puzzle-Solving to Directing

Jeremy Scheff published an article on his personal blog titled "My obituary for programming," using the framework of an obituary to mourn a disappearing professional experience: the kind of programming work where you get paid for solving logical puzzles. This short piece, relayed by Simon Willison, struck a chord in the tech community and hit on the most subtle part of the anxiety surrounding the current wave of AI coding agents.

Scheff's description is precise and carries a touch of nostalgic arrogance: programming used to be one of the best jobs around—you were paid to solve gnarly logic puzzles, and the harder the puzzle, the higher the pay. Even better, even fairly simple puzzles were worth a lot of money, because ordinary people simply couldn't do them. Clients came with problems, and programmers solved them on their own terms: we set the strategy, we set the timeline, and we decided what was possible and what wasn't.

The value of this passage isn't in the sentiment but in the fact that it points out something often overlooked—the appeal of programming as a job has never come only from "building systems that run," but also from the intellectual thrill of the problem-solving process itself.

Coding agent refers to an AI system capable of autonomously planning, writing, running, and debugging code. Unlike earlier code assistants that only did single-turn completions, it typically has tool-calling capabilities: it can read and write files, execute terminal commands, run tests, and self-correct based on errors. Typical examples include IDE-integrated agents built on large language models, command-line agents, and cloud-based agents that execute tasks asynchronously. The key characteristic of such systems is that they break "writing code" into a multi-step loop—observe, decide, execute, verify—thereby pushing the human role from line-by-line writing toward goal-setting and result review. Understanding this distinction matters: the article is not discussing the efficiency gains from code completion, but the structural shift in what programmers' work actually consists of once agents can complete tasks end-to-end.

Two Kinds of Programmers, Two Fates

In his relay, Simon Willison offered a rather crisp split: if you're the kind of programmer who enjoys building working systems and doesn't much care which specific problems got solved along the way, then LLMs are a machine that keeps giving gifts; but if solving those problems is itself an important source of your happiness, then the loss is very real.

This split has more explanatory power than the vague "will AI replace programmers" discussion. It doesn't predict job numbers; it describes a shift in the nature of the work: from personally reasoning through every line of control flow to defining goals, reviewing output, and orchestrating multiple coding agents. For people oriented toward engineering delivery, this is an efficiency dividend; for people oriented toward intellectual play, it's the rules of the game being rewritten.

You may not have noticed that the object of Scheff's "obituary" isn't actually the profession of programming, but the craft-like relationship between professional programmers and code. The obituary genre is itself a rhetorical choice—it isn't predicting death, but acknowledging that something has irreversibly changed.

Intrinsic reward is a concept from behavioral economics and organizational psychology referring to the satisfaction that comes from an activity itself, rather than from external compensation, promotion, or recognition. Its counterpart is extrinsic reward. Programming has long been seen as a career with both: the extrinsic reward of high pay and the intrinsic reward of puzzle-solving pleasure. When AI takes over the "puzzle-solving" part of the task, extrinsic compensation may not immediately decline, but intrinsic reward can be drained away, changing how practitioners subjectively experience their work. This framework explains why some programmers feel a sense of loss even when productivity rises and jobs remain—the loss occurs in the experiential dimension, not the income dimension, and conventional employment statistics struggle to capture it.

The "Nobody Else Can Do It" Moat Is Drying Up

The most cutting line in Scheff's passage is: ordinary people can't do it, so they need us. This is precisely one of the structural sources of programming's high pay—scarcity. When coding agents drastically lower the barrier to "writing code that works," scarcity shifts from "being able to write" to somewhere else: judging what's worth writing, verifying whether code is actually correct, and drawing boundaries within vague requirements.

This explains why reactions in the community are polarized. Some read relief—repetitive labor being taken over. Others read weightlessness—the identity of "I possess a skill others can't" being shaken. Neither emotion is affected; they correspond to two sides of the same thing.

Scarcity premium refers to the compensation above marginal output that a skill commands because its supply is limited. Part of programming's high pay stems from this: people who can write correct, runnable code have long been in short supply in the labor market. When coding agents lower the barrier to "producing usable code," the location of scarcity migrates—from coding execution to problem definition, architectural judgment, quality verification, and accountability. Notably, these substitute capabilities are harder to measure through benchmarks and depend more on domain knowledge and organizational context, so they are not easily standardized or fully automated in the short term. This means part of the premium will disappear, and another part will be redistributed to judgment and accountability.

Why This Discussion Deserves Serious Attention

Most public discussion around coding agents focuses on quantifiable dimensions like benchmark scores, context windows, and tool-calling capabilities. Scheff's short piece reminds us that the social cost of technological replacement isn't measured by productivity alone; it also includes the loss of intrinsic professional reward.

For teams currently using or evaluating coding agents, there's a practical implication here: positioning an agent as "thinking for the programmer" versus "typing for the programmer" leads to completely different collaboration models. The former compresses human judgment space; the latter frees it. The tool itself doesn't determine this—how it's used does.

As for programmers who genuinely love puzzle-solving, the way out probably isn't to reject agents, but to reposition the level of the puzzle—from "how do I write this loop" up to "should this system exist at all." The puzzles haven't disappeared; they've just moved up a layer.

One-line Summary

AI coding agents are draining the intrinsic joy of puzzle-solving from programming and changing what programmers' work actually is.

Paragraph Summary

Jeremy Scheff uses the obituary genre to mourn the disappearance of puzzle-solving joy in programming, and after being relayed by Simon Willison, it resonated throughout the tech community. Drawing on Willison's split, the article points out that programmers who enjoy building working systems gain an efficiency dividend from LLMs, while those who see the problem-solving process itself as a source of happiness face a real loss. One structural source of programming's high pay is scarcity, and coding agents are eroding the "ordinary people can't do it" moat, shifting scarcity toward judgment, verification, and boundary-drawing. The article emphasizes that the social cost of technological replacement isn't measured by productivity alone; it also includes the loss of intrinsic professional reward. Whether agents are positioned as thinking for people or typing for people will determine the collaboration model and the space for human judgment.