For a while now, I've been quietly embarrassed about something, and I think a lot of junior devs are quietly dealing with the same thing — so let's talk about it instead of hiding it.
The Pattern
More times than I'd like to admit, I've walked into a task without fully understanding it. Not "I understood 80% and figured out the rest" — I mean genuinely unclear on what was being asked, why it mattered, or what the actual requirement was. And instead of stopping to figure that out, I'd jump straight to producing a solution — often leaning heavily on AI to generate something that looked right.
It worked, on the surface. Code got written. PRs got opened. Things moved.
Until my senior asked me one simple question during a task walkthrough:
"Why did you do it this way? What does this actually mean?"
And I froze. Not because the code was wrong — but because I couldn't explain the reasoning behind it. I hadn't built it. I had assembled it.
That moment was more educational than any tutorial I've ever done.
The Real Problem Wasn't AI
It's tempting to say "AI made me lazy" and leave it there. But that's not quite accurate. The real issue was using AI to skip the understanding step instead of to support it.
When you don't fully get a task, there's a natural discomfort — a "wait, I don't actually know what I'm doing" feeling. That discomfort is useful. It's supposed to push you to ask questions, dig into the requirements, or slow down. But AI can resolve that discomfort artificially — it gives you a plausible answer instantly, so the uneasy feeling goes away without the actual understanding ever happening.
The output looks complete. Your understanding isn't.
What I'm Changing
Here's what I've started doing differently, and it's already made a visible difference in how I approach tasks:
- Restate the task in my own words before touching any code or any AI tool. If I can't write 2–3 sentences explaining what's being asked and why it matters, I don't understand it yet — full stop. No amount of code will fix that gap.
- Ask clarifying questions before starting, not after getting stuck. Seniors respect a "before" question far more than an "after" one. It signals you're thinking, not scrambling.
- Draft my own rough approach first, then bring AI in as a reviewer — not an author. Even a messy first attempt in my own words is worth more than a polished AI-generated one I can't defend. This flips the relationship: I'm reviewing AI's suggestions critically instead of consuming them blindly.
- Run a 30-second self-interview before presenting any solution. Why did I choose this approach? What would break it? What's the alternative? If I can't answer these, I'm not ready to show the work yet.
- When I genuinely don't know the "why," I say so — instead of guessing. "I don't have a solid reason yet, let me think it through and get back to you" rebuilds far more trust than a shaky, made-up justification ever will. ## Why I'm Sharing This
I think a lot of us who ramped up fast using AI tools are quietly in the same spot — good at producing output, shakier on the reasoning behind it. It's an easy trap because the output looks like progress. But the gap shows up eventually, usually in front of the person whose opinion matters most in that moment.
Getting called out was uncomfortable. But it was also the fastest feedback loop I've had in a while, and it forced a change I probably needed anyway.
If you've caught yourself in the same pattern — reaching for AI to resolve the discomfort of not understanding something, rather than to help you understand it — you're not alone. The fix isn't dropping AI. It's changing what step you use it at.
Curious how others have navigated this, especially those a few years further into their careers. What helped you build that "why" muscle?
