Machikoba no Techo

Only someone who can write it can see the danger.

September. The night squid season for swordtip squid — one of the signs of summer here — is drawing to a close. Those who have been taking their boats out at night are quietly shifting to what we call budouika, the "grape squid". We are sincerely grateful for your continued support.

And there is another thing about September: it is the season when bigfin reef squid gather. As the water temperature settles down from its summer peak, the baitfish come alive all at once. The squid change with them, and schools of young squid move into the shallows — rods bend along the breakwaters in the short windows at dawn and dusk. It may be the most exciting time of the year. For anyone thinking of starting eging, it is also the most forgiving season to begin in.

This month, let me write about the back of the factory again. Last month I wrote that even when AI writes it, stopping to check is a human job. This is the sequel. Over the past year, using so-called "vibe coding" hard on the floor, I have felt both its power and a danger of exactly the same size. And I ran into the question I suspect many people are facing: can code that AI produced be brought onto the floor as a black box, without looking inside?

■ Say "I want something like this", and it works

Vibe coding means skipping the detailed specification: you describe what you want in ordinary language, let the AI write it, and take back something that runs. Over the past year we have built a number of small tools for the floor exactly this way. Or rather, we generate tools the way we breathe.

Let me say first that this is genuinely powerful. What used to be shelved as "I'd like to, but there's no time to look into it" now runs the day you think of it. What would have started with a quotation from an outside firm takes shape over a lunch break. For a small factory like ours, there is no more welcome change.

■ Running and being correct are different things

And yet the most frightening thing this year was precisely that it does run. What comes out usually works. The screen looks clean, the numbers appear. Because it runs, you cannot tell from the outside whether it is sound or dangerous.

Rounding that is subtly different in one place. Undefined behaviour when a value arrives from outside the expected range. Errors swallowed in silence so that everything proceeds as if nothing had happened. You will not see any of this by staring at a working screen. The only people who see it are those who have written that kind of code themselves and been burned by it.

In the end you cannot be at ease until you have followed all of the code that came out. The time you were supposed to save by delegating comes straight back as reading. The threshold for building fell enormously; the threshold for noticing danger did not. That asymmetry is the clearest thing I learned this year. Put in our terms, it would be like standing in front of a 40-million-yen machining centre and saying "it ran, so it's fine". That is never allowed.

■ There is no ideal workpiece in a small factory

So is it an unusable tool? Not at all. In some parts of our work it fits better than anything. But to explain that I need to take a detour through the reality of a small factory.

In my case I routinely do something slightly odd: I generate NC — machine language — by vibe coding. For writing code that outputs NC, Python is usually chosen automatically; in most cases I replace it with Ruby. That is my style.

Modern NC machine tools are extraordinarily precise. Give them an ideal material, an ideal shape and ideal dimensions, and they will cut a finish that astonishes you. But in our workshop those ideals are almost never in place. You have to get it done with whatever is at hand. Material is uneven; shape and size differ every time. The very premise of "as drawn" is not in front of us.

I call this "the spirit of getting it done with what you have". It is the strength of a small factory and our pride, but from the point of view of someone writing a program it is a real nuisance. Because the dimensions differ every time, you cannot write a procedure with hard-coded numbers. Instead of "cut this shape to this dimension", it has to be rewritten as "measure what is in front of you and derive the cut from that value". In other words, the level of abstraction has to be raised considerably. That is the hardest part of programming in a small factory.

■ Perfect for fitting to the workpiece, and for reverse engineering

And this way of working — fitting to the actual piece — resembles vibe coding to a surprising degree. There is no perfect specification first; you close in on the object in front of you, cutting and offering it up, offering it up and cutting again. Have it produce something that runs, point at what is wrong, have it fixed, and try again. Because you can move your hands before the specification is settled, it fits the "get it done with what you have" floor remarkably well.

