3D Printed Software
There's more than one way to fabricate
Personally, I’m tired of calling it ‘vibe coding’. It’s a polarising term and, as an industry, we lack the vocabulary to explain when it does and does not work for our purposes. Clearly some of us are trying to ship production software assembled entirely by agents while others are playing with new toys.
But, if you look closer… most people are somewhere in between. They’re not running factories. They’re not just wasting time either.
They’re 3D printing software.
The 3D Printing Experience
3D printing has been revolutionary: faster, cheaper, you can do it at home. But anyone who’s actually used one knows it isn’t for everyone. You don’t just find a model, hit print and get a perfect output.
What filament? What printer? What settings? How do you prepare models that actually print? And then there’s finishing: sanding, post-processing, all the stuff that makes the difference between “proof of concept”, “technically works” and “actually good.”
The majority of 3D printing output is a byproduct of the user learning the ropes. Widgets and gadgets. Small utilities. Lots of misprints.
But at the top tier? People make incredible things. Things they couldn’t have made otherwise. They explore ideas, iterate through failures, come to conclusions nobody else reached by virtue of the fabrication method.
3D printing didn’t replace all fabrication. It added a new mode.
Three Modes of Software Development
Factory mode. You know exactly what you want. You need reliability and scale. Production systems. Well-specified features. Shipping to customers.
3D printer mode. You have a known-ish problem. You’re solving it your way, with your constraints, in your environment. Personal tools. Custom solutions. Learning by making.
Petri dish mode. You don’t know what you’re looking for. You’re cultivating conditions to see what grows. Research. Experimentation. Unknown territory.
Different strategies for different modes with differing measures of success.
If You’re in 3D Printer Mode
Adjust your expectations accordingly:
Iterate fast, expect mistakes. You’ll throw most of it away. That’s the process, not a failure of the process.
Build one to throw away. The first version teaches you what you actually want. Don’t get attached.
You don’t need a good reason. Useful to you is enough. Not everything needs to be a product.
No one else will care. They’ll see rough edges and think it’s cheap junk. That’s fine. It’s not for them.
The prototype-to-product gap is vast. If you want to cross it, that’s a different mode with different demands. Know when you’re switching.
Most people doing vibe coding are in this mode. Solving a known-ish problem their own way. Tolerating rough edges because it’s for them. Not shipping to millions—making something that works in their specific context.
So, is vibe coding good?
That’s the wrong question.
Good for what?
For whom?
When?