About the series

This is the first part of an article series about using AI to become more useful for the people around you. In this part, I focus on code reviews: how they can become an opportunity for mentoring, sharing knowledge, and helping the whole team move with more confidence.

In the parts that follow, I will look at other habits that have the same effect, from asking the right questions to the documentation and agent context, tools a team relies on every day. Each part looks at the same question from a different angle: how can AI help us make better decisions for the team, not just move faster as individuals?

What it means to be a team multiplier

Working in a team does not automatically make you a team multiplier. At first, the term “team multiplier” can sound like career-ladder language: something you need to prove before you can move to the next level.

In practice, I think it is much more human and much more concrete than that. You become a team multiplier by building habits and a mindset that make the people around you more effective. You share useful context. You help unblock someone. You take responsibility for problems that are slightly outside your usual area of ownership, because solving them helps the team move forward.

AI can support this work. Used well, it can help you prepare and share knowledge, investigate unfamiliar problems, and give your teammates a better starting point. It does not replace judgment, trust, or collaboration. But it can make it easier to act on those values more consistently.

In this post, I want to explore how AI can help build a team multiplier mindset, and where the human part still matters the most.

The process is not a selfish game, and it is not tied to seniority

Developing team multiplier skills can help your career. It may help you grow into bigger roles, earn more trust, and eventually receive better compensation. But that is neither the real reward nor the only one.

The real reward is what changes in you.

You start leaving behind the need to prove yourself all the time. You become less driven by ego, less afraid of failure, and more focused on what helps the team and the company succeed. Responsibility stops being something attached only to a title. It becomes something you choose, even when nobody explicitly asks for it.

And you do not need to wait until you are senior to begin. You can start as a junior, with small steps, and build this mindset throughout your journey.

Code reviews are an opportunity for mentoring and sharing knowledge

With AI involved in writing code, the number of PRs one software engineer can create is increasing. Because of that, the number of PRs we review will probably increase as well.

My recommendation is not to react to this by pressing the “approve” button faster. Instead, we should make reviews more thoughtful.

The colleague who created the PR, even with AI assistance, still owns the change. They are primarily responsible for what they are going to merge and eventually push to production. But as a reviewer, you also have responsibility. Your role is not only to catch obvious bugs. It is also to put the right amount of effort into understanding the change and helping improve it.

This is where code reviews become a real opportunity for mentoring and sharing knowledge. You can use the review to share your review strategies, architectural thinking, and code design experience. Over time, this helps colleagues make better decisions themselves. It also helps them guide AI agents more effectively in the future, because they learn what good technical reasoning looks like.

There are also agreements you can make with your team before a PR is even opened:

• one PR should address a single problem or a single feature
• agree with the team that, when possible, PRs should stay small enough to review in one focused session; if there are too many changes, split them into smaller PRs
• adopt shared code generation guidelines, conventions, design patterns, and domain or project-specific requirements, so the review becomes more structured and focused; I wrote more about this in How I improved AI-generated Python code by setting clear instructions
• instruct the agent not only to generate code, but also to write tests and documentation, and update the agent context for the changes it makes

You can also use agents before and during the review process:

• use agents to validate whether the changes follow team agreements and development conventions
• ask agents to review the changes, but make sure the PR owner has already reviewed and addressed the issues and warnings raised by the agent
• use agents to understand what the code changes are doing, and what intent or requirement might be behind them

The outcome of the review should be shared with the PR owner, but not as an opportunity for blame or criticism. The point is to help your colleague understand the reasoning behind your comments and suggestions. That is where the mentoring happens.

What I do in the PR reviews in the AI era

Since AI-generated code started appearing in the PRs my team reviews, I have developed a few habits:

• I like to see the instruction files alongside the code changes. They show me what context the agent had, and what it was missing. That helps me ask more useful questions: Did the solution cover edge cases, security concerns, or type-conversion issues?
• I check that the instructions used for code generation point to our team coding guidelines.
• For anything more involved than a one- or two-line change, I try to talk through the workflow with the author. I want to understand the motivation and constraints behind the implementation. Then I can give the PR-review agent better checks to run.
• I try to explain the reasoning behind my review comments, not only what I think should change. I want the author to understand the trade-offs and feel confident making a similar decision next time. For more complex changes, I prefer a short conversation to a long comment thread. It is usually faster, and it gives us a chance to think through the options together.
• I treat maintainability as part of the review. I use agents to explore how the code might hold up when the next change arrives.
• I also question unnecessary abstractions. AI can add extra classes, layers, factories, or generic helpers that make a small change harder to understand.
• When the change affects a running system, I review the operational details too: logging, metrics, failure modes, retries, idempotency, configuration, migrations, and rollback plans where they apply.
• In Python, I pay close attention to types and boundaries. I look for clear type hints, input validation, and useful error handling, and I watch for mutable defaults, broad except Exception blocks, hidden global state, and confusing async or concurrency behaviour.
• I expect every meaningful change to have tests, even when the first version of those tests comes from an agent.
• When I find a discrepancy, I try to be specific. I explain which use case the change needs to cover, which failures it should handle, and which exceptions should be allowed to stop the process.

Conclusion

Writing code is no longer the only bottleneck. Having confidence in that code is becoming just as important.

That confidence comes from team members who have the judgment to look at a change and understand whether it is right: whether it solves the actual problem, fits the system, follows the team’s standards, and can be safely maintained later.

I believe code reviews are one of the best opportunities to build this confidence inside a team. When they are done thoughtfully, and ideally through direct conversation, they become more than a quality gate. They become a way to mentor, share knowledge, explain trade-offs, and help teammates develop stronger technical judgment.

AI can support this process. It can help you understand a change, prepare better feedback, check conventions, and explain alternatives more clearly. But it cannot replace the human part: responsibility, trust, context, and collaboration.

This is one part of becoming a team multiplier: using AI not only to move faster yourself, but to help the whole team make better decisions.

What’s next?

In the next parts of this series, I will look at other habits that help turn individual productivity into team productivity: unblocking colleagues earlier, asking better questions, improving documentation and tools, and taking ownership of problems that sit slightly outside your usual scope.

The common thread is the same: AI is most valuable when it helps the team build shared understanding, stronger judgment, and more confidence in the work.

Disclosure

This article was written by me. I used AI to improve clarity, correct grammatical errors, and refine phrasing, but the reasoning and opinions are my own.

The hero image was generated with Gemini 3.1 Pro.