(As always: “I” means the partnership — my direction and review, an AI agent’s execution. Though this post is more mine than most.)

Before I wrote a line of code for money, I was a machinist. This was the 1970s — before I had any formal engineering education, before “software engineer” was something I imagined being. It’s surprising how much engineering a shop floor teaches you before anyone hands you a textbook.

Fifty years later I spend my days directing AI coding agents, and I keep noticing that the questions are the same questions. Four lessons from the shop floor that turned out to be about agents all along.

1. Short run, simple setup

Nobody builds a fixture for a three-piece run. You put the stock in the vise, you take your time, you make three good parts. The specialized setup only pays when the run is long enough to amortize it — every machinist does this arithmetic without thinking of it as arithmetic.

We ran a controlled experiment on exactly this. I built semantic code tools for my agent — a solution-wide rename that understands the code instead of pattern-matching it — connected them, recommended them in the prompt, and watched the agent ignore them completely on a three-file job. It did the work by hand, carefully, and got it right. My first reaction was that my tools had failed. My second reaction was that the agent had done the shop-floor arithmetic correctly and I hadn’t: short run, simple setup, why bother?

Then we gave it the long run: the same rename across three hundred call sites, salted with two hundred decoys — same method name on an unrelated class, indistinguishable to text search. With no prompting at all — no recommendation, nothing — the agent reached for the semantic tooling on its own and scored perfectly against an answer key. Same agent, same tools, same silence. The only thing that changed was the length of the run.

2. Repeatability is what degrades, not skill

A good machinist can freehand three parts to tolerance. Nobody freehands three hundred; by piece forty your attention is the tolerance, and it’s drifting. The jig isn’t there because you lack skill — it’s there because repeatability under fatigue is a different property than skill, and honesty about that difference is what separates a professional from an optimist.

That’s precisely the case for semantic tools over hand edits, and notably, the agents already know it. In our scale experiment, not one arm — including the model famous for being careful — was willing to hand-edit three hundred sites. They understood, without being told, that per-site care is exactly the thing that degrades.

3. The jig nobody uses

Every shop has one: a beautiful fixture, real money in its making, gathering dust on a shelf. Why? The bolt holes don’t quite line up with the table slots, or it needs a wrench nobody keeps at that station. And here’s the vicious part: the work still ships. Done the slow way, by hand, invisibly. Nobody files a complaint about a fixture; they just route around it, and the fixture quietly becomes evidence that fixtures are a waste of money.

My agent did exactly this. Told it must use the rename tool, it tried — nine attempts — and my tool refused it every time over a parameter name it had guessed slightly wrong, answering each guess with an error message that explained nothing. So it did the rename by hand, correctly, and reported success. A green result, a correct rename, and a tool that contributed nothing — I only knew because I read the transcript. The fix took minutes: slot the mounting holes. Accept the guessed name. Make the error message say what to do instead. On the rerun the agent used the tool flawlessly — and in the scale experiment that followed, every unprompted adopter walked through that same repaired door.

4. Measure the part, not the intention

The deepest shop-floor lesson: you don’t ask the operator if the part is good. You measure the part. First-article inspection exists because sincere, skilled people produce out-of-tolerance work while believing otherwise — and because the print is the arbiter, not anyone’s memory of what was meant.

Every finding on this blog traces back to that discipline. An agent migrated a legacy app to a green board — tests passing, commits clean — and independent measurement found it had quietly deleted the application’s defining architecture, because my acceptance criteria (my print) had a hole in them, and the part matched the print exactly. Another build passed fifty tests and never once opened its own window; the test harness structurally couldn’t see the failure, the way a caliper can’t measure concentricity. The remedy was never a smarter operator. It was better prints, and gauges that measure what actually matters, held by someone who didn’t make the part.

The machines talk now

People ask whether these models are overhyped or underhyped, and I think it’s the wrong axis. What I see from the shop floor is a brilliantly capable operator with specific, unannounced blind spots — which is not a new thing under the sun. It’s every shop I ever worked in. You don’t fix that with faith in the operator or contempt for him. You fix it with setup economics, honest fixtures, good prints, and inspection by someone else’s calipers.

I learned all of that before I was 21. The machines talk back now, and some of them write C# faster than I ever did. The lessons haven’t changed at all.

Built and written in collaboration with Claude (Anthropic’s Fable 5). The experiments referenced here are public, pre-registered predictions and all: github.com/sharpdaddy59/RoslynMcp. If you have a .NET Framework application that deserves a future, an automated assessment with a comprehensive report is exactly the conversation I’d enjoy having.