Clean Code en la era de la IA: qué principios permanecen y cuáles se desplazan

Clean Code designa un código fuente que se entiende al leerlo: nombres expresivos, unidades pequeñas, responsabilidades claras, pocas repeticiones. Con la asistencia de la IA, este objetivo gana importancia en lugar de perderla, porque el código que nadie lee por haber sido generado es precisamente el que debe ser comprensible en cuanto algo sale mal por primera vez.

¿Qué es Clean Code?

El término se popularizó con el libro homónimo de Robert C. Martin y describe una actitud, no una norma: el código se lee con mucha más frecuencia de lo que se escribe, por lo que la legibilidad es la cualidad más importante después de la corrección.

De ahí se derivan las reglas conocidas: nombres significativos, funciones pequeñas con una sola tarea, ningún comentario superfluo, ninguna repetición, tratar los errores en lugar de tragárselos. Ninguna de ellas es medible, y esa es la objeción habitual. La objeción se desvía del propósito: son heurísticas para una pregunta que solo puede responderse al leer.

¿Siguen vigentes las reglas de Clean Code cuando la IA escribe el código?

Rigen con más fuerza, porque el destinatario ha cambiado. Antes se escribía de forma legible para el compañero. Hoy se escribe de forma legible para tres lectores, de los cuales dos son nuevos.

• La persona en la revisión. Tiene menos tiempo por línea, porque llegan más líneas. El código poco claro no se examina durante más tiempo, sino que se aprueba sin más.
• El modelo en el siguiente cambio. Un modelo de lenguaje lee su base existente como contexto y continúa lo que encuentra en ella. Una estructura clara y nombres inequívocos actúan así doblemente: sobre la persona y sobre la siguiente generación.
• La persona en caso de incidencia. A las tres de la madrugada, sin acceso al historial de chat en el que se creó el código.

¿Qué principios cobran más importancia?

Cuatro, y los cuatro responden a patrones documentados del código generado.

• Ninguna repetición. El principio más importante del presente, porque los duplicados aumentan de forma medible desde la llegada de la asistencia de IA (las cifras al respecto). Donde se duplica sin que nadie lo note, la regla deja de ser una cuestión de estilo.
• Explícito antes que implícito. Un modelo adivina ante la ambigüedad. Los tipos inequívocos, las firmas claras y las constantes con nombre reducen aquello sobre lo que se puede adivinar.
• Tratar los errores, no tragárselos. El bloque catch vacío es una infracción clásica de Clean Code y, desde 2025, una categoría propia de OWASP (A10).
• Unidades pequeñas y verificables. Lo que se lee de un tirón se lee de verdad en la revisión. Una función de 400 líneas se lee por encima, con independencia del cuidado del revisor.

¿Qué principios se desplazan?

Tres, en los que la antigua justificación ya no se sostiene, aunque la regla permanezca.

• Comentarios. La antigua regla decía: el buen código no necesita comentarios. Sigue siendo cierto para el qué. Para el porqué, el peso se ha desplazado: en el código generado falta la persona que podría explicar la decisión. Una frase que diga por qué se eligió esta solución vale hoy más que antes.
• Funciones auxiliares escritas por uno mismo. Antes se decía: no construya usted mismo lo que existe como biblioteca. Hoy se añade una ponderación, porque cada dependencia adicional es una decisión de cadena de suministro; desde 2025, categoría propia de OWASP (A03). Incorporar un paquete para veinte líneas ya no es automáticamente la opción más económica.
• Generalización prematura. La regla «no construya para casos que no existen» sigue siendo acertada, pero se infringe con más frecuencia: a los modelos les gusta incluir interruptores de configuración y capas de abstracción por adelantado.

¿Cómo hago cumplir Clean Code cuando se genera mucho código?

No mediante formaciones, sino en los tres puntos donde nace el código.

• Antes de la generación: dejar las convenciones del proyecto donde la herramienta las lee. Esquemas de nombres, estructura de directorios, tratamiento de errores, funciones auxiliares existentes. Un modelo respeta las convenciones que conoce.
• Después de la generación: lo que puede comprobarse automáticamente se comprueba automáticamente: formato, complejidad, duplicados, importaciones muertas. Véase análisis estático de código.
• En la revisión: plantear justo las preguntas que ninguna herramienta responde. ¿Ya existe esto? ¿Es correcto el nombre? ¿Se entiende la decisión? Véase revisión de código para código de IA.

Preguntas frecuentes sobre Clean Code

¿No es Clean Code cuestión de gustos?

Las reglas concretas, en parte sí: longitud de línea, colocación de llaves, convenciones de nombres. El fondo no: si una función puede describirse en una frase sin «y» se responde sin juicio de gusto, y esa sola pregunta cubre buena parte de las reglas.

¿Escribe la IA código limpio?

Formalmente, a menudo sí: nomenclatura coherente, estructura convencional, comentarios presentes. Estructuralmente, con frecuencia no, porque al modelo le falta la visión de conjunto: duplica lo que no conoce y generaliza lo que nadie ha pedido. Limpio en lo pequeño, sucio en el conjunto.

¿Sigue mereciendo la pena el libro de Robert C. Martin?

Como escuela de pensamiento, sí; algunos ejemplos han envejecido y partes se discuten con controversia desde el punto de vista técnico. Si se queda con una sola cosa, que sea la pregunta de cuántas veces se leerá este código.

¿Cómo convenzo a un equipo que quiere entregar rápido?

No con la estética, sino con el tiempo de revisión. El código poco claro cuesta tiempo de nuevo en cada revisión y, con un volumen de código creciente, ese se convierte en el cuello de botella, no la escritura.

Las convenciones solo funcionan si la herramienta las conoce antes de escribir. Code Guardian trabaja exactamente así: primero mira qué hay ya en el proyecto, luego construye, y después un audit que señala la redundancia en el diff.

Fuentes

• Robert C. Martin, Clean Code (origen del término y de la colección de reglas).
• GitClear, The Maintainability Gap: 2026 AI Code Quality Research.
• OWASP Top 10:2025, categorías A03 y A10.

Actualizado a 27 de julio de 2026. Clasificación técnica general.