Should You Still Learn to Code in the Age of AI?

The New Developer’s Dilemma

Recently, a lot of my colleagues who are just starting their journey in software development have come to me and asked similar questions:

• “Is AI dangerous to my career?”
• “Should I use AI while learning, or should I learn completely without it?”
• “Should I learn Python or Java and understand how databases work, or just learn to use AI tools?”

These are all valid questions, and not only for junior developers, and I’ve been thinking about this topic for some time now, so I want to share what I have on my mind here. My goal is giving anyone else a lens through which to look at all these new AI developments when it comes to further developing their own software engineering skills.

I figured that the best way to explain my view is through an alternative history story below. This is not what literally happened in programming history, but in my opinion the comparison is useful for understanding what developers face today.

A New Technological Miracle

Imagine this alternative reality set a few decades ago:

You are just starting your SWE career. You want to learn how to program using the hottest and most powerful programming language there is - assembly.

Assembly is at its peak! Everyone around you is learning it, and using it, and it solves so many practical problems. It is much easier than just entering raw zeros and ones. Everybody loves it, and there are tons of materials explaining how to write assembly code in the best possible way.

But suddenly, everyone starts talking about a breakthrough! A major software company has developed a new programming language - C.

C seems like a big hit. It promises that you don’t have to type assembly anymore. You now type code in this new language, and the assembly code gets written in the background! It seems magical, and much much more powerful.

You start to learn it, you get a feel for it, and it seems to work - you are writing much more code and getting more things done. You like it, it seems much easier and useful. Life is good.

But unfortunately, not everyone agrees with you.

C Slop

There are more experienced colleagues of yours who are skeptical. They say they “don’t believe you should use C.” They say they for sure won’t. They also say that the assembly code behind the C code is not good enough. They call it “C slop”.

Even a whole new term emerges: vibe c-oding, used when someone is writing C code without ever checking the assembly code below it.

Your older colleagues claim that C is a shiny new thing and that it is used only by those who can’t write real assembly code. Every day they find a new example along the lines of:

• “Ooh, look at this generated assembly code, it is not fully optimized. I would have written it so much more elegantly”
• “This code written in C will never be optimal compared to if it was written in assembly from scratch”

And when you look at it from the outside, they are right about many of the examples. Some generated assembly is far from fully optimized and an expert could write a better version by hand. But is that really the right question to ask?

New Developer Positions

A few years pass, and something new happens in the field. Companies begin finding more and more areas where the “generated assembly from C” is good enough. It is not perfect, but it is reliable enough, cheap enough, and fast enough for the specific problems they are solving.

For this reason, companies now start aggressively hiring people who can write really good C code. You start seeing offers for these new “C Programmer” positions.

On the other hand, the need for assembly programmers didn’t just go away.

Those who were true experts in assembly - 10x assembly programmers - started being even more valuable in some fields where performance, hardware control or severe resource constraints mattered a lot.

The best part: instead of having a full split into a group of developers who only wrote assembly and a group where programmers only wrote C code, most people found themselves in the middle. They had some understanding of assembly and some understanding of C code. Different individuals worked at different parts of the spectrum.

C code, as an abstraction layer, actually increased the amount and variety of useful software people could build. And interestingly, we as humanity didn’t stop there. Over time, we invented new abstractions on top of C, and the process repeated. The result? More useful code, lower barrier to entry, and new kinds of work for people willing to learn software development.

Software started eating the world.

And what about those older colleagues who kept pointing at the non-optimal generated assembly? Well, they were right - a lot of it really wasn’t perfect. But the main question was never whether the assembly code you got from writing C was perfect or not. The main question was: can you use this “non-perfect” code for something? The market answered that question for them.

Snap, Back to Reality

The parallel between this story and what’s happening today should be clear. Many people are now creating software by describing in natural language what they want to achieve, and AI produces for them the underlying code that makes that possible.

If you zoom out and look at this on the scale of years, we are now in a phase where AI has “just emerged” and many are discussing how it will or will not replace people writing code (Python, Java, C++, etc).

But for me, that’s not the most important question to ask. A much better question is: where will this new way of creating software be useful, taking into consideration its pros and cons?

Where the Comparison Breaks

Of course, this comparison is not flawless.

The biggest difference is that C → assembly is deterministic, while AI → e.g. Python isn’t. A C compiler does not hallucinate. An AI system often receives an incomplete requirement from a human, while a C compiler receives a formally defined program. Compilers also don’t have this jaggedness that LLMs have - when an LLM can solve a difficult architectural task but then fail on an apparently simple implementation detail.

