Frihet ERP (app.frihet.io) es un proyecto que construyo Viktor Berthelius desde BRTHLS. ERP SaaS para mercado español: facturación, VeriFactu, RRHH, compliance fiscal, integraciones contables. Software real, clientes reales, producción real.
En cinco meses, el producto ha enviado alrededor de 47 features mayores a producción. Un solo ingeniero humano en el hilo. Sin equipo externo. Sin contratos de desarrollo.
Este post cuenta la mecánica. No como inspiración. Como sistema replicable con limites claros.
El punto de partida honesto
Enero 2026: backlog de 130 items. Roadmap de producto imposible para un solo developer. Las opciones eran contratar (coste, tiempo, gestión) o encontrar un multiplicador de capacidad que no requiriera coordinación humana constante.
La apuesta fue clara: arquitectura de agentes IA donde el ingeniero humano opera como dispatcher, no como ejecutor.
El riesgo también era claro: los agentes IA generan deuda técnica rápido si no hay sistema de verificación. Sin gates, el código que se mergea hoy revienta producción mañana.
La arquitectura: dispatcher Opus, ejecutores Sonnet
El sistema funciona en dos capas.
Capa 1 — Planificación (hilo principal): Claude Opus analiza el backlog, mapea dependencias, identifica archivos afectados y descompone cada feature en subtareas con superficie de código verificada. Esta capa es cara en tokens pero barata en tiempo. Una sesión de planificación de 20 minutos evita 3 horas de debug posterior.
Capa 2 — Ejecución (sub-agentes): entre 4 y 7 instancias Claude Sonnet corren en paralelo, cada una en un worktree Git aislado. Cada agente recibe:
- Lista exacta de archivos que va a leer y escribir (verificados que existen)
- Simbolos de entrada con número de línea (grep previo del dispatcher)
- Criterios de aceptación y gates obligatorios: build, typecheck, lint, tests
El paralelismo es real. Mientras un agente implementa el modulo de pagos, otro escribe tests del modulo de RRHH, otro actualiza claves de internacionalización. Sin bloqueos entre si porque cada uno tiene su worktree.
Wave-merge cascade: el problema que nadie menciona
Cuatro agentes trabajando en paralelo generan cuatro PRs. Cuando el primero se mergea a main, los otros tres quedan desactualizados.
Este es el coste oculto del paralelismo: la cascade de rebases.
El protocolo en Frihet ERP es directo:
- Merge PR-1 a main
- Los tres restantes hacen
git pull origin main --rebase - Los conflictos se resuelven de forma aditiva (se conservan ambas versiones: tipos, claves i18n, exports de funciones)
git push --force-with-lease(nunca force puro)- CI verde → siguiente merge
Cada cascade cuesta entre 5 y 10 minutos. Con 8-10 PRs en una wave, son entre 3 y 5 rounds de cascade. Tiempo total dispatcher: 40-50 minutos de coordinación para 8 horas de trabajo paralelo. El ratio vale.
Gemini review automatizado: cuando usarlo y cuando no
Después de cada PR, un ciclo de revisión Gemini Code Assist analiza el código antes del merge. La regla es estricta:
Round 1 siempre: el primer ciclo captura errores críticos reales. En el historial de Frihet ERP, R1 ha detectado deploy failures, schema XSD mal formados, tokens de producción filtrados en mocks y políticas de firma incorrectas. Cada uno de esos habría costado horas en producción.
Round 2+ solo si el hallazgo es crítico: si el segundo ciclo menciona “considera refactorizar”, “mejora legibilidad” o “extrae ternario a mapping object” — no se despacha un agente. Eso va al backlog de polish. Cada arranque de agente cuesta 5-10 minutos y tokens reales. El ROI de R2 en correcciones de estilo es negativo.
La regla se aprendio por experiencia. Un día de megasprint gasto el 50% del tiempo en ciclos R2/R3 de polish que no movieron ninguna métrica de negocio.
Gates no negociables antes de cada commit
Sin gates, el paralelismo destruye calidad. Los cuatro obligatorios:
| Gate | Comando | Momento |
|---|---|---|
| Build | npm run build |
Pre-commit |
| Types | npm run typecheck |
Pre-commit |
| Lint | npm run lint |
Pre-commit |
| Tests | npm test |
Pre-commit |
Si cualquiera falla, el agente no commitea. El dispatcher no acepta PRs con gates rojos. Sin excepción.
El coste de mantener este protocolo: algunos agentes terminan su trabajo, encuentran un error de tipos y tienen que corregirlo antes de subir. El coste de no mantenerlo: producción rota a las 3 de la mañana.
Lo que no funciona: anti-patterns reales
Agente sin mapa de superficie. Si el dispatcher no mapea exactamente que archivos toca el agente antes de enviarlo, el agente invierte 10-15 minutos explorando el repositorio. Multiplicado por 7 agentes: una hora perdida antes de que nadie haya escrito una línea. El pre-flight del dispatcher es obligatorio.
Sub-agente hace npm install. Un agente en worktree aislado que ejecuta npm install instala dependencias en ese worktree, no en el repositorio principal. Cuando el PR se mergea y alguien hace build en main, las dependencias no estan. Patrón canonico: npm install se ejecuta en el repo principal después del merge, nunca dentro del worktree del agente.
Agentes tocando archivos compartidos sin coordinación. Si tres agentes editan el mismo archivo de tipos o el mismo archivo de claves i18n, los conflictos son inevitables y costosos. La solución: el dispatcher asigna ownership exclusivo de archivos compartidos a un solo agente por wave. Los demas esperan o trabajan en surface distinta.
Trust Área sin adversarial review. Cualquier agente que toca facturación, compliance fiscal, VeriFactu o calculos de impuestos recibe una instrucción adicional: después de escribir el código, gasta el 10% final de la sesión como revisor adversarial. Que input causa un NaN silencioso? Que respuesta externa causa que un identificador oficial sea fabricado? Sin esta revisión, los bugs de Trust Área llegan a producción con tests verdes.
Que escala y que no
Lo que el sistema escala bien:
- Features de producto con superficie de código acotada y conocida
- Internacionalización y traducciones (mecánico, paralelizable, sin riesgo)
- Tests unitarios e integración (agentes buenos escribiendo tests)
- Documentación técnica y stubs de API
- Refactors mecanicos dentro de scope definido
Lo que no escala con agentes:
- Decisiones de arquitectura que afectan a múltiples subsistemas (requiere Opus en hilo principal, no delegación)
- Bugs de producción complejos donde la causa raiz es ambigua
- Cualquier cosa que toque billing real, contratos, datos sensibles sin supervisión directa
- Definición de producto (que construir, para quien, por que) — eso sigue siendo humano
El resultado en números reales
Cinco meses, alrededor de 47 features mayores en producción. El “alrededor” es honesto: algunos releases fueron refactors con impacto de usuario, algunos fueron features pequeñas, algunos fueron infrastructure que habilitaron tres features posteriores.
El stack paralelo redujo el tiempo de implementación por feature en aproximadamente dos tercios comparado con desarrollo secuencial. Eso no es una promesa universal. Es lo que paso en un contexto específico: un repositorio TypeScript bien tipado, tests existentes como referencia, y un dispatcher que conocia el código a fondo antes de delegar.
Si tu repositorio tiene deuda técnica alta, cobertura de tests baja y documentación escasa, el ratio sera peor. Los agentes amplifican la calidad del sistema base, no la compensan.
Next action
Si quieres aplicar este modelo, empieza por un solo agente, un solo worktree, una sola feature bien definida con superficie mapeada. Mide el tiempo de coordinación. Ajusta antes de escalar a 7 agentes paralelos.
La mecánica no es el cuello de botella. El cuello de botella es la calidad de las instrucciones del dispatcher y la calidad del sistema base que los agentes heredan.
Related
- AI Evaluation Stack 2026: medir sin teatro
- Human-in-the-Loop Debt: cuando el control de calidad destruye el margen
- Operating Cadence: la variable olvidada en equipos con IA
Si quieres explorar si este modelo de ejecución aplica a tu equipo, abre un diagnóstico.