There’s a version of using AI tools that makes you worse as an engineer. You paste in a problem, copy out the answer, ship it, and never understand what happened. Six months later you can’t explain your own codebase.
There’s another version that makes you better. You use it to catch mistakes you wouldn’t have caught until production, understand concepts you’d have guessed at, and get feedback in 30 seconds instead of waiting two days for a review.
I’ve seen both versions. This is about the second one.
The problem with being junior
Being junior in an engineering team isn’t really about not knowing things. It’s about not having calibration.
Senior engineers know when they’re on solid ground and when they’re winging it. They know which patterns are dangerous, which shortcuts bite back, which “it works on my machine” moments turn into 3am incidents.
Junior engineers don’t have that sense yet. You write something, it passes tests, it ships — and you have no idea if you just dodged a bullet or if the bullet is still coming, delayed by three months.
Claude Code doesn’t fix this directly. But it gives you something valuable: a second opinion, always available, that has seen a lot of code.
What I actually use it for
Sanity checks before opening a PR
Before I put code up for review, I paste the diff into Claude and ask: “Is there anything here that could break in production that I might have missed?”
This isn’t about replacing the human review. It’s about not wasting my reviewer’s time on obvious mistakes, and not learning about edge cases in a comment thread three days later.
A recent example: I wrote a background job that processed queued items and deleted them after processing. Claude flagged that I wasn’t handling the case where the delete failed after the processing succeeded — items would get processed twice on retry. I wouldn’t have thought of that. My reviewer might have. But Claude caught it in 10 seconds.
Understanding code I didn’t write
Every team has files that nobody quite understands anymore. The original author left, the comments are wrong, and you need to change something in it.
I’ve started asking Claude to explain files before I touch them. Not “rewrite this” — just “explain what this does and why it’s structured this way.”
The quality of the explanation is usually good enough to get me oriented. When it’s wrong, I find out quickly because I can test it against the actual behavior. Either way, I understand the file better than I would from reading it cold.
Learning from the feedback
This is the one most people skip, and it’s the most valuable.
When Claude tells me something is a problem, I don’t just fix it and move on. I ask: “Why is this a problem? What could go wrong? How does this pattern fail?”
The explanation is often a mini-lesson. After the null check issue I mentioned above, I now write null checks automatically in that pattern. It’s internalized. The next ten times I write similar code, I don’t need to ask.
If you use Claude just to fix things, you’ll keep needing to fix the same things. If you use it to understand why, you’ll stop writing them in the first place.
What I don’t use it for
Generating code I don’t understand
This is where the dependency trap is. If you generate 200 lines of code, ship it, and can’t explain any of it — you haven’t built software. You’ve built technical debt with extra steps.
My rule: I only use generated code I can read and explain. If I can’t explain why a line is there, I either ask until I can, or I write it myself from scratch.
This is slower. It’s also the point. The goal isn’t to ship features. The goal is to become an engineer who can ship features, which requires actually understanding what you’re shipping.
As a substitute for thinking
The worst thing you can do with any AI tool is outsource the thinking entirely. The point of being a junior engineer is to build judgment — the kind that can only come from wrestling with problems.
If you run every question through Claude before trying to figure it out yourself, you’re skipping the wrestling. You might get to the answer faster, but you won’t build the mental model that would let you solve the next problem without help.
My heuristic: try for 20 minutes first. If I’m still stuck, ask for a hint, not the answer. If the hint doesn’t unstick me, then ask for the explanation.
A workflow that actually helps
Before writing code:
- Read the relevant docs, understand what you’re trying to do
- Write it yourself — even if it’s messy
After writing code, before committing:
- Ask Claude: “Is there anything here that could break?”
- Ask Claude: “How would this fail under load / with unexpected input / with a network error?”
- Fix what makes sense, ignore what doesn’t apply
When you get feedback:
- Ask “why” for anything you don’t understand
- Write down the pattern so you remember it
When reading unfamiliar code:
- Ask for an explanation of the overall structure
- Verify the explanation against the actual behavior before trusting it
When stuck on a bug:
- Try yourself first (20 minutes)
- Ask for a hint, not the answer
- Once you’ve found it, ask Claude to explain why that was the cause — solidify the understanding
The calibration you’re actually building
Here’s what gets better with this approach over time:
You get better at knowing what questions to ask. The quality of your Claude prompts improves because your understanding of the problem improves. You start asking “why would this fail at scale” before you need to ask “why did this fail at scale.”
You develop a feel for what AI feedback is worth trusting. Sometimes Claude is wrong. Sometimes it’s overly cautious. Learning to evaluate the feedback is itself a skill — you can’t do it if you’re blindly accepting every suggestion.
You get faster at the things that are worth being fast at. Null checks, error handling, input validation — these are well-understood patterns. Having them pointed out consistently means you stop needing them pointed out.
What you don’t want to be fast at is thinking. Keep that slow. The code is the output of the thinking. The thinking is the job.
The honest warning
It’s possible to use Claude Code well and still not grow as an engineer if you’re not deliberate about it.
The tooling makes it easy to get answers without building understanding. It’s frictionless in a way that can mask a lack of skill building. You’ll feel productive right up until the day you’re asked to do something slightly outside what you’ve been doing, and you realize you can’t.
The engineers who use AI tools well are the ones who are already trying to understand things deeply — and who use the tools to understand more, faster. Not to skip the understanding.
Use it as the second set of eyes, not the first set of hands.
Reference: Claude API & Code Cheat Sheet | How Junior Engineers Should Actually Use Claude Code
Related Reading.
I Used Claude to Review My Code for a Week. Here Is What It Caught.
A week-long experiment using Claude as a daily code reviewer on a real Node.js project — bugs found, security issues caught, where it was wrong, and what changed.
What Are Agent Skills? AI Tools Explained Simply
Agent skills are the actions an AI can take beyond just talking. Learn what skills are, how they differ from prompts, and why they make AI actually useful in real workflows.
What Is a Context Window and Why Should Developers Care?
The context window is one of the most important things to understand about working with AI — and one of the least explained. Here's what it actually is and why it changes how you build.