A few months ago, I built an iOS app. I have zero Swift experience. I described what I wanted to an LLM, iterated on the output, and had something working in a couple of days.
So... why bother learning anything anymore?
I've been thinking about this a lot, and I don't think the answer is as simple as people on Twitter make it sound. AI makes experienced developers faster. It does not make inexperienced developers experienced. Those are very different things.
The iOS App Problem
Yes, I shipped that app. But here's the part I usually skip over: it took me roughly three times longer than it would've taken someone who actually knows Swift. And the AI wrote perfectly fine code — that wasn't the issue. The issue was me.
I couldn't tell when the code was good versus when it just happened to work. When something broke, my entire debugging strategy was pasting the error back and crossing my fingers. I had no idea how UIKit works, so I couldn't steer the conversation anywhere useful. I was basically along for the ride.
Now compare that to how I use AI when I'm working in Go, which I actually know. I'll be building a service and say something like, "Let's use channels here instead of a mutex — the access pattern is fan-out and I want backpressure." Or I'll look at what it spits out and go, "This works, but just use an atomic here — we're only incrementing a counter, a mutex is overkill." I know where race conditions tend to show up, so I can ask it to add checks in the right places. I can decide whether something even needs concurrency to begin with.
Completely different experience. I'm not hoping the output is correct. I know whether it is.
What Actually Changed
AI didn't remove the need for knowledge. It shifted where you spend your time.
Before, a huge chunk of coding was mechanical. Looking up syntax you forgot, writing boilerplate, checking which function takes which arguments. That stuff is basically gone now, and honestly, nobody misses it.
What's left is the part that was always the real job anyway: making decisions. Picking the right data structure. Knowing when a simple approach beats a clever one. Catching the edge case that'll wake someone up at 3 AM. Understanding why one design scales and another falls apart.
AI generates the code. You're the one who decides if it's actually good.
Every Line Still Needs a Reviewer
This one doesn't get talked about enough. Every line of code that ships to production needs someone to review it. A human. Who gets what it does.
If you can't review it, you can't ship it. Well — you can. But you're shipping code you don't understand, and eventually that catches up with you.
I've already seen this happen. Someone generates a whole feature with AI, it passes the basic tests, gets merged. Two weeks later there's a weird bug nobody can figure out because nobody actually understood the code when it went in. The person who "wrote" it can't fix it either, because they didn't really write it.
Learning is what makes you the person who can actually fix things when they break.
Better Knowledge, Better Conversations
The thing I keep coming back to is this: the more you know about a topic, the better your conversations with AI get.
When I first started using AI for Go, my prompts were lazy. "Write me an HTTP server." Now I'll say something like, "Set up an HTTP server with graceful shutdown, a 30-second timeout on the handler context, and structured logging. Just net/http, no frameworks."
The output I get back is wildly better. Not because the model improved — because I got more specific about what I actually wanted.
Same thing applies everywhere. If you understand JavaScript well, you can tell the AI to avoid certain patterns, use specific browser APIs, handle the edge cases you know exist from experience. If you don't have that background, you get generic code that works in the demo and breaks in production.
So What's Worth Learning?
I'm not arguing you should memorize every API or hand-write everything from scratch. That ship has sailed. But there's a baseline you need:
How things actually work. Not every low-level detail, but the mental model. How does async code execute? What happens when you write to a database? Why does this layout break on mobile?
When to reach for what. Knowing that both a mutex and a channel can solve your concurrency problem is step one. Knowing which one fits better and why — that's the part AI can't do for you.
How to read code with a critical eye. AI will hand you something that looks right. Sometimes it is. Sometimes it isn't. You only develop that instinct by writing enough code yourself.
Fundamentals over frameworks. Frameworks come and go every couple of years. Data structures, networking, how databases actually work, security basics — that stuff stays relevant for your entire career.
Where This Leaves Us
The developers doing well right now aren't the ones who stopped learning because AI can write code. They're the ones who kept learning and now use AI to move way faster than before.
It's like power tools. A table saw makes a carpenter faster. It doesn't turn someone who's never touched wood into a carpenter. The saw doesn't know what you're building or whether your measurements are off. It just cuts where you point it.
AI is the best tool we've ever had for building software. But it's still a tool. And a tool is only as useful as the person holding it.
So learn the thing. Understand it for real. Then let AI help you build faster than you could alone.