La arquitectura no hace que la IA programe mejor

Escribo esto antes de que la IA nos reemplace y mate a todo el mundo. Obviamente, los primeros que vamos a ser reemplazados vamos a ser los programadores. No sé por qué. 😅

La arquitectura, los tests y las buenas prácticas no existen para que los desarrolladores nos sintamos más importantes o para demostrar que seguimos siendo necesarios frente a la IA.

Existen para que podamos trabajar con IA de forma más rápida, económica y confiable.

Si estás a cargo de un producto, no basta con revisar si el código que genera la IA “parece funcionar”. Tu responsabilidad profesional es entender qué está haciendo, darle buen contexto y ponerle límites claros.

Si no, la IA no está acelerando tu trabajo: está generando trabajo futuro.

Cuando la IA no tiene suficiente contexto

En mi trabajo tenemos acceso a Claude Code. Además, uso herramientas de IA por mi cuenta. Rara vez llego al límite de uso, pero me ha pasado un par de veces.

Una de ellas fue intentando migrar parte de un proyecto a un lenguaje que no conocía bien. Tampoco manejaba suficientemente el repositorio. Dudaba de cada decisión, no sabía qué partes podía modificar con seguridad y me costaba distinguir entre una propuesta razonable y una respuesta que solo sonaba convincente.

El problema no era que la herramienta fuera mala. El problema era que yo no tenía suficiente contexto para dirigirla.

La IA funciona mucho mejor
cuando no tiene que adivinar.

En cambio, cuando trabajo en un sistema que conozco bien, la experiencia cambia por completo. Puedo pedir cambios más específicos, detectar errores antes, evitar iteraciones innecesarias y llegar a producción con más confianza.

Uso menos tiempo, menos contexto y menos intentos.

Lo que preparo en un proyecto para trabajar con IA

No hay una receta única, pero estas son las cosas que intento definir para que la IA pueda ayudar de verdad:

1. 1
   Contexto del repositorio

   Qué hace el producto, cuáles son sus partes importantes, cómo se ejecuta, dónde están los puntos sensibles y qué no debería modificar sin validación.

2. 2
   Arquitectura y límites

   Qué responsabilidades tiene cada módulo, cuáles son las fuentes de verdad, cómo se comunican los componentes y qué decisiones ya están tomadas.

3. 3
   Forma de trabajo

   Cambios pequeños, revisión antes de implementar, validaciones claras y nada de modificar cinco cosas distintas para resolver un problema puntual.

4. 4
   Tests como red de seguridad

   Para mí, trabajar con Test-Driven Development (TDD) no es opcional. Si la IA propone un cambio, necesito una forma de comprobar que no rompió algo que funcionaba antes.

5. 5
   Criterios de decisión

   Simplicidad antes que complejidad innecesaria. Seguridad antes que velocidad aparente. Entender el problema antes de elegir una solución.

La IA puede generar código, pero no conoce tu producto

Esto no elimina las alucinaciones ni convierte a la IA en una ingeniera senior. Pero reduce mucho el espacio en que puede equivocarse.

La IA puede escribir código muy rápido. Lo que todavía no hace bien es entender por sí sola qué parte del sistema importa, qué deuda técnica vale la pena asumir o qué solución va a ser mantenible seis meses después.

La IA puede proponer una solución.
Tú tienes que decidir si el problema vale la pena resolverlo así.

Ahí sigue estando nuestro trabajo.

Lo que quiero profundizar después

En próximos artículos quiero profundizar en cada uno de estos puntos: cómo documento un repositorio para trabajar con IA, qué tipo de contexto realmente sirve, cómo uso TDD y qué criterios uso para aceptar o rechazar una propuesta del modelo.