How should a junior developer use AI as a tutor and reviewer?

Scope

This workflow is for early-career developers who use AI during study or production work and want to build independent judgment. It addresses the learning loop, not company rules for proprietary data or code-review approval.

Why it happens

AI makes the finished artifact arrive before the learner has formed a model of the problem. The code may work, yet the developer has not predicted a failure, chosen a boundary, inspected an API contract, or practiced recovery. Completion and learning separate.

Avoiding AI entirely also wastes a useful feedback surface. A model can generate contrasting cases, ask questions, challenge assumptions, and explain an error at several levels. The key is assigning it a role that does not remove the cognitive step being practiced.

Diagnosis

After an AI-assisted task, close the transcript and answer:

• What did you predict before running the code?
• Which requirement or invariant determined the design?
• Which alternative did you reject and why?
• What failure did you reproduce?
• Which external documentation confirms the API behavior?
• Can you change one constraint and adapt the solution without copying?
• Can you explain the result to a reviewer with no appeal to “the AI said so”?

Difficulty answering indicates that assistance occupied the driver’s seat rather than a tutoring or review seat.

Solution

Begin each task with a short prediction: expected behavior, risks, and test. Ask the AI for questions or a hint before requesting a solution. When it proposes code, require a line-by-line behavioral explanation, counterexample, and test plan. Verify claims against official documentation and execution.

Use three passes. In the tutor pass, the AI asks and explains. In the critic pass, it searches for edge cases, security issues, and alternative designs. In the reviewer pass, it compares the code to an explicit rubric. The developer owns the design record, runs the tests, and decides what to accept.

Schedule unassisted transfer tasks. Change the language, API, failure condition, or scale so memorized output is insufficient. Review errors with a mentor or peer when stakes are meaningful.

Artifact

Assign seats before a practice task:

Stage	Developer owns	AI may do	AI must not replace	Evidence saved
Frame	Requirements, constraints, prediction	Ask clarifying questions	Choose the objective silently	Problem card
Design	Alternatives and decision	Challenge trade-offs	Declare one architecture correct	Decision note
Implement	Read and understand every change	Suggest bounded patches	Apply unexplained bulk changes	Diff and explanation
Test	Define oracle and failure cases	Propose contrasts/fuzz cases	Grade its own output alone	Test results
Debug	Reproduce and form hypothesis	Suggest discriminating checks	Replace evidence with narrative	Hypothesis log
Review	Final acceptance and escalation	Review against rubric	Approve high-impact change	Review record
Transfer	Solve related case unaided	Stay unavailable until debrief	Feed the answer during assessment	Reflection

Common mistakes

• Asking for the full answer before forming a prediction.
• Accepting an explanation because it sounds clear without running a discriminating test.
• Using AI to write both the solution and the only tests.
• Measuring productivity only by task completion time.
• Practicing one familiar pattern without unassisted transfer to a changed problem.