What's still true for the CNC machinist when AI can generate G-code?

The shift

Toolpath and G-code generation for standard geometry goes from scarce (a skilled programmer's hours at a CAM seat) to abundant — for well-defined features on common materials, AI can produce a runnable program from a model in minutes, at near-zero marginal cost. What stays scarce is everything between a plausible program and a proven-out part: the physical setup, the first cut on real stock, and the answerable name on a part that has to hit tolerance.

The axioms

• Authoring the toolpath is the machinist's core skill — CAM programming was scarce, learned expertise.
• Choosing feeds, speeds, and tooling for a given material requires judgment built from experience — pattern-matching against handbooks, forums, and one's own scrapped parts.
• The program has to be proven out on real material before it's trusted — cutting the first part is a physical act with a physical failure mode.
• The machinist reads the cut in real time — sound, chip color, chatter, tool load — and intervenes before a part or a tool is lost — scarce, embodied attention at the machine.
• Someone is accountable for a part that meets print — a name attached to a dimension that a customer or inspector will check.
• Being wrong is expensive in metal and machine time, not just in rework — scrap stock, a crashed spindle, and lost hours are the cost of an error, and they're borne physically.
• The setup — workholding, fixturing, tool offsets, work coordinate origin, stickout — is what makes the program cut the intended part rather than a different one — physical, per-job, tacit.

Invalid axioms

1. Authoring G-code for standard geometry is the machinist's differentiator. CAM authoring for prismatic parts, common pockets, holes, and standard 3-axis features rested on programming being a scarce, learned skill. For that class of work AI now generates a runnable program from the model directly, and the CAM-operation-selection expertise that took years is being commoditized fastest. The habit-trap: shops still price and value machinists on programming speed and CAM fluency, and quote jobs as if getting to a first program were the bottleneck — when for standard geometry that step is collapsing toward free. (Fast-moving: the boundary between "standard geometry AI handles" and "complex 5-axis / thin-wall / exotic-material work it doesn't" is moving outward month to month — calibrate this call per shop, not once.)
2. Knowing the starting feeds and speeds from experience is the scarce edge. The recall of a good starting recipe — surface speed, chip load, DOC for a given tool-material pair — was scarce because it lived in handbooks, tool catalogs, and a machinist's memory. That baseline is now abundant: AI and tool-vendor data spit out a defensible starting point instantly. The habit-trap: treating "knows the numbers" as the skill, rather than knowing when the numbers are wrong for this setup, tool, and machine.

Unchanged axioms

1. The program has to be proven out on real material, and that's a physical act with a physical failure mode. A plausible toolpath and a proven one are different things, and the gap is only closed by cutting — dry runs, single-block, reduced rapids, first article. AI can generate the program; it can't stand at the machine and watch the first part come off. The cost of skipping proving-out is scrapped stock and a wrecked fixture, and that cost is borne in metal, not tokens.
2. Reading the cut in real time and intervening stays embodied and scarce. Chatter, a change in cutting sound, chip color, a tool loading up, coolant not reaching the flute — these are sensed at the machine and acted on in seconds, before a tool breaks or a part moves. This is action in the physical world under time pressure, exactly where a token-generator is absent. Sensor-and-monitoring systems narrow the per-signal part of this, but the integrated judgment of "something's off, stop" is still human.
3. Someone accountable owns whether the part meets print. A model can generate the code; it can't be the answerable party when a batch is out of tolerance, a spindle crashes, or an inspector rejects a lot. Liability and the standing to sign off on a dimension stay human and organizational, however good the program looks on screen.
4. The setup is physical, per-job, and tacit — and it's where the program meets reality. Workholding that won't let the part shift or ring, fixturing that clears the toolpath, correct tool offsets, the right work origin, controlled stickout — this is hands-on, judgment-heavy, and specific to the machine and the stock in front of you. AI can suggest a fixturing approach; it can't clamp the part, dial in the offsets, or feel that the workholding is marginal. This is the part of the job most practitioners already name as the real work, and the shift confirms them.
5. Diagnosing why a cut is going wrong requires reasoning about the physical process. A rising surface-finish problem, a tool wearing early, a part walking in the vise — tracing that to a dull insert, a rigidity problem, a bad workholding choice, or thermal growth is causal reasoning tied to physical intervention. That stays scarce and hands-on.

New axioms

1. Verifying AI G-code before it cuts metal becomes the scarce, load-bearing step. When a program is free and instant, the constraint moves to checking it — simulation, gouge and collision checking, dry runs, sanity-checking feeds against the actual tool and machine — before the spindle turns. A confidently-wrong toolpath reads as correct on screen and fails at the tool, and nobody has fully worked out who owns this verification pass or how much of it can be trusted to another automated checker versus a machinist's eyes.
2. A confident-wrong toolpath can crash a machine or scrap expensive stock, and the failure is silent until it happens. AI generates programs that look runnable but embed errors a human programmer's intuition would have caught — a rapid through the fixture, a plunge too aggressive for the material, an unreachable feature treated as reachable. Manual authoring was slow partly because the programmer was reasoning about these the whole time; abundant generation strips out that incidental checking. The scrap and crash cost that used to be bounded by careful, slow programming is now exposed unless verification is deliberately rebuilt as its own step.
3. When starting recipes are free, the skill is catching when they're wrong for this exact setup — a judgment that erodes if it's never practiced. Abundant feeds-and-speeds shift the machinist's job from recall to correction. But if a generation of machinists never develops the recipe from scratch, the tacit sense of "that number is too hot for this stickout" may not form — and that sense is exactly the backstop the abundant recipe needs.

Where it breaks

Shops price and staff around programming speed (INVALID: G-code authoring is the differentiator) while the cost and time actually shift into verifying and proving out programs that arrive faster and looking finished but carry silent errors (NEW: verification-before-cut is unowned). A shop that quotes a job as cheaper because "AI writes the code now" and cuts programming hours, without adding proving-out and verification time, is not removing the risk — it's moving it downstream to the first part off the machine, where the failure mode is a crashed spindle or scrapped stock instead of a caught mistake at the desk.

ai-axioms.vercel.app/axioms/industries/cnc-machinist-ai-axioms