A few dark factory patterns Dan Shapiro, in a blog post, shares a set of project guidelines for 'dark factory' software development, where coding agents build projects without human code review. He notes that projects tend to fall apart around day 6 or 7, with patches taking longer and inconsistencies emerging, and his guidelines aim to tame the chaos by enforcing code style, precommit checks, workflow practices, and screenshot tests. A few dark factory patterns Ever since the release of Fable, I've been experimenting in "dark factory" https://www.danshapiro.com/blog/2026/01/the-five-levels-from-spicy-autocomplete-to-the-software-factory/ software development where I direct coding agents to build serious, sophisticated software projects without looking at their code . If I don't look at the code, I find that the projects start to fall apart at a certain size; usually at about day 6 or 7 of the project. Patches and features take longer to implement, inconstancies in the UI begin to emerge, multiple agents begin to trip on each other, and it becomes harder to manage and direct the work to be done. And I find that I transition from feeling intoxicated and excited about the progress to feeling almost nauseous and uneasy about what's actually going on in there. Designing an outer loop is an exercise in correcting idiosyncrasies in the default behavior of coding agents today e.g. they tend to create really big files and rarely and finding ways for them to present their work to you in a format that you can keep up with and trust their unit tests are often BS, but screenshot demos rarely lie . Here is the set of project guidelines that I've developed as part of these experiments to help tame the chaos while keeping the system simple. Please enjoy. Code Style: 1. Write unit-testable, mostly functional code. 2. Red/green TDD 3. Parametrize tests i.e. cross product to keep them tight while exhaustively testing all cases 4. No defensive programming. Do not worry about backwards compatibility within the codebase as you make changes. The project is in version 0.0.x. Do not document "what used to happen" 5. Refactor code. Survey code before working and consider ways you can build the feature or fix the bug by refactoring code, rather than just adding new code. PRs should have a healthy mix of deleted LOC alongside new LOC. 6. UIs should meet accessibility guidelines 7. Constants, copy, formulas, config should be in their own files so that they are easy for humans to audit and review 8. All text UI, docstrings, PR descriptions should use Common Technical English CTE with complete sentences. No metaphors, em-dashes, personifications, or aphorisms. Enforced & Precommit Checks: 1. Limit: - max lines per file to 400, - max lines per function to 100, - max files per folder to 8 2. Use code formatters and linters e.g. ruff, eslint, prettier 3. Check and remove dead code programmatically e.g. vulture 4. Run code coverage tests programmatically, maintain code coverage 95% 5. Gate cognitive complexity at 15, nesting depth at 4 programmatically. Use e.g. ruff C901 plus flake8-cognitive-complexity in Python or sonarjs/cognitive-complexity. Be careful about over-optimizing this e.g. avoid private helpers when inlining would be OK 6. Run and configure these checks in a Makefile, don't do these as one-offs. 7. CI should run <5 minutes. Parallelize or do selective testing to achieve this, don't reduce test or e2e coverage. Workflow: 1. Stack PRs for larger features. 2. In general, PRs should be less than <1,000 lines of code aside from tests 3. PRs should describe: - before/after - approach - alternatives considered, incl approaches taken in other projects or literature - all assumptions made: business logic, constants, semantic definitions or assumptions, decision points, etc. This software exists within a greater organization and reviewers will need to be aware of and responsible for decisions made, so communicate these so that they can direct and support accordingly. 4. Only fix the main issue at hand. If you find additional issues while working, log the issue in github and tag it with the subfeature Screenshot Tests & Changelog These guidelines are used to prove to the reviewer that the feature works or the bug is fixed. Think of this as an repeatable demo. 1. Create an interactive "Changelog" demo app that showcases the feature or the fix, with example s in a changelog/