I let Claude write my React compiler. I only reviewed the tests.

Open the React DevTools "highlight updates" panel on any React app you've ever worked on. Count the flashes. You've done this before, probably in an interview, probably while defending a useCallback. That counting habit is a React-specific anxiety, not a universal one — and the reason matters less for this post than what I did about it.

I spent about a month building a thin wrapper around an existing state library (Legend-State) that tries to compile that anxiety away. The piece I want to write about isn't the wrapper itself. It's how I built the compiler behind it. I didn't write most of the implementation. I wrote tests that described what the compiler should emit, pasted failing snapshots to Claude, and shipped whatever version of the plugin made the tests pass. This post is about why that workflow worked here — and what surfaces it would break on.

The shape of React's rerender tax

I'm not here to relitigate whether React's model is good or bad. Plenty of excellent apps are built on it. But React's default execution model makes one kind of anxiety unusually visible, and naming it is the setup for everything that follows.

In React, when state changes, the component function body re-executes. Child components re-execute in turn unless wrapped in memo. Handlers are new references unless wrapped in useCallback. Derived values recompute unless wrapped in useMemo. Those three tools exist to opt out of the default.

function Parent() {
  const [count, setCount] = useState(0);
  return <Child />; // Child re-executes on every setCount. memo it or don't.
}

Signal-based frameworks like Solid, Vue, and Svelte subscribe at the read site. When a signal changes, only the reactive expression that read it re-runs — often a text node or an effect. The component function itself runs once.

React state libraries — Zustand, Jotai, Recoil, Valtio — are, in large part, ways to reintroduce read-site subscription on top of React's default. They each succeed at a subset of cases, and they each bump into the place where hook rules collide with subscription logic. That collision is the surface I wanted to flatten, and doing it in user-space wasn't enough. The obvious fix ("just run the component body once and subscribe at .get()") runs straight into React's hook rules. That's where a compiler has to enter the picture.

What I wanted: "use scope"

"use scope" is a directive that turns a React component's body into a mount-time factory. The body runs once, state lives in observables, and a compile time plugin wraps each .get() call into a reactive leaf. No hook ordering to preserve. No hook dependency arrays. No stale closures, at the cost of one rule: no React hooks allowed inside a scope block.

Here's what that looks like in practice.

import { observable, onMount } from "@usels/core";

function Counter() {
  "use scope";
  const count$ = observable(0);

  console.log("factory ran");   // fires ONCE — on first run

  onMount(() => {
    console.log("mounted");     // fires ONCE — after paint
  });

  const increment = () => count$.set((c) => c + 1);

  return (
    <button onClick={increment}>
      Clicked {count$.get()} times
    </button>
  );
}

Click the button a hundred times. "factory ran" logs once. increment is the same function reference for the component's lifetime. The only thing that reevaluates on each click is the JSX expression {count$.get()}, which is exactly what changed.

That's the premise. The point of this post isn't the directive. It's how I built the plugin that makes the directive work.

Why I decided not to write the compiler

Here's the thesis of this post in one sentence: the compiler is a surface where I could specify what I wanted better than I could implement it. That asymmetry — clear spec, unclear implementation path — is what makes LLM delegation actually pay off, and it's the only general claim I'll defend here.

I'd never written a Babel plugin. I could read one, but I couldn't have told you with confidence what the right next step was when a transform misbehaved. That's a bad place to start a two-week project from. It's a fine place to start specifying from, because specs don't require you to know the implementation path. They only require you to know what correct output looks like.

So I spent those two weeks writing tests and specs instead of learning internals. Each test was a concrete before/after: input JSX on one side, transformed output on the other. The tests were the thing I could write confidently. The plugin that made them pass was the thing I had no intention of writing.

The lesson isn't "delegate anything hard to an LLM." It's narrower: for surfaces where specification is easier than implementation, LLM delegation is leverage. On surfaces where I can implement faster than I can specify — most product code — this workflow is slower, not faster.