Above all, vibe coding is a good complement for the hardest part: raising the level of abstraction. Show it one hard-coded version and ask for something that still works when the dimensions change, and it picks out what should become a variable. The part of generalisation that used to take a person days — finding the angle of attack — is cleared away at a stroke. That is exactly the capability our "get it done with what you have" floor was missing.

The other good fit is reverse engineering: poking at a mechanism you do not understand from the outside and reconstructing the logic behind it. For reading unfamiliar data formats, or long code someone wrote long ago, and working out what it does, it is astonishingly dependable. This is territory we did not understand to begin with, so an error costs little. Once you have the angle, a person can verify the rest.

Close to home: the NC programs the machine manufacturers themselves output. Honestly, I do not much like them. No indentation, unhelpful comments, no way to read what they are doing. A program you cannot read is a program you cannot stop and check. AI fills that gap. Ask it to add indentation and comments because the code is hard to read, and it comes back exactly that way. Say the abstraction is too low and ask for it to be broken into subroutines, and it divides the code into meaningful blocks. Same behaviour, arranged into a form a person can read — that may be the use we reach for most often right now.

What troubles us most is that nowhere is it written which variables a subroutine has side effects on. Call it and something changes. But what changes is unknown until you have read the whole thing. Have AI read it and ask it to list, in a comment at the top, the variables written inside — and it picks them out. That is work a person spent half a day on.

One concrete example. We often have AI rework the NC programs for our wire EDM machine. It is so convenient it nearly gave me a nosebleed. In the NC world, even though everyone calls it "G-code", each manufacturer has its own habits of writing — dialects, in effect. This model is written this way; that one needs this command. For a human it is a matter of comparing manuals and learning on the floor.

The AI reads that off the style of the program you hand it. It senses whose conventions the code follows, and writes the additions in the same conventions. Feed it the manufacturer's manual as well, and it starts using macros specific to that model without being told. It reads that "this machine offers this instruction" and writes it with a straight face. That tacit knowledge, accumulated on factory floors over long years, can be drawn out like this — honestly, it gave me a chill.

But we never send a program produced that way straight to the machine. We debug. It always goes on the real machine, stepped through line by line, with the values of the variables and the movement of the wire checked by eye. This is where the M01 (optional stop) I wrote about last month earns its keep. However fine the work looks, if you lack the ability to debug it on the real machine, you cannot use this tool. Or rather, I believe you must not. Used as a tool for producing correct answers it is dangerous; used as a tool for finding the angle of attack it is formidable. But confirming that angle is always the human's side.

■ Should it be a black box?

Which brings us back to the opening question. Can code that AI produced be brought onto the floor without looking inside? Honestly, we distinguish between cases where it may and cases where it may not. For now the line we draw is by where it sits. Where a mistake can be noticed and fixed afterwards, where the only thing lost is time, we use it without following all of it. Where a machine moves, dimensions are set and material is consumed — where there is no second attempt — a person reads all of it, however long the way round.

The awkward part is that the black box is not only the part AI wrote. Today's software is built by calling in large numbers of components — libraries published by someone, somewhere, from GitHub and elsewhere. There was a large incident in the JavaScript world only recently. (In fact, backdoors seem to come up almost daily.) A library that a great deal of software rests on was taken over and had a mechanism embedded in it that ran on installation and spread itself onward to the next package. Hundreds of packages appear to have been contaminated within hours. Not long before that there were cases of interception in transit to swap a payment destination — that is, tampering with the part that handles money.

Ask an AI for "something like this" and it will naturally choose and include convenient components. Part of why it is fast is that it does not write those components itself. What we receive, then, is a double structure: inside the box the AI wrote, it is calling someone else's box. No craftsman cuts material without knowing what is mixed into it. I think software is the same.

This question — whether you can trust someone else's box — is not new. In the mid-1990s, D. J. Bernstein, who wrote the mail transfer program qmail (we ran it ourselves more than ten years ago), did not even trust the standard C library — the components that come with the language, which everyone uses without question. He stated in his design notes that he had largely given up on the standard library, and replaced the parts where accidents happen most easily, such as string handling and memory management, with small components of his own that he had developed over years. He did not go so far as to rebuild the operating system, but on one point he was thorough: put the dangerous parts under your own control.

