Prompts de IA para Clean Code: identifica código espagueti y evítalo con Vibe Coding

Si te enfrentas al problema del código espagueti, la IA es una herramienta poderosa. En nuestro artículo Evitar código espagueti explicamos los fundamentos. Aquí te mostramos cómo usar prompts de IA dirigidos y pequeños scripts de validación para analizar tu proyecto, refactorizar según Clean Code, SOLID y OOP, y crear unit tests sólidos. También abordaremos Vibe Coding, pues precisamente ahí emerge rápidamente código difícil de seguir.

Vibe Coding y el riesgo del código espagueti

Vibe Coding significa generar código rápidamente con asistentes de IA como GitHub Copilot, ChatGPT o Claude. Funciona notablemente bien para prototipos y features pequeños. El problema: la IA optimiza para código funcional, no para mantenibilidad. Si aceptas cada sugerencia sin revisión, se acumulan funciones largas, duplicados y dependencias opacas.

El código espagueti no surge automáticamente de Vibe Coding, pero el riesgo aumenta significativamente si no preguntas deliberadamente por Clean Code, SOLID y estructuras testables. La solución es un flujo de trabajo que combina análisis automático, objetivos claros en los prompts y revisión manual.

Analiza tu proyecto automáticamente en busca de código espagueti

Antes de consultarle a la IA, necesitas saber dónde están los mayores problemas. Un pequeño script en Node.js busca en tu proyecto señales de alerta típicas.

// scripts/analyze-spaghetti.js
const fs = require('fs');
const path = require('path');

const TARGET_DIR = process.argv[2] || 'src';
const EXTENSIONS = ['.js', '.ts', '.jsx', '.tsx'];
const issues = [];

function scanDir(dir) {
  fs.readdirSync(dir, { withFileTypes: true }).forEach(entry => {
    const full = path.join(dir, entry.name);
    if (entry.isDirectory()) scanDir(full);
    else if (EXTENSIONS.includes(path.extname(full))) analyzeFile(full);
  });
}

