Does it still make sense to learn how to code?
This is a question I’ve been thinking about a lot recently.
When I started learning programming more than 30 years ago, my teachers didn’t begin with a programming language.
Instead, they taught us algorithms, flowcharts, requirements, inputs and outputs, conditions, loops, and how to reason about a solution before writing a single line of code.
At the time, I didn’t fully appreciate that approach.
Like most students, I was eager to start coding. I wanted to see something working on the screen as quickly as possible.
Looking back, I realize they were teaching us something much more valuable than a programming language.
They were teaching us how to think.
Then came the 2000s.
One of the most valuable skills a software developer could have was the ability to take over an existing codebase, often a legacy one, understand how it worked, fix bugs, and add new features.
Documentation was often incomplete. Sometimes the original team had already left the company. The only reliable documentation was the code itself.
Reading code, understanding its logic, and safely evolving it became a highly paid skill.
It wasn’t everyone’s favorite job, but there was huge demand for it, especially in banking, finance, and manufacturing, where software was becoming a critical part of the business.
Today, AI is changing that equation.
Understanding what a piece of code does, fixing a bug, or implementing a small feature has become dramatically cheaper.
Yes, AI has a cost. Tokens aren’t free.
But if you compare the cost of generating and iterating on code with the cost of hiring experienced consultants to perform the same task, it’s easy to see why the economics are changing.
So what should a young developer learn today?
I don’t think the scarce skill is writing code anymore.
The scarce skill is understanding the problem deeply enough to ask the right questions.
It’s defining clear requirements.
It’s identifying constraints.
It’s evaluating trade-offs.
It’s recognizing when a solution is correct or subtly wrong, when it’s scalable or fragile, when it’s secure or risky, and whether it’s appropriate for a specific context.
Ironically, the lessons I learned more than 30 years ago feel more relevant today than ever.
Algorithms.
Requirements.
Inputs and outputs.
Conditions.
Loops.
System thinking.
These aren’t just programming concepts, they’re ways of thinking.
And they’re exactly the skills I’ve found myself relying on when designing AI workflows, orchestrating multi-agent systems, and reviewing AI-generated code.
The tools have changed, the fundamentals haven’t.
If you’re starting your journey into software development today, don’t worry too much about memorizing the syntax of a language or framework, or collecting prompt engineering tricks.
Invest your time in building mental models that help you understand how systems work.
Because that’s the part that’s hardest to automate.
And I believe it will remain one of the most valuable skills, no matter how much AI evolves.
Top comments (24)
What you are describing is rubbing elbows with the role of a technical product manager, though admittedly, the dev team should know the same things but for the purpose of remaining in scope and assisting with potential blindspots from your where you're sitting as the data engineer, designer, etc. The product manager role and tech roles are collapsed in 2026, and it's something we haven't said aloud, but you can certainly see the shift when speaking with hiring managers. They haven't been able to name it plainly, but essentially they want product managers with more technical depth, and it's easier to make the dev team go through exercises and even courses on product design thinking than it would be to mandate a non-technical product manager to learn how to code and understand what's happening on a deeper level with digital products. Though the best product managers have an intimate understanding of this presently.
You absolutely need to learn how to code. This is coming from someone who came into tech as a non-technical product manager. I'm actually aiming to become a data engineer at this point, because I like it...a lot. But also because it's easier to be intuitive and think like a good product manager if I understand the architecture, pipelines/workflows on a granular level. I've built my own ai-assisted products to demonstrate my capabilities and propose new solutions, but earlier this week, I coded my own project based on a need that my family has. I learned so much from that alone - in ways that building a Replit-generated product cannot teach you in a weekend (absolutely no offense). Understanding code helps with managing tech debt, which becomes extremely costly when budgeting tokenization.
And large enterprises are pulling back from AI because it is actually more expensive to use it at maximum capacity because you cannot entirely trust it, and there is constant debate over governance, ownership when the agents get it wrong, and essential humans in the loop. AI has proven essential when used strategically for operational efficiency and lower-stakes for automated processes that require minimal human oversight. I think the shift back to developers who can identify issues the code cannot is essential. Bloated code and tech debt can be managed well with humans who understand the code. It is extremely important, as it has always been, to understand code.
The real shift is from writing the code to owning the code. And therefore being able to read, understand and judge the code yourself is more important than ever. Not always, not all the code, but when a problem occurs, when AI starts turning itself in circles unable to address the core issue properly, the ones capable of stepping in will be those to save the day.
I mean, just yesterday I used agentic AI to two impressive tasks - identify potential memory leaks in one codebase and fully describe the state of second. AI was done within minutes and it was an incredible time saver. But should I just blindly trust the output and don't care? I don't think so. But to verify anything, you need to know how. Or would you bet everything on second (third, fourth,...) agent? Who watches the watchmen?
as someone still learning i think about this more than i'd like to admit. i keep landing on yes, mostly because reading code i didn't write is still where i learn the most.
I think when people say “you should learn to code,” what they often mean is: learn to think algorithmically.
Learn to take a messy problem, reduce it to its essential parts, understand the constraints, and recognise which problem-solving techniques might apply. Coding is one way to express and test that thinking, but the abstract thinking is the durable skill.
Even with the AI boom, I always knew that coding was still very important in the software landscape; you worded it way better than I could have. Code can generate thousands of lines of code, but you're going to need someone who understands the logic behind the code, someone who knows how to think as a programmer.
I think that, while anyone can generate their own code through an AI model without understanding it all that much, coding has become even more valuable. There's millions of lines of code AI has generated in all kinds of projects, but someone has to understand and review it; everyone can generate code, but not everyone can read the code.
Very interesting read, thanks for sharing. What resonated most is the point that the cost of producing code collapsed while the cost of verifying it didn't move at all — that imbalance explains a lot of what I'm seeing.
▎
▎ I'd add one thing though: I don't think the answer is learning to code without AI. That's not the environment anyone will actually work in. The part that matters is still doing the loop yourself — forming an expectation, testing it, being wrong, and understanding why. Learning to develop with AI is fine, as long as you're the one deciding what needs to be verified.
▎
▎ Because that's the trap: verification only works if you already have a sense of what correct looks like. Without it, "I verified it" quietly becomes "it ran without errors."
I agree. AI can help you get into an unfamiliar codebase much faster and quickly debug for you, but it can’t take responsibility for the final decision. You still need enough programming knowledge to tell whether its reasoning makes sense and whether a fix will create new problems somewhere else. So I don’t think learning to code has become less important. What’s changing is that understanding and judging code may matter more than writing every line yourself.
The point about reading legacy code being a highly paid skill in the 2000s really lands — we're basically back there, just with AI-generated codebases now. Reviewing and judging code you didn't write is the daily job again, and that only works if the fundamentals are solid.
IT IS DEAD 2021 CSE GRAD 8 GPA I worked for 1.5 years as SWE and unemployed from like 3 years it's over guys dead Don't waste your time
The question is whether you would pass technical interviews if you don't know how to code. Furthermore, I think we still need to keep that knowledge to be able to verify the generated code.
I agree that we should know the basics of coding to use AI agents. I believe that the trend is moving toward a basic understanding of business hardware systems in general. A programmer will likely be more like an implementation specialist. In the past, a programmer used code libraries developed over many years; now, they’ll be using prompt libraries ;-) I also believe that every AI project must be properly structured in terms of supervising the work of AI agents.