Programación y código Avanzado 2 min de lectura

Prompt de refactorización: sin cambiar comportamiento

Refactoriza código sin romperlo: primero se fija el comportamiento con pruebas, después se cambia por pasos que se pueden deshacer.

Compatible con: ChatGPTClaudeGemini Actualizado: 25 octubre 2026
Prompt 1143 caracteres · 5 variables
Actúa como desarrollador senior que refactoriza con pruebas y sin sorpresas.

CÓDIGO
[CÓDIGO ACTUAL]

CONTEXTO
- Qué hace hoy (según yo): [COMPORTAMIENTO]
- Qué me molesta: [LEGIBILIDAD / DUPLICACIÓN / RENDIMIENTO / TESTABILIDAD]
- Qué no puede cambiar: [CONTRATO PÚBLICO, FORMATO DE SALIDA, COMPORTAMIENTO EN CASOS RAROS]
- Lenguaje y versión: [LENGUAJE, VERSIÓN]
- Cobertura de pruebas actual: [SÍ / NO / PARCIAL]

PASO 1 — CONGELA
Escribe las pruebas que fijan el comportamiento actual, incluidos los casos raros. Si el comportamiento actual tiene un fallo, márcalo pero no lo corrijas en este refactor.

PASO 2 — DIAGNÓSTICO
Enumera los problemas reales con su línea y su impacto. Descarta lo que es cuestión de estilo.

PASO 3 — PLAN
De 3 a 5 pasos. Cada paso: qué cambia, qué no cambia y cómo comprobar que sigue funcionando.

PASO 4 — EJECUTA EL PASO 1
Solo el paso 1, con el diff completo.

REGLAS
- No mezcles cambio de comportamiento con refactor: si algo cambia de resultado, es otro trabajo.
- Sin reescrituras de estilo que no reduzcan complejidad real.
- Si la mejor decisión es no refactorizar todavía, dilo y explica qué falta.

El refactor no cambia lo que hace el código, sino lo que cuesta cambiarlo después.

02 — Variables

Rellena los corchetes

Los campos resaltados son los sitios donde van tus datos. No hace falta rellenarlos todos: lo que dejes vacío lo completa el modelo con su propio criterio.

[CÓDIGO ACTUAL]
[COMPORTAMIENTO]
[LENGUAJE, VERSIÓN]
[SÍ / NO / PARCIAL]
[LEGIBILIDAD / DUPLICACIÓN / RENDIMIENTO / TESTABILIDAD] Campo para rellenar en el prompt

03 — Cómo se usa

Cómo usarlo, paso a paso

  1. 01

    Fija primero el comportamiento con pruebas, en un commit aparte: así el refactor se puede revertir sin tocar lo demás.

  2. 02

    Rechaza los refactores que empiezan por renombrar: el valor está en reducir dependencias y duplicación.

  3. 03

    Cada paso debe dejar el código funcionando y desplegable. Un refactor que obliga a parar tres días es un riesgo, no una mejora.

04 — Variantes

El mismo prompt, otro resultado

Un prompt no resuelve todos los casos. Estas variantes piden el mismo trabajo con otro tono, otra longitud o otro formato: elige la que encaje.

Solo extraer funciones

Mismo código, pero un único objetivo: extraer funciones con nombres honestos y cero cambios de estructura.

Eliminar duplicación

Mismo código, pero enfocado solo en duplicación: identifica los bloques repetidos y unifícalos sin inventar abstracciones de un solo uso.

05 — Consejos

Notas que suben el resultado de nivel

  • La tentación es reescribir. El refactor bueno se mide en cuánto código se borra sin cambiar el resultado.
  • Una abstracción usada en un solo sitio es peor que la duplicación que pretende resolver.

06 — Preguntas

Preguntas frecuentes sobre Programación y código

¿Cuándo no refactorizar?

Cuando no hay pruebas y el código está en producción, o cuando vas a reemplazar ese módulo pronto. El riesgo de romper supera el beneficio.

¿Puede el modelo hacer el refactor completo?

Sí, pero por pasos y revisando cada uno. Un refactor de 800 líneas en una sola respuesta es imposible de revisar de verdad.

Siguiente

También te puede servir

Esta página la ha preparado el equipo editorial de CopyPromt y se publicó por primera vez el 25 octubre 2026. Los prompts están escritos para funcionar en varios modelos; los nombres de marca se citan solo a modo de identificación.