DEV Community

Isabelle Hue
Isabelle Hue

Posted on

The Svelte 5 bugs your AI code reviewer misses

Generic AI reviewers are built to read any diff on GitHub. That is the problem. They read a .svelte file like plain JavaScript. The syntax checks out, so they wave it through, and they miss the bugs that come from how Svelte and SvelteKit actually run. Those bugs compile, pass review, and break in production.

Why a framework-blind reviewer misses the real bugs

A reviewer that only sees JS syntax cannot reason about what runs on the server versus the client, what is reactive, or what ends up in the browser bundle. That is where SvelteKit bugs live. Here are the ones I kept hitting.

1. Server-only env reaching the client

Importing a secret straight into a component usually gets caught at build. The sneaky version does not: a secret pulled in a universal load and returned to the page, or a PUBLIC_ prefix on a var that should have stayed private. The diff looks fine and the secret is now in your client bundle.

2. window or localStorage at module top level

localStorage.getItem(...) or window.x at the top of a component runs on the server during SSR, where those globals do not exist. You get a ReferenceError and a blank page. A generic reviewer sees valid JavaScript and says nothing.

3. $effect where $derived belongs

In Svelte 5, using $effect to compute a value that should be $derived gives you stale UI. It compiles, it runs, it is wrong, and the linter stays green.

4. {@html} on untrusted input

An old one that still ships, because in review it looks like a harmless one-liner. It is an XSS hole.

5. SvelteKit form-action footguns

Action patterns that quietly break, like the wrong return shape or a bad progressive-enhancement assumption, which a JS-only reviewer has no model for.

What Svelte Autopilot does

It is a GitHub App, and a free Action, that reviews every PR for exactly these patterns:

  1. Reads the diff with a model that knows the Svelte 5 and SvelteKit execution model.
  2. Flags the footguns above, from the server and client boundary to SSR, runes, XSS and form actions.
  3. Posts one grouped, severity-tagged comment per PR, updated on every push.
  4. Stays quiet when the code is fine, tuned against false positives.

The review happens right in the PR, nothing to babysit.

Running it

Two options. The free GitHub Action runs in your CI with your own OpenAI key, and public repos are always free. The hosted app needs no key and no CI config: 10 PR reviews a month free, then $19 a month or $190 a year.

If a Svelte 5 footgun has slipped through your review before, I would like to know which one. You can try it on a single repo at https://svelte.useautopilot.dev

Top comments (1)

Collapse
 
topstar_ai profile image
Luis

This post is a really good reality check for where AI tooling currently fails quietly in modern frontend frameworks.

The core point — that Svelte 5 introduces semantic “footguns” that AI reviewers miss — is absolutely believable, because most AI tools are still operating at the TypeScript / generic JS correctness layer, not the framework contract layer.

And that’s where Svelte 5 gets tricky:

$state, $derived, $effect are not just syntax changes — they are reactivity rules
SvelteKit boundaries (+page.ts vs +page.server.ts) are execution-context rules, not type rules
SSR vs browser execution is runtime environment logic that static review tools often ignore

So you end up with exactly the problem the post describes:
AI says “looks valid JS/TS → approve,” while the actual bug is:

secret leakage to client bundle
broken reactivity chains
SSR crashes from browser APIs
silent state desync issues

What makes this especially interesting is the broader implication:
AI code review tools are still not framework-aware at compile semantics level.

They can catch:

syntax issues
obvious logic errors
type mismatches

But they struggle with:

framework execution boundaries
reactive system invariants
compiler-driven frameworks like Svelte 5

That’s also why Svelte (and similar systems) are disproportionately hard for AI right now — the “correctness rules” are not visible in the code alone, they exist in the framework runtime model.

Net takeaway:
This isn’t just “AI misses bugs in Svelte 5” — it’s a good example of a bigger gap:

AI review tools are still code-aware, not system-aware.

And Svelte 5 just exposes that gap very clearly 🤝