Frihet ERP (app.frihet.io) is a project built by Viktor Berthelius at BRTHLS. SaaS ERP for the Spanish market: invoicing, VeriFactu, HR, fiscal compliance, accounting integrations. Real software, real customers, real production.
In five months, the product has shipped around 47 major features to production. A single human engineer in the loop. No external team. No development contracts.
This post explains the mechanics. Not as inspiration. As a replicable system with clear limits.
The honest starting point
January 2026: backlog of 130 items. Product roadmap impossible for a single developer. The options were to hire (cost, time, management) or find a capacity multiplier that didn’t require constant human coordination.
The bet was clear: an AI‑agent architecture where the human engineer acts as dispatcher, not executor.
The risk was also clear: AI agents generate technical debt quickly if there’s no verification system. Without gates, code merged today can break production tomorrow.
Architecture: dispatcher Opus, executors Sonnet
The system works in two layers.
Layer 1 — Planning (main thread): Claude Opus analyzes the backlog, maps dependencies, identifies affected files, and breaks each feature into subtasks with verified code surface. This layer is expensive in tokens but cheap in time. A 20‑minute planning session avoids 3 hours of later debugging.
Layer 2 — Execution (sub‑agents): between 4 and 7 Claude Sonnet instances run in parallel, each in an isolated Git worktree. Each agent receives:
- Exact list of files it will read and write (verified to exist)
- Input symbols with line numbers (pre‑grep by the dispatcher)
- Acceptance criteria and mandatory gates: build, typecheck, lint, tests
Parallelism is real. While one agent implements the payments module, another writes tests for the HR module, another updates internationalization keys. No blocking because each has its own worktree.
Wave‑merge cascade: the problem nobody mentions
Four agents working in parallel generate four PRs. When the first merges to main, the other three become outdated.
This is the hidden cost of parallelism: the rebase cascade.
The protocol in Frihet ERP is straightforward:
- Merge PR‑1 to main
- The remaining three run
git pull origin main --rebase - Conflicts are resolved additively (both versions are kept: types, i18n keys, function exports)
git push --force-with-lease(never pure force)- Green CI → next merge
Each cascade takes 5–10 minutes. With 8–10 PRs in a wave, that’s 3–5 cascade rounds. Total dispatcher time: 40–50 minutes of coordination for 8 hours of parallel work. The ratio pays off.
Automated Gemini review: when to use it and when not
After each PR, a Gemini Code Assist review cycle analyzes the code before merge. The rule is strict:
Round 1 always: the first cycle catches real critical errors. In Frihet ERP’s history, R1 has detected deploy failures, malformed XSD schemas, production tokens leaked in mocks, and incorrect signing policies. Each would have cost hours in production.
Round 2+ only if the finding is critical: if the second cycle says “consider refactoring”, “improve readability” or “extract ternary to mapping object” — no agent is dispatched. It goes to the polish backlog. Each agent start costs 5–10 minutes and real tokens. The ROI of R2 for style fixes is negative.
The rule was learned from experience. One megasprint day spent 50 % of time on R2/R3 polish cycles that moved no business metric.
Non‑negotiable gates before every commit
Without gates, parallelism destroys quality. The four mandatory gates:
| Gate | Command | Moment |
|---|---|---|
| Build | npm run build | Pre‑commit |
| Types | npm run typecheck | Pre‑commit |
| Lint | npm run lint | Pre‑commit |
| Tests | npm test | Pre‑commit |
If any fails, the agent does not commit. The dispatcher never accepts PRs with red gates. No exceptions.
Cost of maintaining this protocol: some agents finish their work, hit a type error, and must fix it before pushing. Cost of not maintaining it: production broken at 3 am.
What doesn’t work: real anti‑patterns
Agent without surface map. If the dispatcher doesn’t precisely map which files the agent will touch before sending it, the agent spends 10–15 minutes exploring the repository. Multiplied by 7 agents: an hour lost before anyone has written a line. The dispatcher’s pre‑flight is mandatory.
Sub‑agent runs npm install. An agent in an isolated worktree that runs npm install installs dependencies only in that worktree, not in the main repository. When the PR merges and someone builds on main, the dependencies are missing. Canonical pattern: npm install runs in the main repo after merge, never inside the agent’s worktree.
Agents touching shared files without coordination. If three agents edit the same type file or the same i18n key file, conflicts are inevitable and costly. Solution: the dispatcher assigns exclusive ownership of shared files to a single agent per wave. The others wait or work on a different surface.
Trust Area without adversarial review. Any agent that touches invoicing, fiscal compliance, VeriFactu, or tax calculations receives an extra instruction: after writing the code, spend the final 10 % of the session as an adversarial reviewer. What input causes a silent NaN? What external response causes an official identifier to be fabricated? Without this review, Trust Area bugs reach production with green tests.
What scales and what doesn’t
What the system scales well:
- Product features with bounded, known code surface
- Internationalization and translations (mechanical, parallelizable, no risk)
- Unit and integration tests (agents are good at writing tests)
- Technical documentation and API stubs
- Mechanical refactors within a defined scope
What does not scale with agents:
- Architecture decisions that affect multiple subsystems (requires Opus in the main thread, not delegation)
- Complex production bugs where the root cause is ambiguous
- Anything that touches real billing, contracts, sensitive data without direct supervision
- Product definition (what to build, for whom, why) — that remains human‑driven
The result in real numbers
Five months, around 47 major features in production. “Around” is honest: some releases were refactors with user impact, some were small features, some were infrastructure that enabled three later features.
The parallel stack cut implementation time per feature by roughly two‑thirds compared to sequential development. That’s not a universal promise. It’s what happened in a specific context: a well‑typed TypeScript repo, existing tests as reference, and a dispatcher who knew the code deeply before delegating.
If your repo has high technical debt, low test coverage, and sparse documentation, the ratio will be worse. Agents amplify the quality of the base system, they don’t compensate for it.
Next action
If you want to apply this model, start with a single agent, a single worktree, a single well‑defined feature with mapped surface. Measure coordination time. Adjust before scaling to 7 parallel agents.
The mechanics are not the bottleneck. The bottleneck is the quality of the dispatcher’s instructions and the quality of the base system the agents inherit.
Related
- AI Evaluation Stack 2026: measuring without theater
- Human-in-the-Loop Debt: when quality control destroys margin
- Operating Cadence: the forgotten variable in AI‑enabled teams
If you want to explore whether this execution model applies to your team, open a diagnostic.
Translated from the Spanish original with AI assistance and reviewed for accuracy. Read the original in Spanish.