Mentoring Claude: Treating AI Like a Junior Developer

The Penny Drop Moment

I've been writing about using AI in my development workflow for a while now. Content generation, quality checks, automating the SDLC. All of that works. But this post is about something different. It's about what happened when I noticed Claude making the same kind of mistakes a junior developer makes, and realised I needed to respond the same way I would with any team member. Not by working around it. By mentoring it.

This came out of a real session. I was publishing a blog post (I have built a wix blog publishing workflow that uses Claude and the Wix MCP, I prefer that to using the Wix UI) and the process was taking far longer than it should have. Claude was hitting a 10,000 character limit on the Wix document converter API, splitting content into chunks, merging node arrays, fighting with image uploads. It worked, eventually. But it was painful, it was doing it every time and finding ways around the issues each and every time it tried to do it. When I stepped back and looked at what had happened, I realised the inefficiency was obvious. We already had a local Python script that understood the Document format. Claude just didn't think to use it.

That's not a bug. That's a knowledge gap. And the fix isn't to complain about it. It's to close the gap.

You Get Out What You Put In

If you hand a junior developer a task and they take a long, roundabout path to the answer, you don't fire them. You sit down, walk through what happened, and help them see the shorter path. Next time, they take it.

Claude works the same way. It's not going to improve on its own between sessions. It doesn't have some built-in self-improvement loop running in the background. If you want it to get better, you have to actively teach it. That means noticing when something goes wrong, understanding why, and then changing the environment so it doesn't happen again.

In my case, the Wix upload was slow because Claude was using the document converter API when a local script could do the same job with no character limit. The fix wasn't complicated. I added a convert command to the existing script, wrote tests for it, and documented it in CLAUDE.md. Now every future session and every agent I spawn knows to use the local converter. The problem is solved permanently, not just for that one conversation.

That's mentoring. Identify the gap. Close it. Move on.

The CLAUDE.md as Onboarding Document

I wrote about CLAUDE.md in the previous post as a standing briefing for the AI. But through this session I realised it's more than that. It's the same thing you'd give a new joiner on their first week.

Here's what happened. I was using agents (subprocesses) to handle complex Wix API calls. Each agent starts fresh with no memory of what happened earlier in the conversation. So every time I spawned one, it would go through the same discovery process. Call the WixREADME tool. Search the docs. Read the method schemas. Figure out the endpoints. Build the request body. All of that takes time and tokens when I already knew the answers.

If a new developer kept asking the same questions about which API endpoints to use, I'd write it down in the project wiki. So I added a full Wix API reference section to CLAUDE.md. Endpoints, body shapes, known IDs, gotchas. Everything an agent needs to make an API call without rediscovering the docs from scratch.

You document the patterns, the shortcuts, the tribal knowledge. The difference with AI is that it actually reads the documentation every single time. No human developer has ever done that.

Recognising the Patterns

Once I started thinking about Claude as a team member I needed to mentor, I started noticing the patterns everywhere.

The over-engineering pattern. Claude will reach for the most complete solution instead of the simplest one. The official API instead of the local script. The recommended approach instead of the scrappy one that actually fits. Sometimes you have to tell it that good enough is better than thorough.

The context loss pattern. Agents start fresh. They don't know what you already figured out. The answer isn't to repeat yourself every time. It's to write things down where everyone can find them.

The "it worked so it must be right" pattern. Claude will solve a problem in a way that works but isn't efficient. The upload succeeded, so from its perspective, the task is done. It doesn't naturally reflect on whether there was a better way. That's your job. Ask the question. Then work through it together.

The knowledge silo pattern. Claude learns things during a session but that knowledge dies when the session ends. Auto-memory helps with small things. But for structural knowledge, like API patterns and tool usage, you need to make it permanent by putting it in CLAUDE.md or the project documentation.

Most People Don't Teach

I think this is where a lot of people go wrong with AI tools. They prompt, they get output, they use it or they don't. If the output is bad, they try a different prompt. If it's good enough, they move on. There's no feedback loop.

When Claude does something the hard way, I stop and say so. "That seemed harder than it should have been. What was the problem?" Then we work through it. When it takes the right approach, I let that stand too. Both signals matter. If you only correct mistakes, the AI gets cautious. If you also let good decisions pass without challenge, it builds confidence in those patterns.

Good feedback goes in both directions. You don't only show up when something breaks.

Building Towards Trust

The goal isn't to have a junior developer forever. The goal is to build something you can trust with more autonomy over time.

Right now I review most of what Claude produces. I check the code, I read the PRs, I approve the approach. That's appropriate for where we are. But every time I close a knowledge gap, write a better CLAUDE.md section, add a test, or document a pattern, I'm raising the baseline. The review becomes lighter.

A junior needs their code reviewed line by line. A mid-level needs a check on the approach. A senior needs a conversation about the trade-offs and then you let them get on with it. With AI, you're building that progression through documentation, tooling, and feedback rather than through experience and time served. But the trajectory is the same.

I'm not there yet. Claude still does things I wouldn't trust unsupervised. But comparing where I am now to where I was three months ago, the direction is clear. Each session starts from a higher baseline than the last. The people who treat AI as a static tool will always be supervising a junior. The people who actively teach it will end up working with something closer to a senior. The AI itself doesn't change. Your environment does.

It's a Two-Way Street

The interesting thing is that this mentoring process makes me better too. When I have to explain why an approach was wrong, I have to think clearly about what the right approach actually is. When I document API patterns for Claude, I end up with a reference I can use myself. When I write tests for the converter script, I'm protecting my own future sessions as much as Claude's.

This is the same thing that happens when you mentor a real person. Teaching forces clarity. The act of explaining reveals gaps in your own understanding.

I've also started catching my own bad habits. I was letting Claude use agents for tasks I could have just done inline with two API calls. That's not Claude's fault. I was being lazy about the delegation. If I'd been more deliberate about what needed an agent and what didn't, the whole session would have been faster. The mentoring goes both ways. Claude forces me to be a better lead.

The Investment Compounds

Compare what I've described to the alternative. Every session starts from zero, hits the same problems, takes the same roundabout paths. You can do that. It still works. But you're leaving value on the table.

The AI won't ask for a one-to-one. It won't tell you it's struggling. You have to notice, diagnose, and fix. That's the job. It's always been the job. The team member just looks different now.