Sandpaper and the mansion

For forty years, programming kept one basic shape. You wrote the how, in text, one line after another, a little higher level each decade. Then, in about two years, that shape changed. Plenty of career developers feel it as a loss, and I think I know why: we spent so long getting good at setting bits that we mistook it for the creation itself. It’s like getting really attached to the art of operating sandpaper while building an ornate mansion.

The odd part is that the mansion was on the drawing board in 1969.

The future of programming, 1973

Bret Victor’s 2013 talk The Future of Programming is delivered as if it were July 1973. Dressed as an IBM engineer of the era, pens in his shirt pocket, Victor works from an overhead projector and addresses the room as programmers of automatic computing machines. The first time I watched it, it was crushing to realize how little progress we had made as a field.

His premise is that thinking changes more slowly than technology, so every step away from setting bits by hand met resistance. When Donald Gillies, one of John von Neumann’s graduate students, built an assembler, von Neumann reportedly objected to wasting a valuable scientific instrument on clerical work. IBM’s 1954 FORTRAN report promised the language “should virtually eliminate coding and debugging,” and programmers proud of their hand-tuned machine code doubted any compiler could match them. Each step was a better sander, and each met craftsmen proud of sanding by hand.

From his 1973 vantage point, Victor lists four ideas that had already been demonstrated: direct manipulation instead of code (Sketchpad), goals and constraints instead of procedures (Planner, later Prolog), spatial representations instead of text dumps (NLS, PLATO, Smalltalk), and concurrency instead of sequence (the actor model). It would be a shame, he says, if forty years on we were still writing procedures in text files. In 2013, we were.

Planner: what, not how

Around the ten-minute mark, Victor reaches Planner, which Carl Hewitt presented in 1969 as a language for proving theorems in robots. You state a goal; the system works out the steps. A subset called Micro-Planner powered Terry Winograd’s SHRDLU, which took requests in plain English and moved blocks around a simulated world.

That is the experience of a coding agent. “Make the tests pass.” “Add auth to this endpoint.” The agent decomposes the goal.

There’s no lineage here. Claude Code and Codex descend from neural networks, transformers and reason, act, observe loops, not from symbolic AI, and neither Anthropic nor OpenAI has cited Planner as an influence. Planner searched hand-written rules with explicit logic; an agent applies learned, fuzzy judgment. The parallels are still hard to miss:

• Capabilities, not names. Planner’s procedures advertised which goals they could handle, and the system picked a match. Agents choose tools from plain-language descriptions of what each one does.
• Actors. Hewitt’s next idea, the 1973 actor model, grew partly out of Planner: independent agents that communicate only by message. It shaped Erlang, and it’s the mental model for an orchestrator dispatching subagents. Five decades later.
• Autonomy versus control. Planner’s automatic backtracking proved hard to steer. In Why Conniving Is Better Than Planning (1972), Gerald Sussman and Drew McDermott argued that programmers needed explicit control over the search. Swap “backtracking” for “agent” and you have this week’s debate.

The detour

Planner worked in the blocks world because everything there could be written down as rules. Almost nothing else can. What 1969 lacked wasn’t the idea but a system that could fill in the vague, unstated parts of a goal the way a colleague would.

So we took a fifty-year detour into better sandpaper: languages, compilers, frameworks, editors. All of it good work, and all of it still about the how. We sanded well enough, for long enough, that sanding started to feel like building. A rough finish shows, sure.

Nobody tours a mansion admiring the grit of the paper.

A game developer I talk shop with noticed the consequence: with current models, nearly every bug he sees is architectural. Once the sanding is handled, the problems left are in the floor plan. Stating the goal well was the hard part for Planner’s researchers too.

It’s the rate, not the tech

Had what-not-how arrived on a steady path, a little in the eighties and more each decade after, we would have adapted the way we adapted to FORTRAN. AI programming would just be the next layer. Instead, careers were built on a job that barely changed shape, and then it changed overnight. That isn’t vanity. It’s what sudden change feels like after years of getting very good with the sandpaper.

Victor’s 1973 skeptics weren’t always wrong on the details. By John Backus’s own later account, the FORTRAN team was wildly optimistic about debugging; anyone who has debugged anything could have told them. The Conniver critique was right that unchecked search is hard to steer. Their points about control were real. Where they went wrong was direction.

Nothing is wrong with the tech. What we’re resisting is the rate of change.

That’s an age-old tale, as old as the assembler von Neumann didn’t want built, and it’s no reason to miss the chance to ride the wave.

My class of grades 3 to 12 students has no career of sandpaper to set down, so I teach the what side: deciding what the game should be, describing it clearly, and noticing when what came back isn’t what they meant. Experienced developers have been building those same skills for years, right beside the sanding. Those are the skills that matter now.

Victor ends by warning that the most dangerous thought a creative person can have is believing they know what they’re doing. Sanding was never the point. The mansion was, and there’s more of it to build than ever.

If your team is working out how much to hand an agent and how much to keep, let’s talk.