function analyzeFile(file) {
  const lines = fs.readFileSync(file, 'utf8').split('\n');
  let functionStart = null;
  let braceDepth = 0;

  lines.forEach((line, index) => {
    const trimmed = line.trim();

    if (/^\s*(function\s+\w+|const\s+\w+\s*=|async\s+function|=>)/.test(line)) {
      functionStart = index;
    }

    braceDepth += (line.match(/\{/g) || []).length;
    braceDepth -= (line.match(/\}/g) || []).length;

    if (functionStart !== null && braceDepth === 0 && trimmed === '}') {
      const length = index - functionStart;
      if (length > 30) issues.push(`${file}:${functionStart + 1} - Función de aprox. ${length} líneas`);
      functionStart = null;
    }

    if (/^\s*if\s*\(.*\)\s*\{\s*$/.test(line)) {
      const next = lines.slice(index + 1, index + 4).join('\n');
      const nested = (next.match(/\n\s*if\s*\(/g) || []).length;
      if (nested > 0) issues.push(`${file}:${index + 1} - bloques if anidados`);
    }

    if (/\bvar\b/.test(line)) issues.push(`${file}:${index + 1} - se usa var`);
    const todoMatch = line.match(/(TODO|FIXME|HACK)\b/);
    if (todoMatch) issues.push(`${file}:${index + 1} - ${todoMatch[1]} encontrado`);
  });
}

scanDir(TARGET_DIR);
if (issues.length === 0) console.log('No se encontraron señales evidentes de código espagueti.');
else issues.forEach(i => console.log(i));

El script es deliberadamente simple. Para sistemas en producción es mejor complementarlo con ESLint, SonarQube o Codacy. Sin embargo, te muestra rápidamente los puntos críticos que puedes abordar con IA.

De la advertencia al Clean Code

Cuando el script marca una ubicación, copias el código afectado en un asistente de IA y lo trabajas con los prompts de abajo. El flujo de trabajo típico es:

Encontrar el punto crítico
Describir la responsabilidad
Usar prompts para nombres expresivos, funciones pequeñas y tests
Verificar el resultado según Clean Code, SOLID y OOP
Agregar unit tests

Los siguientes apartados te proporcionan un prompt directamente copiable para cada área importante. Distinguimos entre prompts para bloques de código individuales y prompts que consideran el proyecto completo.

Principios de Clean Code y prompts

En el artículo Principios de Clean Code explicamos las reglas. Para trabajar con IA es importante formular estas reglas como objetivos concretos en el prompt. Aquí encontrarás un prompt para cada principio importante de Clean Code.

Nombres significativos

Los buenos nombres reemplazan muchos comentarios. Pídele a la IA explícitamente que elimine variables como x, data o tmp.

Eres un desarrollador de software experimentado. Analiza el siguiente código en busca de nombres de variables, funciones y clases poco claros. Sugiere una alternativa mejor para cada nombre y explica por qué el nuevo nombre mejora la legibilidad. Asegúrate de que los nombres describan intenciones y responsabilidades.

Código:
{{CODE}}

Funciones pequeñas

Las funciones largas son una característica principal del código espagueti. Cada función debe hacer una sola cosa e idealmente caber en pantalla.

Eres un desarrollador de software experimentado. Refactoriza el siguiente código para que cada función tenga máximo una responsabilidad y quepa en pantalla. Extrae funciones auxiliares, usa nombres expresivos y elimina las condiciones profundamente anidadas mediante Early Returns o Guard Clauses. Devuelve el código refactorizado.

Código:
{{CODE}}

Principio DRY

DRY significa Don’t Repeat Yourself. La IA frecuentemente genera patrones duplicados. Un prompt los encuentra y los elimina.

Eres un desarrollador de software experimentado. Identifica en el siguiente código la lógica duplicada y consolídala en funciones, clases o constantes reutilizables. Explica dónde se viola DRY y cómo tu solución mejora la mantenibilidad.

Código:
{{CODE}}

Principio KISS

KISS significa Keep It Simple, Stupid. El camino más simple suele ser el mejor.

Eres un desarrollador de software experimentado. Simplifica el siguiente código aplicando el principio KISS. Elimina abstracciones innecesarias, bucles superfluos o condiciones complicadas. El código debe mantener el mismo comportamiento pero ser lo más simple y autoexplicativo posible.

Código:
{{CODE}}

Buenos comentarios

Los comentarios deben explicar el por qué, no el qué. Los comentarios malos ocultan código deficiente.

Eres un desarrollador de software experimentado. Revisa el siguiente código en busca de comentarios significativos. Elimina los comentarios redundantes o desactualizados, agrega comentarios que falten explicando el por qué, y mejora el código donde debería ser autoexplicativo. Devuelve el código revisado.

Código:
{{CODE}}

Formato consistente

El formato consistente reduce la carga cognitiva. Este prompt limpia el estilo y el tipo de variables.

Eres un desarrollador de software experimentado. Formatea el siguiente código de manera consistente según las convenciones habituales. Presta atención a indentación, espacios en blanco, paréntesis y saltos de línea. No uses var, prefiere const y let, y mantén las comillas consistentes.

Código:
{{CODE}}

Tratamiento de errores

Los errores silenciosos, los bloques catch vacíos y los mensajes poco claros son código espagueti en los casos de error.

Eres un desarrollador de software experimentado. Mejora el tratamiento de errores en el siguiente código. Usa mensajes de error significativos, evita bloques catch vacíos, valida las entradas temprano y utiliza Guard Clauses. Devuelve el código mejorado.

Código:
{{CODE}}

Crear Unit Tests con IA

Los unit tests verifican de forma aislada la unidad más pequeña de un programa, generalmente una función o método. No solo aseguran el comportamiento, sino que también te obligan a estructurar el código de manera testeable. El código testeable suele ser código mejor estructurado.

Al escribir tests, presta atención a una estructura clara de Arrange-Act-Assert, nombres de test significativos y cobertura de casos normales, casos límite y errores. Reemplaza las dependencias externas como bases de datos o APIs con mocks o stubs.

Eres un desarrollador de software experimentado. Escribe unit tests para el siguiente código. Presta atención a una estructura clara de Arrange-Act-Assert, casos de test significativos para casos normales, casos límite y errores. Mockea las dependencias externas y utiliza nombres de test significativos. Devuelve el código de test.

Código:
{{CODE}}

Cuándo usar cada prompt

No todos los prompts se adaptan a todas las situaciones. Aquí hay una orientación simple sobre cuándo usar cada grupo.

Prompts de detalle de código: Úsalos para funciones o archivos individuales que llamen tu atención. Son especialmente útiles cuando estás trabajando en una característica y quieres mejorar rápidamente la legibilidad, los nombres o el tratamiento de errores.
Prompts de unit tests: Aplícalos una vez que hayas refactorizado una función. Los tests aseguran el comportamiento y te obligan a un diseño testeable.
Auditorías de seguridad: Realízalas antes de releases, después de cambios importantes o cuando introduzcas nuevas características que procesen entrada de usuarios.
Auditorías de arquitectura: Úsalas cuando el proyecto se vuelve difícil de extender, la deuda técnica crece o planificas una sesión de refactoring.
Enfoque iterativo en proyectos grandes: Divide las codebases grandes en paquetes, capas o características. Deja que la IA analice áreas sucesivamente y resume los resultados al final.

Auditorías de seguridad con IA

Descubrirás las vulnerabilidades de seguridad en código generado por IA de la forma más confiable si examinas el proyecto paso a paso. Los siguientes prompts cubren diferentes perspectivas.

1. Análisis de seguridad completo

Eres un auditor de seguridad experimentado.

Analiza el proyecto completo en busca de vulnerabilidades de seguridad.

Busca especialmente:

- SQL Injection
- Command Injection
- Remote Code Execution (RCE)
- Local File Inclusion (LFI)
- Remote File Inclusion (RFI)
- Path Traversal
- Cross Site Scripting (XSS)
- Cross Site Request Forgery (CSRF)
- Server Side Request Forgery (SSRF)
- Authentication Bypass
- Problemas de autorización
- Session Hijacking
- Almacenamiento inseguro de contraseñas
- Information Disclosure
- Hardcoded Secrets
- Criptografía insegura
- Race Conditions

Para cada vulnerabilidad encontrada proporciona:

- Nombre del archivo
- Número de línea
- Descripción
- Ejemplo de ataque
- Nivel de riesgo (Low/Medium/High/Critical)
- Sugerencia concreta de mejora

2. Busca problemas ocultos

Busca exclusivamente problemas de seguridad sutiles.

Ignora estilo y calidad de código.

Concéntrate en errores lógicos que un atacante podría explotar.

Busca especialmente:

- verificaciones de permisos faltantes
- problemas de límites de confianza
- entrada de usuario sin validación
- valores por defecto peligrosos
- problemas TOCTOU
- escalada de privilegios
- omisión de comprobaciones de permisos

3. Prueba de penetración desde la perspectiva de un atacante

Ponte en el papel de un tester de penetración.

Intenta encontrar exclusivamente ataques contra la aplicación.

Crea para cada vulnerabilidad:

- Escenario de ataque
- Ejemplo de solicitud
- Requisitos previos
- Impacto
- Estimación CVSS

4. Busca todos los lugares con entrada de usuario

Lista todos los lugares donde se procesa entrada de usuario.

Muestra:

- Fuente de la entrada
- Procesamiento
- Validación
- Escaping
- Accesos a base de datos
- Accesos a archivos
- Llamadas shell
- Accesos de red

Evalúa cada lugar en términos de riesgo.

5. Busca funciones peligrosas

Busca en todo el proyecto funciones potencialmente peligrosas.

Ejemplos:

eval
exec
system
shell_exec
popen
proc_open
passthru
include
require
require_once
fopen
unlink
rename
move_uploaded_file

Verifica cada uso en busca de posibilidades de abuso.

(Por supuesto, puedes adaptar esta lista al lenguaje de programación que uses.)

6. OWASP Top 10

Verifica el proyecto completamente según el OWASP Top 10 actual.

Crea una tabla:

Categoría OWASP
archivos afectados
Descripción
Riesgo
Medidas recomendadas

7. Análisis de API

Si el sitio tiene APIs:

Analiza todos los endpoints de la API.

Verifica:

- autenticación faltante
- autorización faltante
- IDOR
- Rate Limiting
- Mass Assignment
- Injection
- Input Validation

8. “Piensa como un hacker”

Este suele ser mi prompt favorito:

Piensa como un atacante experimentado.

¿Cuáles serían las tres vulnerabilidades que explotarías primero?

Describe paso a paso:

- por qué
- cómo
- perspectivas de éxito
- posibles impactos

9. Reducir falsos positivos

Muy útil:

Reporta solo vulnerabilidades que probablemente sean realmente explotables.

Si no estás seguro, márcalas explícitamente como suposición.

Sin hallazgos teóricos o especulativos.

10. Segunda revisión

Después de que Claude haya encontrado algo:

Revisa tu propio análisis críticamente.

Busca:

- Falsos positivos
- vulnerabilidades de seguridad pasadas por alto
- errores lógicos
- nuevas posibilidades de ataque

Luego crea el reporte de seguridad final.

Un consejo adicional

Si el proyecto es más grande (por ejemplo, varios miles de archivos), comienza con una descripción general de la arquitectura en lugar de buscar inmediatamente vulnerabilidades:

Analiza primero la arquitectura del proyecto.

Identifica:

- Lenguaje(s) de programación
- Framework(s)
- Autenticación
- Accesos a base de datos
- Funciones de carga
- Áreas de administración
- Endpoints de API
- Operaciones de archivo
- Dependencias externas

Luego crea un plan para una auditoría de seguridad completa y ejecútalo paso a paso.

Esto le da a Claude Code una mejor visión general y frecuentemente resulta en auditorías más exhaustivas que un único prompt de “verifica todo”. Lo importante es: Una auditoría de LLM no reemplaza herramientas especializadas (por ejemplo, escanners SAST, de dependencias o DAST), sino que las complementa. Obtendrás los mejores resultados si combinas ambos.

Igualmente importante es una revisión arquitectónica en toda la ejecución. Prompts individuales como “Verifica SOLID” suelen proporcionar solo consejos generales. Es mejor que trabajes con auditorías específicas.

Auditorías de arquitectura, Clean Code y SOLID

Los siguientes prompts te ayudan a verificar el proyecto completo en términos de mantenibilidad, lógica duplicada y SOLID/OOP. Complementan los prompts de detalle de código de la sección anterior y consideran el proyecto como un todo.

1. Revisión completa de la arquitectura

Eres un arquitecto de software experimentado.

Analiza todo el proyecto en relación con:

- Clean Code
- OOP
- SOLID
- DRY (Don't Repeat Yourself)
- KISS
- YAGNI
- Separation of Concerns
- High Cohesion
- Low Coupling

Primero, crea un resumen de la arquitectura.

Después, identifica todos los lugares que violan estos principios.

Para cada problema proporciona:

- Archivo
- Clase
- Método
- Descripción
- Justificación
- Sugerencia de mejora
- Prioridad (Baja/Media/Alta)

2. Encuentra lógica duplicada (mi favorito)

Esto es exactamente lo que describiste.

Analiza todo el proyecto para encontrar lógica duplicada.

Busca específicamente:

- funciones idénticas
- métodos casi idénticos
- código copiado
- lógica de negocio igual
- cálculos implementados múltiples veces
- validaciones duplicadas
- lógica de base de datos duplicada
- llamadas a API múltiples

Muestra en cada caso:

- ambos archivos
- ambos métodos
- grado de similitud en %
- cuál debería ser la base común
- cómo se pueden fusionar los duplicados

Ignora las diferencias en nombres de variables.

3. Verifica los principios SOLID uno por uno

Revisa cada clase individualmente según los principios SOLID.

Para cada clase responde:

Responsabilidad única:
¿Tiene la clase más de una responsabilidad?

Abierto/Cerrado:
¿Hay que modificar código en lugar de extenderlo?

Liskov:
¿Son las herencias correctas?

Segregación de interfaces:
¿Son las interfaces demasiado grandes?

Inversión de dependencias:
¿Se usan clases concretas en lugar de abstracciones?

Proporciona sugerencias de mejora concretas.

4. Clases con demasiadas responsabilidades

Busca God Classes.

Reconoces una God Class por características como:

- más de 500 líneas
- muchos métodos
- conoce muchas otras clases
- contiene lógica de negocio, UI y acceso a base de datos simultáneamente
- posee muchas variables miembro

Propón una división sensata.

5. Métodos deficientes

Busca métodos que violen Clean Code.

Ejemplos:

- más de 30 líneas
- múltiples responsabilidades
- anidamiento profundo
- muchos parámetros
- muchas banderas booleanas
- lógica duplicada

Propón refactorizaciones.

6. Verifica responsabilidades

Analiza cada clase.

Describe en una oración su responsabilidad real.

Si una clase tiene múltiples responsabilidades,
muestra exactamente cuáles son.

Después propón una división sensata.

7. Dependencias

Crea un diagrama de dependencias del proyecto.

Marca:

- dependencias cíclicas
- dependencias innecesarias
- acoplamiento fuerte
- violaciones de inversión de dependencias

Propón mejoras.

8. Verifica herencias

Analiza todas las herencias.

Revisa:

- herencia innecesaria
- ¿debería usarse composición?
- violaciones de Liskov
- implementaciones duplicadas

Propón alternativas mejores.

9. Plan de refactorización

Este suele ser el prompt más útil.

Crea un plan de refactorización completo.

Ordena todos los problemas por prioridad.

Para cada problema describe:

- por qué existe
- qué regla SOLID se viola
- cómo debería verse la clase después del refactoring
- qué archivos se ven afectados
- esfuerzo (pequeño/medio/grande)

Objetivo:

- menos código
- sin lógica duplicada
- mejor mantenibilidad
- mejor testabilidad

10. Revisión de arquitectura rigurosa

Actúa como un Senior Software Architect en una revisión de código.

Sé crítico.

No aceptes lógica duplicada.

No aceptes clases con múltiples responsabilidades.

No aceptes soluciones de copiar y pegar.

Muestra todos los lugares que cambiarías antes de mergear a la rama principal.

Prioriza los problemas más importantes primero.

Un consejo más

Si tu proyecto ya es bastante grande (por ejemplo, más de 20.000 líneas de código), puedes dar a Claude Code este encargo adicional:

Trabaja de forma iterativa.

Recorre archivo por archivo.

Después de cada archivo, crea una lista de los problemas encontrados.

Al final, resume todos los resultados.

Si encuentras métodos similares en diferentes archivos, compáralos entre sí y verifica si pueden fusionarse en una función común o una clase base.

Busca explícitamente violaciones de DRY y lógica de negocio implementada múltiples veces.

Precisamente esta última frase es importante: por defecto, Claude evalúa los archivos de forma aislada. Al dar la instrucción explícita de buscar lógica idéntica o similar en múltiples archivos, detecta implementaciones duplicadas y oportunidades de centralización mucho más confiablemente.

Flujo de trabajo de ejemplo para una sesión de refactorización

Imagina que tomas un proyecto con mucho código generado por IA. Así podría verse un día de trabajo:

Ejecuta node scripts/analyze-spaghetti.js src y recoge los puntos críticos.
Copia las funciones más problemáticas en los prompts de detalle de código para nombres, formato y manejo de errores.
Genera pruebas unitarias para los puntos modificados.
Si encuentras duplicados o clases grandes que cruzan límites de archivos, inicia los auditorías de arquitectura.
Crea un plan de refactorización y trabájalo por prioridad.
Antes de mergear o hacer release, realiza las auditorías de seguridad.
Revisa manualmente todos los sugerencias de IA. La IA te ayuda a encontrar problemas, pero tú decides sobre la solución.

Conclusión

La IA y el code generation son herramientas excelentes cuando sabes qué preguntar. Obtienes los mejores resultados cuando primero identificas código spaghetti con un script simple y después lo limpias con prompts específicos sobre Clean Code, SOLID, OOP y Unit Tests. De esta forma, la IA sigue siendo un acelerador en lugar de un riesgo para la calidad de tu código.

Recomendaciones de libros

Estos libros te acompañan en el tema de Clean Code y desarrollo profesional de software.

Keine Bücher für Kategorie "software-engineering" gefunden.

Täglicher Artikel