The agent has changed the code. The terminal is quiet, and the page looks fine. Before closing the editor, try a few more interactions.
Change a filter while a request is pending. Switch between records. You might find that the selector shows B while the details belong to A, a count no longer matches the list, or a failed request leaves a button spinning.
Then comes another round of explaining, editing, and checking. The useful question is how to connect those rounds: give the agent a clear target, keep track of its changes, recover from interruptions, and establish what is actually finished.
Define what “fixed” means
“Improve this page” is easy to start and difficult to finish. Before handing over the task, describe what should happen after the relevant interactions:
- Which page should pagination return to when a filter changes?
- Should a failed save preserve the user's input?
- After switching records quickly, which record should remain visible?
A long specification is unnecessary. A sequence someone can follow is useful enough.
Suppose a details page has this bug: you select A, then B. B's response arrives first and appears on screen. A arrives later and replaces it, although B is still selected.
You can give the agent this prompt:
Select A, then switch to B while A's request is still pending. Make B's response arrive first, followed by A's. The selector stays on B, but the details change to A. The expected result is to keep displaying B. Trace the existing request and state-update logic, identify the cause, and verify the fix using the same response order.
That gives the agent an investigation to pursue and gives you a result to check.
Understand the existing implementation
Data in a React page might come from an Effect, a route loader, a shared hook, or a data-fetching library. Adding another request and another set of state without understanding those relationships can leave more code to maintain.
Ask the agent to explain three things first: where the request starts, what owns the current query parameters, and what gets updated when the response arrives.
For the A/B example, the question is why an obsolete response can still update the current screen. For fetching directly in an Effect, React describes aborting the fetch or ignoring its result during cleanup. If the project uses a request library, inspect its existing request keys and handling before adding another mechanism.
Check loading and error state too. Guarding the data update alone may leave another bug: an old request finishing could clear the loading indicator for the current one.
Finding the cause in the existing implementation gives you a concrete reason for the change. Start there before considering a different architecture.
Keep the change easy to review
A small interaction fix becomes difficult to review when it also reorganizes half the project. Put the scope into the task:
Follow the existing component, request, and state-management conventions. Complete this behavior fix first. If a broader change is necessary, explain why. Preserve existing changes unrelated to this task.
When reviewing the diff, pay attention to added state and Effects.
If a displayed value can be calculated from current props or state, storing it separately creates another synchronization responsibility. React's state design guide recommends avoiding redundant and duplicate state. An independently edited form draft or a server-provided total can have a separate reason to exist; judge each value by its purpose.
Asking the agent to explain each addition is more useful than repeatedly asking it to “optimize everything.”
When work stops, find out where it stopped
Reading code, analyzing a problem, editing files, and interpreting check results can involve several model calls. The coding tool's connection to its model service is part of that workflow.
If a model request fails, check whether files have changed, whether a test has started, and which step last completed. Review the working tree before deciding where to resume.
With a coding agent that supports a custom model service, configure the service address, credentials, and model in the development tool. The service helps the agent work on your React project; your React application does not need an AI endpoint for this workflow.
The model service can also handle routing and retries. At XylemNode, our Auto group selects a request path based on channel health. When a channel fails, it supports retries across groups while the caller keeps the same model name. For development tasks involving repeated model calls, this can reduce manual switching between channels.
These are the coding agent's model requests. The A/B overwrite still needs a fix in the React application, and Auto does not track which project edits the agent has completed. Use file diffs and verification records to establish where work should continue.
Finish with the original interaction
When the agent says “fixed,” repeat the original sequence: select A, then B, and make A arrive after B. Confirm that B remains visible. Check the normal response order, failures, and loading indicators as well.
With an existing test setup, ask the agent to cover the case using request mocks or controlled response ordering. If verification is manual, record the actions and actual results. A successful build provides useful evidence, but it does not establish that these interactions behave correctly.
The handoff can be short: reproduction steps, cause, changes, completed checks, and anything still requiring verification in the target environment.
An agent is useful when it can follow a specific problem through those steps. Leaving a checkable result makes the next development task easier to start, without first having to work out what the previous task actually finished.
Top comments (1)
@ike_yinike_38324c52071, returning to the exact A-then-B race is the right acceptance test, and I’d also assert that obsolete A cannot clear B’s loading state or overwrite B’s error state. Modeling request identity explicitly with an abort signal or request key makes that invariant reviewable. Would your verification handoff record both the DOM outcome and the controlled network completion order, so the next engineer can distinguish a real state fix from a run that merely got a friendlier schedule?