How to mentor junior developers when AI can finish the task for them
A junior developer completes a task with AI support. The change works, but they cannot explain why it works or where they would start if it failed. More completed tasks would not answer that learning gap.
Mentoring needs space for explanation, questions and supported practice. AI can provide another way to explore a concept, but the team still needs to make time for human feedback and context.
If you lead delivery, manage developers or support somebody entering tech, this session structure gives learning a concrete place in the working week. If you are the junior developer, you can use it to request focused support.
Choose one behaviour to understand
Pick a small change connected to real work: an empty-state message, a validation rule or a single data transformation. Avoid combining a new framework, unfamiliar system and urgent release into one learning task.
Agree what the developer should be able to explain afterwards. For example: “Show how an empty result becomes a helpful message, and explain how we distinguish an empty result from a failed request.” That goal tests understanding as well as completion.
A 30-minute mentoring session
- First 5 minutes: the learner explains the intended behaviour and predicts an awkward case.
- Next 10 minutes: trace the relevant code together. Ask the learner to identify where the state changes and where a failure would appear.
- Next 10 minutes: make one small change or investigate one failing case. Use AI only for a focused question, then check the answer.
- Final 5 minutes: the learner explains the change, its limitation and what they want to practise next.
Thirty minutes is a suggested starting point, not a universal target. Adjust it for access needs, task complexity and the learner’s experience. Protect the time in the team’s plan rather than adding it after a full workload.
Make the question safe to ask
Ask “Which part should we trace together?” rather than “You understand this, right?” The first invites a specific question; the second can make agreement feel like the easiest answer.
Explain the system’s local conventions. An AI can describe a general pattern while missing why this team chose another approach. Point to a relevant example and explain the constraint behind it.
Offer different ways to prepare: a written question, a small diagram or a spoken walkthrough. Do not judge understanding by confidence, accent or how quickly someone speaks. Use the quality of their explanation and the next independent action.
Practise the mentor response
In this fictional case, a junior developer says: “The AI fixed it, but I do not know why.” Which response creates a useful next step?
“Good, close the task and move on.”
The fix may be useful, but the learning question remains. Reserve a short review to compare the old and new behaviour before increasing the task’s scope.
“You should already know this.”
This gives no practical route forward. Ask the learner to identify the first line they cannot explain, then trace it together and choose one independent follow-up exercise.
“Show me what changed and what you expect it to do.”
This is a useful starting point. Ask for a prediction, inspect one difference and test it. If the change is too large to understand, reduce its scope or review it with the appropriate specialist.
Use AI as a focused practice partner
A learner might ask: “Explain this small fictional example, then give me a similar question without the answer.” They can attempt it independently and discuss the reasoning with their mentor.
Check explanations against documentation and working examples. Avoid treating generated tests as sufficient just because they pass: they may repeat the same assumption as the generated implementation. Choose expected results before inspecting the proposed answer.
Follow the team’s rules for sharing code and information with AI tools. Use fictional or approved practice examples when the work material cannot be shared. Keep the mentor responsible for explaining team context and the learner responsible for engaging with the exercise.
Look for growing independence
Keep a small learning record: what the developer can now explain, change and investigate with less support. “Can distinguish a failed request from an empty result” is more informative than “completed five tickets”.
If understanding has not improved, adjust the task, support or time available. Do not assume the person lacks potential. A task may depend on knowledge they have never had a chance to practise.
For your next session, ask the learner to choose one question in advance. Finish by agreeing one manageable action they can try before you meet again. Consistent support makes learning part of delivery, rather than something people must fit around it.
You May Also Like
How to make your contribution visible in tech without being the loudest
The Importance of Mental Health Care for Work-Life Balance
