Can ChatGPT Write G-Code? What a Machine Shop Must Check First

Yes, for simple programs. ChatGPT can write drilling, facing and basic pocket code that is syntactically sensible, but its drafts can carry errors a machine will act on: missing offsets, wrong cycle parameters, unsafe rapids. Never run its output until it has been simulated, read line by line and dry-run, and a programmer has signed it off.

The risk is asymmetric. A wrong paragraph in a report costs a correction; a wrong line in a program can cost a vice, a spindle or a hand. Below is a deliberately faulty draft of the kind a bare prompt can produce, taken apart line by line, followed by the checks that stand between the draft and a cut.

Follow me on Instagram@sagnikteaches

A plausible draft with eight faults

Take a simple job: a 100 x 60 x 12 mm aluminium plate held in a vice, top face skimmed by 0.5 mm with a 50 mm face mill, then four 6 mm holes drilled through near the corners, 15 mm in from the short edges and 10 mm in from the long edges. Work zero is the lower left corner of the top face, with Z zero on the top surface. A bare prompt such as "write G-code to face and drill this plate" produces something like the following (this draft is written for illustration to show typical faults and was not generated in a measured test):

Connect on LinkedInSagnik Bhattacharya

O1001
G21 G90 G54
M06 T1
S3000 M03
G00 X-30 Y30
G00 Z-0.5
G01 X130 F800
G00 Z25
T2 M06
S2500 M03
G00 X15 Y10
G81 Z-12 R3 F250
X85
Y50
X15
M30

It looks complete, and a quick reader may nod it through. Here is what is wrong, line by line.

Subscribe on YouTube@sagnikteaches

1. No tool length offset. There is no G43 H1 after the tool change. The Z moves are therefore measured from wherever the control thinks the tool tip is. On a real machine this is how a face mill meets the vice at rapid speed.
2. Missing decimal points. On many Fanuc-style controls, X-30 with no decimal point can be read in the smallest input unit, so -0.030 mm rather than -30 mm, depending on a parameter. A program that works on one machine moves almost nowhere on another.
3. Rapid plunge into stock. G00 Z-0.5 is a rapid move to a depth below the top face, taken at the start edge. If the cutter is not already clear of the part, it hits it at rapid speed. The approach should be rapid to a safe height, then a feed move down, ideally off the part.
4. The face pass does not cover the plate. One pass along Y30 with a 50 mm cutter covers Y5 to Y55, leaving 5 mm unfaced on each side of a 60 mm plate. The tool is the right width for a pass, but the plan was wrong.
5. Tool change without a safe retract or spindle stop. The program goes straight to T2 M06 from Z25 with no return to the machine's tool-change position and no M05 and coolant off. Some controls will do it; many require a move to the reference first.
6. Drill depth that does not clear the plate. Z-12 stops the drill tip at the bottom face of a 12 mm plate. With a standard drill's conical point, a full-diameter hole is not through, and the parallels or vice jaw sits right under it. A through hole needs the depth to include the point length and some clearance, such as Z-15, and the parallels must then sit clear of the hole positions so the drill breaks out into air.
7. No peck cycle or retract plane for the drill. A G81 feed with no pecking for a 12 mm deep hole in aluminium with a 6 mm drill (twice the diameter) can work, but chip evacuation is the usual weak point; a peck cycle such as G83 with a Q value is the safer default for depth beyond about three times the diameter, and a good prompt should ask for it. There is also no G98 or G99 to say where the drill returns between holes.
8. No cycle cancel and no clean end. There is no G80 to cancel the drilling cycle, no return to a safe position and no M05 or M09 before M30. The next program loaded may start with the cycle still active.

Here is a corrected version that a programmer could sign off after the checks later in this tutorial. It is also written for illustration, in Fanuc-style syntax, and must be adapted to your control:

