AI Lab · productized
Dirigir la IA, no programar en su lugar
Reconstruir un producto dirigiendo la IA de principio a fin, y medir ese pilotaje como se mide un producto: 21 458 acciones de IA dirigidas en una ventana de cuatro meses, cinco verbos de pilotaje, un sistema de salvaguardas. La apuesta: probar que la orquestación es un método, no un golpe de suerte.
Todo el mundo dice “uso la IA”. La pregunta interesante está en otra parte: ¿qué le hacemos hacer, qué conservamos, y eso se sostiene en el tiempo? Durante la reconstrucción de un portal de producto, cada acción confiada a la IA quedó registrada, y luego compilada en un reporte de orquestación. No por la performance de la cifra: para verificar una convicción. Dirigir la IA es un trabajo de diseño y de lead, y un trabajo se mide.
El resultado en la ventana de reconstrucción, cuatro meses del primer commit a la puesta en producción: 21 458 acciones de IA dirigidas, 206 horas activas, 251 sesiones. Cada acción cae en uno de los cinco verbos de pilotaje: explorar, actuar, estructurar, documentar, delegar.
La distribución cuenta la postura mejor que un discurso. La ejecución domina: 56 % de actuar, 37 % de explorar. La estructura y la documentación pesan apenas el 6 % de las acciones, y ese es exactamente el punto: son los gestos que el humano se guarda, porque son los que hacen delegable todo lo demás. Un producto cuya estructura y decisiones quedan trazadas del lado humano sigue siendo gobernable cuando uno ya no está en el loop. Un producto generado sin esa columna vertebral se vuelve un desconocido que ya nadie se atreve a tocar.
Leer el desarrollo completo · el falso arranque, el sistema, el método
El falso arranque que lo enseñó todo
La honestidad primero: el arranque falló. Las ganas de hacerlo bien produjeron un archivo de instrucciones sobrecargado, una arquitectura pensada por adelantado e inyectada a la IA. Resultado: el agente volvía a empezar de cero con cada componente, reinventaba el diseño, mezclaba las tecnologías. El problema no era la IA. Generó exactamente lo que le habíamos dado.
La corrección vino de la tech, y no después de los hechos: el tech lead estructuró antes. Instrucciones divididas por carpeta y por feature, menos de 200 líneas cada una, convenciones de nombres, reglas de test. El principio que queda cabe en una frase: definir antes de generar. El archivo de instrucciones no es documentación, es infraestructura.
Un sistema de tres capas, no una vigilancia
El método se sostiene porque no depende de ninguna vigilancia manual, que tarde o temprano cedería. Tres capas lo cargan.
Las instrucciones escritas primero: una quincena de archivos jerárquicos, cargados en cascada según el contexto, con una fuente única para la visión de producto y una para el design system. Las salvaguardas automatizadas después: cada commit pasa por una verificación de convenciones, un hook de pre-commit (types, lint con tope), un hook de pre-push (tests, build), y la CI repite la misma barrera aguas abajo. La visibilidad por último: un playground local que renderiza cada pantalla en cuestión de segundos, tests, y agentes de review especializados que desafían convenciones, seguridad y deuda.
Dentro de ese marco, el trayecto de una feature sigue nueve etapas validadas, del ticket a la producción, con una descomposición sistemática antes de la primera línea: archivos objetivo, estados a cubrir, preguntas bloqueantes. La IA acelera el trayecto. Nunca decide el rumbo.
Una regla de escritura completa el dispositivo del lado front: el componente del design system primero, custom solamente cuando el sistema no cubre la necesidad, y entonces marcado desde la primera línea con un comentario rastreable por grep. Gobernanza simple, aplicable con una búsqueda de texto, que mantiene un producto asistido por IA mantenible y auditable.
Programar es diseñar
El desplazamiento más profundo no está en el equipamiento, está en el gesto de diseño. La iteración ya no se hace sobre una maqueta, se hace sobre la pantalla real: una intención encuadrada, una propuesta de la IA ya dentro del design system, y luego el ajuste en directo de la jerarquía, de la densidad, de la claridad, hasta el arbitraje final. Figma no desapareció, volvió a su justo lugar: las decisiones que merecen una maqueta, y solamente ellas.
Esto no es saltarse la etapa de diseño. Es desplazarla a un medio más exigente: se juzga sobre el render verdadero, no sobre una maqueta que siempre miente un poco.
Última enseñanza, casi de pasada: el agente de código cambió a mitad de camino, por un arbitraje de disponibilidad y de costo, y luego volvió a cambiar. Ninguno de esos cambios modificó el método. Quizás sea la mejor prueba de una práctica de orquestación: si sobrevive al cambio de herramienta, es que existe de verdad.
Lo que queda por probar
El método se volvió un marco de referencia: quince dimensiones autoevaluables, del contexto de producto a la gobernanza del design system, instanciadas en otros equipos, cada uno con su madurez. Y la prueba se volvió real en el verano de 2026: su creadora se fue, el sistema queda. Las instrucciones, las salvaguardas, el marco y las instancias siguen sin la persona que los construyó, y ese era el criterio desde el principio: una práctica que solo se sostiene por su creadora no es un método. Las cifras de este reporte, en cambio, ya están ahí: se muestran con gusto, en vivo.