From Maker to Minder: AI Coding and the Old Story of Lost Craft

"State of Drift" is a series about keeping control of software drift. Drift is the accumulation of mistakes inside code that appears to work. It isn’t new. AI didn't create it. It merely accelerates it past the point where teams can keep up.

Jonathan Gordon

•

Black and white vintage image of workers with a line of weaving machines

The State of Drift: Part 1

TL;DR: AI coding tools are moving developers from writing code to reviewing it, the same maker-to-minder shift the power loom forced on weavers. Unlike cloth, code can be rewoven. The way out is keeping humans in control of the pattern, not just in the loop checking output.

——————————————

For centuries, a weaver was a maker: someone who knew the whole of the work, the fiber, the tension, the pattern taking shape under their hands, the finished cloth that was recognizably theirs. Then the power loom arrived, and within a generation, that relationship was gone.

We tell the story as one of lost jobs—and it was—but the deeper loss is that for those who remained in the mill, the power loom severed them from the work. They were no longer weavers; they were machine minders. They tended the mechanism that did the making and kept the line moving. The craft that had once belonged to a human migrated into the machine, and what remained was supervision. This is the shift from maker to minder: from creating the work to supervising the machine that creates it.

I've spent 30 years building tools for people who make things, and 30 years watching that one distinction matter more than almost any other. So, when I look at what AI is doing to software, what unsettles me isn't the speed, or even the quality. It's that the substitution isn't new — it has happened before, and we already know how the story ends if we let it run.

The loss beneath the loss: What the machine cost the craftspeople

A weaver who made fabric had a relationship with it. Their judgment was visible in the weave, their care in the finish. The machine minder had none of that. The product became a stranger to the person who produced it.

Nineteenth-century observers had language for this that we've mostly lost. In 1853, Ruskin wrote about the degradation of the worker into a machine and how dividing labor also divided the person, leaving them with a fragment of a task and none of the satisfaction of the whole. Marx, in his 1844 manuscript, called it estrangement: the worker, in the act of working, no longer recognizing the work as their own. Both were pointing at the same wound. The machine didn't just take the job. It took the connection between effort and outcome, between a person and the thing they were proud to have built.

That connection is not a sentimental luxury. It’s most of what makes skilled work bearable. Take it away, and you are left with responsibility without craft: a human still accountable for the output, but no longer its author.

Most of what makes skilled work bearable is the connection to the work. Take it away, and you are left with responsibility devoid of craft.

It was never only the weavers

We remember the weavers because their fall was dramatic, but the pattern repeated across every trade the machines touched: carpenters, shoemakers, watchmakers. Craftspeople who had carried skill to produce the whole were pulled apart into operatives who carried out only a single, repetitive step.

With each repetition, the same three things happened. The machine set the pace, and the human body had to match it. The historian Thompson (1967) suggests that the factory forced a shift from task-oriented work, done to the rhythm of the job and the season, to clock-time, done to the rhythm of a machine that never tired. Fourteen-hour days weren't necessarily about labor exploitation (though they were), but a result of a mechanism that didn't need rest paired with a worker who did.

The skill drained out. When the machine held the expertise, the apprenticeship that had turned novices into masters collapsed, and within a generation, the tacit knowledge went extinct. The era had a word for the cheap, reworked cloth that a loom produced: slop-work (Kingsley, 1850).

The era had a word for the cheap, reworked cloth that a loom produced: slop-work.

By the early 20th century, mechanization and the separation of craft from production gained mass appeal. Taylor's (1915) “scientific management” separated the planning of work from the doing of it and moved conceptualization into the office and left execution to the work floor. Ford's assembly line (Ford Corp., 2020) perfected the arrangement.

This was maker-to-minder taken to its logical end, and it produced staggering output. It also produced the century's defining image of work as something done to people rather than by them.

The new loom: How AI is changing the developer's role

The same power machine has now arrived for software. The weaver is now the developer, holding the one thing the machines cannot spin: the context that turns cheap thread into quality cloth.

Spinning thread was mechanized first, before weaving was. For a generation, cheap thread made hand-weavers prosperous—until the power loom. This is where we are today. The harness (the system of AI agents and tooling that now writes and runs code) is the power loom, and it’s coming for the weaving. Watch what it does to the role: the developer moves from writing to reviewing, from making the cloth to minding the loom that makes it. By the time output is reviewed, the developer is debugging the machine's interpretation instead of their own. Maker to minder, once more.

In the weaver era, slop-work cloth showed when you held it to the light. Generated code doesn't show its flaws so obviously. Instead, issues are invisible in the demo, because you cannot test for what isn't there—missing error states, absent tests, auth checks that lived only in the browser. Drift is a tear forming in the cloth: a dropped stitch here, a loose weave there, opening wider under load. Production is tension. Users are tension.

