Next.js gives you server components, edge middleware, and multiple rendering strategies – but choosing wrong at any boundary creates performance regressions, security gaps, and bundle bloat that only surface in production. VibeRails reads your entire Next.js codebase and finds the architectural mistakes that build tools and linters cannot detect.
Next.js introduced the App Router with React Server Components, fundamentally changing how
developers reason about where code executes. A component that works perfectly as a server
component breaks silently when it imports a client-side library. A component marked with
'use client' at the top of a file forces every child component into the client
bundle, even those that could have remained server-rendered. These boundary decisions compound
across a large application, often resulting in client bundles that are far larger than necessary.
Data fetching in Next.js offers multiple approaches: fetch in server components
with caching and revalidation, route handlers, server actions, getServerSideProps
and getStaticProps in the Pages Router, and client-side fetching with libraries
like SWR or React Query. When a codebase uses the App Router, waterfall requests are a constant
risk – a parent server component fetches data, renders a child server component, which
fetches its own data, creating sequential network requests that could have been parallelised.
Missing revalidation configuration causes stale data to persist in the cache indefinitely, while
overly aggressive revalidation negates the benefits of static generation.
Middleware in Next.js runs at the edge before every matching request. Misuse is common: middleware that performs database queries (which edge runtimes may not support), middleware that duplicates authentication logic already handled in route handlers, or middleware with overly broad matchers that process static asset requests unnecessarily. These patterns increase latency on every page load without providing meaningful value.
Route handler security is another area where gaps accumulate. Next.js API routes and route handlers often lack consistent input validation, authentication checks, and rate limiting. Because they look like simple functions, developers sometimes skip the defensive patterns they would apply in a dedicated API framework. When server actions were introduced, the attack surface expanded further – functions that execute on the server but are invoked from the client need the same security scrutiny as API endpoints, but they are often treated as internal implementation details.
The Next.js compiler catches syntax errors and provides helpful error messages for common
mistakes like using hooks in server components. TypeScript ensures type safety across your
components. ESLint with eslint-plugin-next enforces image optimisation,
font loading, and script placement rules. But none of these tools reason about architectural
decisions at the application level.
Consider a page that uses 'use client' at the top because it needs a single
onClick handler. The linter does not flag this because the directive is valid.
TypeScript confirms the code compiles. But a human reviewer would recognise that the entire
page and all its children are now in the client bundle, when only a small interactive section
required client-side JavaScript. The correct approach – extracting the interactive element
into a separate client component – is an architectural decision that static tools cannot
suggest.
ISR, SSG, and SSR selection mistakes are similarly invisible to tooling. A product catalogue page that uses SSR for every request when ISR with periodic revalidation would serve the same data with dramatically lower server load is a performance architecture choice, not a type error. A blog page that uses client-side fetching when static generation at build time would eliminate loading states entirely is a user experience regression that no linter will catch.
Bundle size regressions from improper imports are particularly insidious. Importing a utility
function from a barrel file (import { formatDate } from '@/utils') can pull the
entire utils module into the client bundle if tree-shaking cannot eliminate the other exports.
Importing a server-only package in a component that is transitively imported by a client
component causes build errors or runtime failures that only manifest in specific code paths.
VibeRails performs a full-codebase scan using frontier large language models. Every page, layout, component, route handler, server action, middleware file, and configuration is analysed together. The AI reads the application structure and reasons about rendering strategies, data flow, component boundaries, and security posture across the entire project.
For Next.js codebases specifically, the review covers:
'use client' that could remain server components, client boundaries placed too high in the component tree pulling unnecessary code into the bundle, server-only imports leaking into client modulesgenerateStaticParamsEach finding includes the file path, line range, severity, category, and a detailed description explaining why the pattern is problematic and how to address it. Findings are organised into 17 categories so teams can filter and prioritise by area of concern.
The most valuable findings in a Next.js review span multiple files. A server/client boundary
mistake involves understanding which components import which modules and where the
'use client' directive propagates. A data fetching waterfall requires tracing
the rendering sequence from layout to page to nested component. A security gap in a server
action is only meaningful when you understand what data it accesses and which client components
invoke it.
VibeRails supports running reviews with two different AI backends – Claude Code and Codex CLI – in sequence. The first pass discovers issues, the second pass verifies them using a different model architecture. When both models independently flag the same finding, confidence is high. When they disagree, the finding warrants closer human attention during triage.
This dual-model approach is particularly useful for Next.js because the framework's conventions evolve rapidly. What was idiomatic in the Pages Router may be an anti-pattern in the App Router. Server actions that were experimental in one version are stable in the next. Cross-validation helps distinguish genuine issues from patterns that are simply different from the latest recommended approach but still functionally correct for your project's Next.js version.
After triaging findings, VibeRails can dispatch AI agents to implement fixes directly in your local repository. For Next.js projects, this typically means restructuring server/client boundaries, parallelising data fetches, adding revalidation configuration, securing route handlers with consistent validation patterns, replacing barrel imports with direct module imports, and adding dynamic imports for heavy below-the-fold components.
Each fix is generated as a local code change you can inspect, test, and commit or discard. The AI works within the conventions of your existing codebase, matching your project's routing structure, data fetching patterns, and whether you use the App Router, Pages Router, or both.
VibeRails runs as a desktop app with a BYOK model – it orchestrates Claude Code or Codex CLI installations you already have. No code is uploaded to VibeRails servers. AI analysis is sent directly to the provider you configured, billed to your existing subscription. Pro plans are per-developer: $19/month (cancel anytime) or $299 lifetime per developer. The free tier includes 5 issues per session to evaluate the workflow.
Vertel over je team en doelen. We reageren met een concreet uitrolplan.