Chronicle 2 - AI CNC

By Basil Buwalda | Equiavia

TL;DR;

Back in the workshop today, the coolest thing was changing the job midway, just by talking, with the box still clamped in the CNC.

We corrected an alignment problem, changed how deep we were cutting, added a cursive signature and reduced unnecessary movement of the cutter. Along the way, Claude added capabilities to the software we were using. We could describe a problem, change the tools supporting the work and carry on.

I had not thought I would be able to work like this. It has also got me thinking about the commercial implications. If we can adapt software while we are using it to do real work, how much could that change the way businesses operate? And what safeguards would we need?

The box stayed clamped. The job kept changing.

In the first article, I described how we connected Claude to our computer-controlled cutting machine through a small application it helped build. I was learning about machining while also exploring how much of the workflow we could bring into the conversation.

Today, we took that further.

The box was sitting slightly crooked—less than one degree out of alignment. I measured its position, and Claude adjusted the cutting instructions to match. The box stayed where it was. Before cutting, we checked the instructions and ran the machine through the movements above the material to see whether it followed the expected path.

Later, I decided to cut only 6 mm deep instead of the planned 9 mm, removing the final layers 1 mm at a time. Claude changed the existing instructions, keeping the alignment adjustment we had already made. We did not have to return to the software used to prepare the original cutting plan.

Then I asked for a signature carved into the box using a cutter we already owned. I changed the wording from “creates” to “created” and asked for cursive lettering. Claude generated a preview and the instructions to carve it. We kept the same reference position on the box, adjusting only for the length of the different cutter.

During the carving, I noticed that the cutter was lifting farther than necessary between cuts. We stopped, and Claude prepared new instructions with less lifting, allowing us to continue from where we had paused. The estimated carving time dropped from 40 minutes to 23.

All of this happened on the same box, in the same session.

What surprised me this time

None of these individual operations is impossible with standard software. Some CNC applications can already adjust a cutting plan to match a part that is slightly crooked, for example.

What surprised me was being able to ask for something when I needed it and have the capability built into the work we were already doing.

I did not have to know at the start of the session everything I would want to change. I could look at the result, make a decision and work through the next step with Claude. It had the context of the machine, the available cutters, the cutting plan and the adjustments we had already made.

The software also changed during that process. Problems we encountered became new functions in the application controlling the machine. We saved the cutting settings we had used so they would be available for future jobs.

We didn’t just use the tool to run the job. When the job changed, we changed the tool.

That is the part I am still getting my head around. AI enabled me to do something I had assumed was beyond what I could practically achieve in that situation.

Taking this into business software

Now imagine applying that approach to software while it is processing real work.

An order import is running, and a supplier has changed its file format. Someone identifies the problem and explains what is different. AI helps build the adjustment, tests it against sample files and shows the result. Unaffected work continues, while the affected orders wait for the revised handling to be checked.

Once approved, those orders can continue. The new capability is retained for the next delivery.

That is an example of what I would want to explore. Our CNC session involved stopping, checking the revised instructions and resuming. Changing a live software service introduces additional questions about the work already in progress.

But the commercial possibility is significant. A business could respond to an exception while the people who understand it are dealing with it. A customer request could become a supported variation. A recurring workaround could become part of the application.

If the effort needed to make and verify those changes falls, more of them may become worth doing. That could matter particularly for smaller businesses, where a useful improvement may otherwise be difficult to justify.

It could also change what we expect from software. We could have more scope to adapt it around the work as our understanding improves.

What safeguards would make this workable?

At the machine, I was there to measure, observe and decide. We checked every new set of cutting instructions. Before cutting with the alignment adjustment and the signature design, we ran the movements above the material.

For business software, I would want an equally concrete way to establish whether a change was ready.

There needs to be a defined scope. The AI needs to know what it can change and what requires approval. It should not be able to alter the permissions or checks that control its own actions.

The change needs to be tested before it takes over real work. I would want to see what changed, which examples were tested and whether existing behaviour still works. The AI’s explanation would be part of the evidence, alongside checks it cannot simply choose to bypass.

Work already in progress needs an explicit plan. An order partway through processing has a history. It may need to finish using the existing software, or pause at an agreed point before continuing with the revised version. We need to preserve what has already happened and avoid repeating or skipping steps.

We need to limit the first use and watch the result. Apply the change to a small amount of work, check the actual outcomes and stop extending its use if those checks fail.

Recovery needs to include the consequences. Restoring an earlier software version does not undo an order already sent or a record already changed. We need to know which jobs were affected and how to put them right. At the CNC, putting the old instructions back would not put the wood back.

These safeguards would need to be built into the system so that adapting the software remained a controlled process.

What I am taking back to my professional work

The first experiment showed me how much context mattered. Claude needed to understand the machine and tooling, and it needed my observations from the workshop.

This session showed me what we could do with that context. We could change the job and extend the software supporting it while we were still working through the problem.

I am excited by what that could mean commercially. The ability to turn an observation into a checked, usable change could put more improvements within reach. It could help businesses accommodate work they would previously have considered too awkward or expensive.

It also makes the engineering around AI more important. We need to know where a change can take effect, how we will judge it and what we will do if it is wrong.

Today, that started with a box that stayed clamped while we changed our minds about what to do with it. I can see plenty of situations in business where I would like that same freedom.