So the question became: how do I know what Claude produced is correct?

Tests were the spec

I wrote the tests before the plugin existed. Each test was a before/after pair: input JSX that reads observables, expected output with <Memo> wrappers around the reactive reads. Claude's job was to produce a plugin that made those pairs pass. Implementation details weren't my primary review surface — I reviewed behavior through test diffs first, and only dipped into the plugin source when a failing case couldn't be explained from output alone.

The harness I used is babel-plugin-tester. It isn't a snapshot-by-convention tool. You write the expected output right next to the input, and the test fails with a readable diff when they disagree. That "readable diff" property is what made the workflow work at all.

Here's an actual test from the plugin's repository, trimmed to the essentials:

import pluginTester from "babel-plugin-tester";
import plugin from "../../src";

pluginTester({
  plugin,
  babelOptions: { plugins: ["@babel/plugin-syntax-jsx"], configFile: false, babelrc: false },
  tests: {
    "wraps $-suffixed observable .get() in JSX child": {
      code: `
        function App() {
          return <div>{count$.get()}</div>;
        }
      `,
      output: `
        import { Memo } from "@usels/core";
        function App() {
          return (
            <div>
              <Memo>{() => count$.get()}</Memo>
            </div>
          );
        }
      `,
    },
  },
});

Three pieces: the input code the developer would write, the output the plugin should emit, the runner. When the plugin gets it right, the test is silent. When it gets it wrong, I get a diff pointing at the exact AST node that disagreed.

The actual loop was narrower than "I wrote all the tests first." I didn't. I wrote a handful of input/output pairs (the obvious shapes, the ones I was certain about) and I told Claude to use babel-plugin-tester as the harness. From there the workflow looked more like a conversation than a solo run:

1. I define a small first batch of input/output pairs for the shapes I'm sure about.
2. Claude produces a plugin that makes those pairs pass.
3. We discuss edge cases: what happens with chained .get(), with attributes, with nested JSX, with the "use scope" hoist. Most of these I wouldn't have thought of on my own; Claude surfaced them, I decided which ones were in-scope.
4. The agreed-on edge cases become new input/output pairs. Sometimes I wrote them, sometimes Claude proposed a pair and I approved the expected output.
5. Claude updates the plugin against the expanded suite. If a patch regressed an earlier pair, the babel-plugin-tester diff surfaced it in the next turn and we circled back.

The part that made this converge rather than thrash is step 3. I wasn't the only source of edge cases, and I didn't pretend to be. I was the source of which edge cases the library should care about, which is a different and much smaller job. The regression catching in step 5 was automatic. Every patch was judged against the whole suite, not just the pair it was trying to satisfy, so a patch that fixed one case and broke another got rejected by the same runner. I never had to diagnose the regression; the test output did. The role I was holding down was "did the diff shrink" and "does this behavior match the library's intent," not "what's wrong inside the plugin."

The cycle ran through roughly five to seven Claude sessions over one to two weeks. The first batch was ~20–30 input/output pairs — the shapes I was certain about. The suite grew to roughly 150 pairs as edge cases accumulated: .get() wrapping in JSX children, in attributes, on chained member expressions like user$.profile.name.get(), the "use scope" directive's hoisting behavior, fine-grained reactivity boundaries, and JSX transform ordering. The artifacts are @usels/babel-plugin and @usels/vite-plugin, real packages, not a thought experiment.

Why this actually worked: the verifiable boundary

The compiler is a pure function from input AST to output AST. No I/O, no concurrency, no hidden state. That's the cleanest verifiable surface in frontend engineering. Snapshot tests are ground truth, and every bug is reproducible. If I'd tried this on a scheduler or a network client, the approach would have collapsed on the first race condition.

What made this surface delegation safe wasn't that it was "easy." AST work isn't easy. It was that a failing test always pointed at a specific AST node in a specific output string. No flakiness, no "works on my machine," no reproduction steps longer than the test itself. When Claude's patch broke something, the runner said exactly what it broke, and the fix landed in the next turn.

