Operamos varios productos simultáneamente con un equipo que hace unos años habría tenido dificultades para mantener uno solo. La pregunta que nos hacen sobre eso es qué herramientas de IA usamos. Es la pregunta equivocada, o al menos mucho menos interesante de lo que parece, porque las herramientas están ampliamente disponibles y la ventaja no está en ellas.
La ventaja está en todo lo que las rodea. Cuando el código se vuelve barato de producir, el coste de un producto se desplaza hacia las cosas que siempre estuvieron ahí pero quedaban eclipsadas: saber si un cambio es seguro, llevarlo a producción sin ceremonia y enterarse rápido cuando algo se rompe. Esas son propiedades de un sistema de construcción, no de un modelo.
Un solo bucle, varios productos
La tentación con varios productos es dejar que cada uno desarrolle sus propias costumbres. Distintos ejecutores de pruebas, distintos pasos de despliegue, distintas convenciones para el mismo problema. Cada divergencia es razonable en local y fatal en conjunto, porque el coste de cambiar de contexto es lo que realmente limita cuántas cosas puede sostener un equipo pequeño.
Así que ejecutamos un único bucle de automatización en todos ellos, con una arquitectura dedicada por producto por debajo. La misma forma de pipeline, los mismos comandos, la misma ruta de publicación, las mismas convenciones sobre cómo se organiza el texto localizado o la configuración de entorno. Nadie tiene que recordar qué producto lo hace distinto, porque ninguno lo hace. Los productos difieren donde deben — un cliente móvil en Flutter y una aplicación web en Nuxt tienen necesidades genuinamente distintas — y son idénticos en la maquinaria que rodea esa diferencia.
El pipeline tiene que ser fiable para ser útil
Un conjunto de pruebas que acierta casi siempre no es un mecanismo de seguridad. Es una sugerencia, y las sugerencias se ignoran bajo presión de plazos.
El nuestro ejecuta unitarias, integración y end-to-end antes de que nada llegue a producción, y un pipeline en rojo detiene la publicación. La regla es absoluta, lo que suena rígido y es justamente el punto: un pipeline que se puede saltar se salta, y la primera excepción siempre es para un cambio que parecía obviamente seguro. El valor de la regla está por completo en que no tenga excepciones, porque en el momento en que tiene una deja de ser infraestructura y se convierte en una negociación.
Esto importa más con IA en el bucle, no menos. Si un modelo produce buena parte del código, el conjunto de pruebas está haciendo más trabajo que antes: ahora es el mecanismo principal por el que se verifica que el código generado hace lo que se pretendía. Velocidad de generación sin un aumento proporcional de verificación es solo una forma eficiente de publicar defectos.
Automatiza lo que haces siempre igual
El filtro útil para decidir qué automatizar no es «qué lleva más tiempo» sino «qué hacemos idéntico cada vez, donde hacerlo ligeramente distinto sería un problema».
Los despliegues califican. También el manejo de entornos y secretos, las actualizaciones de dependencias, la extracción de textos localizados y las partes mecánicas de la revisión — formato, lint, comprobación de tipos, auditoría de dependencias — que deberían estar resueltas antes de que una persona mire nada. Alguien revisando un diff debería gastar atención en si la comprobación de autorización es correcta, no en el orden de los imports.
Lo que no califica es el criterio en sí. No hemos encontrado forma de automatizar la pregunta de si un diseño es correcto, y los intentos de aproximarla producen sobre todo ruido confiado que cuesta más evaluar de lo que ahorra. Automatizar el trabajo mecánico y preservar la atención humana para las decisiones importantes es el intercambio completo, y se derrumba si intentas automatizar también la segunda categoría.
Lo que esto cuesta
Vale la pena ser honesta: esto es una inversión real y compite directamente con publicar funcionalidades. Nuestras herramientas internas no son un proyecto paralelo; se diseñan, revisan y mantienen como cualquier otra cosa, y hay semanas en las que son lo único que se construye.
El retorno no es una cifra de productividad que pueda citar con seriedad. Es una propiedad estructural: un equipo pequeño puede sostener varios productos durante años sin que la carga de mantenimiento crezca más rápido que el equipo. Eso se acumula en silencio y es casi invisible hasta que intentas hacerlo sin ello.