I Ran an AI Code Governor on Next.js. Here's What It Found in 5 PRs.

[Kaandizz]

Interesting Pattern I Found While Testing My Governance Tool on Next.js

I built a tool called Zaxion that checks if PR changes match your repo's architectural rules. Spent some time running it on recent Next.js PRs and kept seeing the same thing, so figured I'd post about it.

What I ran it on

5 recent PRs from the main branch:

• [ci]: trigger signed release commit via API #93285 (release API changes)
• Turbopack: cheaper check in map_next_dynamic #93283 (Rust bindings)
• [not for merge] rules #93282 (docs)
• Stop ignore-listing original stack frames if source maps are disabled #93281 (error handler)
• Apply sourcemaps by default during prerender in next build #93280 (build optimization)

And the result was consistent across all of them: production code changed, but no test file changes.

What that looks like in practice

PR #93285: 339 lines modified in scripts/release-github-api.js. Zero test updates.

PR #93283: New Rust bindings added. Zero test updates.

[You get the idea - all 5 followed this pattern]

Here's the audit report:

Zaxion-Audit-vercel-next.js.html

The secondary stuff I noticed

While the tool was at it, it flagged some other things:

• 8 console.log calls left in production code
• 5 promises without try/catch or .catch() handlers
• A few files pushing past complexity limits

Nothing catastrophic. But patterns.

Why I'm posting this

Not to criticize Vercel. You move fast, and that's clearly a choice that works. I get it.

But I kept thinking: if this pattern shows up in Next.js, where you have dedicated reviewers and strong CI practices, it probably shows up everywhere. Which means human reviewers are probably missing things just because they're tired, or because the PR looks small.

That's what Zaxion does - it doesn't get tired. It just checks the rules.

Genuinely curious

How do you think about this tradeoff? Are the existing tests sufficient to cover these changes? Or is the test coverage something you're aware of and accepting as a speed thing?

Asking because I think most teams would benefit from having something automated catch these patterns before merge, rather than discovering test gaps later.

---

If anyone wants to try it on their own repos: zaxion

Login at: zaxion.dev and try Free Policy Simulator

[icyJoseph]

Two of those PRs are closed, didn't merge. And part of having a test suite, is to be able to refactor or optimize code, with the guarantee that behaviors/features are protected by the tests. We have an ever growing, extensive test suite, we often open new PRs with an e2e to begin with.

Some of the CI stuff would be nice to test, but then that brings up a secondary consideration, does the CI runtime have a proper testing suite? or are we just gonna mock the primitives?

We have our Vercel Bot that, unlike every other tool we have tried, actually does surface errors, opens suggestions for places where a refactor was not applied, hints at optimizations, and even calls out when code, whilst being correct, doesn't adhere to patterns in the surrounding concern.

[Kaandizz]

Hey, thanks for taking the time to reply! Really appreciate the insight into how you guys handle this at scale.

You make a 100% fair point on the refactoring PRs. If the existing test suite provides the necessary coverage to protect behavior during an optimization, forcing devs to write arbitrary new tests just to satisfy a checker is a terrible developer experience. (This is actually why we built branch-level scoping into Zaxion—so teams can enforce test requirements strictly on feat/* branches but disable them for refactor/* or specific directories).

Regarding the Vercel Bot—that sounds incredibly powerful, especially for surfacing context-aware patterns and suggestions.

Just to clarify where Zaxion fits in: it's not really trying to be an AI code reviewer or a suggestion engine. We actually don't use AI to analyze the code at all. Zaxion is a deterministic, AST-based gatekeeper built to enforce strict, non-negotiable architectural and security invariants (like automatically blocking unhandled promises or stopping specific cross-module imports). It evaluates the PR diff mathematically, so it doesn't guess.

Because it's entirely policy-driven, the admins or maintainers dictate exactly what those rules are based on their specific requirements. You don't have to write complex AST queries by hand to do this—maintainers can just write custom policies in plain English (or upload a Markdown guidelines file) and Zaxion translates it into the strict JSON schema it uses for enforcement. Or, if they prefer, they can just write the JSON directly.

To give you an idea, a team could create a high-level custom architectural policy like: "Prevent any file inside packages/next/client from importing modules from packages/next/server , except for shared-utils.js ."

Zaxion would then mathematically enforce that boundary on every PR diff, catching architectural drift before it's merged.

Really interesting to hear how your internal CI and Vercel Bot handle these edge cases though. It's super helpful context for us as we refine how governance tools should behave without slowing down massive projects like Next.js. Thanks again for the perspective!

[PieterDePauw]

You don't use AI, yet I can write my policies in English, which are then turned into JSON. What kind of sorcery are you using for that?

[Kaandizz]

My bad, I explained that terribly!

Let me explain the "sorcery": We do use AI, but we strictly quarantine it to the configuration phase , and keep it completely out of the execution phase .

Here is the actual breakdown of the "magic":

1. Creating the Policy (AI is used here): When an admin writes a rule in plain English (like "Prevent importing X into Y" ), we use an AI model in the background to translate that human intent into Zaxion's strict, machine-readable JSON schema. But as you know Ai sometime make mistake, so i always recommended to use the actual jason format to write the policy.
2. Scanning the PR (Zero AI here): When a PR is opened, the AI is completely out of the picture. Our engine simply parses the code into a structural tree (AST) and mathematically checks it against that JSON schema. It's a lightning-fast, definitive "Yes or No" structural match—no guessing involved.
   So basically: we use AI to help the admins write the rules, but we don't let the AI anywhere near the actual code review so it can't hallucinate, make up false positives, or slow things down.

Hope that makes a lot more sense! No dark arts required, just a strict separation of concerns. 😅