I work solo on a few side projects, and even though I enjoy coding, reviewing my own pull requests isn’t exactly fun (or efficient). I tend to skip reviews, miss obvious bugs, and come back weeks later thinking “what was I thinking?”

So I tried working with a new teammate : Hello Gemini Code Assist 👋🏼

If you haven’t heard of Gemini Code Assist, It is a generative AI coding assistant to help you with tasks across the Software Development Lifecycle and powered by Gemini 2.5. Think of it like a reviewer that gives instant feedback, suggests ready-to-commit code fixes, and even summarizes your pull requests.

Spoiler: It’s like having a helpful teammate who never sleeps ☕

🚀 What Gemini Actually Does on my PR

When I open a PR Gemini jumps in within ~5 minutes. It adds itself as a reviewer (gemini-code-assist[bot]) and I get:

• A summary of the PR ;
• A list of code comments with suggestions ;
• Sometimes even fixes I can commit directly.

I can also talk with it, asking for clarifying questions on the review that it creates, etc.

The available commands are the following :

I usually trigger a /gemini review just before merging to double-check everything.

📄 1. Pull Request Summary

Right after I open a PR, Gemini write a summary comment to give a quick heads-up. It includes:

• A short overview of what’s been changed
• Highlights of the major updates or refactors
• A mini changelog listing the important modifications

Perfect if you want your team (or future you) to instantly understand what’s going on without digging into every file.

🕵🏼‍♂️ 2. Code Review Summary

A few seconds (or minutes) later, Gemini posts a second comment, this one focuses on what it found during its review. It covers:

• A general overview of all detected issues
• Severity and potential impact of each issue (from small nitpicks to critical bugs)
• Suggested improvements to fix or enhance the code

🔍 3. Code Reviews comments and proposals

For each specific issue spotted, Gemini also leaves inline comments right where the problems are in code. Each detailed review includes:

• The priority level of the issue (critical, high, medium, or low)
• A clear explanation of what to change (sometimes with examples)
• A reference to the style guide rule (either Gemini’s defaults or your custom rules)

💡 Gemini Code Assist is currently in preview and may make mistakes. You can react with 👍 and 👎 on gemini-code-assist’s comments to provide feedback.

🙋🏼 4. Answer questions

You can directly ask Gemini Code Assist questions inside pull request comments!

Just mention it manually, and it will read the surrounding code and answer right in the thread with:

• A clear, concise answer based on the code and the context.
• Additional insights or clarifications if needed (e.g., explaining a complex change, suggesting alternatives).

This is super useful when you want a second opinion or quick advice without waiting for a human reviewer.

This is a really simple question here 😄

🛠️ Customizing Gemini for Your Project

By default, Gemini Code Assist acts like a well-trained reviewer even without any customization.

Here’s what it looks for when reviewing your pull requests:

• Correctness: It checks if your code actually does what it’s supposed to. Gemini looks for logic errors, bad API usage, forgotten edge cases, or even race conditions.
• Efficiency: It spots performance issues like unnecessary loops, memory leaks, inefficient data structures, and heavy logging that could slow down your app.
• Maintainability: Gemini cares about your future self. It flags messy variable names, overly complex functions, code duplication, missing documentation, inconsistent formatting, and anything that could make your code harder to read or maintain.
• Security: It keeps an eye out for common security issues like input validation problems, insecure data storage, missing access controls, or vulnerabilities like CSRF and IDOR.
• Miscellaneous: It can also comment on things like testing, scalability, modularity, and error handling/logging.

Guiding Gemini on how to review your code.

Just add a .gemini/ folder at the root of your repo with these two files:

🔧 config.yaml — Control what Gemini does

This file controls how much Gemini talks and when.

Example:

have_fun: true
code_review:
  comment_severity_threshold: MEDIUM
  max_review_comments: 10
  pull_request_opened:
    summary: true
    code_review: true

This configuration tells Gemini to:

• Only flag issues that are medium severity or higher.
• Cap the number of comments to avoid overwhelming you.
• Always post a PR summary and code review when a PR is opened.
• And most important, to enable fun features such as a poem in the initial pull request summary.

📘 styleguide.md — Teach it your rules

You can write your own custom coding rules for Gemini to follow.

For this Go Project, mine’s really simple but you can include stuff like project structure, naming convention, tooling, code style, etc:

- Always return early in functions to reduce nesting.
- Avoid using `panic` outside of `main()` or tests.
- Always check for `err` immediately after a function call.
- Use `log/slog` instead of `fmt.Println`.
- Group standard library imports separately from third-party imports.
- Avoid magic numbers; define them as constants.

It’s not just basic linting — it actually adjusts its review based on what you care about.

You can check a complete example here.

🧵 Final Thoughts

If you’re working solo or on a small team, Gemini Code Assist is a super assistant. It saves time, catches issues, and makes your PRs feel way more professional, even if they’re just for a weekend side project.

I’ll keep using it to double-check my PRs and level up my code reviews (even if it’s just me reviewing myself 😅).

If you already use it, let me know what your config looks like or if you’ve found creative ways to use it!

📝 Official docs

Check out the official docs here :

• https://developers.google.com/gemini-code-assist/docs/review-github-code
• https://developers.google.com/gemini-code-assist/docs/customize-gemini-behavior-github