Shipping fast with AI but don't fully trust the code? I help developers 1:1 turn AI-built apps into something they understand and own. How it works →
Kelsey Hightower said something on the Pragmatic Engineer podcast that I keep coming back to: AI does not change what software engineering is. It is a tool, a more powerful one, but the job did not fundamentally change.
That lands for me because it cuts against the loudest two stories right now. One says AI replaces engineers. The other says you have to bolt "AI" onto everything or get left behind. There is a lot of hype so it's good to put this in perspective.
Code was always decision-making #
"My entire career I always thought about writing code as decision making," Kelsey said. "Every keyword, every if statement, every function call is a decision we're making."
The syntax was never the point. It got in the way often enough that an entire Stack Overflow was built around it. The point was the thinking: what to build, what data structure fits, what to store and what to refuse to store.
He uses the example of a social security number. Writing the parser is the easy part. But should you even do it? What does that do to your compliance surface, your breach blast radius, your downstream reports? The model can produce the function, but you'll have to decide if it needs to be there. That part is still yours. Related article: Design Over Code.
This is why "writing is thinking" survives AI. You start typing a loop and realize the data structure is wrong, so you stop and change the architecture from the top down. The model can produce the loop. It will not feel the wrongness for you. With AI as an accelerator, the engineer deciding on the direction becomes even more important.
Train your own model #
Kelsey introduces a sharp concept: "zero token architecture"; instead of burning tokens, you learn things and think for yourself. His point is not anti-AI. It is that we trained these models on our own work, and the engineers who stay valuable are the ones still willing to train themselves.
"If we put this much effort in training the model so that it can spit things out, you better make sure that you are willing to train your own model."
The depth is what unlocks creativity. He gives the example of someone who could isolate a process without a VM because they knew the full boot sequence from firmware to kernel. You cannot invent at a level you have never reached. The fundamentals are not nostalgia, they are the raw material for the next idea.
I've seen this firsthand. I've interviewed library creators like Sebastián Ramírez and Charlie Marsh on the Pybites podcast. What stands out is a deep curiosity about how things actually work. They are not just "prompt operators," they are people who have internalized the fundamentals and can use them to create new things. The model is a tool, but the creativity comes from the engineer. Lean on AI for everything and you put that at risk.
The fear, Kelsey notes, comes from people whose whole identity was being the only one in the organization who could write code. That skill got commoditized. But the job was never only that. Architecture, design, knowing which problem is worth solving, explaining your reasoning to other people: that is the work. Writing code is the last step.
Mix the colors #
I like how the interview closes. Drop the fear-mongering, drop the "you versus the machine" framing. "Great artists tend to know how to mix colors ... understand the primary colors so you can mix them. That's a superpower." An artist who never learned to mix would need 16 million paint tubes on the desk. Learn the primaries and you can reach any color you want.
That is the whole case for fundamentals in one great analogy, and it resonates with me as a developer coach. Not "here is how to prompt faster," but: why these boundaries, what breaks when the next requirement lands, have you thought about this edge case and how your code handles it? Review, architecture, design.
AI made writing code faster, but it did not make the thinking faster or easier; that still requires deeper knowledge and skills.
The engineers who understand that and keep training themselves are the ones who will keep doing the interesting work, with AI as the best tool they have ever had, not the thing they shy away from using nor the thing they exclusively rely on.
Shipping fast with AI is the easy part. Knowing what to keep, rewrite, and trust is the hard part. I work with developers 1:1 to audit AI-built codebases, trace the real control flow, and make them something you can explain and own, without leaning on a chatbot. How 1:1 coaching works →