What changed about learning, and what didn't

We had just wrapped up a hackathon with the AI Tinkerers Islamabad community at the Taleemabad office. I was sitting with Muhammad Hamza and Ali Nawaz afterwards, and we got onto how learning is changing for computer science students — and for everyone else, really. Ali was kind enough to capture the moment.

It is easy, watching the new world order play out in front of you, to assume everything is in motion. It is not. A lot of it is exactly where it was.

So the useful exercise is not asking what has changed. It is working out which variables are changing around us, and which ones are not — because the two demand completely different responses.

What has not changed

If you want to build something great, you have to put in the effort. That has not moved an inch.

If you want to solve a hard problem, it still takes technical depth and experience. There is no version of this where the depth becomes optional.

And you still learn by building systems — by finding out how they are put together and where their technicalities bite. If you do not ask questions, and you do not take feedback, you will not find out whether the thing you built is right or wrong. That was true before any of this, and it is true now.

The variable that is moving

What is changing is how you learn.

Consider how it used to go. A junior engineer would spend months building a simple CRUD app. Months. And at the end of it they might get no feedback from a senior, and no users in production.

That produced an illusion of experience and very little actual learning. A great many experienced developers in this industry came up exactly that way — including, if we are honest, most of us who now describe those years as formative.

Now that same CRUD app can be built in two or three hours.

Two or three hours is the start, not the finish

Here is the trap: if you stop there, you have not saved months of learning. You have lost it. The months were never the point, but neither was the app — the learning lived in the gap between them, and building fast closes that gap without filling it.

So the effort has to move. It does not disappear; it relocates. Tear the CRUD app apart. Question every decision in it. Better still, build three versions so you have something to compare, because a single implementation tells you almost nothing — you cannot see what a decision cost you until you have seen the alternative.

Every question should unlock several more. Go down the rabbit hole. That is the path.

And if you cannot think of anything to ask — ask the model for questions. Then ask questions about the questions. That sounds like a joke and it is not: not knowing what to ask is the actual bottleneck for most people, and it is now a solvable one.

Simulated users are a stepping stone, not a substitute

You can go further. Build tooling that simulates users. Run different kinds of tests and watch how your system behaves under each.

None of this compares to real users. That feedback will always be the highest quality there is, and nothing here replaces it. But as a stepping stone, while you are learning, it works well — and it is available to you on a Tuesday afternoon, which real users are not.

Where that leaves us

The thing that has not changed is that you learn by building systems and then interrogating them.

What has not changed is that without questions and without feedback, you will not know whether what you built was any good.

What has changed is the way you learn. Only that — but it changes nearly everything about how a career should be spent in the first few years.