Refactoring Prompts

7 Prompts · Copy-Paste Ready

Home › Vibe Coding Prompts › Refactoring

Category · Refactoring

Refactoring Prompts

7 prompts to clean up code without breaking it. Extract, rename, split, deduplicate — with tests that confirm nothing regressed.

The golden rule: Refactor one thing at a time. Refactor → test → commit → next refactor. Never mix refactoring with feature work in the same commit.

1

Extract a function from a code block

Use when a function is doing too much or a block of code is repeated. Extracting is the safest refactor — behavior can't change.

Extract the following block into its own function: [paste the function containing the block] The block to extract is: [paste the specific lines or describe them] Requirements: 1. Function name should describe what it does (verb-first) 2. Move any local variables the block uses 3. Return what the block produces 4. Add a one-line JSDoc/docstring 5. Update the original code to call the new function Preserve all behavior exactly. Do not change logic while extracting.
What you should expect

Two pieces: the new function and the updated original. If AI changes any logic, push back: "You changed the behavior. This is a pure extraction — no logic changes."

2

Rename a symbol across the codebase

Use when a name no longer matches what the code does. Renames are risky because strings, comments, and tests often reference the old name.

Rename [oldName] to [newName] across this codebase. Search and update: 1. All variable/function/class declarations 2. All references (imports, calls, property access) 3. String literals that reference it (error messages, logs) 4. Comments and JSDoc 5. Test files and fixtures Before you start, list every file you'll need to touch with the number of occurrences in each. Then execute the rename. Do NOT rename anything that happens to match the string but refers to something else.
What you should expect

A file list with occurrence counts, then the changes. If AI misses files, ask: "Search the whole repo — you may have missed test files or fixtures."

3

Convert callbacks to async/await

Use when you're modernizing code or fixing callback hell. This is a behavior-preserving change if done correctly — the key is preserving error handling.

Convert these callback-based functions to async/await: [paste the functions] Rules: 1. Every callback pattern becomes await 2. Errors previously passed to callback go to try/catch 3. Maintain the same execution order — sequential stays sequential 4. Do NOT parallelize independent operations unless I ask 5. Preserve the exact same error messages and types 6. Keep function signatures the same (unless they returned a callback) Show the diff. Explain any behavior that might change.
What you should expect

A clean async version with the same semantics. Watch for accidental parallelization — that's the most common refactoring bug.

4

Split a large file into modules

Use when a file has grown past ~400 lines or has multiple unrelated concerns. Splitting is delicate — the imports tree must stay consistent.

This file is [N] lines and needs splitting: [paste the file] Before splitting: 1. Identify the logical modules (by responsibility, not just size) 2. List what each module would export 3. Identify shared dependencies between modules 4. Flag any circular dependency risks Propose the new structure first. Wait for my approval before executing. Once approved, do the split in this order: 1. Create new files with their content 2. Update imports in the original 3. Update imports in all external callers 4. Run the test suite to confirm nothing broke
What you should expect

A proposal before execution. This is the one prompt where you must review before saying yes. If AI just executes, push back: "Show me the plan first."

5

Remove duplication across files

Use when you notice the same logic in multiple places. The safest way to deduplicate is to prove equivalence first, then consolidate.

I have duplicated logic across these files: [paste each file's relevant section, labeled] Analysis needed: 1. Are these actually the same logic, or subtly different? 2. What edge cases differ between the versions? 3. What's the shared abstraction that covers all cases? If the versions differ in behavior, say so — do NOT force a merge. If they're truly equivalent, propose: - Where the shared function lives - Its signature - How each caller would use it Show the diff for each file. Preserve any version-specific behavior with a parameter if needed.
What you should expect

A comparison first, then a merge only if truly safe. Watch for AI merging "similar but different" code — that's how subtle bugs get introduced.

6

Flatten nested conditionals

Use when deep nesting makes code hard to follow. Early returns + guard clauses are the standard fix — and behavior must be preserved exactly.

Flatten this function using guard clauses and early returns: [paste the function] Rules: 1. Preserve ALL behavior — including the "else" cases 2. Every early return must match a condition that exits 3. Combine related conditions where safe 4. Keep the original error messages if any 5. Add a comment for each guard explaining what it prevents After refactoring, trace through these inputs to prove equivalence: - [input 1] → expected: [output 1] - [input 2] → expected: [output 2] - [edge case] → expected: [output]
What you should expect

The flattened function plus a trace confirming each test case still produces the expected output. If the trace is wrong, the refactor is wrong.

7

Modernize old syntax without changing behavior

Use when migrating from older JS/Python patterns to modern equivalents. This is safest when you commit before, then review the diff carefully.

Modernize this code to current [language] conventions: [paste the code] Updates to apply: - var → const/let (as appropriate) - .then() chains → async/await (only if cleaner) - for loops → array methods (only if clearer) - string concatenation → template literals - any outdated patterns I missed Constraints: 1. Behavior must be identical — same return values, same errors 2. No performance regression 3. No new dependencies 4. Do NOT change logic while modernizing Show the full diff, then list every change and why.
What you should expect

A diff plus a change log. Review carefully — "modernization" prompts often slip in logic changes. Ask: "Did any line change behavior, not just syntax?"

🎯 Rules for safe refactoring with AI

❓ Frequently asked questions

What makes a good refactoring prompt?

A good refactoring prompt states the goal (what to change), the constraint (what must not change), and the verification (how to confirm nothing broke). Without constraints, AI will happily rewrite your entire file.

How do I know AI won't break my code during refactoring?

Two things: ask AI to preserve behavior explicitly, and require tests to pass. If you don't have tests, ask AI to write them first against the current code, then refactor.

Should I refactor in one big prompt or many small ones?

Small prompts, one change at a time. Refactor → test → commit → next refactor. Every large refactor should be a series of tiny safe steps.

What is the difference between refactoring and rewriting?

Refactoring changes structure without changing behavior. Rewriting starts from scratch and can introduce new bugs. Prefer refactoring unless the code is fundamentally wrong.

Can AI refactor code it doesn't understand?

Not well. Give AI the surrounding context — what the code does, who calls it, what edge cases exist. The more it understands, the better the refactor.

🔗 Related

🐛 Debugging Prompts
When the refactor breaks something.
🔍 Code Review Prompts
Review before you commit.
🏗️ Architecture Prompts
Plan before refactoring.
📋 All Prompts
Back to library.
← All Prompts