AzamSharp
Learning to Learn in the Age of AI
I started learning programming back in the early 90s. The World Wide Web had just been introduced, but it would still be a few years before I had access to the internet.
Luckily, books were available, and I spent most of my time reading programming books and manually typing code, one instruction at a time, into the editor. One of the first programming languages I learned was GW BASIC. I still remember creating a simple program that displayed a face that would switch between happy and sad.
A few years later, I finally got access to the internet, and a few years after that, Google arrived. Technology was advancing rapidly, but developers still had to struggle to find and implement solutions.
For example, imagine you were building an application that displayed a map, and you wanted to cluster different markers together. You would have to read documentation, search Stack Overflow, or explore other online resources to figure out how to implement it.
Sometimes, you would find the exact answer you were looking for. Other times, you would find something similar and have to think through how to apply that solution to your particular situation.
Fast forward to today, and AI can generate an entire implementation in just a few seconds. This is great because you save a lot of time and suddenly become a 10X developer. But at the same time, you may not have struggled at all. All it took was a single prompt, and your work was done.
But if AI does all the work, what exactly are we learning?
I have been teaching in one form or another since before 2002, and one thing I strongly believe is that if you are not struggling, you are not learning. This is especially true when you are trying to learn something new.
When I was teaching at a physical campus, I would always tell my students to break down a problem into smaller tasks. For each task, give yourself 15 to 20 minutes of pure struggle before asking for help.
That is when real learning happens.
You might try nine different approaches, and none of them work. Finally, on your tenth attempt, you find a solution. But you did not fail nine times. You discovered nine different approaches that did not work.
As Thomas Edison is often quoted as saying:
I have not failed. I’ve just found 10,000 ways that won’t work.
Today, AI has made it easier than ever to avoid that struggle. Even worse, some developers have stopped reviewing AI generated code. They simply assume that because AI wrote the code and it works, it must be good.
Unfortunately, my experience has been that while AI is very good at generating code, it does not always account for the long term consequences of its decisions. It can produce a working implementation without considering how that implementation will affect the architecture, maintainability, or future development of the application.
Generating code is not the same as engineering software.
So, should we stop using AI?
No.
AI is a powerful technology, but with great power comes great responsibility. We should use AI to enhance and amplify our learning instead of replacing it.
Instead of asking AI to generate the complete solution, ask it to point you toward the documentation for the framework you are trying to learn. You can even explicitly tell AI not to provide a solution, but instead to share relevant code samples from the documentation.
You can also ask for a hint rather than working code. That hint might give you just enough information to investigate further and move one step closer to solving the problem yourself.
There is also an important difference between using AI to become more productive and using AI to become a better programmer.
We often measure the success of AI by how much time it saves us. But when it comes to learning, saving time should not always be the goal. Sometimes, spending an hour understanding a problem is more valuable than solving it in five minutes.
One analogy I find helpful is going to the gym. Imagine hiring a personal trainer, but instead of exercising yourself, you let the trainer lift all the weights while you sit on the sidelines.
No matter how much your trainer exercises, you are not going to lose weight or build muscle. Your trainer might get stronger, but you won’t.
The same idea applies to your brain.
Your brain also needs exercise, and one way to exercise it is by working through problems yourself. You need to think critically about different scenarios, explore possible solutions, and understand how your decisions affect the final implementation.
This does not mean you should struggle with everything. There is a difference between productive struggle and unnecessary frustration. Spending hours dealing with a configuration issue may not teach you much, but spending time understanding why your application has a race condition can make you a better developer.
The goal is not to make programming unnecessarily difficult. The goal is to make sure we are still learning.
The next time you are working on a problem, break it down into smaller tasks. Spend 15 to 20 minutes working through each task before waving the white flag and asking AI for help.
During that time, you can still use AI to look up references, documentation, code samples, or even ask for hints. Just resist the temptation to ask it to generate the complete solution.
Those 15 to 20 minutes might feel frustrating, especially when you know AI could solve the problem in seconds. But that struggle is an investment in yourself.
When I was learning GW BASIC, I spent hours writing simple programs and figuring out why things did not work. Today, AI could generate those same programs in seconds.
But I don’t consider those hours wasted. They taught me how to think, experiment, solve problems, and keep going when things did not work.
I am not suggesting that we should stop using AI or go back to the way we programmed in the 90s. I am suggesting that we should be intentional about how we use AI, especially when our goal is to learn.
There is a great quote that captures this idea perfectly:
“You can outsource your thinking, but you cannot outsource your understanding.”
