Using AI to become a team multiplier: a mindset that makes the people around you more effective - part 1

Mon, 03 Aug 2026 00:00:00 +0000

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.

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.

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.

Conclusion

I believe code reviews are a real opportunity for mentoring and sharing knowledge. When they are done in person, or at least through a direct conversation, they can make the process even more human and collaborative. This matters especially in the AI era, where human collaboration can easily become rarer if we let every interaction move into tools and comments.

AI can help the code review process, but it is not a substitute for human judgment and collaboration.

By using AI to support code reviews, you can share clearer and more professionally grounded technical reasoning with your colleagues. That reasoning helps the team generate faster, better, and more reliable code.

This is one piece in the puzzle of becoming a team multiplier.

What’s next?

In the next part of the article, I will explore how pair programming can help the team learn, and how creating documentation, including context for agents, can help the team advance faster.

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.

Engineering Leadership on Peter Fulop

Using AI to become a team multiplier: a mindset that makes the people around you more effective - part 1

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

Code reviews are an opportunity for mentoring and sharing knowledge

Conclusion

What’s next?

Disclosure