The Machinist and the Program

I was watching a video this morning about Fanuc and the rise of numeric control for machining. Something clicked.

Before numeric control

A machinist in 1955 held two things at once: the knowledge of what to make and the skill to make it. The blueprint told you the geometry. Everything else — feeds, speeds, toolpath sequencing, how this material behaves when a tool enters it at this angle — lived in the machinist’s hands and head, accumulated over years of direct work.

The knowledge and the execution were inseparable. You couldn’t hand one off without the other.

Numeric control changed that. MIT’s Servomechanism Lab, late 1950s. The Air Force wanted complex aerospace parts machined to tolerances a human operator couldn’t hold consistently. The answer was to encode the geometry in a program and have the machine execute it. The machinist’s role shifted: programming, setup, inspection. The tool moved; the machinist watched and verified.

The craft hadn’t disappeared. It had relocated.

Where the knowledge went

The early NC programmers were almost always former machinists.

Because you can’t write a good NC program without understanding feeds, speeds, toolpaths, material behavior. The knowledge that used to live in the hands still had to exist somewhere. NC didn’t eliminate it. It moved it upstream, into the programming phase, where it became explicit — a set of instructions that could be inspected, corrected, and reused — rather than tacit knowledge expressed through physical manipulation.

The abstraction layer made the knowledge visible. One machinist’s expertise could be encoded and shared. One program could run on any compatible machine.

The people who couldn’t make the transition were the ones who knew how to cut but couldn’t articulate why. The craft had always required knowing. NC just required knowing you knew.

The same relocation

What’s happening with LLMs and programming isn’t just automation. It’s the same knowledge relocation.

Before: a programmer held the knowledge of what to build and the skill to build it. Those were inseparable because execution was how you discovered constraints. You found out a design was wrong by writing it.

After: the knowledge relocates upstream. Into system design. Into audit work — mapping the territory before the spec. Into specification — making constraints explicit enough that implementation can be mechanical. Into adversarial review — verifying what was delivered against what was intended. The LLM executes. The programmer programs.

The skill hasn’t gone anywhere. It’s just no longer expressed through keystrokes.

Who will be good at this

The early NC programmers were former machinists. Not because machining experience was a job requirement — because you cannot write a program for a process you don’t understand. The abstraction layer doesn’t eliminate the need for domain knowledge. It relocates it to where the program is written.

The people who will be best at LLM-assisted development are probably the ones who actually understand the code. Not because they’ll be writing it — because understanding what should happen is the upstream work. The spec can’t be mechanical unless the person writing it understands the constraints. The audit can’t surface the right findings unless the auditor knew what to look for. The adversarial review can’t catch a subtle architectural assumption unless the reviewer understands the architecture.

The programmers who only know how to type are in the position of machinists who only knew how to cut. The tool changed. The knowledge requirement didn’t.

We don’t have forty years of hindsight on this yet. We’re at the start of the Fanuc video. But the shape seems right: the craft relocates upstream, the people who carry it figure out how to express it in a new medium, and the people who can’t articulate what they know get left behind by a tool they could have used.

The interesting work — for me, anyway — is figuring out what the new medium looks like. What does it mean to encode programming knowledge into a spec, an audit, a review? The NC programmers had APT and then G-code. We’re still working out the language.