Automation is great for redundant processes and ensuring consistency. But there's a right time and a wrong time to reach for it.
I want to share some thoughts and past experiences on automating processes, specifically where I've seen it go wrong and what I've learned from it.
Why Consistency Matters
The fewer one-off cases and derivatives a pipeline needs, the more scalable it is. Consistency leads to predictable outcomes and predictable memory usage. I've seen this proven in shader development; fewer permutations mean less complexity to manage, lower compile times, and a more stable pipeline overall.
result of the tool I wrote to batch swap shaders and update their textures.
Too Much Too Soon
That said, I see too many developers reaching for automation before the pipeline is actually ready for it.
The order matters: first, you need to understand and fully define the pipeline you're trying to streamline. Only then can you figure out how to get there: how much time the code will actually take, how to break it into manageable pieces, and what the edge cases are. I get it, I'm also eager to start writing code. But on a professional project, that instinct can cost you. The more you understand upfront, the less code you'll end up throwing away.
This also requires alignment. Having a shared understanding with your peers and tech directors before you start building is important; otherwise you risk building something that doesn't serve anyone and quietly gets abandoned.
Nobody likes throwing away work, and companies especially don't. The problem with automating too early is that people get precious about a tool once it's been delivered. When that tool eventually needs reworking, the reaction becomes "but we just built that", creating friction that makes it harder to do the right thing. Sometimes you have to bite the bullet anyway. If you don't, you end up carrying tech debt: a tool that's half-baked, a workflow that's awkward, and a shipping schedule that keeps you stuck with both.
Conclusion
Automation itself isn't the problem; the sequence is. Build consistency into the pipeline first, get the team aligned, then write the code. The pipeline definition is the hard part; the code follows from it. The question worth asking before you start isn't "can we automate this?"; it's "do we understand this well enough to automate it?".
© 2026 Stefan Groenewoud - All views are my own, not those of my employer.