How We Actually Split the Work
Most of the hardware on this site was designed with an AI. That sentence gives the wrong idea, so here's what it actually means.
I design my own hardware in Shapr3D. The housings, carriages and hangers on the Caboose Art Wall are mine, drawn by hand. The AI contributes when I ask: parts built in code with build123d and exported as STEP, the math (the Caboose tooth chain, its self-phasing corners), mesh conversions, and checks. I don't review its renders. I open the STEP in Shapr3D and turn it in my hands. When the form is wrong I fix it myself and send it back.
That works because of a set of rules, and every one of them came from something breaking. They live in the AI's memory files, so they carry from one session to the next. Each one below is the rule, what broke, and the check that enforces it now.
Rules for the Machine
These are about the AI not fooling itself. CAD code is unusually good at failing silently: a boolean that does nothing still returns a shape, and a render of the wrong part looks exactly like a render of the right one.
A clean run proves nothing
CAD code fails quietly. A chamfer() call ran without an error and added nothing. A cutter extruded along its face normal, which pointed down, so it landed below the part and removed nothing. The tell was a base volume sitting at exactly 91 cm³ across three separate design changes. Worst of all, a helper that kept only the largest solid after each boolean silently deleted every addition that didn't merge. The script reported success while producing nothing.
Every feature asserts its own volume change, with the right sign and roughly the right size, and asserts the part is still one solid. The AI's own note on the 91 cm³ bug became a habit: “a number that will not move is a cut that is not happening.” When that assert went in, three more failures surfaced immediately.
Check the whole envelope, every build
A gusset on a drawer insert hung 64 mm out the front of the part. Every point-containment probe passed, because probes only test where you think to look, and it was invisible at render scale. I caught it by eye. The cause was a mismatch between two origin conventions, one aligned to the front face and one centred.
Assert the bounding box against the declared envelope on every build. Then, as a final step, intersect the part with a rounded-rectangle prism of its footprint. One line, and nothing can escape the footprint again, whatever got built inside.
Test the test
A containment test returned exactly 83.3% at every location and every depth. That's a constant, not geometry. It had already produced a confident, wrong answer about whether a feature was a post or a bore.
On Roam Touch, a check for flat faces passed while I was looking at a flat top wall. It had been scoped to the surface it had already fixed.
Before trusting a checker, plant a known-bad geometry and confirm it fails with the right number. A suspiciously constant percentage is a red flag, because real geometry varies. Point-in-solid tests moved to the exact CAD kernel instead of a meshed approximation. The flat-face check now covers the entire exterior skin, and every surface it skips is on a named, printed exclusion list.
Print the slice, don't trust the picture
A round void is not always a hole. On Roam Touch, the AI found two “clearance holes” in the end cap and packed them solid. They were half-round open channels, the tracks the cover plate slides in. Sampling rings of points kept giving the wrong answer because the sample radius landed exactly on the wall.
Print a cross-section as text: # for solid, . for air, every half millimetre. A closed ring of # around the axis is a hole. An open side is a channel. It read the port socket, its 1.0 mm cap and the neck width straight off the grid in one look.
Read coordinates out of the model, never from memory
On Roam Touch, features were placed at values remembered from an earlier session. The port tube went at (−65.3, 16.4) when it was really at (−50.87, 13.84). Every feature landed in the wrong place. Part of it came from reading the centroid of a partial cylindrical face, which sits off the axis by about the radius.
Measure the live model every time. Exact axes come from circular edges, not face centroids. And when a scan finds a wall exactly at the edge of the scan range, treat it as unmeasured: an uncapped scan once reported its own limit as a wall and produced two false conclusions.
A check that passes on a part I can see is broken is worse than no check at all.
Rules for Working Together
These are about the handoff between us: who owns the truth, how we describe a part, and what the design is actually optimising for.
A working part is law
On the Caboose motor gear I said: use the exact shaft and hole from the 3MF I shared. That file had printed and fit my motor. The AI spent four rounds second-guessing it. It declared the bore a failed spline, swapped in another file's hub and invented bore diameters. My calipers and one question, “are the shaft thicknesses the same?”, ended it.
Same project, same lesson in a different shape: the printed motor gears had been scaled up 15% to reach the motor standoff. Scaling changes the tooth pitch, to 3.213 mm here, so those gears could not roll on the 2.796 mm racks. Scaling and changing tooth count are not interchangeable ways to resize a gear. Caught before it reached the bench.
When I point at a reference part, it gets replicated exactly, changing only what I named. Every dimension is diffed against it before I see anything. If sources conflict, it asks or measures instead of picking a winner. Fit numbers come from my measured prints, not nominal CAD, because my printed bores are drawn oversize on purpose.
Measure every instance
I fixed a model in Shapr3D and sent it back. The AI measured one slot's depth and applied it to all eight. Mine had a taper. My numbers are drawn by eye, never a formula: the depth steps were 4.40 / 2.60 / 1.30 against length steps of 5.20 / 2.80 / 1.20. That is close enough to look derived, and it isn't.
When I return a model, it gets boolean-diffed against the AI's version, both ways. That once named the whole change in one shot: I had added nothing and removed 9.2 cm³, all of it from one rail. Then the parametric source is rebuilt to match my numbers, so the model stays generative instead of becoming a fork of my mesh.
Speak in bow, stern, port and starboard
Left and right flip depending on which way you're looking at the model and which way it sits on the print bed, and the AI kept generating exactly that confusion. It once read my “the SB lip where the mic goes” as the name of a part.
We talk about CAD in nautical terms, because bow, stern, port and starboard are fixed to the part. They survive rotating it, flipping it for printing and looking at it from behind. The bow gets established once per model and mapped to an axis, and every number gets reported both ways: “the SB lip (+X, x ≈ +40)”.
Design the object, then work out how to print it
An agent was briefed that one end of the Roam Touch bracer “must stay flat, it is the print bed”. It came back with a flat, ugly face. My reply at the time: “don't let print orientation delegate design.” I'd said it before. Trying to get every part printable without support trees can be obnoxious, like my JS code-golf phase. As the AI's notes put it: when avoiding a cost starts distorting the thing itself, the cost was cheaper than the distortion.
Unsupported area gets measured and reported, because I want to know what the slicer will do, but it never constrains the form. “Needs supports” and “cannot be printed” are different things, and only the second is a real objection. The AI's own post-mortem is the part I like: the real failure was not writing it down the first time. Guidance that only lives in one session gets repeated back to you as a fresh mistake.
Every Catch Becomes a Check
The Caboose production track is the clearest example of how this compounds. Its revision log reads like a list of things I caught:
A plug meant to fill a hole filled the open channel instead. The shaft runs through that channel, so it became a pillar in its way.
The arc piece was built with a pipe sweep that overshot the joint planes by about 0.9 mm, into the socket of the next piece. Rebuilt with an exact revolve. Joints are now mathematically flush.
A cut plane left the deep end of the female pocket filled in. The harness now checks 358 mapped void points and 202 solid ones on every build.
A hidden hole sat inside the female pocket, and any fill protruded into the socket. The fill was deleted, and the pocket was verified identical to the standard piece: 972 points, 0 mismatches.
I found each of those once, by looking. After that the harness finds them forever. That's the trade I want: my eye finds a new class of mistake, and the machine makes sure it never costs me attention again.
What No Check Can See
None of the above replaces human eyes, printed parts and iteration. Here's what only showed up in plastic and hands.
The curve that bound
The first Caboose arc jammed. It felt like gear bind, and gear geometry is the obvious suspect. The clue was the pattern: same spot every time, before the bore, only on curves. That points at swept-path clearance, not teeth. The channel seam was pinching the connecting shaft as it went through the bend. The fix was widening the slot from 2.44 mm to 2.64 mm, 0.1 mm per side, on every piece so the straights and curves never step. I printed the arc again: no binding, no rubbing. The straights I'd already printed didn't need reprinting.
The revision before that found something no model could: print distortion over the screw-hole voids raised the tooth valleys across about four teeth at each hole. That made two bind points, fixed to the track, and I confirmed it with a spin test. The fix deleted one hole and moved another 1.5 mm toward the side that doesn't mesh.
The controller I tore apart
On Freeplay, the plan was to use the D-pad and button membranes from an Xbox One S controller. Three days later it was superseded. With the parts in hand, the stack turned out to be tied to the Xbox's curved face, and I switched to dedicated replacement parts.
The workflow that came out of it is a good split: my photos establish the topology and orientation, my calipers establish the hard dimensions, and a printed coupon settles it. When the ABXY test plate passed with the real membrane, that physical result superseded every photo-based estimate before it.
Hands decide ergonomics
Freeplay's thumb positions were a paper estimate until I printed a full-thickness shell and held it. It felt right, so those positions are now locked, and they carried over when the layout changed. Coupons make that cheap. For Roam Touch the AI generates a test piece for every joint: nine joints, 30 g and about an hour and a half of printing, instead of 269 g and eight hours for the whole part. I print them first, in the real material and orientation, because how stiff a snap is depends on which way the layers run.
The eye beats the math
On a synth case, I said “the chamfer's in the wrong plane” five times while the AI's overhang math said it was fine. The math was answering the wrong question, about face angles, while I was looking at a radial tab with its first layer printing on air. When my eye and the math disagree, the eye has been right essentially every time. The rule on its side now: when I repeat a correction, the misunderstanding is the AI's, so stop patching and work out what physical thing I'm looking at.
One Stab, Then Talk
The rule that sums up the whole thing is a collaboration rule. On a set of free-motion handles, the AI ran four rounds of build, render and patch on its own, each one based on its read of a one-line message from me. The result was a yoke you couldn't hold, with both limiter pins on the same side, jammed against the mount. I saw both instantly. It hadn't, because it was checking dimensions numerically and never asking whether the form was right.
So now: on anything new, model one rough pass, hand it over and stop. When a question is about form, don't send me a multiple-choice list of Z offsets. I once replied “bro, i don't understand +26.2 off z or whatever, lol”, then just sent the geometry, which answered both questions. I think in the model. Asking me to answer in prose about it is asking me to work in the wrong medium.
The AI is fast, tireless and good at the math. I'm good at knowing what a part is for and what it'll feel like in my hand. Neither of us gets a good part alone, and we never get one on the first try.
That's the honest version of designing hardware with AI. It isn't typing “make me a controller” and printing whatever comes out. It's a loop: a rough pass, my eye, a printed coupon, a measurement, a rule written down so the same mistake never costs either of us time again, and another pass. The rules make the AI a better collaborator. They don't make it a designer.
Next time: the actual pipeline, from a parametric script to a STEP file I can open, and why a mesh should usually be rebuilt rather than converted when the exact geometry matters.
Nicholas Webb designs and builds hardware at WebbCraft. The rules quoted here are from the working notes the AI keeps between sessions, lightly edited for readability.