Infisical is open source, so our whole codebase is public. Every pull request we merge is a change to security infrastructure that other teams depend on.

We use Greptile to review those pull requests. As of August 2026 it has commented on more than 2,800 of them in our main repository.

Why a security codebase is a hard place to review code

The hard part of reviewing our code is that the consequences of a change usually aren't in the diff.

A pull request might add a few dozen lines to one service and break a permission check three files away, or an integration that consumed the old shape of a response. A reviewer who reads only the changed lines sees clean code. A reviewer who knows the repository inside out sees what could go wrong.

Human reviewers are great, but they need to hold much of the codebase in their head, and that doesn’t scale, especially when engineers are multiplying how much code they create with AI coding agents. It scales worst where it matters most: authorization logic, permission boundaries, and anything touching how a credential is scoped.

Reviewer hours are in short supply in any startup, so we can’t just add more humans to the process. We wanted a way to expand review capacity without giving up the depth that makes a good review.

What Greptile actually does

Greptile is an AI code review platform that validates pull requests with full context of the codebase. Rather than evaluating changed lines in isolation, it examines how a change interacts with callers, dependencies, shared modules, and internal APIs, which is what lets it identify bugs whose consequences extend beyond the diff.

Its findings tend to name the specific file or internal document it read to reach a conclusion, and the claim is usually about a relationship between the change and something outside it: a branch the new tests don't reach, a second component that shares the constraint being fixed in the first, a path that will hand the wrong input to a downstream service.

That is the category of problem we care most about. A change to how a credential is scoped is rarely wrong on its own lines. It's wrong in combination with a caller written six months earlier by someone who has since moved teams.

Tuning matters more than raw coverage

A review tool that comments on everything trains engineers to scroll past it, and a review nobody reads is worse than no review because it provides the semblance of QA without providing it.

To make sure every engineer reads Greptile’s comments, we tuned it rather than leaving it on default settings. We set a moderate strictness level, limit findings to the categories we actually want flagged, and exclude certain files. Findings carry a severity label and open with a one-line claim before the explanation to ensure engineers act on them instead of scrolling past a wall of text.

The result is a review layer that engineers interact with rather than ignore, which is the only state in which it's worth having.

It reads our standards, not just our code

The second thing we get out of Greptile is enforcement of conventions we'd otherwise have to remember.

Our repository carries custom rules that encode decisions we've already made and don't want to reiterate: which internal helper is the right one for a given job, what a particular class of event has to include to be useful later, how new interface work should compose. These are the kinds of things that are obvious to whoever settled them and invisible to everyone else. For a human reviewer, reminding team members of these would also be a chore, but Greptile spots these automatically.

Greptile also reads the convention documents already sitting in the repository and cites them when a change deviates. Our design and documentation style guides stop being things new engineers are told to read and start being things the review process actually checks.

We don't take every finding

An AI reviewer is only worth having if you can argue with it, and we do. Some findings get declined because the engineer knows something about the runtime that the reviewer doesn’t, which can be useful information to feed it. Occasionally a finding is correct about the rule and wrong about the outcome, because the rule itself turned out to be the problem.

What makes that loop work is that corrections carry forward. When an engineer explains why a convention is wrong, the correction can be captured as a standing rule for the repository rather than relitigated on the next pull request. The reviewer gets more useful over time in the specific ways our codebase is unusual, which is not something a generic linter does.

A review layer nobody ever pushes back on is a review layer nobody is reading carefully.

Where this fits with AI-written code

More and more code in any organization now starts as output from a coding agent. This is creating an industry-wide problem: we’re creating more and more code, but human review resources aren’t scaling at the same pace.

Greptile is a great way to enforce high-quality code because it reads every single PR and enforces rules even for small-looking things. It scales review capacity with coding capacity.

We think about this on the credential side too. Our guidance on keeping AI-generated code safe and our work on brokering credentials to agents both start from the assumption that an agent's output and an agent's access should be checked by something that isn't the agent.

Greptile is how we check on code in PRs, and it earned its place in our pipeline. Engineers even tease each other over their Greptile scores in Slack.

Greptile also runs on Infisical. Their team uses us to give their code review agents scoped, read-only access to exactly the secrets those agents need, which is written up in their case study.