Automating React performance with agents and Legend State

Here's a small course player. It has three lessons you can tick off, a progress bar, a captions toggle, and a box for notes. An agent built it for this article, and as far as a learner can tell, it works fine.

Before you type anything, make a guess. When you type one letter into the notes box, how many of the player's components re-render? Only one of them shows the note, so one seems like a fair answer.

Type a note in the player below and watch the counter.

The counter says seven. Every letter you type re-renders seven of the player's eight components, and only the note editor, Notes, has anything new to show.

On a laptop you won't feel it. This player has three lessons and no video, though. In a real course player with fifty lessons, every keystroke would re-render all fifty lesson rows, and on a mid-range phone that turns into typing lag.

You can hunt these renders down by hand with the React Profiler, one screen at a time. That works for one screen, but it doesn't scale to every screen on every pull request. So in this article I hand the job to an agent. We'll set up a loop it can run on its own, then walk through it once on this player.

Don't worry about the tool names yet. I'll introduce each one when we need it.

01Why every component re-renders

The lesson rows are the strange part. You typed a note, and the rows don't show the note. Their props didn't change either, so why did they re-render?

The answer is Context. CoursePlayer, the top component, keeps all of the player's data in React state: which lessons are done, the note, and whether captions are on. It shares that data with every component below it through a Context. Props aren't the only thing React checks. When a Context value changes, React re-renders every component that reads that Context, even a component that only uses one field of it. Typing a note creates a new Context value, so each lesson row re-renders along with the editor.

So what if each lesson row read only its own checkbox, and the notes box read only the note? Then a new note would reach just the component that shows it.

Jay Meistrich argues for this in his App.js Conf 2026 talk, How to Build the Fastest Apps: Break the Rules⁠. His advice is to keep state at the top of the tree but read it at the bottom, in the components that show it. The top component passes down an object that never changes, and each component at the bottom of the tree, the leaf, subscribes to the one value it displays. He calls this "render once." In his own app, moving one update down to a single text component cut CPU use to a tenth. Jay also created Legend State, the library we'll use for the fix.

Checking every component for reads it doesn't need is slow, repetitive work. That makes it a good job for an agent.

02Migrate to Legend State

To render once, each component needs a value it can subscribe to on its own. That value has to remember which components read it and update only those components when it changes. React state doesn't work that way.

Legend State⁠ is a React state library built around values like this, and it calls them observables. A component reads an observable with useValue, and React re-renders it only when the value it read changes. So a component that calls useValue(player$.note) re-renders when the note changes and at no other time.

I asked an agent to move the player's state to Legend State. It did, and the tests passed. If each component now reads only what it shows, typing should re-render one component. Type a note in the migrated player to check.

The counter still says seven. Here's the top of the migrated player.

const player$ = useObservable(initialCourse());
const player = useValue(player$);
const note = player.note;

The problem is useValue(player$). It subscribes CoursePlayer to the whole course, so any change re-renders it. When the note changes, CoursePlayer passes the new note down through Context, and every component that reads that Context re-renders, the same as before. Tick off a lesson and CoursePlayer re-renders again, even though it never shows lesson completion. That click costs three renders: CoursePlayer, the lesson row, and the progress bar.

The agent swapped React state for observables but kept a read that covers the whole course. The code looks like normal Legend State, and it would be easy to approve in a code review. We need something that catches it automatically.

03Let Legend Doctor guide the migration

My team at Genie builds Legend Doctor⁠ for this. It's a linter for Legend State. It flags React code that could move to Legend State and Legend State code that breaks its best practices, and each finding says what to change. An agent can make the edit and then check the result.

On this player, Doctor flagged one line, useValue(player$), because the parent subscribes to the whole course but only uses the note. It suggested narrowing the read to player$.note. The agent went a step further. With only the narrower read, the parent would still re-render on every keystroke and pass the note down through Context, so the agent moved the read into the note editor itself.

In the first tab below, click through The issue, Doctor's finding, and The agent's fix, and watch where useValue moves.

function BroadLegendCourse({ children }: { children: ReactNode }) {
	const player$ = useObservable(initialCourse());
	const player = useValue(player$);
	const note = player.note;
	return (
		<CourseContext value={{ ...legendPlayer(player$), note: () => note }}>
			{children}
		</CourseContext>
	);
}

In the fixed code, CoursePlayer doesn't call useValue at all. The note editor reads the note, and seven re-renders per keystroke drop to one.

The other four tabs come from an extended version of the player, with a button that exports the note, a browser tab title, a quiz, and lesson playback. Here's what Doctor flagged in each one and what the agent changed.

One of these findings wasn't a straight recommendation. For the quiz label, Doctor asked for a source review, so the agent read the calculation and tested scores on both sides of the passing threshold before moving it. Every rule is listed in the detection catalog⁠.

04Move the read to the leaf

After the fix, each component subscribes only to the field it shows, and the parent subscribes to nothing.

// In the note editor, not in the parent
const note = useValue(player$.note);

The note editor reads the note. Each lesson row reads its own completion, and the progress bar reads the completion of all three lessons. Type a note, then tick off a lesson, and watch which nodes light up in the component tree.

Typing re-renders one component, the editor. Completing a lesson re-renders two, that lesson's row and the progress bar. Both of them show something that changed, so every render in this version does useful work.

05Check it in a real browser

So far we've judged each version by its render count, and the count alone can hide a broken screen. Suppose the agent also removes the progress bar's subscription. A lesson click now re-renders one component instead of two, which looks like an improvement, and the progress bar stays at 0% forever.

So for every change, the agent checks two things: which components re-rendered, and what the learner sees. It uses two tools for this.

agent-browser⁠ is a browser an agent controls from the command line. The agent opens a page, clicks buttons, types into fields, and reads what's on the screen, the same way you've been using the player.

genie-react⁠ is the other one, and my team builds it too. It records every component render and effect in a running React app. A Vite plugin connects it to the app during development, and its command-line tool lets the agent read that record after each interaction.

Below is an illustrated replay of the agent running the same check against three versions of the player. Step through A broken fix and compare its report with the progress bar in the preview.

A broken fix has the lowest render count of the three, and the agent still rejects it. The render count alone looks like an improvement. The agent rejects it because the preview shows progress stuck at 0%, not the 33% it expected.

06Run the loop on every change

If you want to try this, start with one feature and one interaction, like this player. Forms, navigation, and server-data caching can wait for later runs. Then give the agent a goal with acceptance criteria. This is the one I used.

/goal Acceptance criteria:
- Maximum performance
- Minimum re-renders
- A full genie-react report
- Everything validated with Legend Doctor and agent-browser
- No shortcuts. No caveats.

A later feature can bring the same broad read back, so we run Legend Doctor in CI on every pull request. At first it only reports findings and doesn't block merges.

pnpm exec legend-doctor src/features/course-player

Once your team trusts the rules, add --fail-on change to block merges on the findings you care about. The GitHub Action⁠ can also comment new findings on pull requests, and the agent can fix those on its next run. Keep the interaction tests as well, because a code scan can't tell you whether the progress bar still works.

Here are the render counts from each version of the player.

We started at seven re-renders for one letter and ended at one, with the progress bar still working. We counted renders, not milliseconds. A slow network request or a long list needs its own measurement.

If you try this on your own app, start with one interaction that feels slow and count what re-renders. Thanks for reading.