Cómo implementar GATE en tu empresa
Una guía para armar el SDLC de una empresa con GATE, escrita mientras todavía lo implemento.
Producto
Quiero que los pacientes puedan reagendar su hora desde la app.
Antes de armar el ticket, separo el pedido del problema.
Problema: los pacientes llaman para cambiar una hora y la línea se satura.
Solución que trae el pedido: reagendar desde la app. Hay otras, como un enlace en el recordatorio.
Datos: especialidad y fecha de atención. Son datos de salud, así que la clasificación es sensible.
Precedente: el catálogo tiene una regla sobre datos de salud en notificaciones.
No está claro si se puede reagendar con otro profesional. Te dejo las dos opciones para que decidas.
Sigue: criterios de aceptación y casos de uso para que los valides.
Desarrollo
Revisa mi cambio antes de abrir el merge request.
Revisé la rama completa contra la base y contra los criterios del ticket.
Bloqueante: el servicio de reagendamiento escribe la especialidad del paciente en el log. Es un dato de salud y una regla del catálogo lo prohíbe.
Falta la entrada de la migración en el registro de cambios.
Los tres casos de uso del ticket están automatizados y pasan.
No marco lo que ya estaba antes de tu cambio.
Dejé listos el borrador del merge request y el guion de verificación. No publiqué nada.
Soporte y SRE
Un paciente dice que reagendó y no le llegó la confirmación.
Seguí la reserva por su número en los tres servicios por los que pasó.
La reserva se actualizó bien.
El servicio de notificaciones respondió «ok», pero el proveedor de correo rechazó el envío porque la dirección rebota.
Alcance: es un caso aislado. Desde el último deploy no hay más rechazos que antes, así que no es un incidente.
Para soporte: confirmar el correo del paciente y reenviar. Cada afirmación va con el enlace a su línea de log.
Liderazgo
¿Qué está bloqueado esta semana y quién lo destraba?
Hay tres cosas esperando a alguien.
Reagendar desde la app espera una revisión hace cuatro días. La destraba el revisor de backend.
Las alertas de pagos esperan que producto decida qué avisar.
La migración de la base de datos espera una ventana de mantención de infraestructura.
Patrón: dos de los tres bloqueos son revisiones. Conviene repartirlas mejor.
Lo saqué hoy del tablero de tickets y de la plataforma de código. No escribí nada.
Último capítulo de la serie. Es una guía, pero todavía no termino de implementarlo. Sigo en la fase de formulación, así que varias recomendaciones vienen de errores míos o de errores que alcancé a evitar.
Implementar GATE en una empresa es construir su propio SDLC. En la práctica, es un repositorio con el método del equipo, su catálogo de reglas, el contexto de cada producto, las skills y la forma en que se suma cada persona. La guía completa está en el repositorio, y aquí resumo lo esencial para quien está evaluando si le sirve.
Lo que se necesita
Primero, una persona que conduzca la adopción, a la que GATE llama orquestador. Necesita autoridad para asignar roles y criterio técnico para rechazar una propuesta del asistente aunque venga muy bien escrita. No tiene que conocer todas las herramientas de antemano, pero sí responder preguntas sobre la empresa y tomar decisiones. También necesita paciencia, porque al principio le va a tocar convencer más de lo que quisiera.
Segundo, un asistente de IA que cargue instrucciones en cada sesión, use skills y trabaje sobre un repositorio. Claude Code, Gemini CLI, Kiro y Codex sirven, y el orquestador elige cuál. También hacen falta una plataforma de código, una herramienta de tickets y, para la operación, una fuente confiable de lo que pasa en producción. Si falta alguna, lo que depende de ella queda en espera y anotado en el plan.
Los pasos
El esqueleto del SDLC se genera con un comando:
python3 bin/bootstrap.py sdlc ../sdlc-miempresa --assistant claude-code --org miempresaDespués, el asistente entrevista al orquestador. Hace pocas preguntas a la vez, cada una con una respuesta sugerida, y construye por capas: primero el gobierno y el plan, y después el método, el catálogo, los productos, las instrucciones, los controles y las skills. Muestra cada capa antes de pasar a la siguiente y al final corre una verificación punto por punto.
Las decisiones del orquestador
Algunas decisiones solo las puede tomar el orquestador: qué asistente usar, quién ocupa cada rol, qué perfiles tiene cada persona, con qué productos parte el piloto y qué queda fuera. Ninguna detiene la construcción, porque todas traen una opción por defecto, y lo que todavía no se sabe queda marcado como pendiente.
La más importante es cuándo termina la fase de formulación. Mientras el SDLC se construye, el orquestador propone y aprueba todo. Eso está bien siempre que, antes de empezar, quede escrito cuándo se acaba. Por ejemplo, cuando se cumplan estas condiciones:
- otra persona instaló el SDLC sin ayuda;
- producto lo usó en un requerimiento real;
- entró al catálogo una regla nacida del trabajo diario.
Desde ese día, el orquestador sigue las mismas reglas que el resto del equipo. Es el día que más espero.
Partir chico
La primera fase cubre producto y construcción, para que los requerimientos lleguen bien definidos y quien los construye trabaje con las reglas del equipo. Después vienen operación y seguridad, y al final la visibilidad para liderazgo. Cada fase parte solo cuando la anterior funciona con personas reales.
Los errores más comunes
El primero es un riesgo que conozco bien: que la formulación nunca termine. El orquestador sigue aprobando todo y el SDLC termina siendo de una sola persona. Otro es llenar el catálogo de una vez con reglas copiadas, que nadie en el equipo siente propias.
Otros dos son más difíciles de notar. Si los puntos de control nunca rechazan nada, en la práctica decide el asistente, porque escribe de forma convincente. Y si las reglas importantes están solo en las instrucciones, sin un control automático o un pipeline que las haga cumplir, en las sesiones largas el asistente deja de seguirlas.
Por último está la tentación de seguir construyendo en vez de usar lo que ya existe. La conozco bien, porque construir siempre parece más urgente que detenerse a enseñar. Pero mientras lo use solo el orquestador, el SDLC sigue siendo un proyecto en construcción.
Qué esperar
En las primeras semanas hay menos trabajo mecánico hecho a mano, y el self-review detecta errores antes de que lleguen a otra persona. En los meses siguientes, el catálogo se llena de reglas propias y las mismas discusiones dejan de repetirse. Con el tiempo, el conocimiento queda escrito y el equipo trabaja sobre lo que ya aprendió.
La guía completa, con la entrevista, la estructura del repositorio y la verificación final, está en GATE en GitHub.
Esta bitácora sigue, porque el proceso no ha terminado. Si lo implementas, me gustaría saber cómo te fue, y más todavía si te toca hacerlo solo.