You can't see a refactor. So try to break the machine.
6 Aug 2026
You paid for a refactor. The arm runs the same path. The screens look the same. Your engineer says the architecture is cleaner and the code is safer. From where you sit, nothing changed. Did you just buy nothing? If you build machines for a living, sooner or later you will sit in front of exactly this question, and you'll have every right to ask it. This note is how I answer it, because making invisible work perceivable is part of what I sell.
Good deep work is invisible on a good day
A refactor doesn't add motions or buttons. Its output is the absence of disasters: the crash that doesn't happen when a sensor drops out, the ruined workpiece that never gets made, the hour of downtime that never starts. You didn't buy new behavior on the happy path. You bought behavior under failure. And failure, by definition, is never on the demo script.
Don't read the code. Break the machine.
So when I deliver deep work, I don't ask you to review code. I hand you a checklist for breaking the machine, and you run it with your own hands:
- Pull a sensor mid-run, or block it. The machine must come to a clean, immediate safe-stop, with an error message that says exactly what happened. Not freeze, not guess, not keep moving.
- Feed it an out-of-range workpiece. The system must refuse to start the motion at all. A machine should never move while blind to what it's holding.
- Make it wait on something that never arrives. It must time out in seconds and report, instead of hanging forever.
When the machine survives everything you can throw at it and fails safe every single time, you have seen the refactor. That's what the money bought: not prettier code, but a machine that has lost the capability to hurt itself, the workpiece, or the person standing next to it.
Your own engineer's easy tweaks are evidence, not a refutation
"Our field engineer adjusted tool parameters and renamed points himself — so what exactly did the refactor buy?" The opposite of what that question implies. Field configuration going in easily, without touching the core, is precisely what a decoupled foundation looks like. Before, a tweak like that meant editing tangled logic and hoping; now it lands in a slot the architecture left open on purpose. The foundation and the day-to-day adjustments aren't rivals: one is the building, the other is the furniture.
One rule keeps this honest: every field tweak flows back and gets merged into a single clean mainline. No forked copies drifting on the shop floor, no black box only one person understands.
What this converts to
Three things, all of them commercial. You can demo destructively in front of your own buyers — block a sensor while they watch, feed a wrong part, let the machine prove it can't be fooled. That kind of confidence sells better than any brochure. After-sales gets quieter, because the mistakes operators actually make get intercepted at the source instead of turning into warranty fights. And the next product variant becomes configuration on top of the same foundation, not a rebuild.
The sign-off checklist
If you're about to sign off a refactor you can't see, ask for these four things and watch them happen:
- Break-and-stop. Cut a sensor signal; the system safe-stops with a clear error.
- Boundary rejection. Enter out-of-range part parameters; the system refuses to start.
- One mainline. Every field tweak has been merged back into a single standard version; no forks.
- Room to grow. The configuration pages have space for the next size, the next tool, the next variant.
You don't have to take this on faith — the checklist is runnable. I put the method in a public repo: a machine you command over MQTT, a gate layer that classifies every command by what it could do wrong, and an acceptance harness that runs the break-it attempts above. About a second, nothing to install. Eight attempts, eight refusals — and the same harness runs in CI on every push, so the safety property can't quietly rot. There's a browser HMI too, if you'd rather pull the sensor mid-move yourself and watch it stop. Code →
Acceptance by destruction is my standard way of delivering work you can't see, written from real industrial practice rather than theory. Everything here is generalized: no specific client, machine or process is described, and no numbers appear that I didn't measure.
Companion notes: the design method behind those safe-stops — Industrial reliability: change the denominator; why the same gates make heavy AI use safe — I use AI heavily. The machine still can't hurt you.; and the same trust logic at project scale — One email per milestone.
If a machine you build needs an interface, a device connection, or data that has to land somewhere else, tell me what it's costing you now. You'll get an honest read on whether it's solvable, and usually something running to look at. Start here →