On effective engineering teams, there's always at least one person who is fluent one layer below where the rest of the team operates. That person tends to be extraordinarily useful in tricky situations. Examples: someone who can read assembly on a team writing C; someone who spends a lot of time in the browser debugger on a frontend team; or someone who is comfortable stepping deep into third-party library code with a debugger.
If any of these examples are familiar, you might chuckle that of course everyone on the team has these skills. But there's a big difference between someone who can barely parse the symbols, and someone who can actually interpret them and extract meaning.
Five to ten years from now, I have no idea whether software engineers still be coding. But I'm sure there will still be code. Do you want to be the person on your team who is fluent in it, or one of the rest who rely on that person?
Well put. The step to AI is a little like the step to using an IDE. It simplifies and automate a various bottlenecks. But when the IDE starts randomly failing, you need to call on that guy that knows how to work without the IDE.
It is exactly analagous to ask how much math you should learn given literally everyone has a scientific calculator in their pocket at all times.
The answer is: to be a mathematician or an engineer, you still need to learn how to do the math yourself. A calculator makes the math easier and faster than doing integrals longhand, but owning a calculator does not mean you know how to apply an integral to a real problem.
You still must learn to write code yourself. You need to know the fundamentals of computer science, programming, algorithms. The AI is good, but it still requires human engineering effort to get good results in exactly the same way that a scientific calculator requires mathematic skill to be input in order to produce useful results.
Facing a tricky software engineering problem armed with AI and no fundamental knowledge puts you in exactly the same situation as facing a tricky vector problem armed with a calculator and no fundamental knowledge. You can punch keys and get numbers out. Maybe you'll even land on the right answer, but it will take you ten times longer, produce worse results, and you won't even know if your answer is right. You won't learn anything either.
Working a tricky problem is how you learn which solutions apply and how to best use your skills. AI is the same way. If you don't have the fundamental skills, you won't learn, you won't get good results, and you'll waste a ton of time producing garbage for no benefit.
AI is a skill multiplier, just like a calculator. It really, truly is a garbage in, garbage out situation. If you don't put in skill and effort, you don't get good results. If you lack the fundamental skill and engineering mindset you will never get good results, you'll never learn how to get better, and you likely won't even have the capacity to judge your work as the garbage it is.
The only exception is the case that AI truly reaches super-human levels of ability in the near future. That case isn't worth worrying about because the problems it will cause go far, far beyond "should I learn to code".
So yes, you should learn the fundamentals. AI makes good programmers better, and conversely makes bad programmers worse.
"coding" is the skill that realizes other skills: it's a delivery medium.
The skill to learn is to be able to see and address the problems that will need solving in the medium term.
Even before AI, software changes a lot (desktop, enterprise, consumer web, IoT, devices, robotics...). So for the "seeing" part, it's like planning to cross the continent not knowing what transport or maps will be available: you can mainly guess they'll come out of the terrain and available materials and expertise.
For the "address" part, it's helpful to have seen similar problems, but probably more helpful to have seen a variety of problems and developed some high-level approaches, typically in academic study. Depending on your domain, that might involve math, or engineering, or biology, or.... All coding is encoding, which is fitting some domain to data structures and algorithms.
For the "delivery" part, it's especially important that your code restrict itself to what's needed by the actual end use. That might not be cool or interesting, and it often requires getting more direct appreciation of the end-use than the often-weak problem statement. It's a trap to just enjoy the beauty of it.
Someone like Noam Shazeer demonstrates the value of good coding: lots of people in his environment had lots of good ideas, but he made it happen (and it looks like he enjoyed it).
Just like math is learned by solving equations, software engineering is learned by writing code
Due to technological advances, solving equations stopped being a marketable skill, but understanding mathematics is as important as ever.
Software engineering will follow a similar route as math- the marketable skill will no longer be to write code, but writing code will be necessary to understand the big picture and build the marketable skills.
I've heard a statement that the mainstream programming language over the past 10 years has been Python, and it has become much simpler than assembly language. So many people will believe that in 5 to 10 years, the most mainstream programming language will be English. The so-called programming ability means being able to express requirements, goals and tests in English.
Learning computer science theory is probably going to be more important for the future than writing code yourself, because LLM coding is here to stay, and the human's job is going to be guiding the LLMs effectively: the AIs are writing code that pass tests, but how would you know that you are having the LLMs coding the right things?
Personally, I think learning specific implementation of algorithms probably should take less of a priority compared to fundamental architectural understanding why these things are done in the first place: data structure, automata theory, interpreter/compiler methodologies, etc. You still have to learn how to code, even if you won't be doing a lot of coding directly yourself, because the fastest way to learn how to evaluate code is by writing code yourself.
I agree with "all of it" and am, respectfully, more than a bit annoyed when this question is asked because it's common. We still learn math while having calculators and there are myriad other examples illustrating the same basic point.
Learning how to code will teach you how to break down problems and think in the way you’ll need to think to use and review code form AI. It will also teach you the language needed… not just the syntax of a programming language, but what is a function, variable, loop, conditional, etc. This will help you better talk to the AI and understand it. Trying to describe a concept you don’t really understand, when there is a simple word that can be used, will save a lot of trouble and headaches.
I’d learn as much as you can without the help or use of AI, to build a solid foundation. If AI falls on its face, you’ll be ahead of all those who didn’t do that. If AI ends up being great, you’ll be able to better utilize it if you speak the same language.
As far as I see it, there is only upside to learning. Even if you’re not going into the industry, learning to code helps the thinking process in a way I think almost anyone can benefit from.
Instead of saying "all of it", let me differentiate what is important to learn in your bones and what is more or less solved (or at least secondary).
You need to understand abstraction layers in the code and how to mentally navigate between them. Every change I make to code goes through a battery of concerns at different levels and perspectives: does this cause any security concerns? Are there unintended downstream effects? What is using this code I changed? How does it affect users? Are there performance concerns? Are there edge cases I am not considering? Can this be done in a cleaner way? Did I make something hard (encode logic/values) that should be soft (config setting, database value)? Are errors being caught? How are errors tracked and observed?
It is most necessary to know the right questions - an LLM can help solve them. Be excessive and wasteful with questions until you internalize when they are helpful. You will be surprised at the things you didn't consider even with small changes to an existing codebase.
You need to be able to read code and reason about it. If I was learning to code now I would spend most of my effort on reading code and conversing with an LLM to explain logic I don't understand, generate Mermaid graphs of code architecture, etc. You can rapidly level up by using LLM to help fill gaps in understanding.
Before all that, you need to know the basics: loops, data structures, variables. You need to understand tech stacks, how and why different layers are distinct (frontend, backend, database, logging, infra etc), how the communicate and how data passes through them.
In other words, architectural understanding and reducing "unknown unknowns" is the priority. If you know you don't know something, it is increasingly easy to address it directly, even if it takes a few more iterations.
There's still a lot of value in learning to code here, even if AI becomes the norm at certain companies.
Remember, you want to be able to understand why your system isn't working as intended if the AI screws up. You want to be able to make changes yourself without relying on Claude or Codex to do everything.
And you especially want this given that these services are operating at a loss right now, and prices are steadily increasing. How long til some companies restrict usage to keep costs down? How many companies can afford to pay whatever these services ask for?
Ideally local models and systems would make things cheaper here, but the gulf between what's available there and through the larger providers is still pretty big, and the requirements for a good AI system are higher than many people can afford on their own.
Even with coding agents, I think beginners still benefit from learning enough to understand system behavior, debugging, and tradeoffs. In our experience, AI accelerates implementation, but understanding why something breaks remains extremely valuable.
But I'll say in 5 years most coding work would be done by agents.
You don’t need to learn how to code if you’re not working on anything important & interesting. But you’ll be limited to what AI can do for you. If you need to solve problems where AI is weak, you’ll need the skills to do the work yourself.
A less obvious problem with not learning to code is that you’ll be less competitive because you don’t really have any specialized skills. Everyone can fire up Claude Code and knock out something. But if Claude Code gets stuck, or simply can’t solve your problem, then what will you do?
None. My company is hiring anyone who can use a computer and having them produce code via AI then review via AI and that is that. I was told to stop writing any code 6 months ago and haven't written a single line since. Not sure learning anything is worth it anymore, I'm shown every day at my company how they are replacing me directly and no longer have "devs" or "IT". They now call "IT", Digital Services and it can all be done by AI.
Programming is the art of applying math to solve problems. What kind of problems do you want to work on? That determines how much math to know, and what kind of programming you'll be needing to learn manually before you start offloading morsels to the bot.
Mathematicians don’t skip past the basics and jump straight into differential equations just because we have calculators, nor do chefs eschew knife skills because we have food processors.
If you don't know how to code, you can't possibly supervise a coding agent. You'd have no way of knowing if the idioms it used are correct or bolted on from another technology in a weird way. You'd have no idea if there's a better way to do a task using features available in the standard library. You wouldn't know if you're using a hammer for a task that requires a screwdriver.
The same goes for learning your second programming language, and the third, and the fourth...
Well, you will be paid for your subjective decision-making, what applies where, system design, and your calculation of trade-offs. Regardless of what scaling laws say, these will remain a problem for humans to solve because real-world systems are messy.
Enough to get through CS101. Databases, networks, operating systems, and all that hardware will certainly be around. Agents can work through them but the trust deficit will still be present(unless something fundamentally changes). So, learn coding but don't get obsessed with it.
YMMV but I think its going to always be important to acquire almost all the knowledge necessary to go to the metal, then allow the tactical to bits to atrophy over time. What remains is all the bones of the first principles understanding - and that will serve you well indefinitely.
An analog for you: I started in software pre-cloud, with a primary focus on web technologies, but at various times learned c/c++/asm/compilers/operating systems/algorithms. I audited many classes, but one instructive one was a course called nand2tetris (going from nand gates to hardware simulated CPU to peripherals to operating system to programming languages and compilers to application layer). Understanding the global through lines in computer science give you immense power.
Does my work as a CTO mean I use this information all the time? Absolutely not. Did I benefit from figuring out how computers work generally throughout literally my entire career? Absolutely yes.
I am actually relatively AI-pilled compared to the average Hacker News reader, but I am against outsourcing fundamental understanding to AI in all forms. Does that mean I write code by hand often anymore? Very infrequently.
I see this question as akin to "do I really need to learn basic flight skills when my A320 has autopilot?". Yes. Yes, you do. For exactly the same reasons. AI is workload reduction the same way that autopilot is workload reduction when used as intended.
You must still learn how to program. LLMs do not actually know or understand anything, and so they insert mistakes all the time. To ensure the code is good, you have to review it, and you can't review it if you don't understand it. If you don't learn how to program, you're going to be setting yourself up for a world of hurt when the LLM starts doing a bunch of stupid stuff but you don't know enough to catch it.
Also, you didn't ask but: be careful about going into tech. 5-10 years in the future is probably far enough that we will be able to see how the AI craze impacts jobs, but right now it's a very uncertain career which is at risk of going away because the business people think they can just have AI do everything. They can't, and they will learn that the hard way, but that will be cold comfort if you're out of work in the meantime. So be careful about choosing this field, it's hard to know what the career potential is like right now.
The better question is: how much independent judgment do you need before delegating implementation?
You should learn enough to:
- turn vague requirements into interfaces, invariants, and tests
- read a diff and explain what it actually does
- debug without asking the same system that wrote the bug
- recognize when the architecture is wrong rather than continuing to patch symptoms
- reason about state, concurrency, failure, security, and cost
That probably means learning one language deeply, plus basic data structures, databases, networking, operating systems, version control, and debugging. Not because you will hand-type every line forever, but because those are the mental models required to supervise an agent.
The curriculum should change, not shrink. Less time memorizing syntax; more time decomposing problems, reading unfamiliar code, testing behavior, instrumenting systems, and understanding failures.
I would use AI early, but periodically remove it. If you cannot build and debug a modest program without the agent, you do not yet know whether it is accelerating you or substituting for understanding.
A practical rule: on’t merge code you can’t explain, and don’t deploy a system whose important failure modes you can’t enumerate.
On effective engineering teams, there's always at least one person who is fluent one layer below where the rest of the team operates. That person tends to be extraordinarily useful in tricky situations. Examples: someone who can read assembly on a team writing C; someone who spends a lot of time in the browser debugger on a frontend team; or someone who is comfortable stepping deep into third-party library code with a debugger.
If any of these examples are familiar, you might chuckle that of course everyone on the team has these skills. But there's a big difference between someone who can barely parse the symbols, and someone who can actually interpret them and extract meaning.
Five to ten years from now, I have no idea whether software engineers still be coding. But I'm sure there will still be code. Do you want to be the person on your team who is fluent in it, or one of the rest who rely on that person?
Well put. The step to AI is a little like the step to using an IDE. It simplifies and automate a various bottlenecks. But when the IDE starts randomly failing, you need to call on that guy that knows how to work without the IDE.
It is exactly analagous to ask how much math you should learn given literally everyone has a scientific calculator in their pocket at all times.
The answer is: to be a mathematician or an engineer, you still need to learn how to do the math yourself. A calculator makes the math easier and faster than doing integrals longhand, but owning a calculator does not mean you know how to apply an integral to a real problem.
You still must learn to write code yourself. You need to know the fundamentals of computer science, programming, algorithms. The AI is good, but it still requires human engineering effort to get good results in exactly the same way that a scientific calculator requires mathematic skill to be input in order to produce useful results.
Facing a tricky software engineering problem armed with AI and no fundamental knowledge puts you in exactly the same situation as facing a tricky vector problem armed with a calculator and no fundamental knowledge. You can punch keys and get numbers out. Maybe you'll even land on the right answer, but it will take you ten times longer, produce worse results, and you won't even know if your answer is right. You won't learn anything either.
Working a tricky problem is how you learn which solutions apply and how to best use your skills. AI is the same way. If you don't have the fundamental skills, you won't learn, you won't get good results, and you'll waste a ton of time producing garbage for no benefit.
AI is a skill multiplier, just like a calculator. It really, truly is a garbage in, garbage out situation. If you don't put in skill and effort, you don't get good results. If you lack the fundamental skill and engineering mindset you will never get good results, you'll never learn how to get better, and you likely won't even have the capacity to judge your work as the garbage it is.
The only exception is the case that AI truly reaches super-human levels of ability in the near future. That case isn't worth worrying about because the problems it will cause go far, far beyond "should I learn to code".
So yes, you should learn the fundamentals. AI makes good programmers better, and conversely makes bad programmers worse.
"coding" is the skill that realizes other skills: it's a delivery medium.
The skill to learn is to be able to see and address the problems that will need solving in the medium term.
Even before AI, software changes a lot (desktop, enterprise, consumer web, IoT, devices, robotics...). So for the "seeing" part, it's like planning to cross the continent not knowing what transport or maps will be available: you can mainly guess they'll come out of the terrain and available materials and expertise.
For the "address" part, it's helpful to have seen similar problems, but probably more helpful to have seen a variety of problems and developed some high-level approaches, typically in academic study. Depending on your domain, that might involve math, or engineering, or biology, or.... All coding is encoding, which is fitting some domain to data structures and algorithms.
For the "delivery" part, it's especially important that your code restrict itself to what's needed by the actual end use. That might not be cool or interesting, and it often requires getting more direct appreciation of the end-use than the often-weak problem statement. It's a trap to just enjoy the beauty of it.
Someone like Noam Shazeer demonstrates the value of good coding: lots of people in his environment had lots of good ideas, but he made it happen (and it looks like he enjoyed it).
Just like math is learned by solving equations, software engineering is learned by writing code
Due to technological advances, solving equations stopped being a marketable skill, but understanding mathematics is as important as ever.
Software engineering will follow a similar route as math- the marketable skill will no longer be to write code, but writing code will be necessary to understand the big picture and build the marketable skills.
I've heard a statement that the mainstream programming language over the past 10 years has been Python, and it has become much simpler than assembly language. So many people will believe that in 5 to 10 years, the most mainstream programming language will be English. The so-called programming ability means being able to express requirements, goals and tests in English.
Learning computer science theory is probably going to be more important for the future than writing code yourself, because LLM coding is here to stay, and the human's job is going to be guiding the LLMs effectively: the AIs are writing code that pass tests, but how would you know that you are having the LLMs coding the right things?
Personally, I think learning specific implementation of algorithms probably should take less of a priority compared to fundamental architectural understanding why these things are done in the first place: data structure, automata theory, interpreter/compiler methodologies, etc. You still have to learn how to code, even if you won't be doing a lot of coding directly yourself, because the fastest way to learn how to evaluate code is by writing code yourself.
All of it. AI is magnificent in hands of a skilled coder. And absolutely crap in hands of someone who has no clue how computers work.
I agree with "all of it" and am, respectfully, more than a bit annoyed when this question is asked because it's common. We still learn math while having calculators and there are myriad other examples illustrating the same basic point.
Learning how to code will teach you how to break down problems and think in the way you’ll need to think to use and review code form AI. It will also teach you the language needed… not just the syntax of a programming language, but what is a function, variable, loop, conditional, etc. This will help you better talk to the AI and understand it. Trying to describe a concept you don’t really understand, when there is a simple word that can be used, will save a lot of trouble and headaches.
I’d learn as much as you can without the help or use of AI, to build a solid foundation. If AI falls on its face, you’ll be ahead of all those who didn’t do that. If AI ends up being great, you’ll be able to better utilize it if you speak the same language.
As far as I see it, there is only upside to learning. Even if you’re not going into the industry, learning to code helps the thinking process in a way I think almost anyone can benefit from.
Instead of saying "all of it", let me differentiate what is important to learn in your bones and what is more or less solved (or at least secondary).
You need to understand abstraction layers in the code and how to mentally navigate between them. Every change I make to code goes through a battery of concerns at different levels and perspectives: does this cause any security concerns? Are there unintended downstream effects? What is using this code I changed? How does it affect users? Are there performance concerns? Are there edge cases I am not considering? Can this be done in a cleaner way? Did I make something hard (encode logic/values) that should be soft (config setting, database value)? Are errors being caught? How are errors tracked and observed?
It is most necessary to know the right questions - an LLM can help solve them. Be excessive and wasteful with questions until you internalize when they are helpful. You will be surprised at the things you didn't consider even with small changes to an existing codebase.
You need to be able to read code and reason about it. If I was learning to code now I would spend most of my effort on reading code and conversing with an LLM to explain logic I don't understand, generate Mermaid graphs of code architecture, etc. You can rapidly level up by using LLM to help fill gaps in understanding.
Before all that, you need to know the basics: loops, data structures, variables. You need to understand tech stacks, how and why different layers are distinct (frontend, backend, database, logging, infra etc), how the communicate and how data passes through them.
In other words, architectural understanding and reducing "unknown unknowns" is the priority. If you know you don't know something, it is increasingly easy to address it directly, even if it takes a few more iterations.
There's still a lot of value in learning to code here, even if AI becomes the norm at certain companies.
Remember, you want to be able to understand why your system isn't working as intended if the AI screws up. You want to be able to make changes yourself without relying on Claude or Codex to do everything.
And you especially want this given that these services are operating at a loss right now, and prices are steadily increasing. How long til some companies restrict usage to keep costs down? How many companies can afford to pay whatever these services ask for?
Ideally local models and systems would make things cheaper here, but the gulf between what's available there and through the larger providers is still pretty big, and the requirements for a good AI system are higher than many people can afford on their own.
Even with coding agents, I think beginners still benefit from learning enough to understand system behavior, debugging, and tradeoffs. In our experience, AI accelerates implementation, but understanding why something breaks remains extremely valuable. But I'll say in 5 years most coding work would be done by agents.
You don’t need to learn how to code if you’re not working on anything important & interesting. But you’ll be limited to what AI can do for you. If you need to solve problems where AI is weak, you’ll need the skills to do the work yourself.
A less obvious problem with not learning to code is that you’ll be less competitive because you don’t really have any specialized skills. Everyone can fire up Claude Code and knock out something. But if Claude Code gets stuck, or simply can’t solve your problem, then what will you do?
None. My company is hiring anyone who can use a computer and having them produce code via AI then review via AI and that is that. I was told to stop writing any code 6 months ago and haven't written a single line since. Not sure learning anything is worth it anymore, I'm shown every day at my company how they are replacing me directly and no longer have "devs" or "IT". They now call "IT", Digital Services and it can all be done by AI.
To the extent that you use AI at all, it should be to accelerate your own understanding in ways that are independently verifiable/falsifiable.
AI amplifies what you are.
If you take shortcuts in your education, you will remain mediocre.
If you dive deep in your understanding, building a broad and deep foundation, then you will be exponentially more powerful.
Back when starting my career, I always remember the repeated questions of "do you need to be able to code to work in infosec?".
The same applies here and in any other tech field, nobody ever regrets that they learned "too much".
Pick your poison and learn everything you can!
Programming is the art of applying math to solve problems. What kind of problems do you want to work on? That determines how much math to know, and what kind of programming you'll be needing to learn manually before you start offloading morsels to the bot.
90% of "Senior" Programmers are not very good programmers, but they think that they are, and look down upon "Junior" Programmers.
Mathematicians don’t skip past the basics and jump straight into differential equations just because we have calculators, nor do chefs eschew knife skills because we have food processors.
If you don't know how to code, you can't possibly supervise a coding agent. You'd have no way of knowing if the idioms it used are correct or bolted on from another technology in a weird way. You'd have no idea if there's a better way to do a task using features available in the standard library. You wouldn't know if you're using a hammer for a task that requires a screwdriver.
The same goes for learning your second programming language, and the third, and the fourth...
Well, you will be paid for your subjective decision-making, what applies where, system design, and your calculation of trade-offs. Regardless of what scaling laws say, these will remain a problem for humans to solve because real-world systems are messy.
depends on the industry .. for 80% of jobs 0 coding knowledge will be needed in 10 years.
for ai research, safety, aerospace, military, trading, gamedev .. those will probably still need coding for a bit longer.
Enough to get through CS101. Databases, networks, operating systems, and all that hardware will certainly be around. Agents can work through them but the trust deficit will still be present(unless something fundamentally changes). So, learn coding but don't get obsessed with it.
> Enough to get through CS101. Databases, networks, operating systems
I don't know what CS101 you took but that covers multiple years of university for me.
YMMV but I think its going to always be important to acquire almost all the knowledge necessary to go to the metal, then allow the tactical to bits to atrophy over time. What remains is all the bones of the first principles understanding - and that will serve you well indefinitely.
An analog for you: I started in software pre-cloud, with a primary focus on web technologies, but at various times learned c/c++/asm/compilers/operating systems/algorithms. I audited many classes, but one instructive one was a course called nand2tetris (going from nand gates to hardware simulated CPU to peripherals to operating system to programming languages and compilers to application layer). Understanding the global through lines in computer science give you immense power.
Does my work as a CTO mean I use this information all the time? Absolutely not. Did I benefit from figuring out how computers work generally throughout literally my entire career? Absolutely yes.
I am actually relatively AI-pilled compared to the average Hacker News reader, but I am against outsourcing fundamental understanding to AI in all forms. Does that mean I write code by hand often anymore? Very infrequently.
How would you reccomend learning to code?
Learn Assembly
All. All.
I see this question as akin to "do I really need to learn basic flight skills when my A320 has autopilot?". Yes. Yes, you do. For exactly the same reasons. AI is workload reduction the same way that autopilot is workload reduction when used as intended.
You must still learn how to program. LLMs do not actually know or understand anything, and so they insert mistakes all the time. To ensure the code is good, you have to review it, and you can't review it if you don't understand it. If you don't learn how to program, you're going to be setting yourself up for a world of hurt when the LLM starts doing a bunch of stupid stuff but you don't know enough to catch it.
Also, you didn't ask but: be careful about going into tech. 5-10 years in the future is probably far enough that we will be able to see how the AI craze impacts jobs, but right now it's a very uncertain career which is at risk of going away because the business people think they can just have AI do everything. They can't, and they will learn that the hard way, but that will be cold comfort if you're out of work in the meantime. So be careful about choosing this field, it's hard to know what the career potential is like right now.
I think "how much coding?" is the wrong unit.
The better question is: how much independent judgment do you need before delegating implementation?
You should learn enough to:
- turn vague requirements into interfaces, invariants, and tests - read a diff and explain what it actually does - debug without asking the same system that wrote the bug - recognize when the architecture is wrong rather than continuing to patch symptoms - reason about state, concurrency, failure, security, and cost
That probably means learning one language deeply, plus basic data structures, databases, networking, operating systems, version control, and debugging. Not because you will hand-type every line forever, but because those are the mental models required to supervise an agent.
The curriculum should change, not shrink. Less time memorizing syntax; more time decomposing problems, reading unfamiliar code, testing behavior, instrumenting systems, and understanding failures.
I would use AI early, but periodically remove it. If you cannot build and debug a modest program without the agent, you do not yet know whether it is accelerating you or substituting for understanding.
A practical rule: on’t merge code you can’t explain, and don’t deploy a system whose important failure modes you can’t enumerate.