I have been thinking about whether there is still a point in learning a programming language when we went all in on AI coding.
It is really hard to motivate myself to learn any new tech anymore when supposedly AI can do it all. Supposedly.
But then I start thinking: is it really so? Is AI really so hands-off that it doesn't need any supervision, and thus doesn't require any knowledge of the programming stack?
I am working mainly with web apps and web services. Good old websites, APIs, frontend, and infra that glues it all together (bash scripts and duct tape included).
But lately, I've done a few apps that are outside that area: a Kotlin/Java-based Android app and a Go-based Linux desktop app.
So I was able to compare how I work on projects in these two buckets.
And it was not by any means obvious in the beginning.
With apps from the first bucket:
• I write specs
• I give technical guidance
• I review some code
• I correct some code, improve the guidance, and tell AI to redo stuff not because it doesn't work, but because I have opinions on how certain things have to be done: how Celery tasks should be called, function-based views vs. class-based views, which specific libraries should be used in the project, and settings for these libraries.
So I have opinions, I have a taste, and I have experience that tells me how certain code decisions affect the project mid-term or down the road.
But when I was building other types of apps, I did zero code review, although I did a lot of testing of the app itself.
First of all, those were not critical apps, at least not at the start. As time goes by, I have higher expectations about their quality and stability.
Second, I have no idea how to read Java or Kotlin, and I have no preferences or experience to offer guidance for Go.
How important the app is dictates how much time and effort I am willing to dedicate to code review. If it is a one-off PoC, a simple, maybe one-time-use piece of software, I will not lift a finger to review the code. I will make sure that it does the job it was created for and then forget about it.
If the app is important, my work relies on it, or it will be viewed by other people who also rely on it to be good, then yeah, I do code review on some parts of the app.
So, web apps that I make are important and I do code review on some parts (I don't care that much about the frontend code as long as it works, which I ensure by actually using it, but the backend must be solid).
These apps that I've done started as fun projects. So there was little motivation to go beyond writing a spec. I just wanted these tools to exist to serve their purpose.
But eventually I started caring enough to have improvement sessions:
• The interface was not convenient enough
• The app was slow
• The app would run out of memory because the document was too big
• etc
And I suspected, from my general programming experience, that some fundamental improvements could significantly improve the performance, stability, responsiveness, and efficiency of the apps.
But since I have no idea how any of it works, I just kept prompting. I had to rely on the choices Claude and Codex have made for me, and hope they are right.
I am sure they are not. But I can't prove it.
So, the conclusion of this mental gymnastics and this article is this:
• Yes, learning to code is important even if we are using AI most of the time
• The importance of learning the specific stack you are planning to use depends on the importance of apps you are building with this stack
• If apps are meaningless PoCs, MVPs, or low-quality nice-to-have tools/automations, and the cost of their failure is not big, skip learning; keep vibing
• If the app is critical, and you can't afford to be stuck unable to solve the problem or bottleneck, and can't just hope to prompt your way out of tough situations because you don't know what's under the hood, learn that stack, learn that programming language, and learn enough about specific libraries and approaches to guide AI.