A few dark factory patterns · Chris Parmer
Ever since the release of Fable, I've been experimenting in "dark factory" software development where I direct coding agents to build serious, sophisticated software projects without looking at their code.
Experimenting is the key word: these experiments were on greenfield projects and prototypes, things that have been on my back burner for years and realistically would need to rewrite again before they saw the light of day.
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, inconsistencies 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 refactor) 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).
Without further ado, here's what I've come with so far. Please enjoy.
# Code Style:<br>1. Write unit-testable, mostly functional code.
2. Red/green TDD
3. Parametrize tests (i.e. cross product)<br>to keep them tight while exhaustively testing all cases
4. No defensive programming.<br>Do not worry about backwards compatibility within<br>the codebase as you make changes.<br>The project is in version 0.0.x.<br>Do not document "what used to happen"
5. Refactor code. Survey code before<br>working and consider ways you can build<br>the feature or fix the bug by refactoring code,<br>rather than just adding new code.<br>PRs should have a healthy mix of deleted<br>LOC alongside new LOC.
6. UIs should meet accessibility guidelines
7. Constants, copy, formulas, config should be in their<br>own files so that they are easy for humans to<br>audit and review
8. All text (UI, docstrings, PR descriptions) should use<br>Simplified Technical English (STE) with complete sentences.<br>No metaphors, em-dashes, personifications, or aphorisms.
# Enforced & Precommit Checks:<br>1. Limit:<br>- max lines per file to 400,<br>- max lines per function to 100,<br>- 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,<br>maintain code coverage >95%
5. Gate cognitive complexity at 15,<br>nesting depth at 4 programmatically.<br>Use e.g. ruff C901 plus flake8-cognitive-complexity in Python<br>or sonarjs/cognitive-complexity.<br>Be careful about over-optimizing this<br>(e.g. avoid private helpers when inlining would be OK)
6. Run and configure these checks in a Makefile,<br>don't do these as one-offs.
7. CI should run ` folder,<br>and a browser automation script that uses<br>and takes screenshots of the feature or fix.
Save the screenshots to the repo.
2. CI should take these screenshots and assure that<br>nothing regressed from previous features (