Cuando adoptamos Cursor y Claude en el equipo, la pregunta no era si la IA podía escribir código — ya sabíamos que sí. La pregunta era otra: ¿cómo evitamos que un equipo que produce el doble de código termine produciendo el doble de bugs?
Después de meses trabajando así en un monorepo con miles de commits — donde una parte importante del código pasa por flujos asistidos por IA — esto es lo que funcionó, lo que falló y lo que haría distinto desde el día uno.
La IA no reemplaza el criterio, lo exige
El primer error que cometimos fue tratar la IA como un desarrollador junior más: darle una tarea y confiar en el resultado. El código compilaba, los tests pasaban… y aun así rompía convenciones del proyecto que nadie había escrito en ningún documento, porque vivían en la cabeza del equipo.
La solución fue invertir el flujo: antes de generar código, generamos contexto. Documentamos las convenciones implícitas — cómo nombramos servicios, dónde viven los tipos compartidos, qué patrones de error usamos — en archivos que las herramientas leen en cada sesión. La IA es tan buena como el contexto que le das.
💡 Regla del equipo: si un patrón se corrige dos veces en code review, se documenta para la IA. La tercera vez no debería existir.
Qué automatizamos (y qué no)
No todo el trabajo se beneficia igual. Nuestra división quedó así:
- Automatizamos: scaffolding de módulos, tests unitarios de casos límite, migraciones repetitivas, refactors mecánicos entre paquetes, y la primera versión de cualquier CRUD.
- Asistimos: diseño de APIs, lógica de negocio y queries complejas — la IA propone, el humano decide.
- Nunca delegamos: decisiones de arquitectura, seguridad, permisos y todo lo que toca dinero o datos personales.
El code review cambió de forma
Revisar código generado por IA no es como revisar código humano. El código de IA se ve bien — está formateado, nombrado con sentido y comentado. El peligro está en lo que parece correcto. Por eso movimos el foco del review: menos estilo, más comportamiento.
// Checklist de review para código asistido por IA
// 1. ¿Los casos límite son reales o inventados?
// 2. ¿Reutiliza lo que ya existe o duplicó un helper?
// 3. ¿El manejo de errores sigue nuestro patrón?
// 4. ¿Hay tests que fallan si el comportamiento cambia?
// 5. ¿Tocó algo fuera del alcance del ticket?
El punto 5 resultó ser el más importante: las herramientas de IA tienden a «mejorar» código vecino que nadie les pidió tocar. Un diff limpio y acotado vale más que uno brillante y extenso.
Lo que haría diferente hoy
Empezaría por la documentación de contexto desde el primer día, no después del primer incidente. Y establecería una métrica simple que al final es la única que importa: no cuánto código genera el equipo, sino cuánto código sobrevive seis meses en producción sin ser reescrito.
La IA nos hizo más rápidos, sí. Pero el cambio real fue otro: nos obligó a hacer explícito todo el conocimiento que antes era tribal. Y eso habría valido la pena incluso sin la velocidad.
