Two AIs, 578 Commits, Zero Hand-Written Code: Vibe Coding Management for an ERP Project

When AI writing code is no longer novel, the real challenge becomes: how do you ensure the code AI writes is reliable, maintainable, and actually meets business requirements? A Bilibili creator spent 29 days having two AI models collaborate on developing an ERP financial module, with zero hand-written code throughout and a total of 578 commits. More importantly, this method held up even in the strict accounting scenario where debits and credits must balance.

Why Choose ERP as a Testbed

The ERP financial module is arguably "hard mode" for Vibe Coding. Debit and credit entries must balance to the last digit; after closing, you can't just squeeze in adjustments—if you squeeze wrong, you can only reverse, not delete; when multiple operations hit the same month concurrently, the result must be complete, not half-done; during database upgrades, an empty database upgrading successfully doesn't mean old data can migrate smoothly. The creator put it bluntly: "I'm using this to prove the method can hold up. If a project like this can stay stable, your projects will only be easier."

This project, called Redmi, went from chart of accounts to year-end closing, split into 40 work packages. The AI was issued 32 remediation task orders, took 767 screenshots under two width rules (1920 and 768), and was sent back for rework and re-acceptance. Every step is recorded in Git, traceable one by one.

The complexity of the ERP financial module isn't just about debit-credit balance; it also involves accounting periods (e.g., monthly closing). After closing, the accounts for that period are locked, and any adjustment must be made through reversing or additional entries, not by directly modifying historical records. This design ensures the integrity of the audit trail and the immutability of financial data. Moreover, concurrent operations require the system to have transaction isolation mechanisms, ensuring that when multiple users operate on the same accounting period simultaneously, data consistency is not compromised. Database migration must consider the difference between empty database upgrades and upgrades with existing data—the latter often involves data conversion and compatibility handling, a common pain point in real projects. These characteristics together constitute the "hard mode" of Vibe Coding, making AI collaborative development face severe tests.

Dual-Model Division of Labor: One Writes, One Verifies

The core method can be summed up in one sentence: one model writes, one model verifies, everything is handed off through documents, and ultimately evidence speaks. The two AIs never talk directly; all handoffs are written as Markdown and committed to Git.

Specifically, there are three roles:

• PM model: breaks down requirements, writes task orders, performs independent acceptance, and issues remediation orders if not qualified.
• Execution model: finds task orders, writes code, runs tests, and submits evidence.
• Yourself: sets direction, makes trade-offs, and is responsible for relaying messages.

In the creator's example, the PM model is Codex and the execution model is Claude Code (CC for short). This division doesn't depend on specific tools; any two models or tools can be split this way. A detail: starting October 2, code was written by Codex, but the rules didn't change—of the 578 commits, 406 carry Claude's signature, 103 are PM test documents and merges, and 69 come from Codex.

Git commit signatures (like "Claude signature") refer to the author information recorded with each commit in version control. In this project, the signature in the commit message distinguishes which AI model generated the code and which commits are PM model document updates or merge operations. This practice helps trace code origins and quickly identify responsibility when issues arise. At the same time, commit signatures reflect the transparency of the collaboration process—all operations leave a trace, facilitating subsequent auditing and review.

Document System: Eight Files Build the Collaboration Skeleton

The division of labor was set on the first day, and eight core documents were subsequently formed:

1. Redmi Project: the division-of-labor map from day one.
2. CLAUDE.md: the sign the executor reads before starting work each time.
3. Collaboration Rules: who is PM, who does the work, how acceptance is done.
4. Roadmap: breaks big requirements into packages.
5. Task Order: the construction order written by PM for the executor.
6. PM Task Entry: a key to start work.
7. Execution Record: what was run, what the results were—all written down.
8. Review Record: PM's conclusions.

Each file is marked with who wrote it. The collaboration rules explicitly state: Codex does not directly write product code, and the executor cannot declare its own work as having passed final acceptance. Acceptance uses only three words: ACCEPTED, Changes Required, Blocked (stuck, missing business decision or external condition).

Task Order: A 289-Line Contract

