What's this about?
The author of Mole shared engineering practice from an entirely AI-generated codebase: at version 1.13 it has roughly 110,000 lines of Swift product code, 73,000 lines of test code and 3,347 XCTests, up from 56 tests at 1.0. His stated principle is that AI-written code should be tested by AI, not by people, because putting humans in that loop slows everything down. What he cares about is not the test count but whether the tests cover the places you would take for granted: files changing after the scan finished, process checks failing, a command returning success while the app did not actually update, an old task returning late and overwriting a newer result.
Why does the test-to-code ratio matter here?
Because tests are the mechanism that lets you stop reading the code. If a human is not reviewing every line, something has to hold the system honest, and an executable specification is the only candidate that scales with generation speed. 73,000 lines of tests against 110,000 lines of product code — roughly 66% — is far above typical for a solo project, and it is the price of not reviewing.
What's the community saying?
- Architecture, layering and abstraction still need the engineer's judgment; settle them with your best model once the first version runs, and record the decisions in a document that evolves with the project.
- Add a test whenever you fix a bug, so the same class of failure cannot recur.
- Accumulate fewer features, and delete the code when a feature is removed.
- Use CI to run the full automated test suite on a clean cloud machine before every release.
- Let AI run its own verification and correction loop; put humans only at the stages that need them.
- Turn anything you repeat into a skill so you are not re-explaining it every time.