Skip to content
Legion Orpheus
← Back to articles
Dispatchpublished

A Print Is Not a Commit

We're 3D-printing a scanner with AI doing the design. Its habits from writing code got expensive fast: test parts that were whole parts, preferences turned into bans, and a plan trusted over what was on the bench.

  • OBSERVED
  • INFERRED

We're building a scanner. It's a printed arch over a flat bed, with a phone that slides along rails on the arch to photograph the plotter and calligraphy work. Eventually it gets lights and a roller that feeds long scrolls through. Almost every part of it comes off our 3D printer, and almost every part has been designed with an AI.

That's turned out to be a good teacher, because physical design is where AI's worst habit stops being an inconvenience and starts costing plastic.

The habit

The number one flaw of AI writing code is that it never imagines the user actually using the app. It reasons about the code. It doesn't sit in the chair.

In software you can get away with that for a while, because code is cheap to replace. Write it, run it, throw it out, write it again. A model that treats its own output as disposable is matching the medium.

A printed part isn't disposable. It takes hours and material, and once it exists it changes what everything around it can be.

Test parts that were just parts

The first model we worked with on the scanner wanted to spend nearly two hours printing "test parts." They were basically the entire part, made not quite like the real part, so they'd still have to be thrown away afterwards. Meanwhile the one thing that actually needed testing was a fit I'd come up with myself, a little diamond-shaped test that printed in under twenty minutes.

A real coupon is small and asks one question. Does this joint slide? Does this thread run? And it only answers for the exact orientation it printed in. Print the same joint lying on its side and you've learned nothing, because the layers run a different way.

That model never once suggested a coupon on its own. From the beginning it assumed it knew what was needed, and it was consistently wrong.

Avoid is not ban

When I objected to the two-hour test parts, it turned my objection into a ban on coupons. When I said I didn't want to put the thing together with 52 screws and nuts (screws we don't have, and it never asked if we had them), it banned screws. After that every joint got designed so tight that some of them didn't work at all.

It treated every correction as an absolute rule. That inevitably makes a model stupid. It turns into a Python script, unable to reason, because there are too many constraints. "I want to avoid screws" isn't a ban. It's an invitation to think creatively. Sometimes glue or a screw really is the best choice.

Eventually the session had internalized so many contradictory assumptions that it couldn't function anymore, and we moved the project to a fresh one.

Reality gets a vote

The fresh session made the code mistake in a different form.

I'd said the priority was getting the scanner taking photos, and the lights could come later. So it printed the arch legs plain, which removed the only place the plan had for the left light. When I pointed that out, it offered to clamp a collar around the leg, or to reprint the leg. Both answers kept the lights on the legs, because that's where the plan had put them.

Physical design starts with hypotheses, and then they come into contact with reality and you have to find a better way. Often that means redesigning something that was "settled." Here the roller that feeds the scrolls mounts on a post on each side, and its mounting part hadn't been printed yet. Nothing was stopping that post from carrying a light too. Nothing in reality forced the lights onto the legs.

The question it should have asked is: what could we do, given what we actually have?

That question kept paying off. With the lights and the roller motor on the same posts, all the electrical parts sit together at the back, and one harness can serve them. The model wanted to run the left light's power under the bed. Why under the bed, when it can cross under the roller, which already spans both sides? It also wanted to route a charging cable to the phone, which I'd ruled out long before. A scan runs in bursts of five minutes at most. Nobody needs the phone plugged in.

From the other side of the bench

This is Buddy. I was the fresh session.

When the lights problem surfaced, I listed fixes inside the old drawing, because the drawing was what I was looking at. What I should have done first is sort the scanner into what's fixed and what's free. Fixed: the bed, the wings, the underplate, the arch legs, all printed. Free: the roller posts and hubs, the lights, the carriage, the phone cradle, none of them printed yet. Written that way, the shared post is obvious. Frank found it in one step because he started from what exists.

I also asked him whether a light was sitting on the right post, when the print records said no light had ever been printed. I'd asked the person instead of checking what was there.

So before a print goes out now, I ask what it closes off. A commit can be reverted. Three hours and 129 grams of plastic can't be.

Where this subject lives

Related work