I don't want to generalize from a single project. I'm not going to write a rule about which surfaces are safe to delegate and which aren't. I haven't tried this workflow anywhere else, and the strength of a rule comes from the cases it predicts, not from the one case it describes. What I can say is why this project worked, and leave the extrapolation to the reader.

Where the delegation boundary actually falls

The previous section is the delegation friendly half of the story. The other half is the set of decisions no test could judge for me. That's not a credit list — it's the place where the verifiable surface argument breaks down, and it's the more important half of the boundary.

Correctness questions produce diffs. Taste and policy questions don't. When the question is "should this .get() wrap in a <Memo>?", a snapshot can answer. When the question is "what should this directive be called?", there's no diff that can fail. That's the line.

Three decisions sat on the non-verifiable side of that line from start to finish:

• The directive name. "use scope", "use memo", "use once", "use factory" all fit. I wanted a word that named the boundary ("this block is a scope; what's inside is stable") rather than the mechanism. An LLM can generate ten alternatives. Ranking them is a judgment about how the library should feel, and that call belongs to whoever has to live with the name.
• The ESLint error copy for no-hooks-in-scope. This rule separates "codebase uses the library correctly" from "codebase has silently broken reactivity." The message a developer sees when they drop useState into a scope block is the difference between a five-minute fix and a lost afternoon. No test can grade wording.
• The Memo-pruning heuristic. When a parent's attribute already subscribes to the same reactive source, the child's <Memo> is redundant. But the line between "correctly pruned" and "silently dropped reactivity" is a policy, not a property. I wanted my own eyes on every edge case.

The delegation boundary isn't "hard things stay with me." It's "questions that can't be answered by a diff stay with me."

The numbers, and what changed for me

Five to seven Claude sessions. One to two weeks of calendar time. The suite started at ~20–30 input/output pairs and grew to roughly 150. That suite size is the work — it's where the two weeks went. What I didn't spend the two weeks on was Babel internals.

The shift this leaves me with is a smaller one than "AI changes everything." Before this project, an idea that required a surface I hadn't worked in before usually died at "I'd need to learn the internals first." Now the same idea starts at "can I write input/output pairs for it?" If the spec writes cleanly, the library is probably worth building. If it doesn't, the idea isn't ready — which is information I used to get much later, and at much higher cost.

One thing I'd change next time: I'd spend longer on the first batch of pairs before any patch gets written. The suite Claude converges against is only as good as the cases I captured early, and the missing ones don't show up until a user hits them months later.

The use-legend repo is on GitHub and the full API reference is on the docs site. The state primitive underneath it is Legend-State; for where React itself is heading on the same problem, see the React Compiler docs.

FAQ

Is the compiler actually written by Claude end-to-end?

I discussed the spec I wanted with Claude, had Claude write the tests against that spec, and then Claude iterated on the implementation against its own test suite. My primary review surface was the diffs between expected and actual output; I dipped into the implementation only when a failing case couldn't be explained from output alone. The policy and API decisions — what the plugin should do — were mine.

What kept you from delegating more of the library to Claude?

Every decision that couldn't be judged by a failing diff: the directive name, the ESLint error copy, and the Memo-pruning heuristic. Tests can rank correctness but not taste, so those calls stayed with me.

What's "use scope" in one sentence?

It's a directive that makes a React component's body run once at mount; state lives in observables, and a compile-time plugin wraps each .get() call into a reactive leaf so updates don't require the component function to re-execute.

How is this different from React's official Compiler?

React Compiler auto-memoizes the existing hook model — same useState/useMemo/useCallback mental model, fewer explicit wrappers. "use scope" goes the other direction: inside a scoped block, it replaces the hook model with a mount-time factory plus observables, so there's nothing to memoize in the first place. React Compiler makes the current model cheaper; "use scope" offers a different model on an opt-in surface.