Review your Prisma schemas with Gemini Code Assist for GitHub

This blog post is a translation of a Japanese article posted on June 30th, 2025. It has been changed as needed to reflect Gemini Code Assist for GitHub going from preview to GA.

In general, database changes have a bigger impact than application code changes, and we naturally tend to be more prudent when applying them. A simple example of things going wrong is forgetting to change default value settings for columns like createdAt , losing the original data in the process. Considering this, it is important to minimize the amount of database changes going to production.

One of the ways to do that is to simply be stricter with database-related code reviews! But review quality highly varies depending on the person conducting them, and they require someone with database domain knowledge, which often becomes a time bottleneck.

To counter that, you would traditionally impose code review guidelines, coach reviewers, or increase the number of code reviewers. In fact, that was probably the only thing you could do… until GenAI, that is! We now have a way to automate reviews and save us some trouble.

In this article, we are going to look at Google Cloud’s Gemini Code Assist for Github, and put it to the test by implementing a review process for Prisma data modeling. Strap in!

The code and style guides shown in this article are purely meant as examples. Exercise caution when using them in production.

What is Gemini Code Assist for GitHub?

Gemini Code Assist for GitHub, per Google, “brings the power of Gemini to the pull request process by acting as a code reviewer.” It can automatically review GitHub pull requests, find bugs and style problems, and even suggest code fixes.

Gemini Code Assist uses the config.yaml and styleguide.md files in your .gemini/ directory to apply settings at the repository or directory level.

Customize settings with config.yaml

You can customize Gemini Code Assist’s behavior using the config.yaml file. This includes choosing files to include or exclude during code review using glob patterns.

An overview of configuration settings

Be sure to check the documentation for any updates to the configuration settings!

• have_fun : Enables fun features such as a poem in the initial pull request summary. Default: false
• ignore_patterns : A list of glob patterns for files and directories that Gemini Code Assist should ignore. Files matching any pattern in this list will be skipped during interactions. Default: []
• code_review : Configuration for code reviews.
  • disable : Disables Gemini from acting on pull requests. Default: false
  • comment_severity_threshold : The minimum severity of review comments to consider. Can choose from LOW, MEDIUM, HIGH, and CRITICAL. Default: MEDIUM
  • max_review_comments : the maximum number of review comments to consider. Use -1 for unlimited. Default: -1
  • pull_request_opened : Configuration for pull request opened events.
    • help : Posts a help message on pull request open. Default: false
    • summary : Posts a pull request summary on the pull request open. Default: true
    • code_review : Posts a code review on pull request open. Default: true
    • include_drafts : Enables agent functionality on draft pull requests. Default: true

If you don’t include any particular settings, Gemini Code Assist defaults to the following:

have_fun: false
code_review:
  disable: false
  comment_severity_threshold: MEDIUM
  max_review_comments: -1
  pull_request_opened:
    help: false
    summary: true
    code_review: true
    include_drafts: true
ignore_patterns: []

As another point of reference, you can also look at Gemini CLI’s own configuration file. It mostly adheres to the default settings, except for comment_severity_threshold which is set to HIGH.

Provide a style guide with styleguide.md

styleguide.md is a Markdown file used to specify information and rules you would like Gemini Code Assist to follow during code reviews. This is typically a chance to put your project’s code guidelines, architecture style, and more in writing.

In this article, we will showcase how, by using styleguide.md, your Gemini Code Assist-powered code review can improve significantly.

A Practical Example: Review Prisma Code using Gemini Code Assist for GitHub

Let’s actually put Gemini Code Assist for GitHub to the test! We’ll see how it handles reviewing a data modeling PR for Prisma.

We’ll first look at how Gemini Code Assist manages without any style guide. We’ll then add a style guide with basic code guidelines that Gemini Code Assist can reference in its review. Finally, we’ll upgrade the style guide with specific data modeling rules to get an even better review!

All the code covered in this article, as well as reviews performed by Gemini Code Assist, will be available in this Github repository:

https://github.com/nnaka2992/gemini_code_assist_with_database

The Prisma schema file up for review

Here’s the Prisma schema file (prisma.schema) we want to review.

// This is your Prisma schema file,
// learn more about it in the docs: <https://pris.ly/d/prisma-schema>

// Looking for ways to speed up your queries, or scale easily with your serverless or edge functions?
// Try Prisma Accelerate: <https://pris.ly/cli/accelerate-init>

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model User {
  id        Int       @id @default(autoincrement())
  email     String    @unique
  name      String?
  posts     Post[]
  profile   Profile?
  createdAt DateTime
  updatedAt DateTime
  deletedAt DateTime?
}

model Profile {
  id     Int     @id @default(autoincrement())
  bio    String?
  userId Int     @unique
  user   User    @relation(fields: [userId], references: [id])
}

model Post {
  id         Int        @id @default(autoincrement())
  title      String
  content    String?
  published  Boolean    @default(false)
  authorId   Int
  author     User       @relation(fields: [authorId], references: [id])
  categories Category[]
  createdAt  DateTime   @default(now())
  updatedAt  DateTime   @updatedAt
}

model Category {
  id    Int    @id @default(autoincrement())
  name  String @unique
  posts Post[]
}

Using Gemini Code Assist without a style guide

