En Mango, la mayoría del código que llega a producción pasa por un agente de IA antes de pasar por un humano. No es una frase de marketing: es la forma de trabajar diaria de un equipo chico operando una plataforma financiera. Y con esa velocidad aparece un problema que no es sobre la IA, es sobre el proceso: ¿cómo mantenés estándares consistentes cuando el código se escribe rápido, en muchos repos, y buena parte no la tipeó un humano?
La respuesta que nos funcionó: la gobernanza no puede ser conocimiento tribal ni una wiki que nadie lee. Tiene que ser código — versionada, revisada y propagada como una dependencia.
La gobernanza vive en un repo, no en una wiki
Los estándares de ingeniería de Mango viven en un solo repositorio. No en la cabeza
del que lleva más tiempo, no en un documento que se desactualiza solo: en archivos
versionados, con su historial y sus PRs. Ahí está definido, una sola vez, cómo
escribimos los commits, cómo modelamos el dinero (spoiler: nunca en float), cómo
manejamos los secretos, qué exige un test para contar como test, y cómo tienen que
comportarse los agentes.
Que sea un repo tiene una consecuencia linda: cambiar una regla es un PR. Se discute, se revisa, se mergea. La gobernanza tiene el mismo rigor que el código que gobierna.
Se propaga como una dependencia, no como un memo
Definir la regla en un lugar no sirve de nada si no llega a los repos donde se aplica. Acá está la pieza que más nos cambió el día a día: cuando una regla cambia, un workflow abre automáticamente un pull request en cada repo de la plataforma con la actualización.
Nadie manda un mensaje de “che, ahora hacemos las cosas así”. El cambio llega solo, como un bump de dependencia, revisable en cada repo por quien corresponda. Un estándar nuevo deja de depender de que cada persona se entere y se acuerde — que es, exactamente, el modo en que las reglas se mueren.
Las decisiones se registran, con sus trade-offs
No todo es una regla; mucho es una decisión. Y las decisiones se pudren en la memoria si no se escriben. Usamos ADRs: un archivo por decisión, con el contexto, lo que se eligió, y lo que se descartó y por qué.
Un ejemplo honesto: cuando evaluamos adoptar un framework de harness de agentes más grande, mapeamos sus patrones contra lo que ya teníamos y descubrimos que la mayor parte ya estaba implementada de forma nativa. Así que no adoptamos el framework entero: sumamos solo los gaps reales, de a uno, cuando los datos mostraban que el problema existía de verdad. Resistir la tentación de implementar la solución completa desde el día uno quedó escrito —con nombre y fecha— para el que venga después.
El harness: las reglas que el agente respeta en runtime
Encima de todo eso está la capa que la gente asocia con “gobernar agentes”: el harness. Son las reglas que un agente tiene que cumplir mientras trabaja, no como sugerencia sino como contrato. Las cuatro que más nos importan:
- Review-risk gate. Antes de abrir un PR, el agente mide el diff. Si es enorme o toca muchas áreas no relacionadas, no abre un PR gigante en silencio: frena y propone partirlo. El check es advisory-first —comenta, no bloquea—: la decisión sigue siendo humana, pero con datos en vez de a ojo.
- Verify-evidence. Un PR no se mergea sin la salida real de los tests en el cuerpo. No “corrí los tests y pasan”: la salida. El modo de falla típico de un agente es decir que algo anda porque debería andar; pedir evidencia concreta lo convierte en un hecho auditable.
- Result contract. Entre fases de un flujo agéntico no se pasa prosa libre, se pasa un envelope consistente (status, resumen, artefactos, siguiente paso, riesgo). El orquestador decide sin tener que interpretar una novela.
- Skill digestion. Cuando un agente delega en un subagente, no le pasa la documentación cruda “por las dudas”: le pasa cuatro o cinco puntos digeridos y específicos. El ruido en el contexto es lo que peor le hace a un subagente.
# Advisory-first: comments the diff size, never blocks the merge.review_risk: threshold_lines: 400 # excludes lockfiles and generated code ignore_globs: - "**/*.lock" - "**/dist/**" on_exceed: comment # comment | warn — never "fail"Lo interesante es que estas reglas no viven aparte: son parte del mismo repo de gobernanza y las lee tanto el humano como el agente. La regla es el contrato para los dos.
Lo que aprendimos
Ninguna de estas piezas es sobre el modelo de IA. Son sobre el proceso que lo rodea. La IA aporta la velocidad; la gobernanza-como-código aporta que esa velocidad sea consistente y auditable en toda la plataforma, no solo en la cabeza de quien la tiene fresca.
Y el consejo, si tu equipo empieza a operar con agentes en serio: no busques el harness perfecto ni escribas el reglamento completo el día uno. Poné la regla que ataca tu peor modo de falla hoy, hacela barata de cumplir, versionala, y que se propague sola. La gobernanza que sobrevive es la que no le cuesta nada al que la respeta — y la que llega sola al repo donde hace falta.