O1001 (PLATE FACE AND DRILL - ILLUSTRATIVE)
G21 G17 G40 G49 G80 G90
G54
T1 M06 (FACE MILL 50 MM)
S3000 M03
G00 X-30. Y20.
G43 H1 Z25. M08
G00 Z5.
G01 Z-0.5 F300.
G01 X130. F800.
G00 Z25.
G00 X-30. Y40.
G00 Z5.
G01 Z-0.5 F300.
G01 X130. F800.
G00 Z25.
M09
M05
G91 G28 Z0.
G90
T2 M06 (DRILL 6.0 MM)
S2500 M03
G00 X15. Y10.
G43 H2 Z25. M08
G98 G83 Z-15. R3. Q3. F250.
X85.
Y50.
X15.
G80
M09
M05
G91 G28 Z0.
G28 Y0.
G90
M30

Two passes, at Y20 and Y40, cover the plate with overlap. The cutter starts and ends clear of the stock, tool offsets are called, decimals are explicit, the drill goes to Z-15 with pecking, and the cycle is cancelled. Even so, this is a program, not a proven program. It still needs a read-through against your fixture and tool table. I have not claimed it is right for your machine because it depends on your tool numbers, offsets and control.

Prompts that remove half the faults before you read a line

A bare "write G-code" is the cause of most of the faults above. Give the model the facts a programmer would ask for. Ask it for assumptions, and ask for safety lines explicitly:

Write a CNC program for a [control, e.g. Fanuc-style 3-axis vertical mill].
Stock: aluminium 6061, 100 x 60 x 12 mm, held in a vice with 8 mm of it above the jaws [state your own figure]. Work zero: lower left corner of the top face, Z zero on top. Units: mm, absolute. Use G54.
Tools: T1 50 mm face mill (5 inserts), H1/D1. T2 6.0 mm carbide drill, H2.
Operations: (1) face 0.5 mm off the top, (2) drill four 6 mm through holes at X15 Y10, X85 Y10, X85 Y50, X15 Y50.
Requirements:
- Start with a safety line (G21 G17 G40 G49 G80 G90).
- Write every coordinate with a decimal point.
- Call tool length offsets (G43 Hn) after each tool change; retract to a safe Z before every change.
- Approach with feed moves, never rapid, below Z5.
- Peck drill with G83 and a Q value; cancel with G80.
- Put a comment on every operation.
- At the end, list every assumption you made and every value I should verify (speeds, feeds, depths, offsets).
Do not use cutter compensation, macros or subprograms.

The last line matters: restricting the draft to plain moves keeps the checking job small. Features such as cutter compensation, canned pocketing cycles and macros each add a way to be wrong.

A ten-program test log for your own shop

As with any AI tool, the useful question is "how often is it wrong on our jobs?" A published failure rate for someone else's prompts says little about your control and your parts. This is a test you can run in a morning on your own machine's simulator, with no cutting.

1. Write ten prompts for the simple parts you actually make: a facing pass, a four-hole pattern, a deep hole with pecking, a tapped hole, a rectangular pocket with a finishing pass, a circular pocket using arcs, an outside profile with cutter compensation, a slot with arcs, a bolt circle of six holes, and a simple turning job if you run a lathe.
2. Use the same prompt format each time, stating the control, stock, work zero, tools and the safety lines.
3. Run each result through a simulator that fits your machine type.
4. Log every failure in one sheet, with a category.
5. Add a human-review column: faults you found by reading that the simulator did not report.

Columns that make the log useful: program number, operation, syntax error (control would reject it), simulator alarm, path fault (gouge, rapid into stock, missed material), logic fault (wrong depth, wrong side, wrong count), missing safety line, found only by reading, and verdict (usable after edit, rewrite, discard). Here is a template with illustrative entries; the verdicts are invented, to show the layout, and are not results:

After ten programs, count how many were usable after a short edit, how many needed rewriting, and how many faults only a human reading caught. If more than a couple of dangerous faults reached the "found by reading only" column, you now know the simulator is not your safety net. Rerun the test when you change the control, the prompt or the model, and keep the log as a record of what you tested.

What a simulator catches and what it cannot