The task order is the core of the entire collaboration. Take the Wave C foreign currency task order as an example: 289 lines total. Section 3 must be read completely before execution; do not act only on command summaries. The fifth line pins the authorized baseline to a commit SHA. Estimated 4 to 6 hours, but duration is not the completion criterion. The task order was committed to Git at 10:24 AM on September 15—that's the issuance. After issuance, the task order everyone refers to can only be that version.

The task order has ten sections, each targeting a real failure mode:

• Authorization and objectives: hard-codes "do not stop to ask after writing the spec; complete C01 through C05 continuously" to prevent the executor from asking at every step.
• Start gate: before starting, read-only verify six items; if any item is not satisfied, stop immediately and report; do not self-fix.
• Required facts and authority order: this task order's PM ruling ranks first, then the governance architecture, then the real code from the previous package, and Oracle materials last.
• Accounting rules: PM defines them first; the executor no longer discusses them.
• Test cost budget: prohibits replacing diagnostic tests with repeated full runs.
• Hard stop conditions: when foreign currency balances can only be calculated by guessing, must stop and hand over to PM.
• Modification boundaries: prohibits changing migrations and all accepted records.
• Delivery and reporting: local commits only; cannot write ACCEPTED oneself; end with one of two: Submitted or Blocked.

"289 lines—I never even had homework that long. For each section I could only choose one real failure to expand on once; what was reviewed was several rounds of counterattacks later."

SHA (Secure Hash Algorithm) is the hash value used in Git to uniquely identify commit objects. Each commit has a unique SHA; any modification to the commit content changes the SHA. Pinning the authorized baseline SHA in the task order means the executor must develop based on that specific commit, ensuring code version consistency. The start gate checks include confirming that the task order on disk matches the issued version and that the SHA's parent commit exactly equals the business baseline, preventing development deviations caused by file tampering or version misalignment.

Start Order and Skills: How to Make AI Follow the Rules

Once the task order is written, how do you get it into the executor's hands? With a key of only 16 lines—the PM Task entry file. Its description says "use only when the user explicitly enters this command." The first thing in the body is "allow and fully execute this task order," then pins two commit numbers.

The creator's operation is simple: create a new task in CC, type slash plus command name, press Enter, and the AI reads the task order itself. The first thing CC does is not write code but verify the gate—confirm that the task order on disk matches the issued version. If the issued commit doesn't match, the entry clearly states: stop immediately, do not guess or self-fix, write status Blocked and wait for PM ruling.

After September 29, the entry was upgraded to 53 lines, all additions being checks: pinning the issued commit SHA, requiring the SHA's parent commit to exactly equal the business baseline, and pinning the file fingerprints of three certificates. Reading the task order doesn't read from disk but uses git show to fetch directly from the issued commit—even if the file on disk has been modified, what is read is guaranteed to be the issued version.

The executor also needs to install specified skills. The creator used the Superpowers plugin (version 6.3.0), with both AIs installing the same version. The most frequently required skills include: writing requirements and specs, executing per plan, red-green-refactor (TDD), and verification before completion. The skills' wording is strict: "No product code without a failing test first" and "No claiming completion without fresh verification evidence." If skills conflict with the task order, follow the task order—the task order constitution and PM rulings take precedence over skills.

Independent Acceptance: The Most Valuable Step

Before submitting for review, the executor reviews its own work first, but the file header clearly states "this is a factual record, not an acceptance conclusion." The main agent dispatches two read-only sub-agents: Review A looks only at accounting formulas, database permissions, and locks; Review B looks only at interfaces, frontend, and accessibility. The two reports had no overlap, but there was one defect neither could read out—it was found by running the browser. "Two copies of the same fact are hard to detect as having diverged by reading; running reveals it."

PM acceptance trusts only evidence. Once, CC self-reported a test line ratio of 0.966, exceeding the limit; PM did not grant an exemption but directly returned it. Return is not just a verbal "fix it"; it's a new remediation task order, with the baseline being the rejected candidate version, each remediation item bound to a review conclusion, and hard-coded "no relying on sleep luck; must see real blocking with your own eyes."

The final hurdle: PM didn't just read reports but confirmed mutation testing during acceptance—deliberately breaking the code to see if tests catch it. Only after all this was ACCEPTED written.

Across the entire process, PM conclusion statistics: 24 returns, 18 passes (including partial and limited acceptance). The top reason for returns was not business logic but insufficient evidence—missing screenshots, wrong reports, tests that didn't actually work.

