Buenas prácticas como interfaz para la IA: la paradoja del código limpio
Una mirada incómoda a cómo el código limpio desplaza el valor del desarrollo hacia contexto, criterio y diseño.
Buenas prácticas como interfaz para la IA: la paradoja del código limpio
Imagina dos proyectos:
- Un monolito viejo, sin tests, con capas y capas de parches y nombres de variables como
a1,tmpycosasFinalV2. - Un sistema modular, limpio, con buenos nombres, capas bien separadas, arquitectura hexagonal, tests decentes y documentación razonable.
Pregunta incómoda: ¿en cuál de los dos crees que una IA tendrá más fácil entrar, entender el contexto y empezar a producir cambios sin romper nada?
Exacto.
La paradoja
Cuanto mejor aplicamos las “buenas prácticas”, más fácil es para una IA automatizar una parte creciente de nuestro trabajo.
Las buenas prácticas como interfaz para la IA
Las buenas prácticas de desarrollo no son magia. Son:
- Estandarizar cómo escribimos código
- Reducir ambigüedad
- Hacer el sistema más legible, predecible y testeable
Eso es fantástico para devs humanos, pero también es perfecto para modelos de lenguaje.
Ejemplos claros
- Clean Code
- TDD y buena cobertura de tests
- Arquitecturas limpias y desacopladas
En cambio, un monolito espagueti
- No tiene tests (o no son fiables)
- Es inconsistente en estilos y patrones
- Mezcla negocio, infraestructura, vistas y parches históricos
A una IA le cuesta mucho más navegar ese caos. A un humano también. Pero el punto es este:
Las buenas prácticas reducen fricción tanto para humanos como para máquinas… y las máquinas mejoran cada mes.
No es que el clean code sea el problema. Es que cambia dónde aportas valor
La conclusión fácil sería: “Pues nada, volvamos al código espagueti para que la IA no nos sustituya”.
Absurdo.
El espagueti ya destruye valor hoy: retrabajo, bugs, burnout, costes ocultos. No es estrategia defensiva, es pegarse un tiro en el pie.
El punto importante es otro:
Las buenas prácticas desplazan el valor del desarrollador desde “escribir código” hacia “entender el problema y diseñar sistemas”.
Cuando el código es limpio:
- Cualquiera (humano o IA) puede añadir una feature sencilla guiándose por tests e interfaces.
- Los refactors locales se vuelven mecánicos.
- Generar boilerplate o adaptar patrones deja de ser diferencial.
Lo que no se vuelve trivial es:
- Entender qué problema merece la pena resolver.
- Negociar con negocio qué no hay que hacer.
- Diseñar límites del sistema, contratos y modelos de dominio.
- Medir el impacto real en usuarios.
- Navegar la organización y los trade-offs políticos/técnicos.
Ahí la IA ayuda, pero no lidera. Todavía.
La trampa del dev que se define por “picar código”
Si tu identidad profesional es:
“Soy quien convierte tickets en código limpio y testeado”
tienes un problema a medio plazo.
Porque:
- Los modelos ya generan código decente, cada vez más alineado con patrones y estilos de proyecto.
- Con buenos tests, linters y CI/CD, puedes montar un flujo donde la IA propone, el sistema verifica y un humano supervisa.
- El cuello de botella deja de ser “escribir la función” y pasa a ser “decidir qué función tiene sentido escribir”.
Dicho de otra forma:
Si tu ventaja competitiva es mecanizable, está en peligro.
¿Dónde puede seguir siendo valioso un desarrollador/a?
No se trata de rendirse, sino de mover la silla de sitio. Algunas direcciones claras:
1) Propietario de contexto, no de líneas de código
Quien entiende negocio, usuarios y restricciones legales/operativas tiene más poder que quien sólo domina el framework de moda.
2) Diseño de sistemas y modelos de dominio
Decidir bounded contexts, contratos entre servicios, modelos de datos, estrategias de consistencia. Esto no cabe en un snippet: es una conversación continua.
3) Curador de cambios, no “mono de teclado”
Revisar, cuestionar y orquestar cambios generados (por humanos o IA), asegurando alineamiento con la estrategia y la arquitectura global.
4) Conector entre mundos
Sentar a la misma mesa a negocio, legal, UX, operaciones y tecnología. Traducir entre lenguajes. Nunca fue una soft skill decorativa: es capacidad central.
5) Gestión del caos real
Integraciones con sistemas heredados, migraciones, datos sucios, procesos humanos. La realidad nunca es tan limpia como el diagrama inicial; navegar ese barro sigue siendo trabajo humano intensivo.
Buenas prácticas sí, pero con otra mentalidad
Sigo defendiendo:
- Clean code
- Buen diseño
- Tests automatizados
- Observabilidad
- Infra decente
Pero con otra lectura:
No solo como herramienta para que mi “yo del futuro” entienda el código.
También como infraestructura para que la IA trabaje para mí, no en mi contra.
Es decir:
- Uso IA para escribir el 70–80 % del código repetitivo.
- Yo me concentro en diseño, decisiones y conversación con el resto de la organización.
- El sistema de buenas prácticas se convierte en un exoesqueleto que multiplica nuestra capacidad, en lugar de un manual para reemplazarnos.
La pregunta incómoda para cerrar
Si mañana tuvieras que justificar tu salario ante alguien que dispone de:
- Un equipo de desarrolladores medianamente competente
- Una IA bien integrada en el flujo de desarrollo
- Un codebase bastante limpio y testeado
¿Qué responderías? ¿Qué aportas tú que no sea razonablemente sustituible?
No tengo una respuesta única. Pero sí una certeza:
Si seguimos hablando de “buenas prácticas” como si el objetivo fuera escribir código perfecto, estamos mirando al sitio equivocado.
Las buenas prácticas no son el fin (en realidad nunca lo fueron). Son el mínimo para jugar en una liga donde el código lo escribirá cada vez menos un humano en solitario.