I still remember what it felt like to be stuck on a bug for an entire afternoon, tabs open across three Stack Overflow threads and a PDF of some library's docs from 2016. That's mostly gone now. Describe what you want in plain English and something spits back a working first draft in seconds.
It's genuinely impressive. I'm not here to be the guy grumbling about "back in my day."
I use AI tools pretty much every day — for boilerplate, for explaining an API I've never touched, for a first pass at test cases, sometimes just to sanity-check an idea before I commit to it. They save real time.
But here's the thing I keep noticing, over and over, in myself and in people I work with.
The developers who get the most out of these tools aren't the ones who hand over the keys and walk away. They're the ones who already know enough to look at the output and go "wait, that's not right" or "yeah, that'll work, but it's going to fall over under load." You need the fundamentals to even ask that second question.
So no, learning the basics hasn't become optional. If anything it matters more now, because the cost of not knowing them is more hidden than it used to be.
Faster isn't the same as easier to understand
AI has absolutely changed the day-to-day of writing software. Ask for a REST endpoint, get a REST endpoint. Ask for a batch of unit tests, get a batch of unit tests. Need to port some crusty old Java class to Python, that's basically a copy-paste-and-prompt job now.
All of that is real, and it frees up time for the stuff that actually needs a human brain.
Where I think people get tripped up is conflating "I got code faster" with "I understand this better." Those are different things. If an AI hands you a hundred lines and you couldn't explain three of them if someone asked, you're just borrowing time. Eventually the bill comes due, usually at 11pm, usually right before a release.
The coding part was never really the hard part
There's this assumption that software engineering is mostly typing code into a file. It's really not, that's maybe a third of the job, if that.
Before anyone writes a function, somebody has to actually figure out what's being asked for, where the landmines are, what the tradeoffs look like between two or three different approaches. Say you're building checkout for an online store. Writing the endpoint that takes a payment token isn't the hard part. What's hard is coupon stacking, two people buying the last unit of something at the same second, a payment provider timing out halfway through, refunds that need to partially reverse inventory, that's the actual work.
An AI can absolutely write syntax for any of that once you tell it what you need. What it doesn't have is your business context, your company's weird edge cases, the thing that broke in prod last March that nobody wrote down anywhere. That part's still yours.
It doesn't know when it's wrong and that's the scary part
I think the most common mistake, especially for people newer to this, is assuming that because the code came from an AI it must be fine. And honestly, most of the time it is. That's part of what makes it dangerous.
Every once in a while it'll quietly use a library version that's been deprecated for two years, or misuse an API in a way that only breaks under specific conditions, or just skip an edge case entirely without flagging it — the same risk shows up when teams treat AI coding help as finished work. And the code doesn't look wrong. It's usually clean, well-named, nicely formatted. It just does the wrong thing.
If you've got a decent mental model of how the system's supposed to behave, you catch this stuff fast — something feels off and you go check. If you don't, you copy it in, it compiles, tests pass (because the tests were also generated and also missed the edge case), and you find out three weeks later from a support ticket.
Being able to read and evaluate code will always matter more than being able to produce it.
Debugging is where you can't fake it
Every project has bugs. Every system eventually does something nobody predicted.
At some point you'll hit something that doesn't get better no matter how many ways you rephrase the question. Maybe it's a slow memory leak that only shows up after four days of uptime. Maybe it's a request that fails once every couple thousand times and you can't reproduce it locally no matter what you try.
That's not a prompting problem. That's a "sit down, read the logs, trace the execution path, understand what the system is actually doing versus what you think it's doing" problem. There's no shortcut through that, it's built entirely on the fundamentals you've picked up from doing this long enough.
DSA still matters & I know people are tired of hearing this
There's a question I see over and over in dev communities: if AI can already solve LeetCode-style problems, why bother learning data structures and algorithms at all?
I get why people ask it. But the answer's still yes, learn it.
An AI can generate a binary search or a DP solution without much trouble. What it can't do is know, for your actual problem, whether a hash map beats a trie, or whether the heap-based approach is going to blow your memory budget in production while the "worse" one wouldn't. Those calls come from actually understanding what each structure costs you, and that understanding is exactly what studying DSA gives you, whether or not you ever get asked to reverse a linked list in an interview.
If you're still building that foundation, spend some time understanding the core data structures, common algorithms, and the trade-offs behind them before leaning too heavily on AI. This comprehensive guide to Data Structures and Algorithms walks through the concepts every developer should know, whether you're preparing for interviews or simply trying to write better software. Once those ideas click, AI-generated solutions become much easier to evaluate instead of blindly trusting.
It's basically a very fast junior engineer
The framing I keep coming back to: AI behaves a lot like a sharp, tireless junior developer. It writes fast, it seems to know a bit about everything, it never gets grumpy about revisions.
But you still review its pull requests. You wouldn't merge a junior's code untouched, and the same rule applies here, maybe more so, since there's no one on the other end who'll push back if you tell it "no, that's wrong, try again." Treat what it gives you as a draft, not a verdict.
Weirdly, experienced devs get more out of this than beginners do
You'd think AI would flatten the gap between senior and junior engineers. In practice it seems to widen it a little. The people saving the most time are the ones who already know exactly what to ask for and can spot a bad answer in about two seconds.
Newer developers sometimes end up worse off in a specific way — they spend less time typing and more time confused about why the thing they were handed doesn't actually work. Not because they're not trying, just because they don't yet have the reference point to know what "working" should even look like.
The tool's the same either way. The gap is in the person using it.
Learn it yourself first, then let the AI catch you up
None of this means avoid AI while you're learning, honestly it can speed things up a lot, if you use it right.
Try the problem yourself first, even badly. Then look at what the AI comes up with and actually sit with the difference. Why is one approach better? What did it think of that you didn't? Change the code instead of just accepting it wholesale.
Do that for a while and it stops feeling like a shortcut and starts feeling more like having a very patient mentor who never minds explaining the same thing twice.
Conclusion
AI has made software development better, full stop. There's no version of "avoid the tools" that makes sense to me anymore.
But it still can't do the part of the job that's actually the job, breaking a messy problem down, weighing tradeoffs, tracking down a bug that shouldn't exist, making a judgment call under pressure with incomplete information. That's still fundamentals, and it's still on you.
This was never really developers versus AI. It's developers who know what they're doing, using AI to get there faster.