Can You Churn Butter?

As I write this, I have six active Claude Code sessions running across three separate projects. Each of those projects would have consumed a full week of my focused attention. They are finishing in about ten minutes.

Here is the part worth dwelling on: I am not switching between them. I am writing this.

This matters because I am, constitutionally, a zone programmer. Twenty minutes to find it. Ten seconds to lose it. Time-slicing has never been in my skill set — not in 1989, not now. The conventional wisdom about AI-assisted development assumes you become a kind of air traffic controller, monitoring a dozen things at once. What actually happened, at least for me, is the opposite. The agent does the time-slicing. I do one thing.

The LinkedIn Problem

Last week someone publicly admonished a colleague for running out of tokens and stopping work until the next day. The verdict, offered with apparent confidence: "What have we become when we are slaves to our tools? If you run out of tokens, you are helpless."

Setting aside that nobody describes a surgeon as "helpless without a scalpel," the framing gets the economics exactly backwards. Those tokens were not burned on behalf of one person doing one task. They were doing the work of ten people, maybe more — the kind of protopian labor offloading that transformative technology is supposed to deliver. Lamenting that an AI system consumed significant compute while producing significant output is like complaining that a steel mill used a lot of electricity.

But the deeper irritant is the framing of dependency as degradation. We apply this logic selectively and inconsistently, and always in the direction of progress.

The Churning Question

Can you churn butter? Repair a sock? Dial a rotary telephone from memory, finger in the hole, waiting for the wheel to return?

People mourn that kids today can no longer write cursive, or drive a manual transmission, or navigate without GPS. Each generation sheds skills that were once essential, sometimes hard-won, occasionally beautiful in their mastery. Each generation also gains skills the previous one found incomprehensible or simply irrelevant.

I can write IBM 370 assembler. I know Lisp. I have spent a lifetime programming Von Neumann architectures with Turing-complete algorithms. These skills will die with my generation — preserved, as all such things are, by the occasional artisan and hobbyist who keeps the passion alive for its own sake, the way a friend of mine keeps HAM radio going. Not because it is useful. Because he loves it. Because building the antenna and coaxing a signal through ionospheric skip to reach someone in New Zealand is the point, not a means to one.

That is a fine reason to do something. It is not, however, an argument for requiring everyone to do it.

I have not written a line of code in over a year. I have shipped more software in that year than in any previous five.

The Question Nobody Asked

The usual anxiety about AI displacing labor focuses entirely on what gets taken. It skips past the more interesting question: what do you do with what you get back?

This is not a new failure mode. Every labor-saving technology in history arrived with implicit promises about leisure that were promptly buried under more work. The washing machine freed women from hours of manual laundry and the time was immediately colonized by higher standards of cleanliness. Faster communication meant more communication expected, sooner. Productivity software made it possible to produce more, so more was required.

We are, as a species, constitutionally bad at receiving the gift of time.

Living in Europe has sharpened my intuition about this. The old world did not arrive at the 35-hour week and the sacred August holiday and the two-hour lunch by accident. Those are not inefficiencies waiting to be optimized away. They are the institutionalized memory of a civilization that learned, at some cost, that output is not the same as life. A French colleague once told me, with genuine puzzlement, that Americans take pride in not using their vacation days. He said it the way you might describe a curious religious practice you cannot personally endorse.

He was not wrong.

The Editor's Chair

Consider what just happened. I used a tool — Claude Sonnet 4.6, tuned with a skill that has learned my voice, my references, my rhetorical habits — to draft an essay that I am now editing. Not writing. Editing. The distinction matters more than it might appear.

I could have written this. I have the skill set, the opinions, the examples already in my head. But it would have taken days of drafting and revision, the particular misery of staring at a paragraph you know is wrong without yet knowing why, the deadline pressure that Hitchens somehow converted directly into eloquence. Christopher Hitchens was famous for producing the most polished prose in a single pass — powered, reportedly, by Johnnie Walker Black and nicotine, on a manual typewriter, in a hotel room in Beirut. He didn't need a second draft. Most of us do.

What I have instead is something different: the accumulated erudition of Hitchens, and his hero Orwell, and Twain, and every eloquent writer who committed words to paper since the quill was invented — distilled into a model that can find the right register for an argument, reach for the precise word, sense when a sentence has gone slack. I don't have a deadline. I don't have to slave over a manuscript. I have something closer to an exceptionally well-read collaborator who does the first pass while I do what I'm actually good at: knowing when it's right.

That is not dependency. That is leverage. The difference between a writer who can produce and an editor who can shape — and the editor, in most rooms, has the higher ceiling.

The Actual Answer

So what have we become, when we run out of tokens?

Temporarily paused, waiting for infrastructure to catch up with ambition. Which is not meaningfully different from waiting for a compiler, or a meeting to end, or a build to finish — except that the infrastructure in question just did the work of a small team while you were doing something else.

The more honest version of the question is: what will you do with the hours AI is quietly handing back to you, project by project, task by task, line of code by line of code?

Here is what I do. I live in a walkable city in the south of Spain. When the tokens run out, I take a walk. Sometimes I bring my phone and connect to a remote Claude Code session, prompting my way through a specification between sips of espresso at a café table while the afternoon light does what afternoon light does in Andalusia. Productive and relaxed at the same time — a combination I had not previously experienced while writing software.

A friend in a similar situation asked me recently whether a full day of prompting and context-switching left me exhausted. I told him yes, honestly — but that the exhaustion is nothing like the stress-exhaustion of the old way. It feels more like the tiredness after a long hike. The good kind. The kind that is obviously doing something beneficial, that makes you want to do it again tomorrow. Like finishing a difficult crossword. Like what Feynman meant when he talked about the pleasure of finding things out.

Building Lego is a fine answer too. So is HAM radio, or learning a language, or sitting at a café in a country where sitting at a café requires no justification. The skills you shed along the way — the assembler, the manual, the cursive — are not losses. They are the price of the ticket.

What you do with the destination is, at last, up to you.