AI-Written React Compiles, but It Can Be Wrong in a Very Consistent Way

AI-written React compiles, runs, and passes tests. Then it writes a useEffect where it should have used derived state.

The title of Matt Pocock's talk at React Advanced Conference is a question: if AI writes code, do software fundamentals still matter? On X, he narrowed the question by one step: specifically, does understanding React still matter?

His answer: yes, and more than ever.

The talk is 31 minutes long, and the full recording is on GitNation: https://gitnation.com/contents/why-software-fundamentals-still-matter

In the comments, someone made the "it compiles but does the wrong thing" point more concrete. Commenter Shivanshu listed several typical mistakes: stale closures, writing an effect where derived state should be used, and 'use client' being sprayed everywhere. He said the people who can spot these within 10 seconds are the ones reviewing PRs.

For readers who don't write React: React is a frontend UI library that uses components and state to describe the interface. The mistakes above won't make the build fail, but they will make UI behavior strange or make the codebase harder and harder to change. A successful compile only means the syntax and types didn't blow up; it doesn't mean the logic is correct.

Someone asked Matt: why does it matter more than before?

Matt's reply was direct: this kind of knowledge used to multiply the output of just one developer—yourself; now it can multiply across as many agents as your budget allows. In other words, knowing React doesn't just mean you can write quickly yourself. You can also judge what multiple agents produce at the same time, set patterns for them, and catch problems when they go off track.

Another reply added a more realistic point. Commenter brav said agents will copy the patterns already in the repo. If your React is bad, bad React will now be copied at 10x speed. Someone has to set the patterns worth copying.

Not everyone agrees. Commenter nk said he wanted to say 'yes,' but understanding React hasn't helped much in recent development, and he asked whether he was doing something wrong. Len Seaside was more direct: React doesn't matter; understanding React is about as important as continuing to understand Macromedia Flash. Nanne said he doesn't think React is the optimal way to build current browser applications, but JSX and components can stick around.

These objections can't be ignored. Some people don't make a living with React, and not every project needs React. But the discussion can move to a more general question: when AI writes code, humans still need to be able to judge what the code is doing.

A commenter shared his experience building AI agents for 7 months; the author is Mjay. His conclusion: prompts can lower the starting point of code rot, but they can't change the slope of the rot. Guardrails must be able to reject, and rules can't live in a repo the agent can modify. Checks need three outcomes: allow, reject, and not tested. A timeout can't count as a pass. This example has nothing to do with React, but the logic is the same. Rather than just using prompts to tell an agent to 'write better,' turn the rules into something that runs on every change.

What Matt means by understanding React is human judgment. What Mjay talks about is hardening judgment into mechanisms. Both point to the same thing: once agents get faster, fundamentals and hard constraints become more valuable.

React will change, and JSX and components may change too. There's no need to mythologize any framework. But being able to see how state flows, what a closure captures, and which patterns will lead a codebase into a ditch—these abilities won't lose value just because AI can write code. AI has raised the speed of writing code, and it has also raised the scale of mistakes. The real question is: when AI writes something wrong, can you see it?