How custom code is killing AM automation
RECODE.AM #3
Automation in 3D printing has always been seen as the key to its industrial adoption. In theory, it all seems simple: a company implements AM technology, identifies repeatable tasks, creates macros and scripts to optimize production, and then scales the solution across other production lines, plants, or regions.
In reality, however, this model—though seemingly logical—quickly hits a hard ceiling. That ceiling is custom code: code written for internal needs, often without a shared language, framework, or standardization.
Instead of driving progress, it becomes a barrier that’s hard to overcome.
At first glance, writing custom scripts may seem like a natural step for any company operating in a digital environment. After all, code flexibility allows tools to be tailored to specific process requirements, machines, materials, and workflows.
Companies hire engineers who create their own automation tools in Python, Bash, C++, or even VBA—handling tasks like exporting, slicing, nesting, geometry verification, and production monitoring.
And these tools really do work—up to a point.
The problem emerges when an organization wants to move from prototyping to serial production.
When it wants to integrate AM with ERP, MES, or PLM systems.
When it needs to scale a solution from one engineer to an entire factory.
That’s when it becomes clear that each of these tools was custom-built for a specific situation by a specific person, who often didn’t leave thorough documentation.
Attempting to standardize these tools, modify the code, and adapt it to a new environment often costs more than building a new system from scratch. Worse still, many of these tools are tightly coupled to specific software that can no longer be updated, or to specific input file structures that have since changed.
In this sense, custom code in AM is no different from legacy software in other industries.
It’s developed quickly, reactively, without scalability in mind. But unlike traditional industrial solutions, the AM industry is too young to have established standards.
There’s no equivalent yet of OPC-UA, MTConnect, or an industrial-grade version of G-code. Every 3D printer has its own API. Every piece of software has a different plugin system (if it has one at all.)
In this chaos, companies try to rescue themselves with in-house tools—but that’s like trying to survive a storm on a raft built from salvaged planks.
That’s why there’s growing talk of the need for an “API-first” approach—an architecture where the system is built from the ground up as a platform with an open, well-documented, and scalable interface.
One company offering such a solution is Dyndrite. Instead of creating another “window-based” machine interface, Dyndrite builds a computational engine and a set of APIs for managing the entire AM process.
Dyndrite doesn’t dictate what the user interface or working environment should look like—it allows companies to build their own tools on a stable and efficient foundation that ensures compatibility, modularity, and easy integration with other systems.
This approach could be a turning point for the entire AM sector.
Instead of writing scripts to repair STLs, companies can use geometric functions via API.
Instead of manually configuring supports for every file, they can implement automated rules.
Instead of patching workflows with CSV files and shared folders, they can create standardized pipelines that work identically at every station.
Even more importantly, they can version, test, document, and deploy those tools just like in a mature DevOps environment.
But this isn’t just about technology. It’s about changing the engineering culture. Many organizations still treat software as an “extra tool”—something you install, configure, and use.
In the world of AM, that’s no longer enough.
We need a shift in thinking: from “install and click” to “build and integrate.” Only then will it be possible to create truly automated, scalable, and safe additive manufacturing.
Custom code won’t disappear overnight—nor should it. It provides immense flexibility and fosters experimentation. But if AM is to grow beyond being a niche technology composed of experiments and proof-of-concepts, it needs to move past this stage.
It needs to enter the phase of standardization, automation, and repeatability.
And to do that, it needs open, well-designed platforms—not yet another collection of scripts that only work on one person’s computer.
The custom code ceiling is not impenetrable—but breaking through it requires a shift in mindset, team structure, and the selection of proper technological foundations. Dyndrite is just one example showing that such a shift is possible.
The rest depends on whether the industry truly wants to evolve—or just keep repeating what once happened to work.