Ingeniería con IA
Trabajar con IA sin método es una apuesta, y GATE es mi intento de dejar de apostar.
01 Definición
La IA prepara Separa el problema de la solución que traía el pedido y clasifica los datos.
La persona decide Producto aprueba la definición.
02 Construcción
La IA prepara Escribe el cambio y lo revisa contra las reglas del equipo.
La persona decide Quien construye lo entiende, lo corrige y abre el merge request.
03 Revisión
La IA prepara Resume el cambio, sus riesgos y las reglas que aplican.
La persona decide Lo aprueba otra persona, nunca quien lo escribió.
04 Producción
La IA prepara Deja listo el deploy y el plan para volver atrás.
La persona decide Una persona decide pasar a producción y se hace cargo.
05 Aprendizaje
La IA prepara Convierte lo corregido en una regla, con su origen.
La persona decide El equipo la aprueba y se aplica desde el cambio siguiente.
Este es el primer capítulo de una serie sobre GATE, el framework que escribí para ordenar el trabajo con IA. Lo marco como opinión: es lo que creo después de varios meses de equivocarme y corregir.
Casi todos los equipos de software usan asistentes de inteligencia artificial. Los usan los desarrolladores, los líderes y la gente de producto, y el trabajo sale más rápido desde el primer día. Pero casi ningún equipo tiene un método. Cada persona trabaja con su propio prompt, en su propia ventana, y lo que aprendió en una conversación se pierde cuando la cierra.
Al principio eso funciona, pero después los mismos problemas se repiten. La calidad depende de quién usó el asistente ese día y de cuán bien supo preguntar. Una discusión que parecía cerrada vuelve a las pocas semanas en otro cambio. La seguridad se revisa cuando el código ya está escrito. Y si alguien pregunta qué estándar se aplicó o quién aprobó un cambio, nadie sabe qué contestar. Lo vi en equipos que me ha tocado liderar, y mi única respuesta era pedir que confiaran.
El riesgo del vibecoding
Hay una forma de usar la IA que se puso de moda, y la entiendo porque es entretenida. Se le pide al asistente que construya algo, se prueba que funcione y se sigue. Para un prototipo de fin de semana sirve. Para un producto que maneja dinero o datos de personas, es una apuesta.
El asistente escribe igual de seguro cuando acierta que cuando se equivoca. Si nadie revisa con criterio, el error llega a producción sin que nadie lo note. Un equipo que genera código sin entenderlo acumula deuda técnica más rápido que nunca.
En un equipo de ingeniería alguien tiene que darse cuenta cuando algo anda mal y hacerse cargo de lo que se entrega. Eso no se le puede pasar a la herramienta, y veo cada vez más equipos que lo intentan.
Qué es GATE
GATE salió de esa preocupación. Es un framework abierto que ordena el trabajo con IA en etapas, y en cada una queda claro qué entra, qué sale y quién lo aprueba. La IA prepara y las personas deciden. El asistente lee el código y los datos, redacta y verifica lo que dice contra la fuente. La persona acepta o rechaza, autoriza cualquier escritura en un sistema compartido y se hace cargo del resultado.
Cada decisión de un code review y cada causa raíz de un incidente se vuelven una regla del equipo, escrita y con su origen, que se aplica desde el cambio siguiente. Así el equipo deja de discutir dos veces lo mismo. Me habría gustado tener esto hace años, cuando cada persona que se iba se llevaba lo que sabía.
Cada empresa arma sobre GATE su propio SDLC, con el asistente que prefiera, sea Claude, Gemini, Kiro u otro. Cómo lo construí y cómo se implementa van en los dos capítulos que siguen.
Lo que cambia en el día a día
Lo primero que cambia es que el equipo gana tiempo. La IA hace el trabajo mecánico, como redactar tickets, reconstruir contexto o armar la cronología de un incidente, y el equipo usa ese tiempo en decidir. Un grupo chico alcanza a cubrir lo que antes pedía varios roles.
La mejora continua tarda más, pero vale más. Cada review deja reglas, cada incidente deja una causa raíz que evita el siguiente y la seguridad se revisa antes de escribir el código. Nada de eso depende de que alguien se acuerde, porque el ciclo lo hace solo.
El conocimiento deja de estar en la cabeza de dos o tres personas, así que alguien nuevo se integra más rápido y una renuncia deja de ser una emergencia. Y de cualquier cambio se puede saber qué se pidió y quién lo aprobó, que es lo primero que pregunta un auditor.
Todavía no está todo funcionando: algunas partes ya andan y otras no.
Quién decide
Gobernar el trabajo con IA es definir de antemano dónde se detiene la máquina y dónde decide una persona, y dejar que el resto avance rápido. GATE fija esos puntos y separa algunos roles a propósito: nadie revisa su propio cambio ni aprueba el diseño que propuso, y quien construye no valida el resultado de negocio. En un equipo chico con un asistente potente es fácil equivocarse muy rápido, y esas separaciones lo evitan.
Un asistente puede dejar listo un deploy impecable, pero la decisión de pasar a producción la toma una persona, y esa persona se hace cargo. Si una empresa espera que la herramienta se haga cargo, el problema aparece en la primera auditoría o en el primer incidente serio.
Lo que pone la experiencia
La IA multiplica lo que hace quien la usa. Si esa persona no tiene criterio, multiplica la confusión. Si sabe qué preguntar y qué no puede fallar, logra mucho más de lo que podía hace unos pocos años.
Si además hay un método que guarda lo aprendido, cada mes el equipo parte de lo que aprendió antes, sin reconstruir el contexto desde cero. Ese método lo tiene que construir cada empresa.
Lo que viene
Los asistentes van a seguir mejorando, y rápido. Van a poder hacer tareas más largas con menos supervisión, y eso hace que una mala decisión salga más cara.
Con el tiempo, la IA va a poder hacer más cosas sin que una persona apruebe cada paso. Me parece bien, siempre que se decida con evidencia y que alguien lo apruebe. Los modelos se vuelven commodity en cuestión de meses, así que creo que les va a ir mejor a las empresas que tengan su conocimiento ordenado que a las que solo tengan el mejor modelo.
GATE es público y se puede usar libremente. Lo escribí para que otras empresas lo usen y para dejar por escrito lo que tenía en la cabeza. Si lo pruebas en tu equipo, me interesa saber dónde se trabó.