Chain-of-Thought Prompting for React Refactors: Get Better Code Changes

Why Refactoring Prompts Fail

Most developers prompt refactors like this: "Refactor this component to use React Query instead of useEffect." The AI jumps straight to code, makes assumptions, misses edge cases, and produces something that technically compiles but breaks subtle behavior.

Chain-of-thought prompting makes the AI reason through the problem before coding. This surfaces issues and produces better solutions.

The Chain-of-Thought Refactor Template

I want to refactor the following component. Before writing any code, first:

1. Summarize what this component currently does, including all side effects
2. Identify any edge cases or subtle behaviors I might not be aware of
3. Describe potential issues with the proposed refactor
4. Outline your plan for the refactor step by step
5. Note any questions or decisions I need to make

Then, once I confirm, write the refactored code.

Component to refactor:
[PASTE COMPONENT]

Refactor goal:
[DESCRIBE WHAT YOU WANT]

Example: Migrating useEffect to React Query

I want to refactor this component from manual useEffect fetching to React Query v5.

Before writing code, analyze:
1. What data does this component fetch and when?
2. What are all the state transitions (loading, error, success, refetch)?
3. Are there any race conditions in the current implementation?
4. Does this component have any mutations (write operations)?
5. Are there any parent components that need to invalidate this cache?
6. What's the right staleTime for this data?

Then outline the plan, and wait for my confirmation before writing code.

[PASTE COMPONENT]

Using the Analysis to Guide the Refactor

The analysis phase typically reveals things you hadn't considered. Common discoveries:

• The useEffect has a cleanup function that cancels requests — React Query handles this differently
• State is being shared with parent via props drilling — should become a shared queryKey
• There's a subtle dependency array issue that's actually a bug — fix it in the refactor

Once you understand the analysis, you can add constraints:

Great analysis. A few notes before you write the code:

1. The queryKey should include the userId so different users get different cache entries
2. staleTime should be 5 minutes for this data (it changes rarely)
3. Keep the loading skeleton exactly as-is — don't change the UI
4. The onSuccess callback should remain — it's needed for analytics tracking
5. If the request fails, show a retry button (I don't have this currently but want it)

Now write the refactored component.

Chain-of-Thought for Architecture Decisions

I'm debating between two approaches for our notification system.

Approach A: Polling every 30 seconds
Approach B: WebSockets for real-time updates

Before recommending an approach:
1. What are the actual latency requirements for a notification system?
2. What's the infrastructure complexity difference?
3. What are the failure modes of each?
4. What does our current tech stack (Next.js/Vercel) support well?
5. At what user scale does each approach break down?

Give me a recommendation with reasoning, not just a list of pros/cons.

When to Use Chain-of-Thought

Use it for: complex refactors, architectural decisions, performance investigations, and any change where you want to catch issues before they're baked into code. Skip it for simple changes like "rename this variable" or "add a prop to this component" — the overhead isn't worth it for trivial edits.