One founder. Parallel AI sessions. Adversarial quality gates. Built using resonant software principles: native interfaces for both human and AI, shared state, either user acts on behalf of the other. This page discloses who does what, what the controls are, and what the numbers look like.
Counted from git history, the work graph, and pytest collection across both repos. The idea was conceived March 6, 2026. It launched March 15.
Commit breakdown: 105 feature, 148 fix, 25 test, 14 refactor, 35 site, 35 work tracking. Launch day alone: 142 commits across 8 parallel tracks. The fix count reflects a codebase under active adversarial review. Fixes land fast because the test suite catches regressions before they compound.
Every feature goes through five stages. The stages are sequential. Work within each stage runs in parallel across independent AI sessions.
An AI session researches the codebase, existing patterns, and constraints, then produces a design. The design is reviewed and iterated before any code is written. The human makes all architecture and priority decisions. The AI produces options and trade-off analysis.
The approved design is broken into outcome-scoped work units. Each one has a verifiable done condition, is self-contained enough to survive context loss between sessions, and fits in one AI session. Dependencies are wired into a graph. The human reviews the decomposition before work starts.
One AI session implements the work unit. Four independent AI sessions review the implementation for correctness, edge cases, API contract compliance, and test quality. The human dispatches sessions and resolves conflicts between reviewers.
Every code change runs through the full test suite: unit tests, integration tests, and end-to-end tests. Tests are written before the implementation (red-green). The suite must be green before any commit lands on main. CI enforces the gate.
After all implementation lands, a multi-pass adversarial review runs across the entire codebase. Five independent AI sessions each take one pass: security, bugs, dead code, anti-patterns, test coverage. Findings are triaged by severity. Ship blockers are fixed before release.
Four sweeps have run across both repos. A pre-launch sweep, a post-fix resweep, a hardened sweep focused on token theft and agent corruption, and a verification sweep. Together they produced 232 findings. 108 have been fixed. The rest are triaged and tracked.
The sweep finding real issues is the point. A clean result would be suspicious. 108 findings fixed across four sweeps. The remaining 124 are tracked and prioritized.
Daily activity from March 6 (first design session) through March 16 (day after launch). Data extracted from git history, the work graph, and session transcripts. The charts measure resonance at the AI-app edge: agent dispatch density, flaw injection rate, and the ratio of work completed to work discovered.
| Role | What it means |
|---|---|
| Architect | Makes all design and priority decisions. Sets constraints. Approves decompositions before work starts. |
| Dispatcher | Assigns work to parallel AI sessions. Routes the right task to the right capability tier. Resolves conflicts between reviewers. |
| Ship authority | Decides what blocks a release versus what ships later. No finding is dismissed without human triage. |
| Quality gate | Reviews sweep findings. Approves or escalates. The multi-layer process is the review. |
The human does not write code. Quality assurance comes from the process: test-driven development enforced by CI, four independent reviewers per implementation, and a five-pass adversarial sweep before every release. The git history is the record.
Mallcop uses AI to find security problems in your environment. We used the same approach to build it. That raises a legitimate question: if AI can make mistakes, does that mean mallcop has bugs that compromise the analysis it produces?
The answer is the process. Every commit requires green tests. Every implementation goes through four independent reviews. Every release goes through a five-pass adversarial sweep. Four sweeps have found 232 real issues. 108 have been fixed. The rest are tracked and open.
If this methodology produces trustworthy results, the product works. If it does not, you should not use it. The code is Apache 2.0. Read it.
mallcop