How to Judge an AI Coding Tool as a React Developer

React has a specific problem for AI assistants: the rules changed. Server components, the client boundary, and the hooks rules that apply on one side but not the other are exactly the kind of thing a model trained largely on older code gets wrong confidently.

The result is that generic advice about AI assistants is close to useless for React work. What you need is a discriminator: something that separates tools that track the current framework from tools that produce confident, obsolete code.

Below are the four tasks we would run. Run them against any assistant you are considering, on your own codebase, in about twenty minutes. They are ordered so the most decisive one comes first.

The four tasks

1. Convert a client component to a server component and move the data fetch.
2. Add a form with validation and a pending state.
3. Find and fix an unnecessary re-render.
4. Extract a piece of duplicated JSX into a reusable component with sensible props.

Task 1: the boundary test, which decides most of it

This is the one that matters. A tool that has not internalised the server/client split will produce something along these lines, and produce it confidently:

// suggested "server component"
export default async function Page() {
  const [open, setOpen] = useState(false);  // will not run on the server
  const data = await getData();
  return <Panel data={data} open={open} />;
}

This is the single most useful discriminator for React work. If a tool does this, it does not understand the framework you are writing in, and you will spend your time correcting it.

Tools with repository-wide context tend to do better here, largely because they can see the "use client" directives in neighbouring files and infer the convention from your codebase rather than from training data. Inline completion tools, which see a much smaller window, are the most frequent offenders.

Run this task first. If a tool fails it, nothing else about the tool matters for React work.

Task 2: forms, where these tools genuinely earn their place

Expect every serious assistant to do well here. Form scaffolding with a server action, a pending state and field-level errors is repetitive, well-represented in training data, and easy to verify. This is where the time actually gets saved.

Use these tools for the code that is tedious and verifiable. Do not use them for the code that is subtle and hard to test.

Task 3: performance work is not a strength

Ask an assistant to fix an unnecessary re-render and the characteristic response is to reach immediately for useMemo and useCallback, frequently wrapping things that were never the problem. The tell to watch for is the opposite behaviour: a tool that asks what the profiler actually showed is reasoning about the problem rather than pattern-matching to it.

Render performance is a measurement problem. A tool that cannot see your profiler output is guessing, and memoising everything is the standard guess. It usually makes the code harder to read without making it faster.

Task 4: extraction is a genuine win

Pulling repeated JSX into a component with a sensible prop interface is where these tools are consistently good. They name props reasonably, they spot the varying parts correctly, and the result is easy to review because you can see the before and after side by side.

Reading your results

If you mostly…	Use
Work across many files in a large app	A repository-context assistant
Write a lot of forms and CRUD screens	Any of them — this is solved
Chase render performance	The profiler, not an assistant
Learn React	An assistant, but read every line it writes

One habit worth adopting regardless of which tool wins

Paste the relevant section of the current framework documentation into context before asking about anything released in the last year or so. It is unglamorous, it takes ten seconds, and it eliminates the large majority of framework-lag errors — which are, by a wide margin, the most common category of wrong answer in React work.

The underlying reason is worth understanding: these tools are not wrong about React because they reason poorly. They are wrong because React's rules changed after their training data was collected, and nothing in the model knows that. Supplying the current rules fixes the actual problem. Prompting more elaborately does not.

So which assistant should you use for React? Whichever one passes task 1 on your own codebase. We are not going to pretend that ranking holds still long enough for a list to be worth printing. If you are handing whole tickets to one rather than autocompleting inside it, which tickets to give an AI coding agent is the next question.