Most of what I write on this blog is about data and analytics, but by trade I am a software engineer. That background shapes the way I think about technology in general, and about AI in particular. So today I want to step slightly outside my usual lane and talk about something that has been on my mind for a while, watching young people enter this profession.
A generation that wants everything now
I have seen the same pattern play out again and again. Young people come into programming full of energy, but also with a strong urge to see results immediately. They do not want to wait. They do not want to learn things step by step. They want to see code, an app, something tangible, and they want it fast.
The trouble is, that approach rewards the wrong thing. Writing code and getting early, visible results creates the feeling that you already know a lot. The app runs, the screen fills with content, the client is happy, and the brain quickly concludes: I understand this. But "it works" and "I understand why it works" are not the same thing, even though in that moment they feel identical.
On the other side, there is the person who goes slower. Who learns the fundamentals of software engineering first: the principles, the methodologies, the patterns that were shaped over decades of real, often painful industry experience. Who learns how to manage user requirements properly, how to weigh speed against quality, why some architectures crack under pressure while others hold up fine. That person takes longer to reach their first tangible result. But once they get there, the foundation is solid. What follows is exponential, not linear, while the person who jumped straight into code, skipping the fundamentals, often stalls, because there is nothing underneath to build on.
The miner and the mining engineer
I like this comparison because it captures the difference so well.
A miner knows how to dig. He knows the tools, he knows the terrain from experience, he knows exactly what to do when he goes underground tomorrow. But he does not understand the geology, the rock mechanics, the chemistry that determines whether one approach is safe and another is a disaster. A mining engineer designs the system that the miner then carries out. He understands the why, not just the how.
Software works the same way. A coder who knows the syntax, follows tutorials, and stitches together solutions through trial and error is useful, up to a point. An engineer who understands why Conway's Law predicts that a system's architecture will mirror the communication structure of the team, why technical debt always charges interest eventually, why adding people to a late project usually slows things down instead of speeding them up (Brooks's Law), that person is the one designing the systems. Plenty of people stay miners forever. Fewer become mining engineers. The difference is rarely talent. It usually comes down to whether they skipped the fundamentals in the rush for quick results.
Where AI fits into this story
This brings me to the part that worries me most these days, and to a term I have started using for it: thinkslope. It is a blend of "thinking" and "slope", meant to evoke a slow, almost unnoticeable slide backwards. There is also a deliberate echo of "slop" in there, the diluted, generic thinking that AI produces when it does the thinking for you.
In practice, I keep running into people who are not using AI to make their process more efficient, but to think on their behalf. That distinction matters a great deal, and it is easy to miss:
AI as an accelerator: the engineer already knows what they want, understands the trade offs, and uses AI to get there faster. The thinking stays theirs. AI just speeds up the typing.
AI as a substitute for thinking (thinkslope): the engineer hands over the actual decision making to AI. Which architecture to choose, whether a trade off is acceptable, whether the solution even makes sense in context. They stop thinking with the tool and start outsourcing the thinking to it entirely.
The laws and principles of software engineering, Conway's Law, Brooks's Law, the CAP theorem, technical debt, Hofstadter's Law, and plenty of others, were never theoretical abstractions to begin with. They came out of decades of painful, real world experience on projects that failed for entirely predictable reasons. When a young engineer skips that understanding and leans on AI to think for them, they end up with code, but not with the mental model that tells them whether that solution is actually any good in that particular context.
At that point they are not even an operator who at least knows what they are doing. They become a passenger on the thinkslope, where judgement quietly erodes while everything feels faster and easier.
Why this matters for data analytics too
The same logic applies to the world of data, which is mostly what I write about here. AI can now write a query, a model, or a dashboard in seconds. But the ability to tell whether that output actually makes sense, whether the methodology fits the question being asked, whether you have wandered into a statistical trap, that still requires understanding the fundamentals. The tool gives you speed. The fundamentals give you judgement. And judgement is the one thing that cannot be automated.
Technology, whether it is programming, AI, or data analytics, can either extend our knowledge or quietly replace it. The difference always comes down to the same thing: are we using the tool to speed up our own thinking, or are we letting it think for us.