A student asked me about using AI code review in team development training for an existing project.

Tools such as Gemini Code Assist and CodeRabbit may find problems that people miss and reduce the burden of review. They may also give newcomers a chance to discover problems they would not notice on their own.

But does it count as training if they simply run the commands and apply the changes suggested by AI?

AI review can improve the code. Does the person who wrote it improve as well?

People Could Follow Instructions Without Learning Before AI

At first, I thought newcomers might need prior knowledge before using AI.

Without that knowledge, they cannot judge whether an AI comment is correct. If they apply a change without understanding why, they may not recognize the same problem the next time it appears.

However, this problem existed before AI.

A senior member might say, “Run this command” or “Change this part,” and a newcomer might do exactly that. The code is fixed, but the newcomer does not know why. Avoiding AI does not automatically produce learning.

The difference may not be between people who use AI and people who do not. It may be between people who finish after following instructions and people who try to understand the reason behind them.

AI may amplify that difference rather than create it. Because it quickly offers concrete fixes, work can continue even when the person applying them does not understand them.

What Can Be Looked Up and What Requires Conversation

I do not expect newcomers to memorize every language feature and framework before using AI.

It is often better to check language syntax, APIs, and framework behavior in official documentation or with AI. An upgrade can make previous knowledge obsolete. In some situations, being able to find and verify current information matters more than remembering it.

Git workflows, pull request practices, and team conventions are somewhat different.

General practices and operating instructions can be found online. External information alone, however, cannot explain why a particular team chose its workflow or what that workflow is intended to protect.

Suppose a team has a convention that changes should be divided into separate commits.

If a newcomer only memorizes that commits should be small, the convention may look like an inconvenience. Its purpose is not to increase the number of commits. It is to help anyone understand the intent of a change quickly, even when they return to it later.

AI can apply a rule. People still need to share which forms of collaboration that rule is intended to protect.

The Explanatory Debt in One Giant Commit

Suppose a newcomer implements a feature and commits every change at once when the work is finished.

From the newcomer’s perspective, this is a natural sequence.

The implementation is complete. It works. Now everything can be committed.

But if that commit mixes the new feature with renamed variables, formatting changes, and an unrelated bug fix, the reviewer must separate those intentions after the fact.

Even when the final code works, it is difficult to tell which differences were required for the feature. It is also difficult to decide which change should be reverted when a problem occurs. The reviewer or a future maintainer must reconstruct the thinking that the author did not organize.

This might be called explanatory debt.

Unreadable code leaves the burden of understanding to the future. In the same way, one giant commit leaves the burden of interpreting a change to the future.

Branches and commits do more than save work.

A branch defines the purpose of a change. A commit explains why a set of changes belongs together. A pull request communicates the intent of those changes to the team.

The change history, not only the code, needs to be readable.

What AI Can Read Is Not Necessarily Easy for People to Read

AI code review may find individual problems even in a large diff. That ability is useful.

However, the more easily AI interprets a large diff, the easier it becomes for a newcomer to proceed without organizing the change into explainable units.

They may conclude that their commit structure is good enough because AI can analyze it. If so, they lose opportunities to practice making changes readable for people.

Having AI split the commit afterward does not solve the learning problem either. If the newcomer simply accepts the result, they have not judged which changes belong to the same intention.

AI being able to read code and a person being able to understand the intent of a change quickly are different matters.

The goal of team development training should not be the ability to produce a diff that AI can process. It should be the ability to edit one’s changes into a form that other people can understand.

Ask for an Explanation Before Giving the Answer

If AI review is used in training, it may be better to use it after the newcomer has made an initial judgment rather than showing the answer from the beginning.

For example, the process could be:

  1. The newcomer reviews their own changes.
  2. They describe the purpose of the branch and why they divided the commits as they did.
  3. They ask AI to review the changes.
  4. They compare their judgment with the AI comments.
  5. They decide whether to accept each comment and explain why.
  6. A person reviews both the code and the newcomer’s reasoning.

AI does not have to complete the fix.

  • “Does this commit contain changes with different purposes?”
  • “Does this formatting change need to be in the same commit as the feature?”
  • “Can you describe the purpose of this branch in one sentence?”

AI can ask questions like these instead.

The newcomer thinks first, AI questions gaps in the explanation, and a person communicates the intent specific to the project. In this arrangement, AI is not a replacement reviewer but a partner that starts a conversation.

Introducing AI review alone does not create review education. A team must also decide when to use it, what the newcomer must explain, and who makes the final judgment.

Leave the Experience of Judgment With the Newcomer

In Designing Support That Does Not Steal Learning , I wrote that more helpful support is not always better support.

People cannot begin when they cannot find the entrance. But if every instruction and answer is provided, they lose the experience of researching, forming a hypothesis, and failing. The same applies to AI code review.

AI can be an entrance to learning something unknown. It can point out problems that people miss and introduce another way of thinking.

However, if the training ends when the newcomer applies AI comments, the code may be fixed without leaving them able to evaluate a review.

AI itself does not take learning away.

Support that gives the answer before the learner thinks and delegates the judgment to AI takes learning away.

When one giant commit appears, the training should not end by asking AI to split it. The newcomer should consider why it needs to be divided and who will read it later.

Even when AI is used, the newcomer should explain the intent of the change and make the final judgment. If the training preserves that experience, AI can support learning without taking it away.