I miss when my dreams were code
October 10, 2026
Abstract illustration for the essay

Lately I have been thinking about the difference between a tool and an instrument.

A good tool tries to disappear. It shortens the path between what you want and what you get. Fewer steps, fewer decisions, less contact with the material. That is the design goal, and most of the time it is the right one. You do not want a spreadsheet that fights you on every cell.

An instrument is different. It does not necessarily exist to challenge you for sport. A violin is still built to be playable. But it is not built to remove the hard parts of music. It is built to transmit them: intonation, breath, timing, the tiny corrections your body learns only by repeating them. The same goes for athletes, dancers, artists, authors, engineers, mathematicians etc. The friction is a feature, not a bug. It’s something you master over years of practice, not a task you check-off a list.

Writing software used to feel like playing an instrument.

You sat inside a loop: idea, keystroke, surprise, revise. You could follow a hunch down a rabbit hole, lose an afternoon, and come back with something you could not have planned on a whiteboard. The work was inefficient in the productivity sense. It was dense in the learning sense.

I fell in love with code for that reason. It taught me how to think.

It was never just the means by which you got an idea into the world. It was the medium in which the idea became intelligible to you. You were not only translating imagination into syntax. You were imagining in syntax: giving a thought behavior, a shape, edges it did not have while it was still a sentence in your head. You could inhabit it, poke it, break it, show it to someone else, and be surprised by what came back.

That is the part I miss when I say I miss when my dreams were code. Not nostalgia for harder tooling, but nostalgia for a kind of contact.

Now there is pressure to stand one level above the loop. Describe, delegate, review. Become the person who directs the making instead of the person who makes. Sometimes that is wonderful. Sometimes it is how you ship. I am not arguing against it.

But there is a difference between having something built for you and building something that teaches you what you wanted to build. The first optimizes output and the second optimizes understanding. They overlap, but they are not the same optimization problem.

The new tools are extraordinary at first. You can compress a week of exploration into an afternoon of prompts. I use them. I am glad they exist. I only notice what they quietly increase the distance you used to have to travel inside your own idea.

Not every inefficiency is waste and not every abstraction is progress. Sometimes the distance a tool removes is also the distance through which you discover something. If you always arrive at the answer without walking the maze, you get the result without the map.

I do not think the answer has ever been to reject the tools. The answer might be smaller and more stubborn: protect the parts of the process where thinking is the work, even when they are no longer strictly necessary.

Nature has a creative immune system.