A solo founder used a formal AI doctrine to log 984 commits in 58 days

Michel Faure tracked every metric from a 60-day sprint with Claude Code on a production ERP. His playbook isn't about AI hype, but about building a verifiable audit trail for development.

An investor asked Michel Faure a simple question about his AI-assisted development velocity: "What's that based on?" Instead of a narrative, Faure produced a material inventory. Over sixty days of solo work on a production ERP, he claims to have logged 984 commits, averaging sixteen per active day. The project accumulated a reported 131,628 lines of code.

These numbers come from a detailed public blog post where Faure documents his methodology. The core of his work is not just using an AI code assistant, but building a rigorous, documented, and versioned system to manage its use. Most accounts of AI development are brief demos or vendor announcements. A field report with this level of claimed numerical detail is rare.

A material inventory, not a narrative

Faure’s response to his investor is grounded in specific, auditable (if unverified) metrics. He reports working 58 out of 60 calendar days. The output from this period includes 984 commits and 131,628 lines of TypeScript, TSX, JS, and JSX, measured with a command-line script.

Beyond code volume, the system produced a significant governance footprint. Faure reports writing 74 formal architecture decisions and executing 276 Supabase migrations. This documentation provides a traceable history of the project's evolution, moving beyond the ephemeral nature of a prompt-and-response session. The goal was to create a record that could be audited later, by an investor or a future engineering hire.

Versioning the AI piloting doctrine

The most distinct part of Faure's playbook is the formalization of his interaction with the AI. He created what he calls an "AI piloting doctrine," a set of 18 project-specific rules stored in the repository. This doctrine was not static. He reports that it evolved through nine distinct versions over the 60-day period, from v0.2 to v0.7.

Each version was updated in response to a specific incident, failure, or new understanding. This iterative process, complete with documented retractions and acknowledged version skips, treats the human-AI interaction itself as a piece of software that requires maintenance and upgrades. The doctrine governs how the AI is prompted, how its output is verified, and how its contributions are integrated.

An audit trail for every decision

To support the doctrine, Faure maintained a detailed log of his work. He documented 44 distinct development sessions in the project's docs/ folder. This practice ensures that the context for a specific block of code or architectural choice is not lost. It creates an explicit link between a high-level decision and its low-level implementation.

This audit trail is the tangible answer to the investor's question. It provides a layer of legibility that is often missing from AI-assisted projects. The system is designed to prove that the high velocity of code generation is matched by a high degree of intentionality and governance.

WHAT WE'D CHANGE

Faure’s system is a masterclass in disciplined solo execution, but its metrics and methods have clear limitations. The focus on lines of code and commit frequency as primary output indicators is a known trap. These volume metrics say nothing about code quality, maintainability, or business impact. An AI assistant can generate thousands of lines of trivial or incorrect code, inflating output without creating value. The author himself notes the numbers "don't say what they appear to say," but a more robust playbook would incorporate tests, performance benchmarks, and user-facing outcomes.

This playbook was also designed for a single developer. Its reliance on intense personal discipline would be difficult to scale to a team. How do you enforce a unified doctrine across five engineers with different habits? How do you merge documented sessions or reconcile conflicting architectural decisions? Scaling this system from a personal methodology to an organizational process requires tooling and standardization that are not addressed in the post.

Finally, the analysis omits the cost of governance. The time spent writing 74 architecture decisions, documenting 44 sessions, and iterating on a formal doctrine is substantial. A complete assessment would weigh the claimed productivity gains against this significant administrative overhead. Without that calculation, the true return on investment remains unclear.

LANDING

What's at stake behind Étienne's question is less the performance of a device than the possibility of measuring it honestly. The most valuable asset produced during this 60-day sprint was not the codebase. It was the system for generating, documenting, and auditing that codebase. For founders building with AI assistants, the playbook is clear: the process you build around the tool is more important than the tool itself. Answering for your work requires more than just pointing to the volume of code produced; it requires a complete, verifiable inventory of decisions made along the way.

The investor read

For investors, an AI-heavy codebase can be an un-diligenceable black box. Faure's methodology signals a potential solution: treating the development process itself as a product with versioning, documentation, and a clear audit trail. This transforms AI-assisted coding from a source of opaque risk into a legible, governable process. It demonstrates extreme capital efficiency for a solo founder, but its real value is in de-risking the asset being built. While currently a bootstrapped playbook, a scalable version of this 'doctrine' could become a key indicator of engineering maturity for any team building with AI. It suggests a future where due diligence focuses as much on a company's AI governance repository as its source code.

Pull quote: “What's at stake behind Étienne's question is less the performance of a device than the possibility of measuring it honestly.”