4
25 Comments

I Built an AI PR Reviewer That Actually Understands Next.js — Meet MergeWell

Your generic linter doesn't know the difference between a Server Component and a Client Component. MergeWell does.

We've all been there.

You open a pull request at 4 PM on a Friday. Your teammate glances at the diff, sees it's a Next.js change, and approves it — because honestly, who has the bandwidth to reason through every App Router edge case under deadline pressure?

So you merge. And Saturday morning you're debugging why your Server Component is leaking session data to the client, or why your page is hydrating twice, or why use client is now at the top of a file that's pulling in a 200kb library that should never have touched the browser bundle.

Next.js is powerful. It's also genuinely complex — and most code review tools treat it like it's just React with a router bolted on. It isn't.

That's why I built MergeWell — a PR reviewer built specifically for Next.js codebases.

The Next.js Code Review Problem Is Real

Generic code review tools miss Next.js-specific mistakes entirely. They don't know that:

  • Adding "use client" to a component that fetches data server-side is an architectural mistake, not just a style preference
  • Calling cookies() or headers() inside a component that's rendered statically will silently break at runtime
  • Importing a heavy client-side library into the wrong boundary will bloat your bundle without a single warning in your diff
  • Using useEffect to fetch data in a component that could just be async is a step backwards in the App Router world
  • Forgetting export const dynamic = 'force-dynamic' when you need it means your page caches stale data in production

These aren't abstract concerns. They're the kinds of bugs that survive review, pass CI, reach production, and cost real time to debug. Because they're not syntax errors — they're conceptual errors that require understanding how Next.js actually works.

What Is MergeWell?

MergeWell is an AI-powered pull request reviewer built from the ground up for Next.js projects.

It reviews your diffs the way a senior Next.js engineer would — one who knows the App Router deeply, has opinions about the Pages Router, and understands the mental model shift that comes with React Server Components.

Think of it as having a Next.js specialist on your team who reviews every single PR, 24/7, without ever getting tired or distracted.

What MergeWell Catches

🧩 Server vs. Client Component Mistakes

MergeWell understands the RSC boundary. It flags when you're:

  • Adding "use client" unnecessarily, forcing client-side rendering where server rendering would be faster
  • Using browser APIs or hooks in files that run on the server
  • Passing non-serializable props (like functions or class instances) across the server-client boundary
  • Accidentally including server-only code (like database queries) in Client Components

📦 Bundle Size & Import Mistakes

Next.js's power is its ability to keep your client bundle lean. MergeWell spots when a PR is about to undo that:

  • Heavy libraries being imported into Client Components that should live server-side
  • Missing next/dynamic lazy loading for large components
  • Barrel imports that prevent tree-shaking

🗃️ Data Fetching Anti-Patterns

The App Router changed how we think about data fetching. MergeWell knows both worlds:

  • useEffect data fetching in components that should be async Server Components
  • Missing revalidate or incorrect caching strategies in fetch() calls
  • Waterfall fetches that could be parallelized with Promise.all
  • Redundant getServerSideProps patterns that belong in the Pages Router era

⚡ Rendering & Caching Issues

This is where Next.js gets subtle — and where most reviewers check out:

  • Pages that need force-dynamic but are missing it, leading to stale static renders
  • Incorrect use of unstable_cache or revalidatePath
  • Components that break static generation by opting into dynamic behavior unintentionally
  • Route handlers missing proper cache headers