So, my point was NOT to say that you should blindly trust everything AI writes and vibe code throughout your whole career. My point is that there are use cases where the AI-generated code is good enough.

Its usefulness depends not only on how good or fast the output is, but also on how easily that output can be verified. Imperfect code can be extremely valuable if errors are cheap to detect and correct. For example, a solution that takes ten minutes to generate and twenty minutes to verify may be much more valuable than one that takes several hours to write manually. You should be aware of those use cases, or even pursue them if you want to specialize in working at this layer.

On the other hand, it becomes much more dangerous when failures are not easy to spot right away and verification is difficult to perform.

Find Your Place on the Spectrum

To answer the questions from the beginning, I think it is important to realize that (just as before) there are likely to be jobs for people in all three positions across these layers.

• Being a specialist with deep expertise in Python, Java, databases or another underlying technology
• Being a hybrid developer who combines traditional coding expertise with AI-native workflows
• Being a developer who works primarily through AI, at the layer above source code itself

To be clear, working primarily through AI doesn’t mean just “vibe coding”. Vibe coding is when you let AI write the software without really understanding what it is doing or checking whether the result actually works as you intended.

AI-native development is very different. Here, a developer may not inspect every generated line, but that does not mean they are blindly accepting whatever an agent produces. They have to know how to select tools and models, manage context, evaluate the output, diagnose failures from behavior, design guardrails, and take responsibility for the system’s behavior.

But Will There Be Enough Jobs?

Now, there is an elephant in the room I want to address. Even if you agree that these layers will exist, you might still ask: “If AI writes the code, won’t companies simply need fewer of us?”

I don’t think so, and the reason is the Jevons paradox: when the price of something drops, we don’t consume the same amount for less money - we consume much more of it. AI is dramatically lowering the price of creating software, and the demand for software is nowhere near saturated. Every team has a backlog of ideas that were never built because building them was too expensive.

We already saw this pattern play out once: when spreadsheets automated calculation, the number of bookkeeping clerks went down, but the number of accountants and analysts went up. Cheap calculation did not reduce the demand for people who work with numbers - it exploded the demand for analysis. I expect cheap code to do the same for people who build software.

But I want to be fully honest here, especially with junior readers. I can’t promise that the number of junior positions will stay the same, because the work AI does best today overlaps a lot with the work juniors used to learn on. That is the difference from the compiler story above.

What I can tell you, from what I see in hiring around me, is what separates the juniors who do get the jobs from the ones that don’t: they are the ones who understand that these layers exist and deliberately build their position across them, instead of just vibe coding their way through tasks. Since many are taking shortcuts today, you can get ahead by learning systematically, with AI as a great help, but never the substitute.

So I won’t be discussing “will there be jobs”, but “how do I become one of those juniors”. The rest of this post will talk about that.

What Can You Do Next?

The most important part for you, the reader who is a developer, is to figure out where you want to belong. Check what can be done with each of those layers, and then choose your position based on what you like. Ask yourself the following questions:

• What kind of systems do you want to build?
• How costly are mistakes in that field?
• Can results be tested easily?
• Do you want to work on implementations, or primarily define and evaluate outcomes?
• How often will you need to diagnose failures below the AI layer?

For example, if someone is building prototypes or creating low-risk automations, they may be able to work primarily at the AI layer. Someone building database engines, security infrastructure, or safety-critical systems will need much deeper control of the underlying code.

Also, you don’t have to dedicate yourself permanently to one position. Most developers will move between these layers in their everyday work and in their careers, depending on the problem they are solving, and that is fine. But know that those layers exist, so you can navigate the future with more confidence in your own abilities.

For junior programmers, your goal should not be just to “ship software fast with AI”. It should be to develop strong mental models and the ability to understand and reason about what the AI creates. If you ask me, the best starting point is to learn both conventional software fundamentals and AI-native workflows, and then as you go through your career, decide where across these layers you want to specialize.

That way, you will actually be able to “read the code”.

Learn the AI Layer

Before I finish, it is important to say that everything I talked about in this blog post does not apply only to junior developers. My personal opinion is that regardless of what you do as a software engineer, you should still learn the AI layer. It is getting more and more capable and widespread over time. For some people, it will remain just an accelerator for their specialized work. For others, it may become their primary interface for creating software.

One thing is certain: AI is not going away. Learn how to steer it.