Cómo se construyó GATE

GATE empezó como una lista. En los equipos que me ha tocado liderar desde que la IA entró al trabajo diario se repetían los mismos problemas: decisiones que se perdían, reviews que cambiaban según quién las hiciera, fallas de seguridad que aparecían tarde y una pregunta que nadie podía contestar, la de qué estándar se había aplicado a un cambio.

La primera versión

La primera versión ordenó el trabajo en un ciclo de trece etapas, desde que alguien plantea una necesidad hasta que el sistema corre en producción y la organización aprende algo de lo que pasó. Cada etapa define lo que recibe, lo que entrega y quién la aprueba, y entre una y otra hay puntos de control donde el proceso se detiene hasta que decide una persona.

Dos decisiones se mantuvieron desde el comienzo. La primera fue separar algunos roles: quien construye no revisa su propio cambio, quien propone un diseño no lo aprueba y quien construye no valida el resultado de negocio. La segunda fue dejar vacío, a propósito, el catálogo de reglas. Un conjunto de reglas copiado de una guía retrata a quien lo escribió, y el equipo nunca lo siente propio. Las reglas tenían que salir del trabajo real.

La prueba en una organización real

La verdadera prueba fue aplicarlo en una organización con productos, personas y urgencias reales, y ahí aparecieron cosas que en el papel no se veían.

La más importante fue que el framework describía un SDLC ya funcionando, pero no decía nada de quién lo construye. Faltaba un rol, el orquestador, y una fase de formulación con una salida escrita desde el inicio, porque mientras el sistema se construye una sola persona propone y aprueba. También quedó claro que aprobar cada escritura por separado no resiste el ritmo real de trabajo, y que funciona mejor autorizar un alcance por sesión, con una lista corta de acciones que siempre piden permiso. Y las reglas importantes no pueden depender solo de las instrucciones al asistente, porque en las sesiones largas se diluyen; tienen que hacerlas cumplir el entorno y la plataforma.

Producto, que muchas veces no trabaja con repositorios, necesitaba su propia puerta de entrada. Y los casos de uso que valida producto terminaron siendo el mejor puente entre la definición de un requerimiento y las pruebas automatizadas que después lo protegen.

Todo eso volvió al framework. De ahí salió también la idea que hoy lo ordena, la de que GATE es la base y que sobre ella cada empresa construye su propio SDLC con el asistente de IA que elija.

Una empresa que no existe

Quedaba una duda: ¿podría otra empresa construir su SDLC solo con lo publicado, sin la ayuda de quien escribió GATE? Para averiguarlo, un agente de IA sin contexto previo inventó una empresa de software de salud, con su equipo, sus productos y sus herramientas simuladas, y construyó su SDLC siguiendo únicamente la guía.

Salió un SDLC completo, que después se usó en todo el ciclo. Al definir un requerimiento, separó la solución que traía el pedido del problema de fondo. El self-review encontró datos personales escritos en un log, las pruebas automatizadas atraparon una regresión y el diagnóstico de un incidente, filtrado por ambiente, evitó una conclusión equivocada.

La prueba también encontró problemas en GATE, que era justamente lo que se buscaba. Había huecos en los guardias de permisos, un validador que dejaba pasar reglas sin origen y supuestos de plataforma que un equipo chico no siempre cumple. Cada uno se está corrigiendo, y la prueba se va a repetir.

Un framework que también aprende

GATE aprende en tres niveles. El equipo aprende con cada review y cada incidente; el producto, cuando lo entregado se mide contra el problema original, y el framework, con cada empresa que lo implementa. Cada una anota dónde se aparta de GATE, y lo que resulta ser una lección vuelve como propuesta, sin datos de la empresa.

Por eso GATE no está terminado ni pretende estarlo. Mejora con el uso, igual que los equipos que lo usan.

El siguiente artículo explica cómo implementarlo en tu empresa.

Volver al blog