Detectar y corregir code smells: los diez más frecuentes en el código generado por IA

Un code smell es un punto del código fuente que funciona y, aun así, señala un problema más profundo. El término procede de Kent Beck y Martin Fowler. En el código generado por IA ciertos smells aparecen con una frecuencia superior a la media, porque el modelo ve el fragmento que debe modificar, pero no el código existente en el que escribe.

¿Qué es un code smell?

Un code smell es un motivo de sospecha, no un defecto. El código se ejecuta, las pruebas están en verde y, aun así, la estructura indica que la próxima modificación en ese punto será incómoda.

Es importante delimitarlo: un smell no es una infracción de regla que se pueda corregir automáticamente. Algunos smells están bien donde están — duplicados deliberados entre dos módulos que deben evolucionar de forma independiente, por ejemplo. Una herramienta puede señalar la sospecha; si se confirma lo decide quien conoce el contexto.

¿Qué code smells aparecen con más frecuencia en el código generado por IA?

Diez patrones, ordenados según lo caros que resultan más adelante.

• Lógica duplicada. El mismo comportamiento en varios lugares. Con diferencia el smell más frecuente y más caro, y el único cuyo aumento puede medirse a lo largo de los años — véase la deuda técnica por código de IA.
• Implementación paralela. Una nueva función auxiliar junto a la existente, que hace lo mismo, porque el modelo no conocía la que ya había.
• Función demasiado larga. El código generado tiende a escribir el flujo completo en una sola función, porque así estaba descrito en el prompt.
• Error silenciado. Bloque catch vacío o un valor por defecto que hace que un fallo parezca un éxito. Desde 2025, categoría propia de OWASP (A10).
• Valores mágicos. Números y cadenas de texto directamente en el código, cuyo significado solo se deduce del contexto.
• Generalización especulativa. Un interruptor de configuración, una interfaz, una capa de abstracción para un caso que no existe. A los modelos les gusta construir «por si acaso, para más adelante».
• Comentario en lugar de claridad. Un comentario que describe lo que hace la línea siguiente. No sustituye a un nombre comprensible y se vuelve falso en la próxima reforma.
• Grumos de datos. Los mismos cinco parámetros viajan a través de seis funciones en lugar de estar agrupados en un objeto.
• Restos sin uso. Importaciones, variables, funciones de un estado intermedio descartado.
• Prueba sin aserción. Una prueba que ejecuta código y no comprueba nada. Genera cobertura y ninguna seguridad — véase Medir la calidad del código.

¿Cómo encuentro code smells en mi proyecto?

Una herramienta encuentra seis de los diez patrones anteriores; para los otros cuatro necesita a una persona. La separación merece la pena, porque ahorra tiempo de revisión.

• Detectables por máquina: duplicados, funciones demasiado largas, errores silenciados, valores mágicos, restos sin uso, pruebas sin aserción. De ello se encarga el análisis estático de código.
• Detectables solo por una persona: implementación paralela (presupone conocer el código existente), generalización especulativa (presupone conocer los requisitos), comentario en lugar de claridad, grumos de datos.

Precisamente los cuatro humanos son los que aumentan con el código de IA — y los más difíciles de ver en el diff, porque la contraparte está en otro archivo.

¿Cómo corrijo un code smell sin romper nada?

En cuatro pasos, y el primero es el que con más frecuencia se omite.

• Primero, asegurar. Antes de reformar un punto, debe existir una prueba que fije el comportamiento actual. Sin esa prueba, cada reforma es una apuesta.
• Una sola cosa por paso. Fusionar el duplicado y dividir la función y cambiar los nombres da como resultado un diff que nadie puede revisar.
• Dejar el comportamiento sin cambios. Un refactoring que corrige un error de paso deja de ser un refactoring. La corrección de errores es un commit aparte.
• Comprobar después de cada paso. Ejecución de pruebas en verde y, después, el siguiente paso.

Cómo se ve esto en concreto con código generado lo describe el artículo Refactoring de código generado por IA.

¿Merece la pena corregir todos los smells?

No — y esta es la frase más importante sobre el tema. Un smell en código que nunca se volverá a tocar no cuesta nada. El esfuerzo de corregirlo siempre cuesta.

La priorización sensata combina dos magnitudes, ambas legibles en el repositorio: cuántas veces se modificó este archivo en los últimos meses y qué complejidad tiene. Lo que queda arriba a la derecha — modificado con frecuencia y complejo — merece atención. El resto puede oler mal.

Preguntas frecuentes sobre los code smells

¿Es un code smell lo mismo que un bug?

No. Un bug es un comportamiento incorrecto. Un smell es un comportamiento correcto en una estructura que dificulta futuras modificaciones. Un smell puede permanecer años sin consecuencias.

¿Reconoce una IA los code smells de forma fiable?

En los patrones detectables por máquina sí, a menudo mejor que un motor de reglas, porque lee también el contexto. En las implementaciones paralelas no es fiable, porque le falta precisamente la visión de conjunto que hace visible el smell — a menos que la herramienta explore activamente el código existente antes de escribir.

¿Cuántas líneas puede tener una función?

No existe un límite normalizado, y cualquier cifra que se mencione es una convención. Más sólida es la pregunta de si la función puede describirse en una frase sin «y». Si la descripción necesita una «y», la función hace dos cosas.

¿Debería corregir los smells antes de construir una funcionalidad?

Solo allí donde se integrará la funcionalidad. Ordenar en el entorno de la propia modificación es barato y se revisa, porque de todos modos forma parte de la revisión. Una limpieza generalizada como proyecto aparte rara vez encuentra a quien la encargue.

Los cuatro smells que ninguna herramienta encuentra nacen todos en el mismo punto: allí donde nadie ha comprobado lo que ya existe. Code Guardian plantea precisamente esa pregunta antes de la primera línea: ¿qué función, qué helper, qué consulta existe ya?

Fuentes

• Martin Fowler, Refactoring (origen y catálogo de los code smells, junto con Kent Beck).
• GitClear, The Maintainability Gap: 2026 AI Code Quality Research (proporción de copiar y pegar).
• OWASP Top 10:2025, categoría A10 «Mishandling of Exceptional Conditions».

Fecha: 27 de julio de 2026. Valoración técnica de carácter general.