Recently, a reader named Alton Zheng left a comment on my previous post, asking a challenging question: How do you approach teaching or mentoring others to maintain an "old school" engineering mindset in today’s AI-driven environment?
This made me reflect deeply on my years as an instructor. Long before the advent of Large Language Models, I always operated under a core principle: software development — when understood not merely as typing syntax, but as architecting solutions — is fundamentally rooted in philosophy. I am not talking about textbook academic philosophy, though perhaps that would help too. I am talking about a structural mindset. Of course, as engineers, we must eventually translate thought into practice and deliver a concrete, working result. But the philosophical approach to a problem is what wins the long game.
Years ago, when I was teaching Visual Basic, I constantly drilled into my students that searching for a solution is entirely independent of the programming language. The language itself is just an implementation detail, a tool to be studied.
During the first week or two, some students would actually protest. They would look at me and say, "You aren't teaching us." They expected predefined standards, snippets to copy, and rote memorization. But I refused to give them the answers. I enforced boundaries, models, and constraints. Over time, as they realized that the solutions to complex bugs and logic loops were suddenly originating from their own reasoning without my intervention, they finally understood.
They weren't just learning to code; they were learning how to think.
The Core: Seeing the Forest, Not Just the Trees
In my career, the time spent typing code has always been a fraction of the time spent analyzing the problem and exploring potential paths. A trained engineering mind doesn't just fix the immediate bug or implement the current feature request; it looks at how the system will evolve over time. It anticipates the client's next needs by looking at the whole forest, not just the single tree. It requires freeing your imagination to find non-conventional solutions or to refine existing ones.
This is the exact opposite of how modern AI operates. LLMs predict the next token or the next line of code based on a statistical distribution derived from existing literature. By definition, AI operates within the boundaries of the statistically probable. But in real-world engineering, the standard, 'statistically probable' solution is rarely the elegant, tailor-made architecture your specific context demands.
One might argue that AI's randomness can sometimes mimic human intuition, occasionally assembling existing pieces into a novel puzzle no one has thought of before. But there is a fundamental difference: AI's randomness is a blind statistical roll of the dice. Human intuition, on the other hand, is a purposeful leap driven by an understanding of constraints. AI can generate a thousand unpredictable combinations, but it lacks the contextual judgment to know which puzzle actually makes engineering sense. It can suggest the pieces, but the architect must still design the picture.
Analyzing and verifying requirements is a continuous mental exercise. Even if your reasoning ultimately leads you to rewrite standard, well-known patterns, the process itself is invaluable. It is the mental gym that keeps your brain flexible, disciplined, and ready for the unexpected.
Language is a Detail, Autonomy is the Goal
If you focus solely on the syntax of a language—whether it was Visual Basic decades ago, a trendy JavaScript framework last week, or an AI prompt today—you are trapping yourself in a commodity skill. When you look at a problem from a high architectural level, the language becomes a mere deployment detail.
As a mentor, my goal has never been to hand out ready-made snippets. It is to force the developer to step back and look at the structural layout. That "click" moment—when a junior developer realizes they solved a complex architecture loop entirely on their own—is the moment they transition from being a simple executor to a true professional.
In the AI era, this shift is critical. If you only know syntax, you are letting the AI do the thinking, which makes you obsolete. If you master structural reasoning, you learn how to learn. The AI becomes your high-speed compiler, but you remain the sole custodian of the system design.
Case Study: GemmaLink – Architecture Wins Over Syntax
I had a chance to put this philosophy to the test during a recent challenge on DEV.to. The goal was to build an application leveraging Google's lightweight Gemma models.
Instead of getting hypnotized by the AI model itself, I started with an architectural question: What would be genuinely useful, fun, and capable of running entirely local—respecting privacy with zero cloud dependencies? That is how the idea for GemmaLink was born.
Then came the engineering constraints. I knew the target user shouldn't have to deal with installing Docker, configuring Python environments, or setting up complex LLM studios. The app needed to be a single, lightweight, zero-dependency binary that could run anywhere.
The ideal architectural fit for this was Go—a language I only knew at a basic level.
Did I let that stop me? No. Because the language is just a detail. I used AI extensively to generate the Go syntax, acting as a tireless assistant. But the core architecture, the strict definition of requirements, the data layout, the testing, and the debugging? That was entirely mine. Without a structured engineering mindset setting the boundaries, the AI would have just generated generic Python scripts completely useless for my deployment constraints. Architecture won over syntax.
Conclusion: The Human Element of Mentoring
At the end of the day, passing down an "old school" mindset cannot be compressed into a rigid set of mathematical rules. Mentoring isn't something you can automate because it is built entirely on empathy, active listening, and human communication. A good mentor must first know how to listen, setting aside their own biases to understand how the student thinks.
My goal is to instill rigor and structure, but the curiosity, the drive, and the final decisions must always belong to the developer. It took me years of practice, experimentation, and trial to shape this mindset—and truth be told, even I struggle to fully rationalize it sometimes. But that is exactly how it should be. We are not all wired the same way, and each of us connects with others differently.
More of my thoughts and technical articles can be found at nospace.net.
What do you think? Does this "learning to learn" approach make sense in your current AI-driven context? Let's discuss in the comments below.