From the Lathe to the CNC: How I Build Software with a Fleet of AI Agents

I build software differently than I did a year ago. I still own the ideas, the architecture, and the outcome. But most of the code is now written by AI coding agents running on two machines at home. I plan and curate the work during working hours, and the agents build 24/7.

The best comparison I have comes from machining.

The manual machinist

Before CNC, a machinist thought up the part, drew it, planned the operations, and then made it by hand at the lathe and the mill.

That was how I worked for most of my career. I worked out a feature, planned it, and then wrote every line myself. The amount I could build was limited by the hours I could spend at the keyboard.

What CNC changed

CNC machines did not replace the machinist. They changed the job. The machinist still owns the drawing and the plan. The machine does the cutting. The machinist checks the parts against the blueprint and adjusts until they match.

My work now looks like that. I turn ideas into plans with firm guidance on architecture and outcome goals. The agents do most of the coding. I confirm, send back, and refine until the result is exactly to specification.

The shed

The agents run on a PC and a Mac mini. A small tool I wrote, ai-shed, keeps them working when I'm not at the keyboard. It is open source.

• Each piece of work is a GitHub issue. I label an issue for a machine, and the machine picks it up from its queue.
• Each machine runs workers. A worker is a coding session with a written brief: what to work on and what not to touch.
• A supervisor checks each worker every 30 seconds. If a worker goes quiet, a reviewer model reads the brief, the queue, and the last screen of output. It decides whether the worker is on track, needs a nudge to the next issue, is done, or needs a decision from me.
• Decisions wait for me. One command, shed status, lists what needs me on every machine, oldest first.

The supervisor has firm limits. It never tells a worker to merge, deploy, or weaken a test. It does not make my decisions. After three nudges that don't get a worker moving, it stops and reports the worker as stuck.

A normal day

During working hours I do three things.

I write the plan. Each issue is a spec. It says what the outcome is, which architecture it fits into, what it must not change, and how we will know it works. A vague issue gets a vague pull request.

I curate the queue. I decide what goes first, what waits, and what is too risky to hand to an agent.

I check the work. Each pull request is a part off the machine. If it matches the spec, it moves on. If it doesn't, I send it back with a ruling, and a worker picks it up again.

Then I stop for the day and the machines keep going.

For one project, the operations platform I build for a hauler with a landfill, three transfer stations, and about 100 trucks, that comes to 1,157 commits and 950 merged pull requests in the last 30 days. More than half of those commits landed outside 8 a.m. to 6 p.m. Commit counts are not a measure of quality. They do show that the work continues when I'm not there.

The repository holds the tolerances

The supervisor keeps the workers moving. It does not make their work safe to accept. That is the job of the repository, the same way a machine shop relies on its fixtures and gauges and not on the machine.

• Main is protected. Every change goes through a pull request.
• Checks run before a push, and the full test suite runs again in CI.
• Each release goes to staging first, where it gets browser smoke tests.
• Risky features ship turned off and get turned on after a checklist.
• Nothing reaches production without my sign-off.

These checks are what let me leave the machines running overnight and accept the results in the morning.

Limits

• The reviewer can be wrong. It reads a terminal screen. The limits above reduce the cost of a wrong call, but they don't prevent it.
• Agents hit usage limits. A machine can sit idle until a limit resets. The shed reports this, but it can't fix it.
• A bad spec gets repeated. A vague issue used to cost me an afternoon. Now it can produce several pull requests that miss in the same way.
• Judgment stays with me. What to build, what to leave out, and when a design is wrong even though the tests pass are still my decisions.

Why this matters for haulers

I build for haulers in the middle of the market: operations with real complexity that don't want enterprise software. Building a full operations platform for that market used to take a team. Working this way, one person who knows the industry can do it. That is how Strata and Klau are being built.

If you want to run your own shed, the code is on GitHub. If you're a hauler and want to talk about what this could build for you, get in touch.