AI can write code, so do we still need to learn technology?

“AI can write code, so do we still need to learn technology?”

I’ve been asked this question countless times over the past two years. Most answers are either a simple “yes” or “no,” with people arguing back and forth. I don’t think any of them hit the mark, because there’s no one-size-fits-all answer.

To answer it, you first have to answer another question: what kind of engineer do you want to become?

Let me be clear—I’m only talking to those in computer science-related fields, or people who genuinely plan to make a living writing software. How other industries use AI is a different story, and not part of this article.

First, admit that half of “no” is correct

I’m not going to start by arguing against “don’t bother learning,” because half of that statement is true. Pretending it doesn’t exist is just self-deception.

Syntax, APIs, and specific language features are indeed losing value. In the past, a big part of an engineer’s hard currency was “I remember how to call this function” or “I know how to work around this pitfall.” Now, if you don’t remember, it doesn’t matter—AI remembers better than you. Tasks like memorizing APIs, digging through documentation, and writing boilerplate code are things AI does fast and reliably.

So if your understanding of “learning technology” stops at “master a language, memorize the framework, and be able to type out code based on requirements,” then yes, those skills are rapidly depreciating. That anxiety is real, not just in your head.

But what I want to say is that this is just the most superficial layer of technology—and the easiest to replace. Equating that layer with “technology” itself is the real misunderstanding.

What’s really disappearing is the growth buffer for junior engineers

Stanford’s latest AI Index has a striking number: among software developers aged 22–25, employment has dropped nearly 20% since ChatGPT launched.

What lies beneath that number isn’t “we don’t need programmers anymore”—it’s something more specific.

How did someone used to grow into a competent engineer? They started with the most basic tasks: CRUD operations, minor bug fixes, integrating APIs, writing tests. Those tasks themselves don’t require much skill, but they serve as a buffer zone—a two- or three-year period where a newcomer slowly internalizes what they learned from books into practical hands-on experience. Companies essentially paid for you to make mistakes and gradually figure things out, accepting that your output wouldn’t match your salary in the first couple of years.

Now, those are exactly the tasks AI takes over first.

So the buffer zone is gone. There are fewer and fewer hands-on tasks for junior engineers. The time window for you to slowly grow your skills is narrowing dramatically. That’s the real story behind that 20% drop. It’s not that we don’t need people—it’s that nobody has the patience anymore to let you climb the “from zero to competent” slope at your own pace.

Interestingly, another set of numbers tells a different story. In the same report, among people over 30 working in similarly AI-exposed fields, employment actually increased by 6% to 12%. AI hasn’t eliminated software engineering as a profession; it has eliminated the entry-level rungs that used to lead into it.

My personal take: this is the most unfriendly aspect of this wave for anyone trying to break into the field. Not that the destination is blocked—but that on the already tough path at the entrance, the buffer is gone.

So the center of learning needs to shift upward

The buffer is gone, which means you have to skip that slow growth phase and reach directly for higher ground.

Concretely, the focus of learning shifts from what junior engineers used to learn toward what senior engineers and architects need to master: how to use middleware, why it’s designed that way; the inevitable trade-offs in distributed systems; the subtle pitfalls in concurrency control. AI can spit out concepts, but applying them correctly and stably in a real system depends on whether you have a mental map.

Also, designing large systems and making trade-offs in specific contexts—how to decompose a system, where to draw boundaries, where consistency is required and where latency can be tolerated—these questions have no standard answers. AI will always give you a seemingly reasonable solution, but you have to judge whether it’s right. This has always been the difficult part, and AI hasn’t made it easier—instead, it has made “the ability to judge” more valuable.

Then there’s another skill that was rarely talked about before but has become essential: reading and reviewing AI-generated code. In the past, senior engineers reviewed code from juniors; now humans review code from AI. AI can generate code that looks correct, but it often contains logical errors, security vulnerabilities, and architectural red flags. Much AI output goes into production without human review, and that’s creating real problems. People who can spot these issues are the ones every team desperately needs.

