The Maker's Paradox

There's a pattern that repeats across every major shift in the means of production, and if you've read your Frankfurt School you already know the punchline: the tool reshapes the toolmaker long before the toolmaker notices. What's happening with AI-driven development is not an exception. It might be the most compressed instance of it we've seen.

The productivity trap, or: how I learned to defer deep sleep

The standard pitch goes like this: AI writes the code, you make the decisions, everyone goes home early. Anyone who has actually worked with these systems for more than a few months knows this is closer to an inversion of what actually happens.

The machine doesn't get tired. It doesn't hesitate. It doesn't have a weak Thursday afternoon. It throws itself at every problem with the undifferentiated intensity of something that has no concept of self-preservation. And this turns out to be contagious. The tireless productivity of the machine creates a pull, a vortex really, that drags you into an endless cycle of production. You tell yourself it's about the product. It isn't. The product is always just the pretext. What actually is in the making is the production process itself: how to prompt better, how to structure context, how to squeeze another increment of capability out of the system.

The means have become the end. The cruel irony is that the people who've been doing this for decades, the ones who thought they'd left the all-night coding sessions behind, are the most susceptible. They have the craft knowledge to direct the machine effectively, and the machine rewards that knowledge with an intoxicating torrent of output. The promise was less work. The delivery is different work at higher intensity with no natural stopping point.

Deskilling as upgrade

Programming, the actual activity of writing code, is a craft tradition barely a few generations old. It has its own rhythms: the strange, time-devouring interplay of hacking and waiting, thinking and testing, puzzling and solving. People have spent thousands of hours in that mode. The labor was the thinking - Denkarbeit.

When AI handles implementation, that entire mode of engagement compresses into moments of machine evocation. You describe, the machine produces. The Denkarbeit disappears. What remains is direction and review, cognitively demanding for sure, but fundamentally different in character. The experience of wrestling with code, of being stuck and then unstuck, of building understanding through the resistance of the material: that you stop needing.

The hand-weaver who moves to a programmable loom (the first programmable machine, as it happens, built in 1804 by a French silk weaver named Jacquard) doesn't stop working. But the work shifts from the pragmatics of the weave to the optimization of the machine. The fabric becomes incidental, something that just needs to be "done" so you can refine the punch cards. Something that needs to exist so the next generation of process refinement can begin.

Managers far enough from the codebase, of course, have always seen it this way. Writing code was always just an unfortunate necessity between the idea and the product. Certainly not a contemplative practice, not something anyone would call craft. What's new is that the people who write the code are starting to see it this way too. The immersion gives way to eclecticism: this model or that one, this workbench or another, whichever gets you there faster. Willingly.

Refining the punch cards

And I've been doing exactly what this essay describes. Rather than weaving, I spent months tinkering with the loom, trying to understand how it works, why it makes the choices it makes, what would happen if you structured the work around decisions rather than tasks.

The results are two recently published pieces. Beyond Agile / Fusion attempts a process model for AI-driven development built around goals, decisions, and coherence rather than stories and tasks. Understanding Claude Code dissects the internals of the AI coding agent I use daily. Both were written with the machine, about the machine, in service of getting better at using the machine.

What surfaced, after the tinkering, was one question that resists automation: not "does the code work?" but "does the output respect the decisions that were made, and do those decisions still make sense for the goal?" This is where human judgment is structurally required rather than merely welcome. Everything else the machine can approximate. This it cannot, because it requires a relationship to the purpose of the work that extends beyond the immediate task.

Dissecting the agent revealed its own version of the same problem. These systems have no memory. They simulate continuity by re-reading everything, every turn, and when context overflows they compress it lossily, discarding whatever seemed unimportant without knowing what will matter later. The human, supposedly freed from implementation, becomes the keeper of continuity, the one who maintains the context files that prevent the machine from drifting into incoherence across sessions. You're not writing the code anymore. You're writing the memory that makes the code possible.

Refining the punch cards, feeding the vortex.

Mündigkeit

The ship has sailed, and it won't be coming back. What matters now is what happens to the guild.

If the labor was the thinking, and the labor is automated, where does the next generation learn to think? You can teach someone to write prompts, to review output, to maintain context files. How can you teach the intuition that comes from thousands of hours of Denkarbeit: from being stuck, from building understanding through the resistance of the material? That intuition is what makes coherence review possible. It is what tells you the output is junk even when every test passes.

The only way to learn to judge the machine's work is to have done the work yourself. And the machine is making sure nobody does.

Adorno, late in his career, arrived at one concept as the measure of whether change is progress or regression: Mündigkeit, the capacity for autonomous judgment, for which English has no single word. Not knowledge, not skill, but the ability to think for yourself in the face of systems that think for you. The maker's paradox is a Mündigkeit problem. The Denkarbeit may need to survive not as production method but as practice: deliberate, perhaps inefficient, but irreplaceable as the source of the judgment that keeps everything else coherent.