🔒 Security Concerns Specific to Next.js

  • Server Actions that lack proper input validation or authorization checks
  • API routes missing rate limiting or CORS configuration
  • Environment variables being exposed to the client that should stay server-side (anything without the NEXT_PUBLIC_ prefix that's referenced in Client Components)
  • Middleware that could be bypassed

🏗️ App Router Architecture

MergeWell reviews structural decisions, not just line-level bugs:

  • Route grouping that could simplify the layout hierarchy
  • Layouts that re-render unnecessarily
  • Loading and error boundary placement
  • Parallel and intercepting routes used incorrectly

A Real Example

Here's the kind of thing MergeWell catches that generic reviewers miss entirely.

Imagine this gets added to your codebase in a PR:

// app/dashboard/page.tsx
"use client";

import { getUser } from "@/lib/db";

export default function DashboardPage() {
  const [user, setUser] = useState(null);

  useEffect(() => {
    getUser().then(setUser);
  }, []);

  return <div>Welcome, {user?.name}</div>;
}

A typical reviewer might see "looks fine, it fetches a user and displays it." MergeWell sees:

  • "use client" is unnecessary — this component has no interactivity
  • getUser() is a database call running client-side, which means it's either hitting an API route unnecessarily or, worse, running DB code in the browser bundle
  • The useEffect pattern introduces a loading flash and a waterfall
  • The fix is to make this an async Server Component — two lines of change, dramatic performance improvement

That's the difference between a generic review and a Next.js-aware one.

Who Is MergeWell For?

Solo Next.js developers — You're the only reviewer on your own PRs. MergeWell is the senior Next.js engineer you can't afford to hire yet.

Small teams shipping fast — Velocity is everything at an early stage. MergeWell keeps quality high without slowing you down.

Teams migrating from Pages Router to App Router — This is where mistakes happen most. MergeWell understands both paradigms and catches the conceptual mix-ups that happen mid-migration.

Open-source Next.js project maintainers — Give contributors expert-level feedback without spending hours on every PR.

Agencies building client projects — Consistent Next.js quality standards across every project, every client, every developer on your team.

Built for the Way Next.js Actually Works

MergeWell was built with one belief: a good code review tool has to deeply understand its domain.

Generic AI review tools that work on "any codebase" are useful for catching obvious bugs. But Next.js has a specific mental model — server vs. client, static vs. dynamic, caching layers, React Server Components — that requires genuine framework expertise to review well.

MergeWell isn't a linter with an AI layer. It's a reviewer that thinks in Next.js.

Try MergeWell on Your Next PR

MergeWell is live and ready for your Next.js project.

👉 mergewell.codewavelabs.org

If you're building with Next.js — whether it's a SaaS, an e-commerce site, an internal tool, or a side project — MergeWell will catch the things that slip through every other review.

Better Next.js code starts here. Let's merge well.

Built something with Next.js and ran into a review nightmare? Drop a comment — I'd love to hear about it. And if you try MergeWell, feedback is always welcome.

Tags: nextjs code-review react developer-tools ai webdev javascript typescript

posted to Icon for group Community Building
Community Building
on May 3, 2026
  1. 2

    This is a really sharp observation about the gap between generic linters and framework-specific code review. The Server Component vs Client Component boundary issue is one of those things that sounds simple in theory but creates genuinely nasty bugs in practice.

    I've been thinking about this same problem space from a different angle. I'm building ClipForge, a tool that uses AI to repurpose long-form developer content (tutorials, architecture docs, walkthroughs) into context-aware snippets that actually understand the framework they're targeting. The hard part isn't the AI itself -- it's teaching the model to reason about framework-specific semantics instead of just pattern-matching keywords.

    One thing I've learned: narrow-domain AI tools perform way better than general-purpose ones for developer workflows. A reviewer that only knows Next.js will catch things a generic code review tool never will, same way a tool that only understands React Server Components will give better advice than one trying to handle every framework simultaneously.

    How are you handling the training data problem? Getting high-quality examples of actual Next.js review mistakes seems like the bottleneck for this kind of tool.

    1. 1

      That’s a great way to put it—and ClipForge sounds like you’re tackling a very similar problem from the content side.

      Totally agree on narrow-domain tools. The difference once you constrain the problem to something like Next.js is huge—you move from pattern matching to actually reasoning about intent and boundaries.

      On the training data side, I’m actually not relying on traditional fine-tuning (at least not right now). The approach is more:

      Docs-grounded context → dynamically pulling relevant Next.js docs based on the diff
      Heuristic + pattern layer → identifying risky areas (RSC boundaries, data fetching, caching, etc.)
      Real PR feedback loops → using early users’ PRs to see what it catches vs misses

      You’re right though—the real bottleneck is high-quality examples of actual mistakes, not synthetic ones. That’s why I’m leaning more toward:

      grounding + real-world iteration > static training datasets

      Long term, I do think there’s a dataset opportunity here—something like “framework-specific failure cases” would be insanely valuable across tools like yours and mine.

      Curious—how are you handling correctness in ClipForge when the model generates framework-specific snippets?

  2. 2

    Really like the focus on Next.js-specific review — this is a real pain most tools miss.
    Quick question — have you thought about scaling the distribution of MergeWell, instead of relying only on direct users finding it?
    We’ve built a system that helps with that. Happy to share if you're interested.

    1. 1

      Thanks for your feedback.

      Happy to see what have you got for the distribution, please share.

      1. 1

        Appreciate it — I’ll keep it simple.

        What we’ve built is a system where other developers or creators can help distribute your tool — and earn a share from the sales.

        It can also support simple team structures, so distribution can grow beyond just one layer. You can define how the revenue is shared, and we can help design that if needed.

        If this sounds interesting, happy to walk you through a quick example.

        1. 1

          lets connect - Happy to talk.
          Please dm here -> https://www.linkedin.com/in/rishugren03/

  3. 2

    The core value prop is clear. The challenge now is convincing teams to trust AI reviews alongside human ones—that takes repetition and visible accuracy.

    One thing that worked well for my small developer tool (a Firefox extension): targeting the exact subreddits and forums where users spend time and contributing genuinely before promotion. For a Next.js-specific tool, the Next.js Discord and r/nextjs are the right ecosystems. Be helpful there first, let the tool come up naturally.

    The other thing: first 10 paying customers are the hardest. Consider outreach to OSS project maintainers who might benefit—they talk to each other and have influence.

    1. 1

      Yeah, that makes a lot of sense.

      Trust is definitely the bottleneck here—I’m trying to solve that by showing real PR examples where the reviewer actually catches meaningful issues, not just generic suggestions. Repetition + visible accuracy is the only way this works.

      Agree on the distribution too.

      OSS maintainers is a great call—I hadn’t prioritized that enough. Getting a few of them to try it on real repos could create much stronger validation than random users.
      Appreciate this—this is exactly the kind of practical insight I needed.

  4. 2

    The core value prop is clear. The challenge now is convincing teams to trust AI reviews alongside human ones—that takes repetition and visible accuracy.

    One thing that worked well for my small developer tool (a Firefox extension): targeting the exact subreddits and forums where your users spend time and contributing genuinely before any promotion. For a Next.js-specific tool, the Next.js Discord and r/nextjs would be the right ecosystems. Be helpful there first, let the tool come up naturally.

    The other thing: the first 10 paying customers are often the hardest. Consider an explicit outreach to OSS project maintainers who might benefit—they talk to each other and have influence.

    1. 1

      Yeah, that makes a lot of sense.

      Trust is definitely the bottleneck here—I’m trying to solve that by showing real PR examples where the reviewer actually catches meaningful issues, not just generic suggestions. Repetition + visible accuracy is the only way this works.

      Agree on the distribution too.

      OSS maintainers is a great call—I hadn’t prioritized that enough. Getting a few of them to try it on real repos could create much stronger validation than random users.
      Appreciate this—this is exactly the kind of practical insight I needed.

  5. 2

    Generic tools treat Next.js like React with a router, often leading to painful Saturday morning debugging sessions.
    MergeWell catches architectural mistakes like RSC boundary leaks, "use client" misuse, or database calls bloating your client-side bundle.
    What is the most painful Next.js bug that ever managed to sneak past your manual code reviews?

    1. 1

      Works on localhost, breaks in prod
      hydration bug
      Caused by subtle server/client mismatch.

      1. 1

        Hydration errors are the "it works on my machine" phantoms that wait for production to expose a mismatch your local environment was too polite to flag. Debugging these ghosts is exactly why catching server-client discrepancies early is such a massive win for your deployment stability. Are you currently using any specific linting rules to flag browser-only globals before they reach your server components?

  6. 2

    This is much stronger than “AI code review.”
    You’re not selling generic PR automation.
    You’re selling fewer expensive Next.js production mistakes in a framework where most bugs come from boundary mistakes, not syntax.
    That’s the right wedge.
    The product feels sharper than the name though.
    MergeWell explains the action, but not the weight.
    It sounds collaborative and clean.
    The product is doing architecture enforcement, bundle protection, and production-risk prevention.
    That’s a heavier category than “merge well” suggests.
    Vroth.com would carry this better if you push further into infra-grade code reliability instead of staying positioned as a PR helper.

    1. 1

      That’s a fair take, and I agree with the direction.

      MergeWell was meant to feel approachable as a PR tool, but the product is clearly doing heavier work like enforcing boundaries and preventing production issues. There’s definitely a gap between how it sounds and what it actually does.

      Right now I’m keeping the lighter positioning to reduce friction for early users, but I do see it evolving toward a deeper reliability layer, closer to what you’re suggesting with Vroth.com.

      Really appreciate this, it’s sharp feedback

      1. 1

        That makes sense for early adoption.

        But I’d be careful not to let “approachable” keep the product trapped as a PR helper.

        If the real value is preventing production mistakes before they ship, that is not lightweight. That is reliability infrastructure.

        MergeWell helps users understand the entry point.

        Vroth fits the category you’re actually moving toward:
        boundary enforcement
        code reliability
        production-risk prevention

        So the timing question is simple:
        are you optimizing for easy first understanding, or for the category you want serious dev teams to trust later?

        1. 1

          That’s a really sharp way to frame it.

          Right now I’m deliberately optimizing for easy entry and quick adoption—getting devs to try it inside their existing PR flow without overthinking it. Calling it a “PR reviewer” lowers that barrier.

          But I agree with your point: the real value isn’t just reviewing code, it’s preventing production mistakes before they ship. That naturally pushes it toward a reliability layer, not just a helper.

          So I think the path is:

          Start with approachable positioning → get usage and trust
          Gradually shift toward reliability + enforcement as the product proves itself

          Vroth (or that direction) feels more like the end state/category, while MergeWell is the entry point.

          Appreciate you calling this out—it helps clarify the long-term positioning vs short-term strategy.

          1. 1

            That path makes sense.

            The only risk is that the market starts categorizing you before you are ready to shift.

            If devs first remember it as “another PR reviewer,” it becomes harder later to make them see it as reliability infrastructure.

            That category memory forms early.

            MergeWell is good for entry.
            But Vroth is closer to the trust layer serious dev teams would buy into once the product proves it prevents production risk.

            So I’d treat this less like a future rename question and more like a timing question.

            How long do you want the product to be remembered as a PR helper before the heavier category becomes harder to own?

  7. 1

    This really hits the spot. I have definitely had those Friday 4 PM moments where I just click approve because the App Router logic is too much to think about after a long week. Managing the RSC boundary and those accidental client-side leaks is a constant headache when you are trying to move fast with a small team. A generic linter basically knows nothing about these "conceptual" mistakes. I love that MergeWell actually understands the "why" behind the code. I am definitely giving this a try—it sounds like a real lifesaver!

    1. 1

      Glad that resonated 😄

      Those “Friday 4 PM approvals” are exactly the kind of situations I had in mind while building this—especially with App Router + RSC where things can look fine but break in subtle ways later.

      You’re spot on about linters too—they’re great for syntax and rules, but they don’t really catch those conceptual boundary issues like server/client leaks or data fetching mistakes.

      That’s the gap I’m trying to fill with MergeWell—less about style, more about why this might break in production.

      If you do try it, I’d genuinely love your feedback—especially if it catches (or misses) something in your PRs 🙌

  8. 1

    Nice build Rishu. I've been deep in the AI tooling space myself — building ClipForge, a tool that repurposes long-form video into short clips using AI. The parallels are interesting: both MergeWell and ClipForge solve the problem of 'generic tools don't understand domain context.' Just like a generic linter misses Next.js-specific issues, a generic video editor doesn't understand pacing or hook retention. There's a real pattern here — domain-specific AI is where the value is.

  9. 1

    The framing of "a reviewer that thinks in Next.js" is sharper than most launch posts I see — that domain depth is exactly what generic AI-on-everything tools can't replicate. Counter-thought from my own indie path though: I shipped a tiny iOS side project trying to be "a memo app" and it floundered until I narrowed it down to "a Captio replacement that emails on one tap." Picking a sub-niche inside Next.js (App Router migrations, where pain is acute and recent) might convert harder than the full umbrella. Honestly, your real PR example is the strongest part of the post — I'd lead with three of those before the bullet sections. Quick question: do users prioritize the RSC boundary catches, or are bundle-size warnings the more retention-sticky win?

  10. 1

    The Server/Client Component boundary detection is genuinely impressive. Most AI code review tools are generic linters with an LLM generating comments — they flag style but miss the architectural issues that actually cause production bugs.

    The useEffect-to-fetch pattern you mentioned is one I see constantly. Teams migrating from Pages Router to App Router often keep old patterns alive without realizing the mental model shift. MergeWell catching those mid-migration issues could save teams weeks of debugging.

    I've been building a different kind of AI tool (ClipForge — video repurposing SaaS) and the same principle applies: narrow domain expertise beats broad general capability every time. Sharp focus on Next.js is a strong bet.

  11. 1

    This looks like a really impressive project 👍 Most AI PR reviewers only scratch the surface, but if MergeWell truly understands Next.js structure and logic, it can be a huge productivity boost for developers.

    1. 1

      Appreciate that 🙌

      That’s exactly the gap I’m trying to address—most reviewers stay at the surface, but with Next.js, the real issues are usually in structure, rendering boundaries, and data flow.

      The goal with MergeWell is to go beyond “looks good / minor suggestion” and actually catch things that could break in production.

      If you get a chance to try it, would love to know how well it holds up on real PRs 👍

Trending on Indie Hackers
7 years in agency, 200+ B2B campaigns, now building Outbound Glow User Avatar 105 comments How I built an AI workflow with preview, approval, and monitoring User Avatar 61 comments The "Book a Demo" Button Was Killing My Pipeline. Here's What I Replaced It With. User Avatar 55 comments I built a desktop app to move files between cloud providers without subscriptions or CLI User Avatar 27 comments Show IH: I built an AI agent that helps founders find the right people User Avatar 24 comments My AI bill was bleeding me dry, so I built a "Smart Meter" for LLMs User Avatar 23 comments