Cómo se construyó GATE
GATE partió como una lista de problemas que se repetían al trabajar con IA, y construirlo me enseñó más de lo que esperaba.
- Una lista Los problemas que se repetían al trabajar con IA.
- La primera versión Trece etapas, con puntos de control donde decide una persona.
- Una empresa real Alguien tenía que construir el SDLC, y lo hice yo.
- Una empresa que no existe Un agente la inventó y armó su SDLC solo con la guía.
- Lo que encontró 33 problemas en GATE. Cada uno se corrige en el framework.
Segundo capítulo de la serie. El primero contaba lo que creo, y este cuenta lo que pasó cuando lo llevé a la práctica, que fue bastante más desordenado.
GATE nació de una lista de problemas. Desde que los equipos que me ha tocado liderar empezaron a usar IA a diario, veía repetirse lo mismo: las decisiones se perdían, cada review dependía de quién la hiciera y las fallas de seguridad aparecían tarde. Y cuando alguien preguntaba qué estándar se había aplicado a un cambio, nadie sabía responder.
La primera versión
La primera versión ordenaba el trabajo en trece etapas, desde que alguien plantea una necesidad hasta que el sistema corre en producción y el equipo aprende de lo que pasó. Cada etapa dice qué recibe, qué entrega y quién la aprueba. Entre una y otra hay puntos de control, donde el proceso se detiene hasta que una persona decide.
Desde el principio tomé dos decisiones que se mantienen. La primera fue separar roles: nadie revisa su propio cambio ni aprueba el diseño que propuso, y quien construye no valida el resultado de negocio.
La segunda fue partir con el catálogo de reglas vacío. Cuando un equipo copia las reglas de una guía, las siente ajenas y no las usa. Las reglas tenían que salir del trabajo real, aunque eso significara partir casi sin nada.
La prueba en una empresa real
La prueba de verdad fue aplicarlo en una empresa con productos, personas y urgencias reales. Ahí aparecieron problemas que en el papel no se veían.
El más importante, y el que más me costó aceptar, fue que GATE describía un SDLC ya funcionando, pero no decía quién lo construía. Faltaba un rol, que llamé orquestador, y ese rol era yo. Mientras el SDLC se construye, una sola persona propone y aprueba todo, y eso contradice la separación de roles que el mismo GATE defiende. Lo resolví agregando una fase de formulación con una condición de término escrita desde el primer día.
También aprendí que pedir aprobación para cada escritura no funciona al ritmo real de trabajo. Es mejor autorizar un alcance por sesión y tener una lista corta de acciones que siempre piden permiso. Y las reglas importantes no pueden estar solo en las instrucciones del asistente, porque en las sesiones largas el asistente deja de seguirlas. Hay que hacerlas cumplir con controles automáticos y con la propia plataforma.
La gente de producto, que muchas veces no usa repositorios, necesitaba otra forma de trabajar con el SDLC. Y los casos de uso que valida producto resultaron ser la mejor conexión entre la definición de un requerimiento y las pruebas automatizadas que después lo protegen.
Todo eso lo incorporé a GATE. De ahí también salió la idea que hoy lo ordena: GATE es una base sobre la que cada empresa construye su propio SDLC, con el asistente de IA que prefiera.
Una prueba con una empresa inventada
Me quedaba una duda. Si GATE solo funcionaba conmigo al lado, había construido otra cosa que dependía de mí. ¿Podría otra empresa armar su SDLC solo con lo publicado? Para probarlo, un agente de IA sin contexto previo inventó una empresa de software de salud, con su equipo, sus productos y herramientas simuladas, y construyó su SDLC siguiendo solo la guía.
El agente armó un SDLC completo y después lo usó en todo el ciclo. Al definir un requerimiento, separó la solución que traía el pedido del problema real. En el self-review encontró datos personales escritos en un log. Las pruebas automatizadas atraparon una regresión y, en un incidente, filtrar por ambiente evitó una conclusión equivocada.
La prueba también encontró problemas en GATE, que era lo que buscaba: huecos en los controles de permisos, un validador que dejaba pasar reglas sin origen y supuestos sobre la plataforma que un equipo chico no siempre cumple. Los estoy corrigiendo uno por uno, y después voy a repetir la prueba.
GATE también aprende
GATE aprende en tres niveles. El equipo aprende con cada review y cada incidente. El producto aprende cuando lo entregado se compara con el problema original. Y el framework aprende de cada empresa que lo implementa: cada una anota en qué se aparta de GATE, y lo que sirve como lección vuelve como propuesta, sin datos de la empresa.
Por eso no lo considero terminado. Lo construí entre urgencias, como casi todo en una empresa, y ahora quiero que pase a ser de quienes lo usan. El último capítulo es una guía para quien quiera intentarlo, escrita por alguien que todavía no termina de implementarlo.