AI Coding Workflow for React

The working pattern for React AI coding is small enough to review and specific enough to repeat. Give the agent a named task and only the context it needs, then tie the result to a check you can rerun. The table below breaks that into moves.

Each of those moves fails in its own particular way, and the order they come in is doing more work than it looks like it is. Skip the boundary and you get a diff nobody wants to read, because the agent has quietly rewritten files you never meant to open. Thin context fails more quietly: the code compiles, the tests pass, and it ignores every pattern the rest of the repo follows. Then there's the check, which to me is the real one, because it's the whole difference between a result you verified and a result you're taking someone's word for.

The step people skip is the plan. I think it's because it feels like overhead, thirty seconds of nothing visibly happening while you're trying to get work done. Actually, that's not quite the reason. It's that the cost of skipping it lands much later, so it never registers as the mistake it was. If the plan names files you didn't expect, you've learned something for free. If it names the right ones, you've got a reference to check the diff against when it arrives. And once there are four hundred lines on the screen, changing the approach means throwing that work away, which nobody is good at.

Running React AI coding as a team comes down to one habit: leave a trail the next reviewer can follow. The steps below keep the prompt and its proof attached to the change, so nobody has to reverse-engineer what the agent did.

1. 1Pick one real backlog item with a clear owner and expected result.
2. 2Add only the context the agent needs: files, failing output, constraints and done state.
3. 3Ask for a plan before code when the task touches more than one file.
4. 4Run checks that match the risk: unit test, typecheck, visual pass or review checklist.
5. 5Capture the prompt, diff, result and reviewer note so the workflow can be repeated.

Keep whatever lets you rerun the work or hand it to someone else. A finished task is the merged code plus the short trail that explains how it got there.

• The prompt or plan that shaped the work.
• The files changed and the reason each file changed.
• The command, screenshot or review note that proved the result.
• The rule, checklist or template you would reuse next time.

A screenshot proves one state, and a component almost never has one. Loading, empty, the error path, the row that wraps on a narrow phone, the disabled variant nobody remembers owning. Cursor's browser tool can produce the evidence for each of them, since screenshots are integrated with the file-reading tool so the agent sees the page as an image rather than a text description, and it can read console messages and errors alongside them.

The move I used to make was asking for a screenshot once the component looked done. That gets you whichever state the agent happened to land on, which is nearly always the happy path, since that is the one the code was just written to satisfy. Naming the states you want proof of in the prompt, before it starts, costs a sentence and gets you the awkward ones as well.

Authenticated views are less painful than they used to be. Browser state persists between agent sessions per workspace, so cookies, localStorage, sessionStorage and IndexedDB content survive, and the signed-in dashboard you need for a component is still there tomorrow. Storage is isolated per workspace, which is the part that makes it safe to rely on.

Network traffic is readable too, though as of the current docs that one is only in the Agent panel. Worth knowing before you plan a verification step around it.

Use the selection for anything spatial and text for anything behavioural. In Design ModeA way to point at an element in Cursor's built-in browser and change it directly, instead of describing it in words. Press Enter for the full definition. you click an element, draw on the page, or say what you want out loud, and the instruction carries the selected element, the code behind it and the surrounding layout with it. Writing out "the third card, the one whose icon sits two pixels low" is where the loop starts costing more than the fix.

The multi-select case deserves a thought before you use it. You can select several elements across the site, describe the changes in text, and agents kick off in parallel, with the result appearing live on the page after hot-reload. Which is quick, and it also means several diffs arriving at once against a page you were looking at rather than a plan you wrote. I would keep it to changes I could still describe as one intention.

The apply button in the design sidebar is not a style patch. It triggers an agent that translates your visual adjustment into code changes, so what comes back is a diff like any other and gets read like one.

While the component is still the diff you are reading. The browser tool audits it directly, and Cursor's own example prompt for @browser covers contrast ratios, semantic HTML and ARIA labels, keyboard navigation and missing alt text, framed against WCAG compliance standards. That is a check available in the same session that wrote the component.

Leave it to a later ticket, though, and it stops being a fix and turns into a rewrite, because the markup decision that broke keyboard navigation is usually the one the component was built around. A div that should have been a button is a five-minute change on the day and a several-file change a month later.

Probably the most useful habit here is running the audit before the visual review rather than after it. Not because the audit matters more, but because once a design looks right to you, the pressure is to ship it, and every finding after that point has to argue against a thing that already looks finished.