The disconnection is already surfacing among software engineers. A survey of nearly 1,300 developers by Tolinski (2026) found that they described their work as increasingly supervisory rather than creative. Two in three reported experiencing more pressure to produce, not less, and that there was growing anxiety about skills quietly eroding.

This is the lesson of the power loom. The faster the looms run, the more stitches drop and the wider the tear.

This time the cloth can be rewoven

History doesn't have to repeat, and that's why I build what I build.

When a power loom wove shoddy, that was final. A poorly made yard stayed poorly made, and obsolete weaving skills stayed obsolete. Code is different. Code can be refactored. Debt can be paid down. And people, given back their agency and their craft, can recover. The Industrial Revolution ran in one direction because its material couldn't run in the other. Ours can.

The maker-to-minder slide is a choice, not a fate. It is the difference between keeping the human in the loop and keeping the human in control.

A “human in the loop” reviews AI output after it's made, at the machine's pace. They’re a minder stationed downstream of the loom, checking its cloth at the machine's pace, accountable for work they no longer author. You can’t inspect cloth as fast as a power loom creates it, so the dropped stitches or misaligned patterns get past. This is happening now. One study found that about 30% of code is shipping without any human review at all (Faros AI, 2026).

A “human in control” sets the patterns and tolerances the AI must work within before anything is made. They’re still a weaver. Instead of keeping up with the machine’s pace, they set the pattern and the tolerances the loom must hold to, and the machine runs inside them. The weavers had a phrase for a loom that kept every thread aligned: it ran true. That’s the aim: not a loom with no one running it, and not a human inspecting every single thing, but a loom that runs true because a maker defined what true means. Cognitive energy is put toward direction instead of verification. That’s not only more sustainable to run; it hands work that was worth doing back to the craftsperson and their judgment, intent, and authorship. Control keeps the maker connected to the making.

Keeping the maker making

The Industrial Revolution's lesson was never that machines are the enemy. It’s that a machine, left to define the terms, will quietly shift the human to attendant and call it progress. We don't have to accept those terms this time.

That is what “re-weaving” means to me: not resisting the machine, and not surrendering to it, but insisting the human stays the maker while the machine does the tireless part. Speed didn't destroy craft two centuries ago; accepting mediocrity did. It doesn't have to this time.

Keep the human in control, not just in the loop, and the oldest casualty of every industrial age gets spared: the maker stays connected to the making, and the craft, instead of being replaced, finally has somewhere to go.

Frequently asked questions

What is drift?

Drift is the build-up of mistakes inside code that appears to work. Drift isn't new, but AI coding tools speed it up because they generate code faster than any team can fully review. The flaws usually don't show in a demo. They show up later, in production and under real use.

What does "maker to minder" mean?

"Maker to minder" describes a worker moving from creating the work to supervising a machine that creates it. During the Industrial Revolution, the power loom turned skilled weavers into machine minders who tended looms instead of weaving cloth. AI coding tools are doing something similar to software developers, moving them from writing code to reviewing code the machine wrote.

How is AI changing the role of software developers?

Developers increasingly describe their work as supervisory rather than creative. They spend less time writing code and more time reviewing and debugging what an AI produced. Many also report more pressure to produce and worry that their skills are eroding, the same pattern craftspeople went through when their trades were mechanized.

What's the difference between "human in the loop" and "human in control"?

A human in the loop reviews AI output after it's made, at the machine's pace. They're accountable for work they didn't author, and errors slip through because no one can inspect output as fast as it's generated. A human in control sets the patterns, standards, and tolerances the AI must work within before anything is made. Their judgment goes into direction rather than inspection, and they stay the author of the work.

Can AI coding go differently than the Industrial Revolution did?

Yes. Badly woven cloth stayed bad, but code can be refactored, technical debt can be paid down, and developers can rebuild their skills. That means the maker-to-minder shift in software is a choice, not a fate. Keeping humans in control, not just in the loop, lets teams get AI's speed without giving up craft or authorship.

References

Faros AI. (2026). AI Engineering Report: The Acceleration Whiplash.

Ford Corp. (2020). The Moving Assembly Line and the Five-Dollar Workday. Ford.com

Kingsley, C. [as Parson Lot]. (1850). Cheap clothes and nasty. London: W. Pickering

Marx, K. (1964). Economic and Philosophic Manuscripts of 1844. International Publishers

Ruskin, J. (1900). The Nature of Gothic: A chapter from The Stones of Venice. George Allen.

Taylor, F. W. (1915). The Principles of Scientific Management. Harper & Brothers.

Thompson, E. P. (1967). Time, work-discipline, and industrial capitalism. Past & Present, 38(1), 56-97.

Tolinski, S. (2026). The True Cost of AI Coding. Syntax Podcast.