Becoming a Junior Engineer in the Age of AI

Someone asked a question on Zhihu the other day: now that AI is this capable, is there still any point in learning all that technology?

A few years ago I would have answered more confidently. Today, I find it genuinely hard to give a clean yes or no. Things are moving too fast, and a lot of the career paths we used to take for granted are quietly coming apart.

When I first started out, my fundamentals were honestly weak. I couldn’t have given a clean explanation of how TCP differs from UDP. A lot of what I “knew” was half-knowledge at best. Looking back, the reason I got into the industry wasn’t that I already knew enough. It was that someone was willing to bet that this kid didn’t know much yet, but might grow into it. That bet gave me a starting point. From there I patched up the basics piece by piece, walked into the usual traps, and slowly turned concepts I had only heard about into things I could actually understand, use, and judge.

What worries me today isn’t really whether AI is going to write your code. It’s that AI is quietly rewriting how engineers grow up.

Because “learning technology” was never one single thing.

Some of it is tool-shaped. How to use a framework. How to call an API. How to spin up a scaffold. This kind of knowledge used to take real time to feel out. Now you can mostly just ask AI, and the answers come back fast and presentable.

But there’s another layer that has nothing to do with whether you can drive a tool. It’s knowing why a system is shaped the way it is. Knowing how network, storage and concurrency constraints quietly bend your code. Knowing why a design works today but is going to bite you later. And one layer deeper, there’s something that’s barely “technical” anymore. It’s closer to judgment: what counts as good code, what counts as a bad abstraction, when to push for elegance, when to accept something rough, which trade-offs are real and which ones are just delaying the bill.

The hard part is mostly that second layer.

You can’t learn it up front. Almost nobody learns to judge first and then writes code. It runs the other way around. You spend years dealing with work that isn’t pretty: ugly legacy code that has to be changed, problems that aren’t intellectually exciting but grind you down, code reviews that turn into uncomfortable arguments, outages that quietly built up over months before they finally broke. A lot of what looks like “skill” later was never really studied. It was earned through mistakes, rework, disagreements, and cleaning up after yourself.

This is where things start to shift.

What AI takes away first isn’t the hardest work. It’s the unglamorous, repetitive, formative work. AI will autocomplete your code, generate a page, explain an error, refactor a structure, and quite often hand you a pretty reasonable answer. So a lot of the friction you used to have to walk through yourself, get stuck on, and slowly figure your way out of, gets smoothed over before you ever feel it.

That isn’t bad on its face. Efficiency goes up, the cost of trying things drops. But there’s a quieter problem. If someone gets used to “the answer arrives first” too early, they may never go through the part where the answer actually grows out of something.

And underneath all of this, the issue isn’t only AI.

Almost every successful product of our era is pushing people in the same direction: less friction, faster feedback, less waiting. Short video does it. Food delivery does it. Recommendation engines do it. AI does it. Open your mouth and a result appears. Pause for a moment and a response appears. Express a vague need and someone fills in the slow, tedious, sometimes frustrating middle for you.

Humans have almost no natural defense against this. Getting an answer immediately is its own reward. It removes the wait, the confusion, the long stretch of trial-and-error that feels like nothing is happening, and the dull pain of being told “no” by reality and having to reorganize your thinking. Real understanding has never been comfortable. It usually means delayed gratification, long stretches without visible results, a lot of repetition, and long periods where you can’t even tell whether you’re getting better.

Technical learning happens to grow against that grain. The most valuable part rarely lives in the moment you can finally say “I get it.” It lives in the long stretch before that, the part where you don’t get it, where things stay blurry, where reality keeps pushing back.

So the deeper risk with AI may not be that it replaces learning. It’s that it slowly makes people unable to sit with not-yet-understanding. Once someone has been wrapped in instant feedback long enough, they lose the patience to stay inside their own confusion. They lose the ability to be on okay terms with being clumsy, slow, and unsure. And a lot of important things only ever grow during exactly that uncomfortable stretch.

That’s also why most of the maturing in a career doesn’t happen during the smooth parts.

Coming back to AI itself, the thing that should make you cautious is how easily it manufactures the illusion of competence. The page renders, so you assume you understand it. The code compiles, so you assume you’ve got it. The plan sounds reasonable, so you assume you can also tell whether the plan is actually any good.

But producing something that works and knowing why it works are not the same thing. And knowing why something works today is not the same as knowing where it’s going to break tomorrow.

You can’t really judge a piece of writing without being literate first, and even then you still need a sense of what good writing looks like. AI coding is increasingly muddy in the same way. The line between “produced an output” and “actually understood it” is getting harder to see. It becomes very easy to mistake the ability to invoke for the ability to understand, and the ability to express for the ability to judge.

So back to the original question: is there still any point in learning all that technology?

If by “technology” you mean tool-shaped knowledge — the syntax of a framework, the parameters of an API, the standard recipe of some development pattern — then yes, that kind of value is going to keep getting diluted, and faster than before. AI is going to keep eating into it.

But if by “technology” you mean defining the problem, understanding the constraints of a system, breaking down a real-world scenario, choosing between several plausible designs, knowing where to look when something breaks, and knowing which corners cannot be cut — then that work hasn’t become less important. It has become more important than before.

The stronger the tool, the more you need someone who knows when it’s reliable and when it isn’t. Someone who knows when to trust it and when to push back. Someone who can tell when it’s saving time and when it’s quietly borrowing against the future.

And here’s the catch.

These higher-leverage skills don’t grow by reading a few articles or asking AI a few times. They grow out of real product experience, out of having to live with the consequences of your choices, out of the residue left by repeatedly bumping into messy reality. Judgment, in the end, isn’t just accumulated knowledge. Most of the time it’s something the cost of being wrong slowly forces out of you.

So what I actually worry about now is no longer “will junior engineers still write code.” It’s something else: if AI replaces a lot of the friction that used to grow judgment, what is supposed to mature people in this profession?

Maybe new paths will emerge. They’re just not visible yet. Maybe the effective way to learn won’t be writing everything by hand from scratch. Maybe it will be using AI to fail faster, while at the same time forcing yourself to do the parts that can’t be skipped: verify it yourself, explain it yourself, look back on it yourself, own the outcome yourself.

Otherwise, “efficiency” is often just a nicer wrapper around not-yet-understood.

And if a whole industry quietly settles into that state, what it loses over time probably won’t just be the hands that used to write the code.

I’ve been thinking through these questions on and off for a while, and I’ve been collecting some of it into a small open-source book on AI programming, kept on GitHub and updated bit by bit. If any of this resonates with you, or if you happen to be in the middle of the same transition, you might find it worth a look: AI-programming-book