Verify AI-Generated G-Code Before It Runs

AI will happily write you a G-code program. It won't tell you it's about to crash your machine.

Large language models such as ChatGPT, Claude and Gemini, and the AI assistants built into CAM systems, can produce G-code that reads perfectly: correct syntax, plausible coordinates, sensible-looking cycles. That fluency is exactly the danger. The code looks right because the model is very good at producing text that looks right — but it has no idea what your machine's travels are, which work offset is active, how tall your fixture is, or how your specific control will execute what it wrote. It's confident and it's blind, which is the worst combination to send to a spindle.

AI-generated and automatically generated programs aren't inherently bad. They're just unverified in a way CAM output never was — and they need a check built for exactly that gap.

What AI gets right

AI tools trained on large amounts of G-code handle the standard parts reliably:

• Basic syntax — G0, G1, G2/G3, G81–G84, M codes
• Common program structure — safety line, tool call, G43, M30
• Feed and speed ranges for common materials
• Standard canned cycle parameters

For simple programs — a hole pattern, facing a flat surface, a basic contour — the output is often syntactically correct and structurally sound. The problems are elsewhere.

Why AI-generated G-code fails differently

A human programmer's mistakes tend to be careless slips, close to the block where they were made. An AI's mistakes are confident and structural: one wrong assumption — units, work offset, tool-length convention — propagates through the whole program. They cluster in predictable places:

• Plausible but wrong numbers. A coordinate, a depth, a feed, or an offset that's the right kind of value but the wrong one — the model has no ground truth to check it against, so it fills the gap with something that looks reasonable.
• Invented conventions. Ask for a program and the model may assume an origin, a tool table, or a retract plane that doesn't match your setup — quietly, without flagging the assumption. It typically assumes G54 with the origin at a corner or the center of the part.
• Generic code, not posted code. AI writes "generic" G-code, not output tailored to your machine by a post-processor. The difference shows up in rigid tapping (M29), tool change sequences and machine-specific modal codes.

The AI doesn't know your machine

A G-code program only becomes safe or dangerous in the context of a specific physical setup, and none of that setup is available to a model writing text:

• Travel limits. Your machine has finite X, Y and Z travel. A move that's reasonable on paper drives a real axis past its limit and faults — or, combined with a wrong reference, crashes.
• Work-holding and fixtures. Where your vise sits, how tall your clamps are, what the fixture looks like. This is the biggest source of real crashes, and the AI cannot route the tool around a clamp it doesn't know about.
• Tooling. The real tool assembly — tool, holder, extension, shrink fit — sets the collision envelope. The AI assumes generic tooling.
• The offset table. Work offsets (G54–G59) and tool-length offsets live in the control. The AI writes a program that references them without knowing the values, so a program that's correct against the intended offsets is a crash against the real ones.
• Control-specific behavior. How your Fanuc, Siemens, Heidenhain or Haas resolves a G43 call, a canned cycle or a tapping mode depends on that control and its parameters. A program valid for "a Fanuc" may not run correctly on your 31i with your parameter set.

This isn't a weakness a better model fixes. It's structural: the limitation is access, not intelligence. The code can be flawless as text and still be dangerous as motion. Only running it against a real model of your machine and control tells you which.

Typical errors in language-model G-code

• Plunge moves at rapid (G0) instead of feed (G1)
• Missing G43 tool length compensation
• G28 in absolute mode (G90) instead of incremental — a classic crash
• Canned cycle parameters in the wrong dialect for your control
• Feed rates calculated for the wrong material or tool diameter
• Mixed mm and inch values, or inch feeds on a machine running in metric
• Moves beyond the machine's travel limits

For a worked example of these errors caught in a real verification run, see ChatGPT G-code: 5 errors to check before it runs.

Why the usual checks don't apply

The verification habits shops rely on all assume the program came from somewhere trustworthy — and AI code breaks that assumption:

• CAM simulation doesn't apply. The whole point of AI-generated code is that it didn't come from your CAM. There's no toolpath in Fusion or Mastercam to simulate — the program exists as raw G-code with no CAM project behind it.
• "It posted cleanly" means nothing. There was no post. Clean syntax is not verification; it's just grammar.
• Reading it over looks safe. That's the trap — plausible code is designed, in effect, to survive a read-through. The errors are in the numbers and the machine interaction, not the syntax.

An AI-generated program is, in verification terms, exactly like a hand-written or legacy program from an unknown source: the only trustworthy check is to execute it against an accurate model of the actual machine.

Verification checklist for AI-generated G-code

Syntax and structure

• Safety line present (G17 G21 G40 G49 G80 G90 or equivalent)
• Correct work offset called (G54 or the one your setup uses)
• Tool length compensation active (G43 H_ on the first Z move after each tool change)
• G28 uses G91 (incremental), not G90
• M30 or M02 at program end

