Coaching a junior team on Claude Code without breaking their instincts

The risk nobody talks about with junior teams and AI

A senior engineer reading AI-generated code has a quiet, constant background process running. Something looks off. The shape of this function is wrong for our codebase. That import does not exist. I have never seen us handle errors like that. The reflex is not conscious; it is the residue of years of being burned.

A junior developer does not have that reflex yet. They are still building it. And when an AI hands them a plausible-looking block of code that compiles and roughly does the thing they asked for, the path of least resistance is to accept it.

That is the actual risk on a junior team adopting AI-assisted development. Not that the AI will write bad code. It will, sometimes. The risk is that the people receiving the code do not yet have the calibration to notice.

I spent part of a recent engagement coaching a team of around nine developers, predominantly junior, including bootcamp graduates and a few people working in languages they had not used before. The client adopted Claude Code internally partway through the engagement. The mentoring became a meaningful part of my role almost overnight.

This is what I learned about coaching juniors on AI tools without breaking the instincts they were still trying to build.

Do not lecture about AI in the abstract

The first instinct, when you see a junior accept AI output too quickly, is to give a talk. AI hallucinates. AI does not understand your codebase. AI is a tool, not an oracle. All of this is true and all of it bounces off.

It bounces off because abstract warnings do not change behaviour. A junior who has just shipped a working feature with AI assistance has direct, recent, positive evidence that the tool works. A general caution from a more senior person does not outweigh that. It just feels like the older developer being grumpy about new tools.

What changes behaviour is showing them, on the code they are actually working on, a concrete moment where the AI was wrong. Not a contrived example. Not a screenshot from a blog post. A real moment in the actual repo, where the output looked fine and was not.

On this engagement, the failures came in three flavours.

The first was over-elaboration. The AI would generate four variations of a component when the design system had room for one. It would invent variants that solved problems we did not have. The code was clean, well-named, internally consistent. It was also waste, and it scattered the surface area of the design system in ways that would cost us later.

The second was wrong-shape integration. We were working with several third-party platforms in the education sector, each with its own conventions for things like enrolment events, learner records, and assessment uploads. The AI would generate integration code that looked correct at a glance but quietly assumed conventions from a different platform. The function names were plausible. The shape was wrong.

The third was platform boundary confusion. Some of the third-party systems were close cousins, similar domain language, overlapping concepts. The AI could not reliably tell where one ended and the next began unless we had explicitly shown it. Without that, it would blend them, producing code that referenced fields from one platform inside flows that belonged to another.

When I sat with developers and walked through these specific failures in their actual code, the lesson landed. Not because I argued harder, but because the evidence was right there in their own pull request.

Two rules, repeated until they were boring

I tried to keep the coaching down to two rules, because I wanted them to be repeatable in the moment, not memorised from a deck.

Rule one: verify, do not trust. The AI is a draft generator. A draft is a starting point. You do not merge a draft. You read it, you run it, you check it against the docs of the third-party platform you are integrating with, and you decide whether it survives contact with reality. If you cannot verify it, you do not ship it.

Rule two: every session has a brief and a verifier defined before the session starts. Before you open Claude Code, write down two things. What am I asking it to do? How will I know if the output is right? The brief stops you from drifting into vague prompts. The verifier stops you from declaring victory because the code compiled.

The verifier did not have to be elaborate. Sometimes it was a unit test. Sometimes it was a manual check against the third-party platform's actual response payloads. Sometimes it was running the integration end-to-end in a sandbox. The point was that the verifier existed and was named in advance, so that "looks fine" was not allowed to be the answer.

These two rules sound obvious written down. The reason I repeated them constantly, in standups and in code reviews and in pairing sessions, is that the pull of accepting plausible output is strong, and rules that do not get repeated do not stick.

Code review is where the discipline gets reinforced