What runs through qmail is the idea of reducing, as far as possible, what you have to trust. Beyond writing his own components, he divided the inside of the program into small parts by role, built so that even his own parts do not trust one another. If one of them is taken over, it cannot go any further. Someone thought this through thirty years ago. Of course we cannot imitate writing every library ourselves. But the idea — draw your boundaries on the assumption that untrustworthy things will get mixed in — carries straight over to today.

And the frightening thing is that if the box is too big, there is no way back. Take something you do not understand deep inside as one large lump and you cannot separate it out when something happens. So the countermeasure has to be taken in the design: keep it in a form you can always swap out. This part can be replaced with something else; remove this component and the whole still runs. Build it that way and, on the day something happens, you can throw away just that box.

What that requires is design skill in the object-oriented sense. What do you treat as one unit, what do you expose to the outside, how much of the inside do you hide? Where do you draw the boundary? What used to be thought of as "writing nicely" has become a practical necessity for not taking dangerous things inside. Precisely because AI writes the contents, the ability to decide the boundary is what is needed.

And this line moves if you leave it alone. After a run of things going well, people inevitably want to make the box bigger. Worse, the ability to notice danger dulls in exact proportion to how little you write yourself. This tool has the property that the more you use it, the less you can see through it. So the line has to be redrawn on the human side, not the tool's.

■ Systems engineering, more than coding

Looking back over the year, this is where my impression changed most: what will really be indispensable from here is not coding itself but systems engineering.

Deciding what to build and what not to build. Drawing the line between what is delegated to the machine and where human judgement takes over. Preparing, before you build, how you will get back when it stops working. Deciding where the data sits and who is responsible for it. However clever it becomes, AI will not decide these for you — because deciding them requires knowing the work on the floor.

As the time spent writing code fell, we began spending time on design, on operation, and on judging when to stop. Ironically, the disappearance of the effort of writing made the weight of the work that comes before writing much easier to see.

■ Every process in-house, in Arita

In a small company, the person who built it uses it, and when it breaks the same person fixes it. So "can we build it?" matters far less than "is this within what we can look after ourselves?" Keep it to a scale you can restore under your own power on the day it stops. It is not flashy, but I believe this is what DX cut to your own size means.

This is exactly the same story as making egi. Prototypes come together far faster than before. But the step of confirming them at sea cannot be shortened by any means. What decides good from bad, in the end, is always the sea. The faster we can build, the more time we put into confirming — that is the use we have chosen.

In a small provincial town — Arita, in Saga Prefecture, Japan — we continue to make egi in-house through every process, from design to mould cutting, volume production and sale. That is what August had me thinking about. Components written by someone somewhere in the world run inside our own factory, and an AI reads the dialects of our machines. In the middle of that, what should be left in human hands? The answer is not half arrived at, but I intend not to stop thinking about it.

■ Going to sea this month

September brings a run of new colours and products for us. Akazamurai Meteor Glow Orange is an orange that changes expression between phosphorescent glow and UV illumination; it is scheduled for release this month. JetChaser Purple Edition, aimed at shore tip-run, is also this month. In addition, JetChaser size 3.0 and size 3.1 will go on general sale, with shipping planned for the end of September.

This year also marks the fifteenth year since the "Akazamurai" colour of EgiSharp was born. At the end of last month we released images of a colour commemorating the fifteenth anniversary. The fact that it has gone on being chosen for fifteen years is not our own confidence — it is the answer given by the people who have used it.

However clever the tools become, the one who judges at the end is a person, and what decides good from bad is the sea. We will keep that in mind and go on making things, one step at a time. Thank you again for your support this month.

September 2026
KeyStone Corporation
Nobuhide Kanagawa, Representative Director