You can’t see a refactor. So try to break the machine.
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. What it produces is disasters that don’t happen: the crash that doesn’t occur when a sensor drops out, the ruined workpiece that never gets made, the hour of downtime that never starts. You didn’t pay for new behavior when everything goes right. You paid for behavior when things go wrong, and failures are never in 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. It mustn’t freeze, guess, or keep moving.
- Feed it an out-of-range workpiece. The system must refuse to start the motion at all. A machine should never move when it can’t tell 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 safely every time, you have seen the refactor. That’s what the money bought: not prettier code, but a machine that can no longer 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 answer is the opposite of what the question implies. Field configuration going in easily, without touching the core, is exactly what a well-separated foundation looks like. Before, a tweak like that meant editing tangled logic and hoping for the best. Now it goes into a slot the architecture left open on purpose. The foundation and the day-to-day adjustments aren’t in competition: 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 run destructive demos in front of your own buyers: block a sensor while they watch, feed in a wrong part, and let the machine show it can’t be fooled. That confidence sells better than a brochure. After-sales gets quieter, because the mistakes operators actually make are stopped at the source instead of turning into warranty disputes. And the next product variant becomes configuration on 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, and the system stops safely with a clear error.
- Boundary rejection. Enter out-of-range part parameters, and the system refuses to start.
- One mainline. Every field tweak has been merged back into a single standard version, with no forks.
- Room to grow. The configuration pages have space for the next size, the next tool and the next variant.
Acceptance by trying to break things is my standard way of delivering work you can't see, written from real industrial practice. Everything here is generalized: no specific client, machine or process is described, and no number appears that I didn't measure.
Related 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.