The temptation, when a team is using AI tools, is to turn code review into AI detection. Reviewers start trying to spot AI-generated code from across the room. Was this written by a human or a model? It is the wrong question. It is also a question reviewers tend to be bad at answering, which makes the exercise demoralising.

The right question in code review on an AI-assisted team is: what verified this?

If the answer is "I ran it and it worked", that is not a verification, that is a vibe. If the answer is "the test passes", that might be a verification or it might be a tautology, depending on whether the test was generated alongside the code by the same prompt. If the answer is "I checked it against the platform's documented response shape and added a test that mirrors the contract", now we are talking.

I started asking that question, gently, in every review I did. Not "did you write this" but "what convinced you this was right". After a few weeks, the team started asking each other the same question without me prompting. That was the goal.

Do not try to ban the tools

A coaching pattern I deliberately avoided was making juniors feel bad for using AI assistance.

If you tell a junior developer that they should not use Claude Code until they have earned it, three things happen. They use it anyway, just quietly. They lose access to a learning tool that is genuinely useful for exploring an unfamiliar codebase. And the conversation about verification stops being a coaching conversation and starts being a compliance conversation, which is much harder to win.

The juniors on this team were going to use AI tools. Bootcamp graduates have used them since their bootcamp. Developers learning a new language often reach for them as a translator. The honest question was never whether they would use them. It was whether they would verify what came out.

So the framing I tried to keep was: the tool is fine, the discipline is the thing we are building together. Treat it like any other power tool. You can use a circular saw on day one. You also wear the safety glasses on day one.

A specific moment that changed the team's behaviour

Partway through the engagement, one of the developers had a session with Claude Code that produced about six variations of what was nominally the same component. The variations were not redundant in a trivial way. They had different prop shapes, different defaults, slightly different behaviour around edge cases. It looked like the model had been asked an open-ended question and had answered it with a buffet.

The developer brought the output to a review feeling pleased. They had a lot of code, and it ran.

We sat with it for half an hour. We worked out which one variation we actually needed. We worked out why the others were tempting and wrong. We worked out what the brief should have been if we had wanted just the one. And we wrote that brief down, retroactively, as a kind of artefact.

The next session that developer ran with Claude Code, they wrote the brief first. The output was much smaller, much closer to what was needed, and reviewable in a few minutes rather than an afternoon. The lesson was not "AI generated too much code". The lesson was "an open prompt produces an open answer". They felt that lesson because they had lived through the half hour of cleaning it up.

That is the kind of teaching moment I cannot manufacture. I can only notice it when it happens and slow down enough to make it count.

What I would do differently next time

If I were starting this engagement again, I would begin the AI coaching in week one rather than waiting until the team had been working for a while.

Habits set quickly on a new codebase. By the time the team adopted Claude Code internally, several patterns of working with the tool had already taken shape, some of them good, some of them less so. Reshaping habits is harder than forming them. Starting earlier would have meant the brief-and-verifier rhythm was the default from the first commit, rather than something we retrofitted.

I would also be more deliberate about collecting the AI-was-wrong moments and using them as teaching artefacts. On this engagement, they happened organically and I responded to them in the moment. A small shared document of "here is a real failure on our codebase, here is what we learned" would have given the team something to refer back to without me in the room.

Why this matters beyond one engagement

The team continued using Claude Code after I left, in roughly the way I had taught. As a draft generator that needed verification, with briefs and verifiers defined up front, and with code review treating "what convinced you this was right" as a normal question to ask.

That is the part I am proud of. Not that they used the tool, but that the discipline around the tool survived the handover. Patterns outlast engagements. So do bad habits, which is why the early coaching matters.

If you are leading a junior team that is starting to use AI-assisted development, the work is not really about the tool. It is about helping people build the verification reflex before they need it, on the codebase they are actually working on, with examples that feel real because they are.

That is a leadership exercise as much as a technical one. Worth doing properly.

If you are thinking through how to introduce AI tooling on a team that is still finding its feet, I am happy to compare notes. No pitch, just a conversation if it is useful.