Mutation testing is a method for evaluating the effectiveness of test cases. It deliberately introduces small errors (mutations) into the code and then runs the test suite to check whether the tests can detect these errors. If tests fail to catch a mutation, the test cases are insufficient. In this project, PM confirmed mutation testing during acceptance to ensure tests not only pass but actually detect potential defects. This is more reliable than relying solely on test pass rates, especially in financial scenarios with extremely high accuracy requirements.

Code Iron Rules and Gates: 59 Lines of Hard Constraints

The project constitution has an "anti-north-star": page count, code volume, empty-shell modules, and green tests cannot masquerade as real delivery. But the creator admits: "This constitution is still a draft to this day; what's actually in effect are the specific rulings I've added one by one."

What controls AI coding style is 59 lines of code iron rules: a hand-written file has at most 300 effective lines of code, a function at most 50 lines, no more than 10 branches, no more than three levels of nesting, no more than 5 parameters. Compressing code by cramming multiple statements into one line to evade limits is prohibited. Financial-specific rules include: amounts must not use floating point (0.1 + 0.2 ≠ 0.3); the same accounting event in the same ledger is recorded only once; posted vouchers cannot be directly modified or deleted—only reversed or appended.

Iron rules are text; gates are code. The number 300 is written directly into scripts; exceeding 300 lines fails the quality gate directly. WFC itself hit this—two migration files were too long and were blocked, so they were split into four. It didn't relax the gate but split along natural seams.

All checks have a single entry point: the Verify script, with four targets—backend, frontend, end-to-end, and quality—any failure returns a non-zero exit code. The gate also reports its own blind spots each run, such as approval thresholds, tax rates, and account numbers written as pure numbers that static scanning can't catch—the comment says "so green lights won't be mistaken for proof of full compliance."

Three Tiers: From Personal Projects to ERP Level

This method doesn't need to be copied wholesale. The creator offers tiered recommendations:

• ERP level: long task orders pinning file fingerprints, PM recalculation and mutation testing, all 11 gates open.
• Ordinary business projects: 30 to 60 line task orders, one Verify command, and another model reviewing changes and test results.
• Personal small projects: even two conversations in the same model works; the key is to write it down, don't skip. 10 to 20 line task orders specifying goals, non-goals, and completion criteria.

The minimal starter pack has six files: entry file (who writes, who verifies, what to read first), iron rules (within five), task order template (goals, non-goals, files that can/cannot be changed, ending status), execution record (which commands were run, how many times, results), review record (one of three conclusions), and one verification command. Any step failing returns non-zero.

"AI makes mistakes—it made many this month. What I can do is ensure detected errors are blocked before merging into the mainline. Vibe coding is not about letting go; it's about checking in a different way; two AIs are not about replacing each other but about watching each other."

The Cost and Lessons of Dual-Model Collaboration

This method is not without cost. Wave C was returned three times in one day, about 13 hours; financial-related task order files numbered 64, execution records 188; the two AIs don't talk directly, and every round relies on human relay. But the creator believes it's worth it: "CC won't collapse after three returns; PM also writes omissions and mistakes; rules are patched as we go; everyone is learning by doing."

For any developer trying Vibe Coding, this method provides an actionable framework: start with the minimal starter pack, and add tiers as the project grows complex. Try writing a task order first—it may be a better starting point than letting AI write code directly.

One-line Summary

Two AIs collaborating for 29 days with 578 commits and zero hand-written code completed an ERP financial module, ensuring code reliability through document handoffs and independent acceptance.

Paragraph Summary

This article introduces a Bilibili creator's practice of using two AI models to collaboratively develop an ERP financial module. In 29 days, two AI models (PM model and execution model) completed 578 commits through Markdown document handoffs in Git, with zero hand-written code throughout. Core methods include: task orders as contracts pinning authorized baselines, start gates and modification boundaries; code iron rules limiting file lines and function complexity; independent acceptance trusting only reproducible evidence; and tiered configurations adapting to different project scales. Despite costs like frequent returns, the method remained robust in strict accounting scenarios requiring debit-credit balance, providing an actionable framework for Vibe Coding.