Skip to content
Back to AI Coding

Refactoring Prompt Patterns

Preserve behavior: state invariants, ask for a plan, gate with existing tests.

Prompt EngineeringIntermediate

Why

GitHub's 2024 survey found 92% of US respondents use AI coding tools to generate test cases, and 73% of open source respondents use AI tools for coding or documentation. Refactors must preserve behavior.

Stating invariants ('response shape unchanged') and gating with existing tests catches behavior changes that a 'make it cleaner' prompt would silently introduce.

When

Use for any non-trivial refactor. Skip for pure renames with IDE tooling.

How

1. State the goal + invariants ("response shape unchanged; no new deps"). 2. Ask for a plan first; review. 3. Execute; run existing tests after each step. 4. If tests go red, the refactor changed behavior — revert and re-plan. 5. Commit per step with refactor: prefix.

Example

Goal: "replace assertValid with zod.safeParse in src/api/**" Invariants: "response shape and status codes unchanged; no new deps beyond zod." Plan: 12 routes, one per commit. Run npm test after each — red means behavior changed.

Common Problems

  • ⚠Error: Model returns "I cannot help with that" → rephrase to remove restricted phrasing; narrow scope and provide explicit allowed examples.
  • ⚠JSON parse error on model output → wrap with a fenced ```json block and add "respond with valid JSON only" to the system prompt.
  • ⚠Error: Token limit exceeded (400 Bad Request) → split the prompt, summarize prior context, or switch to a larger context model.

Best Practices

  • ✓State invariants explicitly before the refactor.
  • ✓Use existing tests as the behavior-preservation gate.
  • ✓Measure the outcome with a concrete metric (time saved, defect rate, test coverage) so the practice can be justified and improved.

FAQ

What is Refactoring Prompt Patterns?

Preserve behavior: state invariants, ask for a plan, gate with existing tests. It helps developers quickly grasp the core value and use cases of Refactoring Prompt Patterns.

How do I get started with Refactoring Prompt Patterns?

To get started with Refactoring Prompt Patterns, focus on these points first: State the goal + invariants ("response shape unchanged; no new deps").

What are common mistakes with Refactoring Prompt Patterns?

Common mistakes when using Refactoring Prompt Patterns include: Error: Model returns "I cannot help with that" → rephrase to remove restricted phrasing; narrow scope and provide explicit allowed examples.; JSON parse error on model output → wrap with a fenced ```json block and add "respond with valid JSON only" to the system prompt.; Error: Token limit exceeded (400 Bad Request) → split the prompt, summarize prior context, or switch to a larger context model..

What are the best practices for Refactoring Prompt Patterns?

Best practices for Refactoring Prompt Patterns include: State invariants explicitly before the refactor.; Use existing tests as the behavior-preservation gate.; Measure the outcome with a concrete metric (time saved, defect rate, test coverage) so the practice can be justified and improved..

How do I learn more about Refactoring Prompt Patterns?

Start with the official docs, then search real-world examples on GitHub. Validate patterns in a small scratch repo before applying them to production code.