AI Coding Workflow for React

Give the agent one named task, only the context it needs and a check you can rerun. A task shaped this way produces a diff small enough to review and a result you can repeat.

Each move fails in its own way. Without a boundary, the agent edits files you never meant to open, and the diff becomes hard to read. Thin context fails more quietly: the code compiles and the tests pass, but the change ignores patterns the rest of the repo follows. Without a check you can rerun, you are taking the agent's word that the work is done.

Asking for a plan before the agent writes code is the easiest step to skip. It means a short wait while nothing visible happens, and the price of skipping it shows up later, in review.

If the plan names files you didn't expect, you learn that before any code exists. If it names the right files, you have a list to check the diff against. Once four hundred lines of diff are on screen, changing the approach means throwing that work away.

The habit that matters most for a team is leaving a trail the next reviewer can follow. The steps below keep the prompt and its proof attached to the change.

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.

Match the effort to the change. A one-file fix needs a clear done state and a typecheck, and a plan adds little. A change across several files is where a plan pays for itself, and where the check should include tests and a reviewer who knows that code.

Keep whatever lets someone rerun the work or pick it up later. A finished task is the merged code plus a short trail that shows 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.

The last item pays off over time. A rule or template saved from one good run means the next run starts from what already worked, not from a blank prompt.

A screenshot proves one state, and a component almost never has just one. It has loading, empty and error states, a row that wraps on a narrow phone, and a disabled variant nobody remembers owning. Cursor's browser tool can produce evidence for each of them. Screenshots go through the file-reading tool, so the agent sees the page as an image instead of a text description, and it can read console messages and errors alongside them.

Asking for a screenshot once the component looks done gets you whichever state the agent landed on. That is nearly always the happy path, because the code was just written to satisfy it. Name the states you want proof of in the prompt, before the agent starts. It costs one sentence and gets you the awkward states as well.

Signed-in views stay testable across sessions. Browser state persists between agent sessions for each workspace, so cookies, localStorage, sessionStorage and IndexedDB content survive, and the signed-in dashboard you need is still there tomorrow. Storage is isolated per workspace, so one project's sign-in doesn't leak into another's.

The agent can read network traffic too, but Cursor's docs say that is currently available only in the Agent panel. Check that before you plan a verification step around it.

Point at anything spatial, and write out anything about behavior. 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, box in an area or dictate a note, and Cursor sends the note with the element's details and a cropped screenshot. In React apps, those details include the component name and component stack, so the agent can find the source. Writing out "the third card, the one whose icon sits two pixels low" is where the loop starts costing more than the fix.

Multi-select keeps related changes in one note: hold Shift and click to add more elements to the note you have open. Cursor's docs suggest it when the change depends on how the elements relate, such as making one component match another. We'd keep each note to one intention, so the diff that comes back makes one change you can read. If your dev server hot reloads, the changes appear in the running app as the agent finishes.

CSS edits go through the agent as well. On a note for a single element, Edit CSS properties opens a CSS inspector, and Cursor sends your changes with the note. The agent turns them into code changes, so what comes back is a diff like any other, and it gets read like one.

While the component is still the diff you are reading. The browser tool can audit it directly. Cursor's example @browser prompt checks color contrast ratios, semantic HTML and ARIA labels, keyboard navigation and missing alt text, and the docs frame the audit against WCAG compliance standards. That check runs in the same session that wrote the component.

Leave it to a later ticket, and it turns from a fix 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.

Run the audit before the visual review, not after it. Once a design looks right to you, the pressure is to ship it, and every finding after that point has to argue against something that already looks finished.