Motion

• No G0 moves into the part (plunges should be G1)
• R-planes in canned cycles are above the part surface
• Z depths match the part design
• Feed rates fit the tool diameter and material

Machine-specific

• Canned cycle syntax matches your control (M29 before G84 if required)
• M codes are valid for your machine
• Feed rates in the right units (mm/min vs inch/min)

Simulation

• Full machine simulation with the actual fixture geometry
• All tool change positions verified
• No collisions with fixture, clamps or machine structure

The first three groups can be checked by reading. The last one cannot — and it is where systemic AI errors show up at once: a Z depth off by a factor of 25.4 from a mm/inch mix-up reads fine, but in simulation the tool plunges through the table.

Where Eureka 3X Pro fits

Eureka 3X Pro reads the raw .nc — wherever it came from, including straight out of a chat window or an automated pipeline — and simulates it against a controller-accurate twin of your machine: real travels, real limits, real offset and tool-length behavior, real material removal. It catches the plausible-but-wrong move that no read-through would, before the program reaches the spindle.

This is what makes AI programming usable rather than reckless. The pattern that works is simple and it keeps a human in charge:

AI proposes → Eureka verifies → you approve.

The AI drafts the program; Eureka executes it against your machine model and shows you exactly what it would do — collisions, over-travels, tool interference, the lot; you decide whether it runs. The verification loop is what turns "the AI wrote it, so I hope it's fine" into "the AI wrote it, and I watched it run safely on a digital twin first." That's not a limitation on using AI — it's the thing that lets you use it at all on a machine you can't afford to crash.

It's also future-proofing. As automated and agentic tools take on more of the programming, the generation gets cheaper and more abundant — which makes independent verification more valuable, not less. The safety layer is the part that doesn't get automated away.

That is the idea behind Eureka MCP, now in early access. It connects AI agents such as Claude directly to Eureka, so the agent that writes a program can also run it on the machine twin, read collisions and alarms, and correct the code before a person reviews it. The loop stays the same — AI proposes, Eureka verifies, you approve — without copying files between a chat window and the simulator.

Already experimenting with AI-written G-code? Don't run it blind. Drop the program into Eureka 3X Pro and watch it execute on a twin of your machine first — that's the difference between a clever experiment and a scrapped part.

Eureka 3X Pro — 30-day free trial, no credit card required.

The right role for AI in CNC programming

AI works best as an assistant, not an autonomous programmer:

• Draft a program structure, then verify and edit it
• Suggest feeds and speeds as a starting point, checked against your tooling data
• Convert between control dialects (Fanuc to Siemens syntax) with human review
• Generate repetitive sections such as bolt circles and arrays
• Explain G-code blocks or control-specific behavior

The programmer keeps responsibility for the program that runs. Simulation is the verification layer between AI output and the machine. For how AI output compares with post-processed CAM code, see AI vs post-processor; for getting better drafts in the first place, see prompt engineering for CNC G-code.

FAQ

Is AI-generated G-code safe to run? Not without verification. AI can produce syntactically perfect code that's physically dangerous because the model has no knowledge of your machine's limits, your setup, or how your control executes the program. Verify it against an accurate machine model before running.

Can ChatGPT or other AI tools write usable G-code? They can produce plausible G-code, and sometimes it's fine. The problem is you can't tell the safe output from the dangerous output by reading it — both look correct. Simulating it on a controller-accurate twin is how you tell the difference.

How do I verify AI-generated or automatically generated G-code? Open the raw .nc in Eureka 3X Pro and simulate it against a twin of your machine. Because it works from the actual program rather than a CAM toolpath, it doesn't matter that no CAM system produced the code.

Won't a better AI model fix this? Not fundamentally. The limitation is access, not intelligence: a model generating text has no channel to your machine's travels, your clamp positions or your offset table. Without that context it can only guess, however capable it is.

Isn't valid G-code enough? No. Validity is a property of the text; safety is a property of the text running on a specific machine, in a specific setup, under a specific control. A perfectly valid program can drive the tool into a fixture the AI never knew existed.

Why can't my CAM simulation check it? CAM simulation runs on a CAM toolpath. AI-generated code has no CAM project behind it, so there's nothing for the CAM to simulate. You need a verifier that works directly from the G-code.

Does this help with agentic / automated programming pipelines? Yes. The more code is generated automatically, the more it needs an independent verification step. Eureka 3X Pro is that step — the "AI proposes, Eureka verifies, human approves" loop that keeps automated programming safe.

This is an emerging area — if you're building AI or automation into your programming workflow, verifying every generated program against a real machine model is the practice that keeps it safe.

Run every G-code program risk-free — before it touches your machine.