Every engineer knows the feeling: you've documented your pull request rules in Confluence, Slack, and even the PR template, and yet someone still forgets them. A risky database migration sneaks through. A data model change ships without a product review. A "minor refactor" silently alters business logic.

At Mergify, we hit that wall too. Clear documentation wasn't enough, because we're all human. Instead of more checklists or stricter code review policies, I decided to try something different:

AI-powered pull request linters using GitHub's actions/ai-inference.

The result? In minutes, we had single-purpose, high-signal bots that catch issues humans miss, and do it without any of the old "regex hell" or brittle heuristics.

From Documentation to Automation

We had rules like:

• Data API and database structure changes require review by the product team.

• Database migrations must avoid locking or downtime.

• PR titles and descriptions should match the actual diff.

Everyone agreed with those rules. Everyone knew them. Yet, people still missed them. It wasn't neglect: it was fatigue. Context-switching is hard, and reviewers can't hold every rule in their heads at once.

Historically, the fix would be to write a linter or static analysis tool. But those are expensive: you spend weeks writing parsers, heuristics, and CI integrations, and months maintaining them.

With actions/ai-inference, I realized we could do the same thing in minutes: by writing natural language prompts instead of code.

One Job, Done Well: Single-Task AI Linters

actions/ai-inference lets you define a workflow that:

1. Feeds context to an LLM, such as the PR diff, title, and description.

2. Uses a prompt (in YAML) to describe what the AI should check.

3. Returns structured JSON with an action: comment, fail, or noop.

Instead of a single all-knowing "AI reviewer," I wrote a few narrow, purpose-built linters, each focused on one rule. The result was higher precision, less noise, and a review experience that actually helped, rather than nagging.

Here's one of my favorites.

Detecting Dangerous SQL Migrations

This workflow automatically scans database migration diffs and leaves a comment if something looks risky.

name: Detect dangerous SQL migration

on:
  pull_request_target:
    branches:
      - main
      - devs/**
    types: [opened, edited, synchronize]

The real "intelligence" lives in the prompt:

A typical output:

This migration removes nullable=False from column user_id without adding a NOT NULL constraint. This may allow nulls and break existing assumptions.

No need for a SQL parser. No brittle regex. Just rules, expressed in English.

Within the first week, these AI linters flagged two risky migrations, issues that had previously slipped through human review, with no false positives so far.

Two More That Took Minutes to Add

1. Product Review Enforcer

We have a rule: any data API or schema change must be reviewed by the product team.

Our AI linter checks the diff and PR body, and if it identifies model or endpoint changes without the @product-team or a needs-product-review label, it leaves a brief comment reminding the author.

2. Title vs. Diff Consistency

This one compares the PR title and description to the actual changes. If a PR titled "Refactor tests" also edits billing logic, it flags it.

Keeping metadata accurate saves time later, particularly in changelogs, release notes, and incident reviews.

Why Tiny Linters Beat Generic AI Reviewers

We tried broader AI review tools. They tend to comment on everything: indentation, naming, code style, and quickly become noise.

These single-purpose linters are different:

• High signal, low noise: they only comment when a rule is broken.

• Team-specific: the prompts encode our internal practices, not generic advice.

• Zero friction: no new tool, no UI; just comments in GitHub where reviews already happen.

It's automation that feels like part of the team.

The Only Catch: Diff Is All You Get

These linters can only see what's in the PR diff, title, and body. They can't access the live database, production telemetry, or other branches.

That's fine; they're meant as diff-level safety nets. They catch human errors early, without trying to be a full static analyzer or CI auditor.

Each linter runs in seconds and costs just a few cents per PR, roughly the price of a coffee per sprint, for automation that never forgets a rule.

From Weeks to Minutes

Building our first heuristic-based linter for migrations would've taken a week or more. With actions/ai-inference, it took less than an hour:

• Write a YAML prompt describing the rule in plain English.

• Add a short workflow to send the diff and handle responses.

• Iterate on the prompt until it comments correctly.

That's it.

Once we saw it work, the pattern spread fast. "We should remind people to…" became "let’s write a 10-line AI check."

Reflection

Mergify automates the mechanics of merging: queues, conditions, policies. These AI linters automate the human reminders that typically precede them. They encode shared understanding in code. They don't replace reviewers: they help them remember the rules.

In short, it's just another form of merge automation.

This experiment changed how I think about automation. If I can describe a rule in a few sentences and it only needs the diff, it's probably worth automating.

Next time I'm about to say, "please remember to…," I’ll stop and ask:

Can I teach this to a small AI linter instead?