The 'Obituary for Programming' and What Coding Agents Take Away

On 19 October 2026, Simon Willison linked to an essay by Jeremy Scheff titled "My obituary for programming". There is no benchmark in it and no product launch. It is a personal account of what coding agents change for people whose careers were built on writing code by hand. It is worth a builder's attention because it names a cost that most agent-adoption talk skips.

What the essay actually says

Scheff's argument, as Willison quotes it, is that programming was a great job because you were paid to work on tricky little logic puzzles. The trickier the puzzle, the more you earned, and even simple puzzles paid well because ordinary people could not solve them and needed programmers. In his telling, programmers also held the levers: they set the strategy, made the timeline, and defined what was and was not possible.

Willison adds a short, useful framing. If you are a programmer who thrives on building working systems and does not care too deeply about the problems solved along the way, LLMs are "the gift that keeps on giving". If directly solving those problems was a big part of your enjoyment, he says, the loss is very real.

Why this matters for people building with agents

The useful reading is not nostalgia. It is a description of two different jobs that used to be bundled together: solving the puzzle and delivering the working system. Agents are good at compressing the first one. That makes the second one, and everything around it, the part where people now spend their attention.

• Framing the problem. An agent solves the puzzle you hand it. If the problem is mis-specified, you get a well-built wrong thing.
• Verification. When you did not write the logic line by line, tests, review and observability become the way you understand it.
• Strategy and scope. The levers Scheff mentions, strategy, timeline and what is possible, remain human decisions, and arguably carry more weight.
• Craft motivation. Teams that hire for the love of the puzzle may need to rethink how they keep people engaged when the puzzle is delegated.

A practical checklist for AI-assisted teams

1. Write the problem statement and acceptance checks before prompting the agent, so you own the definition of done.
2. Keep the hard, high-risk puzzles, such as money movement, auth and trading logic, under deliberate human review rather than skim-approving diffs.
3. Treat tests as the contract: if an agent changes behaviour, a failing test should be the first signal.
4. Decide explicitly which problems are worth solving by hand for learning, so skills don't quietly atrophy.

Our take

We build with agents and teach others to, so we read this as a fair accounting rather than an argument against the tools. Both of Willison's camps are real, and pretending otherwise makes adoption harder. The healthiest posture is to be honest about what is being traded: less hands-on puzzle solving, more responsibility for framing, verification and judgment. For fintech and trading software in particular, where wrong behaviour is expensive, that responsibility is the part you cannot hand off.

Caveats

This is an opinion essay and a link post, not data. It does not measure productivity, employment or code quality, and we are not claiming it does. Treat it as a well-articulated perspective to test against your own team's experience.