Slow is Smooth, Smooth is Fast

“Slow is smooth, smooth is fast.” That was drilled into me during my time in sports. It’s the difference between running through your bracket and losing in the first match. It enforces good technique.

I think we need to bring that mindset to mentoring the next generation of engineers. There is immense value in reaching for the “old way” until there is mastery.

Take Kubernetes. It’s rare for a new grad to have a deep understanding of orchestration. When they build their first side project using Minikube, I want them to write out the YAML manually. Yes, it’s incredibly dull. But that dullness is what makes the difference between finding a bug in minutes and making your paying customers very unhappy.

The elephant in the room is: “Justin, why bother when AI is so good?”

Sure, AI is great at identifying local fixes within files and even some system design. But there are hard limits.

One of the products I work on at IBM is WXA4Z—Kubernetes on steroids. It deals with OpenShift, Red Hat’s extension of K8s, which comes with its own twists on operators and the Operator Lifecycle Manager (OLM). We’re talking 700 pods per cluster, Cloud Pak for Data, Spyre Cards, and custom storage requirements. It has so many moving parts it’ll make your head spin.

In my experience, AI has struggled to help with the problems we encounter there. My team and I have built up deep institutional knowledge testing it to the point where we’re like “OpenShift whisperers,” called in to debug other teams’ clusters.

If I never took the time to go back and review K8s, OCP, Podman, and common cluster operations the hard way, I’d be stuck. But because I did, I can move even faster now. I use spec-driven development to map out how I want resources deployed, then build agentic skills or MCP servers to let LLMs read my data and triage issues.

AI only works well on proven issues. It falls apart quickly when you need long-context reasoning or are dealing with products that have enormous SBOMs. That’s why big brownfield projects struggle to adopt AI. That’s why COBOL will likely stay on the mainframe longer than any of us would like to admit.

We need to keep our core skills sharp every year. Not just for the sake of tradition, but so that when we use AI to program our software, we still have the “taste” to know what good software actually looks like.