Cómo implementar GATE en tu empresa

Implementar GATE en una empresa significa construir su propio SDLC: un repositorio con su método, su catálogo de reglas, el contexto de sus productos, sus skills y la forma en que se suma cada persona. La guía completa está en el repositorio, y aquí va lo esencial para quien está evaluando si le sirve.

Lo que se necesita

Primero, una persona que conduzca la adopción, a quien GATE llama orquestador. Necesita autoridad para asignar roles y criterio técnico para rechazar una propuesta del asistente aunque venga bien escrita. No tiene que conocer de antemano todas las herramientas, pero sí poder responder preguntas sobre la empresa y tomar decisiones.

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 cumplen con eso, y la elección es del orquestador. Además 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, la parte que depende de ella queda en espera y el plan lo deja anotado.

Los pasos

Un comando genera el esqueleto del SDLC:

python3 bin/bootstrap.py sdlc ../sdlc-miempresa --assistant claude-code --org miempresa

Después, el asistente entrevista al orquestador con pocas preguntas a la vez, cada una con una respuesta sugerida, y construye por capas: gobierno y plan, método, catálogo, productos, instrucciones, guardias y skills. Muestra cada capa antes de seguir y, al terminar, corre una verificación punto por punto.

Las decisiones del orquestador

Hay decisiones que solo puede tomar el orquestador, como 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 razonable por defecto, y lo que todavía no se sabe se marca como pendiente para seguir avanzando.

La decisión más importante es cuándo termina la fase de formulación. Mientras el SDLC se construye, el orquestador propone y aprueba todo, y eso es razonable siempre que antes de empezar quede escrito cuándo se acaba. Por ejemplo, cuando se cumplan estas tres 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 queda sujeto a las mismas reglas que el resto.

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. Operación y seguridad vienen después, y la visibilidad para liderazgo, al final. Cada fase se abre cuando la anterior ya funciona con personas reales.

Los errores más comunes

El primero es una formulación que nunca termina. El orquestador aprueba todo indefinidamente y el SDLC acaba siendo de una sola persona.

El segundo es llenar el catálogo de una vez con reglas copiadas, que nadie en el equipo reconoce como propias.

El tercero es tener puntos de control que nunca rechazan nada. Cuando eso pasa, en la práctica decide el asistente, por lo convincente que escribe.

El cuarto es dejar las reglas importantes solo en las instrucciones, sin un guardia o un pipeline que las haga cumplir.

A eso se suma la tentación de seguir construyendo antes de usar lo que ya existe. Mientras lo use solo el orquestador, el SDLC sigue siendo un proyecto en construcción.

Qué esperar

En las primeras semanas se nota el trabajo mecánico que ya no se hace a mano y los errores que el self-review detecta antes de que lleguen a otra persona. En los meses siguientes, el catálogo empieza a llenarse de reglas propias y las mismas discusiones dejan de repetirse. Con el tiempo, el conocimiento queda escrito y el equipo crece 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. Si lo implementas, me gustaría saber cómo te fue.

Volver al blog