Interestingly, algorithms and data structures, in my opinion, haven’t lost their importance—they remain fundamental.

Many people conflate “syntax is losing value” with “fundamentals don’t matter either.” That’s mixing apples and oranges. Syntax is the skin of technology; algorithms and data structures are the bones. AI can write beautiful skin for you, but if the underlying data structure is wrong or the complexity calculation is off, the prettier the generated code, the deeper the landmine it buries. That bone-level knowledge is precisely the ruler you use to judge whether the AI’s solution is correct.

The only thing that has truly lost status is the superficial skin—syntax and language features—not the bones underneath.

The cost of not learning is that you can’t even see the traps

By this point you might ask, “Since AI can write everything, why do I need to understand the details? If it runs, it’s fine.”

There’s an often-overlooked cost.

The solutions AI gives you usually look correct—they run, they pass tests. But they often contain traps that only a knowledgeable person can spot. Race conditions in concurrent scenarios, an invalid assumption in a distributed system, a design that works perfectly with small data but collapses under scale, injection vulnerabilities, memory leaks. None of this will appear in the comments of the code it gives you.

If you haven’t learned the underlying layer, two things happen simultaneously. First, you can’t see the landmines it plants, and when they blow up, you can’t even locate where the problem is. Second—more subtle—you won’t even know how to formulate requirements for the AI.

You can’t say to it “consider idempotency here” or “an optimistic lock would be better in this part” or “don’t use strong consistency in this scenario,” because those terms and concepts aren’t in your head. The requirements you can describe determine the upper limit of what AI can produce for you. The parts you don’t understand can’t be requested, so the AI won’t proactively think of them either.

That’s why I say the cost of not learning isn’t “you’ll code slower”—it’s “there’s a wall between you and AI that you can’t even see.”

But for ordinary people, you really don’t need to study to the bone

That said, calibrating this correctly requires looking at both sides. Everything I’ve said above applies specifically to people who want to make a living from this field. If you’re not that.

If you just want to use AI to build small things for yourself—an automation script, a little tool, a simple website—then there’s really no need to stuff middleware, distributed systems, and concurrency control into your brain. That’s a ticket to a different world, and you don’t need it.

The dividing line, in my opinion, is one thing: does the thing you want to build have complexity? Does it need to be decomposed into systems spanning multiple domains?

If not, AI plus a little basic common sense is enough to build what you want. Going deeper would just be a waste. If the answer is yes, then sorry—everything I said earlier is necessary, and after AI, the bar will only get higher.

Don’t let anxiety-driven slogans like “everyone must learn architecture” kidnap you. Whether you need to go deep depends on how complex the thing you want to build is—not on how loudly others shout.

The craftsmanship from old-school coding determines how high you can vibe

I really agree with something a tech influencer named Baoyu (宝玉) said. Roughly: how well you understand and master technology through old-school coding determines the height and complexity of what you can vibe-build now.

The more I think about it, the more I feel he hit the root.

Vibe coding appears to level the playing field—anyone can describe something to AI and get a result. But that’s just the starting line being flattened. When it comes to building something complex, the ceiling is still determined by the craft you built up in old-school coding. The deeper your understanding, the higher you can reach together with AI. If you can only describe surface-level requirements, what you build will also stay at the surface.

So back to the original question: Should you still learn technology in the AI era?

Yes. But stop equating “learning technology” with memorizing syntax or learning frameworks. AI takes care of that skin. What you really need to learn is the underlying layer that lets you judge, design, and see through traps. That judgment and taste can’t be acquired by watching video courses—it grows only by trial and error, by making trade-offs in real projects. AI hasn’t made it less important; on the contrary, it has turned something that used to come with practice into a threshold you have to actively reach for—and it’s getting harder.

As for whether you can reach it, go back to that first question: What kind of engineer do you want to become?

Hi, I’m Niko, a lifelong learner. A 17-year veteran programmer who codes with AI every day. Here I share experiences in learning and using AI, technical thoughts, pitfalls I’ve encountered, practical tools, and skills. Follow me and let’s learn together.