AI Coding Tools on React: Where They Go Wrong

I used Claude Pro in the browser on this site's React code, for Tailwind layout work and for one state bug that took me roughly 1 hour to close. I kept nearly all of what it wrote; a few lines were mine. The two things it got wrong were both structural. It changed components that already worked while fixing something else, and it put hooks and browser code inside components that run on the server, which Next.js will not allow.

This is one tool on one codebase, so treat it as a log rather than a roundup. I have not run the editor extensions people compare in these articles.

The server and client rule it keeps forgetting

In the App Router, which this site uses on Next 16.3.1, layouts and pages are Server Components by default. The documentation that ships with the package is specific about what belongs on the client: state and event handlers such as onClick and onChange, lifecycle logic such as useEffect, browser-only APIs such as localStorage and window, and custom hooks. Anything in that list needs a Client Component.

That is the line the model walks over. The code it hands back looks like ordinary React, because it is ordinary React, and in a server file it fails. The same docs note that importing a third-party component that uses client-only features straight into a Server Component produces an error, because the framework cannot tell from the import that the component needs the browser.

Once you know the rule, the fix is mechanical and takes seconds. The cost is that you have to know the rule, which means the tool is fastest for people who could have written the code anyway.

Layout work went better than logic

For Tailwind classes and layout, the first answer was usually close enough to keep. Styling is self-contained: a wrong class shows up in the browser immediately, and nothing two files away depends on it. That is why a few lines of mine were enough on top.

State was slower, and the hour went mostly on narrowing down which render was the problem rather than on typing. The useful part was pasting the component and the error into the same message. The part I had to supply was which behaviour was correct in the first place.

When a fix brings changes I did not ask for

The habit that costs me most is the one where a fix arrives with unrequested changes to code that worked. A model in a browser tab sees the file you pasted and nothing else, so it rewrites freely and cannot know that a prop it renamed is read somewhere else. On a small site I catch it, because the tests fail or the page looks wrong. On a large codebase I would not want to find out that way.

So I paste narrowly now, one component at a time, and I read the diff before I save it. The same habit applies to the free account I open more often for code, and this comparison of the two explains why I open that one.