¿Importa el clean code cuando la IA escribe el código?

El código ya no lo tiene que mantener un humano. Entonces, ¿para qué el clean code?

MARCO FUCCI DI NAPOLI
Co-founder rowads.studio

La encontré en un post de LinkedIn de Marco Fucci di Napoli, fundador de Rowads Studio, un equipo de cinco personas que abandonó completamente las code reviews al adoptar lo que llaman extreme Claude Coding. Su métrica de progreso: el request to live time, el tiempo desde que se pide una funcionalidad hasta que está en producción. Si no está en prod, no hay valor.

Me cautivaron especialmente dos ideas.

• Primera: si el código ya no necesita ser mantenido por un humano, ¿qué sentido tiene el clean code?
• Segunda: el request to live time no es un concepto nuevo, es el viejo principio de que si no está en producción no hay valor, actualizado al ritmo de los agentes.

El planteamiento me pareció tan sugerente que lo compartí con el equipo en Slack. La reacción fue inmediata: en menos de una hora, tres compañeros habían entrado al hilo a rebatir, matizar y ampliar la pregunta. Lo que siguió fue una conversación lo suficientemente interesante como para trascender el canal y acabar convertida en este post.

El argumento a favor: menos fricción, más producto en vivo

El razonamiento parecía sólido. Si la IA escribe el código, el cuello de botella deja de estar en la implementación y pasa a estar en la toma de decisiones de producto. En ese contexto, una code review que tarda dos días en desbloquearse tiene un coste real: el request to live time se dispara y el valor llega tarde.

Kevin Martínez lo matizó con algo que comparto: el esfuerzo debería desplazarse hacia lo que antes no teníamos tiempo de hacer, no hacia sacar más funcionalidades sin parar. Durante años, cosas como los tests de carga, la accesibilidad (a11y), la auditoría de seguridad o los Core Web Vitals quedaban en el backlog con la excusa de «no me da la vida». Con herramientas como Claude generando implementaciones en minutos, esa excusa desaparece.

Kevin lo resumió con unas preguntas que deberían tener respuesta en cualquier equipo de ingeniería hoy:

• ¿Tienes tests de carga en tus APIs críticas?
• ¿Está la accesibilidad auditada en el front?
• ¿Hay observabilidad real en producción, no solo logs?
• ¿Has revisado los Core Web Vitals del último trimestre?

Si la respuesta a alguna de estas es «no, porque no teníamos tiempo», la IA acaba de quitarte esa excusa. La pregunta ya no es «¿puedo hacerlo?», sino «¿sé lo suficiente para pedirlo bien y validarlo?». Ese matiz cambia dónde debería invertir tiempo un equipo de ingeniería: el valor del trabajo no desaparece, se desplaza.

Lo que no me convence —y creo que el propio post de Fucci di Napoli lo reconoce implícitamente— es la idea de que más features equivalen a mejor producto. Los agentes pueden escribir código más rápido, pero la calidad de las decisiones de producto sigue siendo responsabilidad humana.

Clean code con IA: ¿patrón de diseño o consumo innecesario de tokens?

En ese punto la conversación tomó un giro más técnico, e incómodo para quienes llevamos años aplicando arquitectura hexagonal como estándar de calidad.

De ahí surgió la hipótesis de Kevin, formulada sin rodeos: una base de código organizada en veinte capas de abstracción le cuesta más a la IA que una implementación simple y directa. Cuando un agente tiene que saltar entre interfaces, repositorios, casos de uso, adaptadores y DTOs para entender qué hace una funcionalidad, el consumo de tokens se multiplica. Y con él, la latencia y el coste.

Para comprobarlo, Kevin tenía en mente un experimento concreto: el mismo cambio, aplicado sobre una arquitectura hexagonal típica y sobre una implementación KISS (Keep It Simple, Stupid) o YAGNI (You Aren’t Gonna Need It). Su predicción: el consumo de tokens sería al menos un 100% mayor en el enfoque clean code.

Lo que sí sigue siendo relevante —quizás más que nunca— es la legibilidad para el agente. No es lo mismo que la legibilidad para humanos, pero tampoco es opuesta. Un código que describe con claridad su intención es más fácil de modificar para la IA que uno lleno de abstracciones implícitas.

Si algo es complicado para nosotros, para el agente también lo será.

KEVIN MARTÍNEZ
Software architect en Orbitant

Carlos Jiménez planteó la otra cara: «¿Puedes dormir bien sabiendo que la IA ha implementado un if-else hell?» Es una pregunta legítima. Hoy, muchos todavía necesitamos entender y auditar lo que el agente produce. Pero Carlos fue más lejos: puede que en el futuro las IAs inventen su propio lenguaje de abstracción, y entonces ni el clean code ni las best practices tendrán sentido en los términos que las conocemos hoy. Al tiempo.

Y hay un riesgo que Kevin nombró y que conviene no perder de vista: decir que sí a todo porque «con Claude se hace en cinco minutos» lleva directamente al producto Frankenstein. Features acumuladas sin coherencia, sin un porqué detrás, sin que nadie se haya preguntado si el usuario realmente necesitaba eso. La velocidad de implementación no reemplaza la claridad de producto. Si ya estás usando IA para escribir mejores tickets y definir funcionalidades con más precisión, vas un paso por delante.

¿Volvemos al monolito? Arquitectura, contexto y agentes

