Prompt Engineering

AI-Generated Code Cleanup — Deflate the Generated Bloat

Generated code duplicates instead of extracting, wraps without deciding, and defends against impossible states. This prompt hunts those exact failure modes — without preserving bugs as behavior.

Open in Refactor Prompt Builder

Overview

AI-generated code has a recognizable signature: repetition where a human would extract, abstraction layers that make no decision, defensive checks for states that cannot occur, and over-general solutions to specific problems. This prompt configures the contract for that material — the AI-generated context hunts each failure mode by name, and adds the rule that makes this cleanup different from other refactors: generated code can look right while being subtly wrong, so the model must verify the code does what it appears to do, and a discovered bug gets flagged rather than silently preserved as behavior. Simplification priorities do the deflating; the safety rules keep it honest.

How to use this resource

Hunt the signature

Repetition, over-abstraction, impossible-state checks — the known failure modes of generated code, by name.
Deflate, don't redesign

Simplification priorities remove the bloat; the non-goals keep the cleanup from becoming a rewrite.
Flag what looks wrong

Subtly-wrong generated logic gets flagged as a question — never silently preserved, never silently fixed.

Why This Works

Naming generated code's specific failure modes beats generic cleanup instructions
The looks-right-but-wrong rule addresses what makes generated code uniquely risky
Flag-don't-fix keeps the cleanup a refactor instead of an uncontrolled patch

Best for

Code accepted from AI assistants under deadline pressure
Vibe-coded prototypes being promoted to real modules
Teams adding a cleanup pass to their AI-assisted workflow

Not for

Judging whether the generated code is acceptable at all — that's the Code Review Prompt Generator
Validating the generated code's output format — that's the AI Output Validator

Use cases

Consolidating the near-identical handlers a generator produced
Removing wrapper layers and single-implementation interfaces
Deleting defensive checks for states that cannot occur

FAQ

What makes this different from a general refactor prompt?

It hunts the failure modes specific to generated code by name: repetition to consolidate, "unnecessary wrappers, interfaces with a single implementation, layers that make no decision," and "defensive checks for impossible states." The rule that sets it apart is the looks-right-but-wrong one — verify the code does what it appears to do. The refactor-prompt-builder configures this contract; your assistant runs the cleanup and you review the change list.

What happens if the cleanup finds a real bug in the generated code?

It flags the bug rather than fixing or preserving it. The context rule is explicit: "do not silently preserve a bug as behavior: flag it," and the SAFETY RULES say to flag uncertain behavior "instead of deciding it" — ask, don't guess. Worthwhile-but-unsafe transformations land under "Suggested but not applied" with what information would unlock them. That keeps it a refactor, not an uncontrolled patch.

Do I need to tell it the programming language before pasting the code?

You don't have to. The line reads "Language: not specified — infer it from the code and stay consistent with it," so it works from what you paste into the "Code to refactor" block. It also preserves public contracts — signatures, return types, error types, serialized shapes — unless you explicitly say otherwise, so inferring the language doesn't put your API surface at risk.

Customize This Resource

Opens this setup in Refactor Prompt Builder. Generate to get the full refactoring contract — then adjust the goal, risk level, and validation strategy.

Open in Refactor Prompt Builder

Prompt Template

Copy it as-is, or use Open in Refactor Prompt Builder to load it pre-filled and customize it with your own context.

REFACTORING OBJECTIVE
Clean up this AI-generated service: collapse the repetition and remove the abstraction layers that make no decision.
Refactoring goal: simplification — reduce nesting, branching, and dead weight while keeping every behavior.
Change how the code is built — never what the code does. If a transformation cannot be made safely with the available information, leave that code unchanged and say why.

EXISTING CODE CONTEXT
Code context: AI-generated — review for the failure modes typical of generated code.
- Hunt repetition: generated code duplicates logic instead of extracting it — consolidate the copies.
- Hunt over-abstraction: unnecessary wrappers, interfaces with a single implementation, layers that make no decision.
- Hunt unneeded complexity: defensive checks for impossible states, dead branches, over-general solutions to specific problems.
- Verify the code does what it appears to do — generated code can look right while being subtly wrong. Do not silently preserve a bug as behavior: flag it.
Language: not specified — infer it from the code and stay consistent with it.
Code to refactor:
```
[Paste the code to refactor here]
```

REFACTORING GOAL
Primary goal: Simplification.
Transformation priorities for this goal:
1. Flatten control flow: guard clauses and early returns instead of deep nesting.
2. Reduce branching: collapse conditions that encode the same decision more than once.
3. Remove dead code — but only code proven unreachable, not code that merely looks unused.
4. Shorten the path from input to output: remove indirection that adds steps without adding meaning.