Let’s first look at what Gemini Code Assist for GitHub does when it doesn’t have any style guide to reference:

https://github.com/nnaka2992/gemini_code_assist_with_database/pull/5#discussion_r2173642355

Result: not good enough

Here, Gemini Code Assist points out a problem with the createdAt and updatedAt columns. They do not have any default values set, so a CREATE operation will fail if they are not provided manually.

On the other hand, Gemini Code Assist is not taking into account the overall application structure, such as all other tables having a createdAt and updatedAt columns that we could reference, or that other tables should implement Row-Level Security based on our User model. This is domain-specific context that cannot be easily inferred without a style guide.

Enhancing Gemini Code Assist with a style guide

Next, let’s write a style guide to let Gemini Code Assist for GitHub know about our code guidelines.

The styleguide.md overview

You can take a look at the complete style guide on GitHub, but it essentially covers the following:

• Putting naming conventions in place for model and column names
• Providing primary key rules and data types for ID columns
• Forbidding implicit many-to-many relations
• Adding createdAt/updatedAt columns to all tables and setting them to auto-update
• Enforcing explicit referential integrity for constrained fields on update and delete
• Prefixing boolean columns with is/has/can
• Setting rules for model field ordering

Result: way better!

Here’s how Gemini Code Assist reviewed the code, this time with our style guide to go off of:

https://github.com/nnaka2992/gemini_code_assist_with_database/pull/8

Gemini Code Assist pointed out the following:

• For the User model:
  • Use uuid for the id column.
  • Add default value and auto-update settings to the createdAt/updatedAt columns.
  • Order the fields correctly according to the style guide.
• For the Profile model:
  • Use uuid for the id column.
  • Create a primary key with userId/id columns for Row-Level Security.
  • Add createdAt/updatedAt columns.
  • Enforce referential integrity with the User model.
  • Order the fields correctly according to the style guide.
• For the Post model:
  • Use uuid for the id column.
  • Create a primary key with userId/id columns for Row-Level Security.
  • Avoid creating an implicit many-to-many relation with the Category model.
  • Change the boolean published field’s name to isPublished.
  • Enforce referential integrity with the User model.
  • Order the fields correctly according to the style guide.
• For the Category model:
  • Use uuid for the id column.
  • Add default value and auto-update settings to the createdAt/updatedAt columns.
  • Avoid creating an implicit many-to-many relation with the Post model.

That is a lot! And it is proof that adding a style guide allows Gemini Code Assist to take into account the project’s code guidelines. It is especially impressive that it is able to detect implicit many-to-many relations, something that is not easily doable by simply grepping the codebase.

Beyond code fixes: Adding advanced rules to the style guide

Finally, let’s add data modeling rules to the style guide and see how different Gemini Code Assist for GitHub reviews our Prisma schema.

The styleguide.md overview

You can find the updated style guide on GitHub, but here’s what we are adding:

## 8. Deletion Strategy
### 8.1. Deleted Tables
Instead of soft deletion with a `deletedAt` field, we use separate deleted tables with database triggers to maintain a complete audit trail of deleted records.

For each main table that requires deletion tracking, create a corresponding deleted table with:
- The same structure as the original table
- An additional `deletedAt` timestamp field
- An additional `deletedBy` field to track who deleted the record

(Skipping example model for brevity)

### 8.2. Deletion Triggers
Database triggers MUST be created to automatically copy records to the deleted table before deletion. These triggers are managed in version-controlled .sql files as they are not part of the Prisma schema.

(Skipping example trigger for brevity)

### 8.3. Naming Convention for Deleted Tables
- Deleted table names MUST follow the pattern: `Deleted{OriginalModelName}`
- Example: `User` → `DeletedUser`, `Post` → `DeletedPost`

### 8.4. Gemini Code Assist Implementation Notes
When implementing deletion functionality, Gemini Code Assist should suggest the following changes:

(Skipping for brevity)

Result: great! But not perfect

Here’s our final Gemini Code review:

https://github.com/nnaka2992/gemini_code_assist_with_database/pull/9

The gist of it is similar to the previous review, with one exception: Gemini Code Assist now points out that the User model contains a deletedAt column, and suggests to instead archive deleted user records in a separate DeletedUser model.

This demonstrates how Gemini Code Assist can make suggestions based on an updated style guide. However, it does fall short of actually providing code for the DeletedUser model. This could be solved by just rerunning Gemini Code Assist, but it does illustrate one of the potential limitations of current coding agents.

Conclusion

This blog post introduced a method for partially automating database-related reviews using Gemini Code Assist for GitHub, a generative AI tool.

The accuracy of the reviews changed significantly before and after providing coding standards, and it also became possible to generate change suggestions for rules that delve into data modeling. This indicates the potential to greatly simplify data modeling reviews by saving SQL anti-patterns and data modeling anti-patterns as a styleguide.md.

This will enable safer database changes even in organizations without a database engineer. In organizations that do have a database engineer, it will reduce the engineer’s review burden, allowing them to focus on more advanced and essential tasks.

At the same time, it can be said that for anti-patterns and rules that are specific to an organization and difficult to generalize, a database engineer will need to periodically organize the context and cultivate the styleguide.md.

References

• prisma/prisma
• Glob Patterns Reference
• Customize Gemini Code Assist behavior in GitHub