Why it is written this way
The most common issue with refactoring prompts is simply asking "please clean up this function" and receiving an entirely rewritten block of code—only to discover subtle behavioral bugs in production. Debugging that requires a tedious line-by-line diff.
Setting the Role to "a developer maintaining legacy code" establishes the right cautious mindset. Experienced maintainers avoid sweeping, arbitrary changes. In the Task paragraph, defining "external behavior" explicitly in terms of inputs, outputs, exceptions, and side effects prevents the AI from altering critical execution orders (like database writes or emails) while only focusing on return values.
The Constraints are captured via variables because restrictions vary across teams, and renaming a signature can break upstream callers. Directing the model to report conflicts rather than silently breaking rules keeps the output safe.
Requiring an initial table and pausing for a "Proceed" signal is the core mechanism of this prompt. Generating everything at once overwhelms review and tempts developers to blindly paste it in. Iterative refinement lets you adjust naming and boundaries early before code is written. Including "Arguments & Return Value" in the plan ensures clear parameter passing instead of accidental global state dependencies.
Unfamiliar terms? See Aha AI: role-prompting, output-format
Compared with a bad example
This function is too long, refactor it for me please.
(paste code here)
This results in a completely rewritten block of code all at once, often silently flipping logic conditions or renaming parameters. Without explicit constraints, it might introduce third-party libraries or break function signatures. With no explanation of what changed or why, review becomes nearly impossible, forcing you to revert the code.
Variations
When you need to understand what the function does first
Please list what the following {{target language}} function does step by step from top to bottom using numbered points. Keep each line concise ("Does X") and explicitly mention where conditional branches lead. Do not suggest any refactoring or improvements.
""" {{source code snippet}} """
Use this first when inheriting unfamiliar code. Suppressing refactoring suggestions prevents analysis and code modification from getting mixed up.
When isolating and removing duplicate code only
You are a {{target language}} developer. Identify only the duplicate logic in the code below. Target only repetitive patterns that occur 3 or more times, and exclude anything where modularization would harm readability. For each finding, list: "Duplicate Section | Frequency | Consolidated Code", while strictly following: {{rule to follow}}.
""" {{source code snippet}} """
Use this when you want to eliminate redundancy without altering overall structure. The "3 or more times" threshold prevents over-abstracting small two-line snippets that are cleaner left inline.
Model notes
Longer functions risk output cutoff when rewritten all at once. Always request the plan first and process one function at a time.
Related prompts
Last updated 2026-09-02 · Found a mistake? Let us know