A free simulator such as CAMotics (open source, free, for Linux, macOS and Windows, according to its own site) is a good first gate for 3-axis mill programs: it shows the tool path and the cut workpiece in 3D. Its site is also straightforward about limits: it covers 3-axis only, has no lathe or five-axis simulation, and does not yet detect over- or under-cutting, collisions with the tool shaft or fixtures, or rapid moves in the material. Those you have to spot yourself in the 3D view. Check the current version for changes. Other options include the graphics mode on your own control, backplot in your CAM software and commercial verification packages; ask your machine builder what suits your control.

So a clean simulation tells you the path is plausible against a model. It does not tell you the program is safe on your machine this morning.

Checking feeds and speeds with a calculator, not with the chat

Feeds and speeds are arithmetic, and language models make arithmetic slips. Check with two lines of maths. The tutorial on why AI is bad at maths explains why, and the sums here are short enough to do by hand.

• Surface speed = pi x diameter (mm) x rpm / 1000. The 50 mm face mill at 3,000 rpm gives 3.1416 x 50 x 3000 / 1000 = about 471 m/min. The 6 mm drill at 2,500 rpm gives 3.1416 x 6 x 2500 / 1000 = about 47 m/min. Compare with the tool maker's recommendation for aluminium and your tool coating.
• Chip load per tooth = feed (mm/min) / (rpm x number of teeth). The face mill at 800 mm/min, 3,000 rpm and 5 inserts gives 800 / 15,000 = 0.053 mm per tooth. The drill at 250 mm/min and 2,500 rpm gives 0.1 mm per revolution.

If the AI picks a feed of 2,500 mm/min on the same face mill, chip load is 0.17 mm per tooth, over three times higher; the sum shows it in ten seconds. The same discipline applies to the tapping example above: for a rigid tap, feed per minute equals pitch times rpm, so M6 at 1.0 mm pitch and 500 rpm is 500 mm/min, and a program that writes F1.0 under feed-per-minute mode is asking for a feed of 1 mm a minute. That illustrative log entry is a mix-up between two feed modes, and it belongs in the logic-fault column.

The dry run, step by step

Once the simulation and the read-through are clean, move to the machine. Exact steps and switch names vary by control, so follow your machine builder's manual. The principles are the same everywhere:

1. Raise the work offset. Shift the Z offset up by 50 to 100 mm so the program runs in the air above the vice with no part or a scrap blank.
2. Single block. Step through one block at a time, with rapid override at its lowest setting. Watch the axis display against what the block says.
3. Run the first tool change and offset call slowly and watch the Z position against the tool table.
4. Feed hold in reach. Keep a hand on feed hold and the other near the emergency stop for the first rapids.
5. Restore the offset. The most common error in a dry run is forgetting to put it back; use a written step on the setup sheet.
6. Run the first part at reduced override, with the door shut, and watch the first cut. Measure the first article before running more.

Treat a dry run as a separate event, not a formality. Skipping it because "the simulator was clean" is how a missing offset reaches a vice: the table above shows the simulator may never have seen that fault.

A sign-off sheet that makes someone accountable

Program ownership matters as much as the technique. Whoever approves the program is responsible for it, whether it came from CAM, a colleague or a chat window. A one-page sign-off sheet might hold:

• Source of the program (CAM, hand-written, AI-drafted) and the prompt used.
• Control, machine and post-processor or dialect.
• Simulator used and a screenshot of the result.
• Line-by-line read completed by [name], with the date.
• Feeds, speeds and depths checked by calculation.
• Tool list matches the tool table; offsets confirmed.
• Dry run done, with offset restored.
• First article measured against the drawing.
• Programmer sign-off.

The record also helps your own learning. After a few weeks, the pattern in the "AI-drafted" jobs tells you which kinds of draft saved time and which cost more checking than they were worth. Where the checking takes longer than writing the program yourself, write it yourself.

Jobs where ChatGPT earns its place beside the machine

Drafting a cutting program is the riskiest use. Safer uses where it still helps:

