Frihet ERP (app.frihet.io) es un proyecto que construyo Viktor Berthelius desde BRTHLS. ERP SaaS para mercado español: facturacion, VeriFactu, RRHH, compliance fiscal, integraciones contables. Software real, clientes reales, produccion real.
En cinco meses, el producto ha enviado alrededor de 47 features mayores a produccion. Un solo ingeniero humano en el hilo. Sin equipo externo. Sin contratos de desarrollo.
Este post cuenta la mecanica. No como inspiracion. 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, gestion) o encontrar un multiplicador de capacidad que no requiriera coordinacion humana constante.
La apuesta fue clara: arquitectura de agentes IA donde el ingeniero humano opera como dispatcher, no como ejecutor.
El riesgo tambien era claro: los agentes IA generan deuda tecnica rapido si no hay sistema de verificacion. Sin gates, el codigo que se mergea hoy revienta produccion manana.
La arquitectura: dispatcher Opus, ejecutores Sonnet
El sistema funciona en dos capas.
Capa 1 — Planificacion (hilo principal): Claude Opus analiza el backlog, mapea dependencias, identifica archivos afectados y descompone cada feature en subtareas con superficie de codigo verificada. Esta capa es cara en tokens pero barata en tiempo. Una sesion de planificacion de 20 minutos evita 3 horas de debug posterior.
Capa 2 — Ejecucion (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 numero de linea (grep previo del dispatcher)
- Criterios de aceptacion 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 internacionalizacion. 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 coordinacion para 8 horas de trabajo paralelo. El ratio vale.
Gemini review automatizado: cuando usarlo y cuando no
Despues de cada PR, un ciclo de revision Gemini Code Assist analiza el codigo antes del merge. La regla es estricta:
Round 1 siempre: el primer ciclo captura errores criticos reales. En el historial de Frihet ERP, R1 ha detectado deploy failures, schema XSD mal formados, tokens de produccion filtrados en mocks y politicas de firma incorrectas. Cada uno de esos habria costado horas en produccion.
Round 2+ solo si el hallazgo es critico: 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 dia de megasprint gasto el 50% del tiempo en ciclos R2/R3 de polish que no movieron ninguna metrica 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 excepcion.
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: produccion rota a las 3 de la manana.
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 linea. 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 despues del merge, nunca dentro del worktree del agente.
Agentes tocando archivos compartidos sin coordinacion. Si tres agentes editan el mismo archivo de tipos o el mismo archivo de claves i18n, los conflictos son inevitables y costosos. La solucion: el dispatcher asigna ownership exclusivo de archivos compartidos a un solo agente por wave. Los demas esperan o trabajan en surface distinta.
Trust Area sin adversarial review. Cualquier agente que toca facturacion, compliance fiscal, VeriFactu o calculos de impuestos recibe una instruccion adicional: despues de escribir el codigo, gasta el 10% final de la sesion como revisor adversarial. Que input causa un NaN silencioso? Que respuesta externa causa que un identificador oficial sea fabricado? Sin esta revision, los bugs de Trust Area llegan a produccion con tests verdes.
Que escala y que no
Lo que el sistema escala bien:
- Features de producto con superficie de codigo acotada y conocida
- Internacionalizacion y traducciones (mecanico, paralelizable, sin riesgo)
- Tests unitarios e integracion (agentes buenos escribiendo tests)
- Documentacion tecnica y stubs de API
- Refactors mecanicos dentro de scope definido
Lo que no escala con agentes:
- Decisiones de arquitectura que afectan a multiples subsistemas (requiere Opus en hilo principal, no delegacion)
- Bugs de produccion complejos donde la causa raiz es ambigua
- Cualquier cosa que toque billing real, contratos, datos sensibles sin supervision directa
- Definicion de producto (que construir, para quien, por que) — eso sigue siendo humano
El resultado en numeros reales
Cinco meses, alrededor de 47 features mayores en produccion. El “alrededor” es honesto: algunos releases fueron refactors con impacto de usuario, algunos fueron features pequenas, algunos fueron infrastructure que habilitaron tres features posteriores.
El stack paralelo redujo el tiempo de implementacion por feature en aproximadamente dos tercios comparado con desarrollo secuencial. Eso no es una promesa universal. Es lo que paso en un contexto especifico: un repositorio TypeScript bien tipado, tests existentes como referencia, y un dispatcher que conocia el codigo a fondo antes de delegar.
Si tu repositorio tiene deuda tecnica alta, cobertura de tests baja y documentacion 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 coordinacion. Ajusta antes de escalar a 7 agentes paralelos.
La mecanica 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 ejecucion aplica a tu equipo, abre un diagnostico.