RISK PROFILE
Risk level: Balanced.
- Apply reasonable improvements: moderate restructuring is allowed where the benefit is clear.
- Group related changes, but keep each group reviewable and separately verifiable.
- When a transformation is borderline-safe, apply the conservative version and note the more aggressive option.

SAFETY RULES
These rules apply to every transformation, at every risk level:
1. Identify behavior assumptions before changing code — list every assumption you rely on.
2. Flag uncertain behavior instead of deciding it: if you cannot tell what a branch does or why it exists, ask — do not guess.
3. Do not remove functionality. Code that looks redundant may be load-bearing.
4. Do not invent requirements. Refactor toward the stated goal, not toward an imagined better product.
5. Do not rewrite unrelated code. Touch only what the goal requires.
6. Explain why each change exists — every transformation traces to the stated goal or to a named problem in the code.
7. Preserve public contracts — signatures, return types, error types, serialized shapes — unless explicitly instructed otherwise.

TRANSFORMATION GUIDANCE
Known failure modes of this goal — watch for:
- "Looks unused" is not "is unused" — check for reflection, dependency injection, serialization, dynamic dispatch, and external callers before deleting anything.
- Inverting conditions to flatten nesting is a classic behavior-change risk — verify every branch still routes the same inputs to the same outcomes.

BEHAVIOR PRESERVATION REQUIREMENTS
- Preserve observable behavior: the same inputs produce the same outputs, including error cases.
- Preserve business rules: every condition, threshold, and special case survives the refactor exactly.
- Preserve outputs: formats, ordering, precision, and encodings stay identical unless the goal explicitly targets them.
- Preserve side effects: writes, emitted events, log lines other systems consume — and their relative order.
- Preserve integrations: API shapes, serialized payloads, database access patterns, and external call sequences.
- These requirements hold unless the instructions explicitly say otherwise — and any knowingly behavior-affecting change must be flagged, never silent.
- If achieving the goal and preserving behavior conflict, behavior wins: stop and explain the conflict instead of compromising it.

VALIDATION STRATEGY
Goal-specific validation: confirm every input class still reaches the same outcome — simplification must shrink the code, never the behavior.
- Identify the key workflows this code serves and describe how to verify each still works after the refactor.
- List the major edge cases the original code handles and confirm each is still handled — name them individually.
- Recommend regression checks for the riskiest transformations made, riskiest first.

ASSUMPTIONS
- List every assumption made about the code's behavior, inputs, or environment.
- Mark each assumption VERIFIED (with its evidence) or UNVERIFIED (with the question that would resolve it).
- Any transformation that depends on an UNVERIFIED assumption must be flagged as conditional on it.

NON-GOALS
- Do not invent requirements.
- Do not redesign the entire system.
- Do not remove behavior without justification.
- Do not introduce new features.
- Separate assumptions clearly from facts.
- Flag uncertainty instead of resolving it silently.
- Explain the tradeoffs of any change that has them.

OUTPUT REQUIREMENTS
- Return the refactored code, complete — no elided sections, no "rest unchanged" placeholders inside changed units.
- Follow it with a change list: for each change — what changed, why it serves the goal, and its behavior impact (expected: none).
- Flag any change that could plausibly alter behavior, with the reason it might and the check that would confirm it does not.
- Where a worthwhile transformation was skipped for safety, list it under "Suggested but not applied" with what information would unlock it.

More resources from Refactor Prompt Builder

Resource

Refactor Prompt — the Behavior Preservation Contract

"Refactor this code" invites silent behavior changes. The refactoring contract preserves business rules, outputs, and side effects — and flags uncertainty instead of deciding it.

Prompt Engineering

Resource

Safe Refactoring Prompt — Zero Regression Tolerance

For code that ships weekly: a refactoring prompt where regression avoidance outranks improvement depth, log lines stay intact, and every step is rollback-friendly.

Prompt Engineering

Resource

Architecture Cleanup Prompt — Boundaries Without a Redesign

Dependency cycles, leaky modules, misplaced responsibilities — cleaned up within the existing design. Explicitly not an invitation to invent a new architecture.

Prompt Engineering

Resources that pair well

Resource

Code Review Prompt — the Review Contract

"Review this code" gets shallow comments. The review contract gets findings with severities, a checklist, and a verdict.

Prompt Engineering

Resource

Playwright Test Prompt

getByRole over CSS chains, auto-wait over sleep, web-first assertions — Playwright tests written the way Playwright wants.

Engineering

Resource

Debugging Prompt — the Investigation Contract

"Fix this error" gets guesses. The investigation contract gets a ten-stage diagnosis: facts separated from assumptions, alternatives weighed, fixes justified.

Prompt Engineering

Related tools

Tool

Refactor Prompt Builder

Build behavior-preserving refactor prompts — goal, risk level, and code context turn into a safe refactoring contract.

Coding Workflows

Tip: Save time by exploring related resources and tools that integrate with this resource.