58 commits, four stacks, one day
How one developer with a team of five AI agents completed 30 backlog items in a single day, and why the most important team member is the one who isn't allowed to write code.
the AIssistant project · July 11, 2026 · data: git history + backlog + reviewer memory
API · billing · RLS
UI · i18n · specs
voice · Twilio
as needed
(10:39–23:42)
303 files
completed
avg 1.6 rounds
Context
AIssistant is a SaaS product for the Czech market: a multi-channel AI assistant handling bookings and customer communication for businesses over email and phone. A technically non-trivial system: multi-tenant architecture with Row Level Security on PostgreSQL, Stripe billing with three tiers and add-ons, telephony via Twilio, a realtime voice pipeline (STT → LLM → TTS) with a sub-500 ms latency target, and hard GDPR constraints, meaning all processing inside the EU.
Three programming languages, three applications, one person. The classic answer would be "hire a team." The answer in this project was to build one out of AI agents.
And this is not "AI-assisted development" at the margins: practically all of the product's code (over a hundred thousand lines across three stacks) was written by AI agents. The human role is product and operations: requirements, priorities, decisions, approvals, and deployment. The day described here is not an exceptional showcase; it is the normal working mode in which the product was built.
Three design decisions
1 · The team-lead must not write code or verify. Its definition contains explicit prohibitions: no implementing (an emergency escape hatch of ~5 lines), no running tests or reading diffs between implementation and review. The temptation to "save a round-trip" by self-verifying is explicitly labelled a bug in the role definition. Separating implementation from verification is the entire point of the role.
2 · The reviewer must not change code. It may only read, analyze, and report, "as if the code will ship to production immediately and will be hit by hostile inputs, bad timing, and partial failures." Findings carry a severity (🔴 blocker / 🟡 warning / 🔵 nit), an exact file:line, a concrete fix, and an owner. Done means "review clean": zero open findings.
3 · The reviewer has persistent memory versioned in git. 43 topic files, ~230 recorded patterns: traps that have already burned someone in this specific project. The team-lead injects them into every specialist's brief before spawning. A mistake found in March no longer even reaches review in July.
Beyond the roles, quality is held by skill packs (nine files of codified standards that take precedence over any prompt) and OpenAPI-first contracts. The spec is the source of truth for all three stacks and the reviewer checks for drift.
The process: from audit to "review clean"
- Scope analysis. The team-lead picks specialists from the task's "technology fingerprints." When ambiguous it over-spawns; every brief has a self-elimination clause.
- Parallel implementation. Specialists on different stacks work concurrently; dependencies are handled with a "contract ready" message.
- Review follows immediately after implementation. The reviewer reads the diff and its blast radius: call sites, migrations, generated clients, tests.
- Finding routing. The team-lead splits findings by owner and sends them back verbatim.
- Stateless re-review. The reviewer re-reads the affected files and judges by the current code, not by notes. The loop runs to zero findings.
Even that day's backlog came from the same mechanism: at 10:39 an adversarial audit of the three stacks against the feature matrix produced 38 tasks with priorities, dependencies, and line-level references, including findings like a paid feature missing its enforcement, which would otherwise have meant a silent revenue leak.
The day in numbers
Commits by hour · Jul 11, 2026
58 commits between 10:39 and 23:42. The 9 pm peak is billing, FE, and infra closing in parallel.
Review rounds per change
39 review runs: half clean on the first pass, none needed more than three rounds.
Findings by severity
40 documented findings in one day, all resolved before "review clean."
The scope was not "many small tweaks." A single day produced, among other things: per-minute call metering with hard quotas, operator fallback with toll-fraud protection, a Stripe plan-change flow with a proration saga, CSV exports with OWASP protection, kill-switch parity for the voice channel, production deployment configuration, and PIN-gated voice search. Plus ten new DB migrations and an FE test suite that grew from 701 to 783 tests, 783/783 green at end of day.
What the review actually caught
The technical specifics are deliberately generalized in this published version. Every finding was fixed before the branch was merged, but a map of one's own attack surface does not belong in a case study. Five classes from that day:
Tenant isolation masked by the test environment 🔴 blocker
A security check wired in the wrong order would have blocked legitimate traffic for an entire channel in production. Tests missed it: the test database role had higher privileges than the production one and silently bypassed the isolation policies. The reviewer forced a regression test under the same role production uses.
Over-scoped secrets between services 🟡 warning
One service was receiving the platform's complete secret set in its deployment configuration while needing a fraction of it. A compromise of one component would have become a compromise of everything. Result: a least-privilege, per-service split of configuration.
A configurable value with financial impact 🟡 warning
A setting a customer can change themselves could redirect a paid external operation onto the operator's account. Fix: an in-code allowlist plus a guard at the external platform level as a launch precondition.
Injection into data exports 🟡 warning
A classic OWASP class: externally influenced data behaves as executable content when the export is opened in a spreadsheet. Plus a warning about the memory footprint of bulk exports.
An oracle in a verification flow: designed in ahead of time
Verifying a secret must not reveal, through response behavior, whether the secret even exists. The authorization flag may only be set in deterministic code after a cryptographically verified response, never from the prompt: the LLM is never a security boundary; deterministic code is.
None of these are style nits. They are classes of bugs that slip past senior review in ordinary teams. They require holding database security-policy semantics, external-platform billing, and office-software behavior in your head at the same time.
Why it works
- The separation of implementation and verification is structural, not voluntary. An implementer cannot approve itself and the orchestrator cannot skip review. The roles technically don't allow it.
- Reviewer memory compounds. Every finding becomes an input to the next brief; the team's learning curve is stored in git.
- Standards are codified, not tribal. Skill rules take precedence over prompts and over existing code.
- Contracts instead of coordination. The OpenAPI spec lets three stacks work in parallel; drift is caught by review, not by an integration surprise a week later.
- Stateless re-review. The reviewer cannot wave a fix through based on its description; it must re-read the code.
Honest limits
- The human remains product owner and ops. Product decisions, the Stripe catalog, Twilio configuration, production secrets, and the deploy are explicitly human gates. "Review clean" does not mean "deployed."
- The metrics measure output and discipline, not business value. 18,958 lines in a day speaks to process capacity; correctness is better evidenced by the 39 review runs and the regression tests those findings produced.
- Review has real costs. An average of 1.6 rounds means real extra spend in tokens and time. That is by design, not overhead to optimize away.
- Commit counts are a lower bound. The repository's history was squashed during development; 179 commits says little about the real number of iterations. The July 11 session, by contrast, is preserved commit by commit, which is why it is the study's primary data sample.
- The process admits its own blind spots. The reviewer records findings about its own environment and process, not just about the code.
Whole-project numbers (Feb 21 – Jul 11, 2026)
Lines of code by stack
~115,000 lines total. The backend has more test code than production code.
| Metric | Value |
|---|---|
| Total commits | 179 (after squash, lower bound) |
| Total code | ~115,000 lines |
| DB migrations | 118 |
| Test files (BE / FE / PY) | 219 / 73 / 14 |
| Reviewer memory | 43 files · ~230 patterns |
A detail worth highlighting: the backend has more test code (38,823 lines) than production code (35,592 lines). That is not a property of AI coding in general. It is a direct consequence of a reviewer that refuses to sign off changes without error-path coverage, and of a memory full of patterns like "the superuser test masks this bug; it needs a test under the application role."
Conclusion
An agentic team is not "faster autocomplete." It is an organizational pattern: roles with separated powers, adversarial verification as an unbypassable gate, codified standards, and memory that compounds over time. With this pattern, one person managed a day's output comparable to a multi-person team's sprint, with a quality audit trail most human teams don't keep.
The biggest leverage is not in who writes the code, but in how the loop that refuses to let it through is built.