Mucha gente cree que “usar agentes de IA” es abrir Cursor y ponerse a escribirle. No fue eso lo que llevó a Flagify de un boceto en una servilleta a producción.

El trabajo de verdad fue construir el sistema alrededor de los agentes.

El problema del que nadie habla

Los agentes de IA son potentes, pero también olvidadizos, y se equivocan con toda seguridad sobre cosas que nunca han visto. Dale a uno un monorepo con servicios en Go, SDKs en TypeScript y Terraform, y mirá cómo pasa veinte minutos haciendo grep a ciegas antes de entregar algo que casi compila.

El cuello de botella no es el modelo, es el contexto.

Cada hora que pasé volviéndole a explicar la arquitectura a un agente era una hora sin sacar nada. Así que dejé de tratarlos como practicantes brillantes y empecé a tratarlos como infraestructura.

Cuatro capas que cambiaron la cuenta

No te voy a recorrer archivo por archivo. Lo que importa es la forma.

1. La capa de contexto. Armé un grafo de conocimiento del código (unos 1.600 nodos agrupados en unas 90 comunidades de código relacionado) que cada agente consulta antes de tocar un archivo. El grafo sabe qué SDK le habla a qué endpoint del API y qué módulo de Terraform aprovisiona qué secreto. Los agentes dejan de buscar a ciegas.

2. La capa de comandos. El propio CLI del producto trae un comando de setup que deja instrucciones curadas en el agente que estés usando: Claude Code, Cursor, Copilot, Windsurf. El agente no tiene que adivinar las convenciones. Solo las lee.

3. La capa de decisiones. Cada decisión de arquitectura vive en una bitácora. Por qué Postgres, por qué SSE en vez de WebSockets, por qué el CLI se distribuye como binario de Go con un shim de npm. Cuando un agente pregunta “¿uso X acá?”, la respuesta ya está escrita.

4. La capa de skills. Agentes especializados para trabajos especializados. Uno se encarga de los releases, otro revisa la UI contra el design system, otro escribe copy de marketing con una voz específica. Cada uno se queda en su carril.

Lo que salió de verdad

Con ese andamiaje listo, un solo trimestre produjo lo que habría sido un año de trabajo en solitario:

  • Un API en Go con evaluación en streaming y sincronización por SSE
  • Cuatro SDKs de TypeScript (Node, React, NestJS, Astro) con codegen tipado
  • Un CLI distribuido por Homebrew y npm
  • Una extensión de VSCode que muestra el estado de cada flag en línea, por ambiente
  • Una GitHub Action para condicionar deploys
  • Staging en AWS aprovisionado con Terraform, con observabilidad real incluida
  • Un sitio de marketing, documentación, páginas de integraciones y redes programadas

Ninguna de esas cosas es novedosa por sí sola. La ventaja está en tenerlas todas hechas, y bien hechas, por una sola persona.

La vista del CEO

Los inversionistas preguntan cuál es mi ventaja injusta. La respuesta honesta no está en el roadmap: es la velocidad.

Un equipo chico con un stack de agentes bien instrumentado saca hoy más o menos al ritmo que un equipo de diez personas en 2023. El costo por feature entregado baja mucho. Puedo prototipar una integración en una tarde y tener la documentación y el post de lanzamiento listos antes de que termine la semana.

No tiene nada de mágico. El contexto simplemente se va acumulando.

Lo que no les dejo hacer

Los agentes no deciden qué construir y no hablan con clientes. No sienten la fricción cuando un flag se comporta de una forma que el desarrollador no esperaba. Esa parte es mía.

Tampoco tienen credenciales de producción, no hacen push a main y no aprueban sus propios pull requests. Cada agente tiene su correa, y eso importa más que el modelo.

Lo que te llevás

Si sos founder y estás viendo un repo vacío ahora mismo, la primera pregunta no es “qué modelo uso”. Es: ¿qué necesita saber un agente para ayudarme, y dónde pongo ese conocimiento para que lo pueda alcanzar?

Los modelos salen más baratos y más parecidos entre sí cada mes. El trabajo de conectarlos a tu sistema, no.

Flagify ya está en producción, por si querés ver qué construye este stack.