• Explaining code. Paste a program (yours, not a customer's confidential one) and ask for each line in plain English. A new operator learns faster, and it often reveals a line nobody understood.
• Reviewing a human program. Ask: "List anything in this program that could crash a three-axis vertical mill, and anything that is dialect specific." It will miss some things, but it can flag a missing G80 or an unsafe rapid. Treat the answer as a second opinion.
• Writing a setup sheet from a finished, proven program: tool list, offsets, stock, fixturing notes and inspection points.
• Drafting macros or probing routines for a programmer to review, where the control manual is the reference.
• Converting formats or tidying comments, with a diff to confirm that only comments changed.
• Training notes that explain what each G and M code does on your control, built from your own manual.

The first of these has the lowest risk and the fastest payback. Take a program with 140 lines that only the retired programmer understood; an hour with the chat tool and a person checking each explanation against the manual produces a commented version the whole shop can read.

The routine from prompt to first article

The routine in short: sort the job by risk, give a full prompt, simulate, read, calculate feeds, dry run, sign off. If drawings come from customers, the tutorial on reading engineering drawings with ChatGPT covers NDAs and export-control checks before you paste anything. Once programs are proven, AI quality control for small manufacturers covers checking what comes off the machine, and a builder's safe-use routine for AI answers shows the same habit of treating AI as a draft in another trade. If you would like help building the prompt, the checking sheet and the sign-off for your shop, that falls within my AI implementation consultation, and a 1:1 call can be booked here. This tutorial is not a safety certification: your machine builder's manual and your site's safety rules come first.

Questions machinists ask about AI-written programs

Which controls does ChatGPT know best?

OpenAI does not publish which control dialects its models handle best, so assume nothing and test your own with the ten-program log. Always state your control and machine in the prompt, and check every cycle call against your own manual, because cycle parameters differ between controls.

Is a simulator enough to make a program safe?

No. A simulator checks the path it is given against the machine and tool it models. It cannot know your real work offset, your tool lengths, a clamp in the way or a dialect difference your control reads differently. Treat simulation as one gate, followed by a line-by-line read and a dry run.

Can it write lathe programs?

It can draft simple turning programs, but the risks are higher, because canned cycles such as roughing and threading differ widely by control and the free simulators often do not cover lathes. Check the cycle syntax in your manual and use your control's graphics mode or a full simulator before a cut.

Should it write programs for a production run?

Not on its own. For a repeat job, a program from your CAM system, proven on the first article, is the safer source. Use ChatGPT for jigs, fixtures, one-off simple parts, macro ideas and explanations of existing code, with the same checks every time.

Can I paste a customer's part into the chat?

Only if your agreement with the customer allows it. A geometry description for a fixture plate is different from a customer's confidential drawing. See the tutorial on drawings and NDAs before you paste anything that belongs to someone else.

Further reads

• How to Stop AI Tools Training on Your Business Data — Switch off training on your data in the main tools.
• Can AI Schedule Production for a Small Maker? A Spreadsheet Test — Schedule the jobs once the programs are proven.
• Where Should a Small Manufacturer Start With AI? — See where G-code help ranks among a maker's AI options.
• How Much Does AI Visual Inspection Cost a Small Manufacturer? — What visual inspection costs after the part is cut.
• AI for HVAC Contractors: Getting Answers From Manuals and Spec Sheets — Asking questions of manuals, a method that suits a controller manual too.
• AI Systems for Manufacturing: MRP Add-On or Chatbot on Your Own Data? — Choose between an MRP add-on and a chatbot on your own documents.
• How to Use AI in a Machine Shop: Five Jobs Beyond Quoting — RFQ triage, work instructions and inspection paperwork costed in hours and dollars, plus scheduling notes and customer updates for a 12-person shop.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: the CAMotics project website (features and listed limitations); the LinuxCNC G-code reference (G43, G80, G83, G84, G98 and G99); a published summary of the FANUC decimal-point input parameter. All checked 5 November 2026. The programs and logs in this tutorial are written for illustration and were not produced by a measured test.