Cómo construimos
con agentes.
De un truco de QA a un producto.

Empezó porque el QA era tedioso.

No fue un proyecto de laboratorio. Fue un dolor repetido, resuelto una vez.

• Hacer QA a mano: repetir los mismos flujos una y otra vez. Tiempo que no escalaba.
• Vi el uso de navegador del agente: podía manejar el browser y probar la app solo.
• Ahí nació la idea: que el agente corra el E2E por mí.

De un truco de QA a un flujo de punta a punta.

1 a 1, esto no es más rápido. En paralelo, cambia la escala.

Es honesto decirlo: hacer bien una tarea tiene su costo. La ganancia no está en cada tarea, está en cuántas corren a la vez.

Un mirror local, y un clon real por tarea.

Probamos git worktrees y nos quedaron cortos: aíslan el árbol de archivos, pero no el mundo alrededor. La misma rama no se checkoutea dos veces, y los puertos y el entorno se siguen pisando.

Clonar desde local es instantáneo, la base sale fresca y no le pegás a origin por cada tarea. Cada task tiene además su bloque de puertos y su entorno: dos agentes en paralelo no se cruzan.

Skills guían. Tools ejecutan.

De ahí sale la regla de cuándo escribir una tool: no hagas pensar al agente lo que un script resuelve. Si es repetitivo y tiene respuesta exacta, va a una tool. Si necesita criterio, va en prosa.

Compartir el workflow era un dolor.

Cada mejora había que repartirla al equipo, y eso no escalaba. Lo resolvimos primero con git; después vino el problema de gobernarlo.

Forge: nuestro workflow, empaquetado.

En una empresa grande el mismo dolor está multiplicado: gente no técnica construyendo con v0, Bolt o Lovable; un CTO sin forma de ver ni controlar eso; y un champion de AI que no logra mover el negocio porque lo que sale no se sostiene.

Compartirlo lo resolvió git. Gobernarlo y distribuirlo a escala es Forge: la biblioteca de cómo hacemos X con agentes. La organización lo ejecuta; Forge lo distribuye y lo gobierna.