So I got this comment on my last video and it genuinely stopped me in my tracks. It was from @Thiccolo and it reads:
“For someone like you, who likely has years of experience without LLMs, your brain totally understands good code/bad code, good architecture, and just general intuition around code and systems. LLMs must be an absolute gamechanger. But for someone like me who is starting out in this field, how am I supposed to build the years of experience and intuition that comes from manually writing code and building systems when companies are expecting AI to be used from here on out?”
The number of upvotes this got told me everything. A lot of you are feeling this exact thing and not really talking about it. So let’s talk about it.
Here’s the real problem. AI is making it really easy to build what I’d call shallow competence. You’re shipping fast, your manager’s happy, things look good on paper. But the moment someone in a code review asks you “hey why did you go with this approach?” and you freeze. Because honestly? You don’t know. The AI gave it to you and you just ran with it. Does this sound familiar?
That’s a problem. And it’s going to catch up with you.
To be clear, the reason experienced developers are valuable isn’t because we write code faster than you. It’s because we’ve spent years learning what not to do. We’ve made terrible architectural decisions and had to live with them. We’ve been paged at 2am because of something we shipped that seemed totally fine. That failure pattern recognition is what companies are actually paying for. And right now, a lot of junior devs are accidentally skipping all of that.
When I was learning, and I know this is going to sound like “back in my day” type stuff, struggle was just a given. You had a bug, you read the stack trace, you traced through the code, you dug through the logs. That was just the job. Nobody was handing you answers. And as frustrating as that was, it’s exactly how I built the intuition I still rely on today.
Okay so what do you actually do about this? I put together 5 strategies that I think can genuinely help. And I’ll be straight with you, some of them are more practical, some of them are more mindset-y. But all of them matter.
1. Learn the fundamentals — for real
I know, I know. Everyone says this. But I mean it in a specific way. You need to know what good looks like before you can evaluate what AI is giving you. Otherwise you’re just blindly accepting whatever it spits out.
Two books I’d genuinely recommend — I’ve got them right here on my desk. Head First Design Patterns is excellent for understanding coding patterns, which ones to reach for and why. And Designing Data-Intensive Applications is one of those books that I wish I’d read earlier — when I finally did read it a few years into my career I kept going “oh, I learned this the hard way.” That’s a sign of a good book.
2. Study failures
This one is so underrated. Cloudflare, AWS, Azure, Google … whenever there’s a big outage, these companies publish detailed post-mortems. What happened, what the root cause was, how they fixed it, what they’re doing to prevent it. Read those documents. They’re gold.
If you’re at a bigger company there’s probably an internal version of this too. At Amazon they’re called COEs — Correction of Errors. Facebook has their own version. Most big tech companies do. Go find them and read them. There’s something about understanding exactly how a complex system fell apart that just sticks with you in a way that reading documentation never does.
3. Manufacture the struggle
This is the big one for me. Before AI, struggling through a problem wasn’t optional — it was just what you did. Now there’s an escape hatch available 24/7 and it’s really, really tempting to use it every single time.
Don’t.
Before you paste that error into an AI, actually try to figure it out yourself first. Read the stack trace. Trace through the code. Go through the logs. Try to form a hypothesis about what went wrong. This is how you build real debugging instincts. You can still use AI afterwards, but make the attempt first.
Same thing goes for tickets. I always say the best way to learn how a system works is to go and fix things that are broken in it. Sign up for on-call, pick up the tickets nobody else wants. It feels like a grind but you will learn more from that than almost anything else.
4. Never ship code you don’t understand
I feel pretty strongly about this one. If I’m reviewing your code and I ask you why you went with a certain approach, and you tell me “the AI suggested it”, I’ve immediately lost confidence in you. Not because you used AI, but because you clearly didn’t bother to understand what you were putting in front of me.
Every line you commit, you should be able to defend. Why this library? Why this pattern? What are the trade-offs? If you can’t answer that, you’re not ready to ship it. It doesn’t matter if you need to go a bit slower to get there, go slower. The alternative is building a reputation as someone who just copies and pastes, and that’s really hard to shake.
5. Prompt for the why, not just the answer
This is more of a tactical one. When you’re working with AI, instead of just asking it to solve your problem, ask it to give you a few different approaches and explain the pros and cons of each. Ask it why it’s recommending one option over another.
Two things happen when you do this. First, you actually learn something about the trade-offs instead of just accepting the first answer. Second, AI will sometimes actually change its recommendation when you force it to reason through it out loud. So you’re not just learning more, you’re often getting a better answer too.
Now look, I know some of you are reading this and thinking “okay but Daniel, if I slow down I’m going to look bad. Everyone else is shipping twice as fast.”
And yeah, that tension is real, I’m not going to pretend it isn’t.
But here’s the thing. You can’t completely stop, obviously. What you can do is be smart about finding the pockets. Your downtime, side projects, the tickets nobody’s fighting over. That’s where you do the deliberate, uncomfortable learning. You don’t have to torpedo your output — you just have to be intentional about when and where you’re building real skills versus just shipping.
And honestly? You’re in a better position than you might think. You have access to something I genuinely dreamed about when I was learning — AI that can explain anything to you, at any time, at whatever level of depth you want. Use it as a tutor. Ask it to explain things. Make it teach you, not just do things for you.
The bottom line is this: your value as a developer is not in your ability to ship code. It’s in your ability to look at code — whatever produced it — and know whether it’s good or not. That’s what companies are going to need going forward.
Build that skill set now. You’ve got the tools. Use them wisely.
📚 Books I mentioned:
