I work with new developers often, and one pattern keeps showing up: heavy reliance on AI tools and copy-pasting from tutorials or the web without really understanding what the code does. This isn’t a rant about AI or “the way things were.” It’s about what happens when you skip the “why” and only do the “what”—and what to do instead.
The Problem I’m Seeing
More and more juniors:
- Get a task, paste a solution from ChatGPT/Claude/Cursor, and move on.
- Follow a tutorial step-by-step, get something working, but can’t explain the code or change it later.
- Fix bugs by trying the next AI suggestion or Stack Overflow answer until something works, without understanding why.
The result? Code that “works” until it doesn’t. When it breaks—in prod, in a review, or in an interview—they’re stuck because they never built a mental model of what’s actually happening.
Why “It Works” Isn’t Enough
1. You Can’t Debug What You Don’t Understand
If you don’t know what a piece of code is doing, you can’t reason about why it failed. Debugging is basically asking: “Given what this code is supposed to do, where did reality differ?” If you never knew what it was supposed to do, you’re just guessing.
2. Small Changes Become Scary
Someone asks: “Can we change this so it also does X?” If you pasted the block from an AI or a tutorial and never understood it, every change feels risky. You either avoid it or paste another block and hope it fits. Understanding turns “magic code” into something you can modify confidently.
3. Interviews and Reviews Expose the Gap
In interviews and code reviews, people ask “why did you do it this way?” or “what does this line do?” If the honest answer is “the AI wrote it” or “the tutorial said so,” that’s a red flag. Knowing the flow, the types, and the tradeoffs is what separates a junior who grows from one who stays stuck.
4. You Don’t Build Real Skills
Copy-paste and “AI did it” don’t create lasting skills. The skill is in reading code, tracing execution, and making deliberate decisions. Without that, years of “shipping” can still leave you unable to design or debug on your own.
What “Understanding the Code” Actually Means
It doesn’t mean memorizing everything. It means for the code you write or change, you can:
- Explain what it does in plain language (data in → steps → data out).
- Trace it: given this input, what happens line by line (or step by step)?
- Justify choices: why this function, this structure, this library?
- Modify it safely: where to change things and what might break.
You don’t need to know every API by heart. You need to know how to read the code and the docs and reason about cause and effect.
How to Use AI and the Web Without Falling Into the Trap
Use AI as a Tutor, Not a Substitute for Thinking
- Ask “explain this code line by line” or “what’s the tradeoff between approach A and B?”
- After you get a solution, step through it yourself. Comment each part in your own words. If you can’t, slow down and learn that part before moving on.
- Use AI to generate tests or examples, then run them and change them so you see how behavior changes. That forces understanding.
Use Tutorials and Web Answers as Starting Points
- After copying a snippet, break it: remove a line, change a value. See what breaks and what doesn’t. That teaches you what that part is responsible for.
- Before pasting, try to write a one-sentence summary of what the solution does. If you can’t, treat it as something to learn, not just use.
Build a “Understand First, Then Implement” Habit
- For each feature or bug: spend a few minutes stating the goal and the constraints in your own words.
- Then see if you can sketch the approach (even in pseudocode or comments) before opening AI or Google. You don’t have to get it right—you have to think first.
- Use AI and the web to fill in details, correct your sketch, or show best practices—not to replace that thinking.
Learning Principles That Help
Fundamentals before frameworks
Variables, flow, functions, data structures, and basic async. If you understand these, any framework or tool becomes “syntax and patterns” on top of something you already get.Read and trace before you write
Open an existing file and trace one user action or one request from top to bottom. Write a short note: “When X happens, the code does A, then B, then C.” Do this often.Break things on purpose
Change one thing, run the app, see what happens. Then revert and try another change. This builds a causal model of the codebase.Explain to someone (or a rubber duck)
If you can explain a function or a flow in simple language, you understand it. If you can’t, you’ve found the exact spot to study.Ship small, understandable pieces
Prefer a simple loop you understand over a “clever” one-liner you don’t. Readable and correct beats short and mysterious.
A Message to Juniors
Nobody expects you to know everything. Everyone uses AI and the web. The difference is whether you use them to avoid understanding or to speed up understanding.
When you paste code, pause. Ask yourself: “In 30 minutes, could I explain this to another developer?” If not, block that 30 minutes and make sure you can. That habit is what turns you from someone who depends on AI and webcoding into someone who can debug, redesign, and grow—with or without tools.
A Note to Seniors and Teams
If you’re mentoring or hiring: assume good intent. Juniors aren’t “cheating” by using AI; they’re trying to be productive. The fix isn’t to ban tools—it’s to set the bar clearly: “We value code you can explain and modify.” Do code reviews that ask “what does this do?” and “why this approach?” Pair on debugging and walk through the execution flow together. Model “I don’t know—let me read the code and find out.” That’s how you help new developers build the habit of understanding, not just delivering.
If this resonates—especially if you’ve been on either side of this—drop a comment or share how you balance using AI with actually understanding the code. Happy coding, and here’s to writing code we can explain.
Top comments (0)