Probablemente la parte más contraintuitiva de toda la conversación, y la que más me ha hecho pensar: los microservicios podrían estar jugando en contra cuando el que desarrolla es un agente de IA.

Kevin lo lanzó sin rodeos: «hasta volveremos a los monolitos, porque con microservicios todo está separado y le cuesta más a la IA tener la imagen completa del sistema«. Carlos, que no suele ceder fácilmente en debates técnicos, lo respaldó de inmediato: «con tanto microservicio no es tan simple darle a la IA el contexto de toda la plataforma».

La implicación práctica es que los monorepos y, en cierta medida, los monolitos modulares, facilitan que el agente opere con más contexto en menos pasos. No es nostalgia de la arquitectura de hace diez años. La arquitectura que optimizamos para equipos humanos distribuidos puede no ser la óptima para equipos que trabajan con agentes. Kevin lo aceptó con resignación elocuente: aunque le duela, el monorepo parece tener sentido al fin.

Lo que sí se vuelve indispensable en sistemas distribuidos con IA en el ciclo de desarrollo es el contract testing. Si los servicios van a ser modificados por agentes de forma semi-autónoma, los contratos entre ellos son la única red de seguridad fiable. Sin ellos, una refactorización generada por IA puede romper integraciones sin que nadie lo detecte hasta producción. En arquitecturas distribuidas, el contract testing deja de ser una buena práctica para convertirse en un requisito.

Un flujo de trabajo emergente que Kevin está explorando es el TWD (Test-While-Developing): en lugar de escribir los tests después del desarrollo, se usan como mecanismo de comunicación con el agente durante el proceso. Los datos al comparar herramientas de testing son elocuentes:

1. TWD-relay: ~200–400 tokens por ejecución (~30 líneas, solo pass/fail + error)
2. Cypress: ~2.000–5.000 tokens (logs, capturas de pantalla, stack traces)
3. Playwright: ~1.500–4.000 tokens (informe HTML, trazas, logs verbosos)

El agente ejecuta y valida en tiempo real, con un consumo de tokens entre 5 y 10 veces menor que con las alternativas tradicionales. Una decisión de arquitectura que antes nadie habría priorizado se convierte, con IA en el ciclo, en un factor con impacto directo en coste y latencia.

Y hay una lección más en todo esto, que Kevin resumió con la claridad que tiene para las cosas obvias que nadie dice: lo que es difícil para humanos también es difícil para la IA. La complejidad no desaparece. Se traslada.

El happy path no es suficiente

Hay una última pieza en este debate que David Rueda trajo a la conversación, y que merece espacio propio porque es la que más fácilmente queda enterrada bajo el entusiasmo tecnológico.

Sobre el papel, con IA se puede implementar cualquier funcionalidad perfectamente. El problema, como apuntó David, es que trabajamos con usuarios reales, y los usuarios reales son impredecibles: no siguen el happy path, dan a un botón cuarenta veces porque se frustran, introducen datos en formatos inesperados, usan la herramienta de formas que nadie anticipó en el prompt. Para el happy path la IA está genial. El resto sigue siendo territorio humano.

Es una pregunta que conviene no pasar por alto. Los edge cases siguen siendo responsabilidad del equipo de ingeniería, no porque la IA no pueda detectarlos, sino porque identificarlos requiere un modelo mental del usuario que todavía no se delega bien a un agente. Saber qué puede salir mal es conocimiento de dominio y ese conocimiento sigue viviendo en las personas.

¿Qué pasa con los usuarios que dan a un botón 40 veces porque se frustran o no saben cómo usar la herramienta?

DAVID RUEDA
Software engineer en Orbitant

Esto tiene una implicación concreta: el tiempo que ganamos en implementación deberíamos reinvertirlo en definir escenarios límite antes de pedirle al agente que los resuelva, no después. Un agente que recibe un prompt claro con casos de error explícitos produce código mucho más robusto que uno al que simplemente le pedimos «implementa esta funcionalidad». La calidad del output sigue dependiendo de la calidad del input humano.

Hay, además, una dimensión de producto que la velocidad puede oscurecer: las funcionalidades que se entregan rápido también se acumulan rápido. Sin un proceso de revisión, de producto y no solo de código, un equipo puede llegar a producción con diez funcionalidades en dos semanas y descubrir que la mitad no resuelve el problema real del usuario. La observabilidad y el análisis de comportamiento real cobran aquí un valor que antes parecía opcional.

Eso no invalida la velocidad que aporta la IA. Significa que la velocidad hay que dirigirla bien. Y dirigirla bien sigue requiriendo criterio de ingeniería.

Volviendo a la pregunta del principio: ¿para qué el clean code si lo escribe la IA? La respuesta es más matizada de lo que parece. Las prácticas cambian de forma, no de propósito. Lo que antes servía para que otro humano pudiera entender y modificar tu código, ahora tiene que servir para que un agente pueda operar en él con eficiencia. El objetivo es el mismo. El destinatario, no tanto.

Lo que parece cambiar de verdad es dónde está el valor del trabajo de ingeniería, pero lo cierto es que dicho valor nunca residió en escribir código sino en solucionar un problema de negocio con una visión clara de producto respaldada por una definición concreta de ROI. Lo que cambia es que ahora el ingeniero no tiene más excusas para no entender el negocio al que quiere dar solución.