Building a Set of Rules for My Dark Software Factory

By Joel Dare - Written August 13, 2026

My plan is to create a set of rules for my Dark Software Factory. Something I can put in the README at the root of the monorepo or into the CLAUDE.md file. The rules that govern every move the LLM makes.

I started with Haiku 4.5 as the model on this since I expected it to read over 200 short documents.

Here’s the prompt I started with:

I’m building a dark software factory. Loop through each of the md files in the root directory. Make a bullet list of rules for the dark factory. Example: “- Write minimal code”.

That went way too fast, so I tried again:

Make a list of every file. Go through them one at a time. Update this list with my personal philosophies about software, coding, or business.

That also went very fast, about 40 seconds. So, I asked it how many files it read. It had read 21. The ones it thought were most likely to contain the information. So, I asked it to read every file.

This is when I learned that Haiku 4.5 does not have an auto mode. I would need to manually approve every command.

Read every file. Continue adding to the list.

Haiku turned out to be the wrong model for the job. It consistently returned quick answers, ignoring my instructions to “read every file”. Always generating a list of files likely to contain this information instead of reading all of them.

For this project, and with no auto mode, the result was a painfully slow process compared to what I’m used to.

Reviewing the List

Reading through the list was awesome. It really did capture my philosophies well.

But, in this case, I’m trying to make a list of instructions for my Dark Software Factory. I needed to prune and edit the list for that purpose.

While editing manually, I found it hard to remove things that didn’t really apply to LLMs. These are my own philosophies and I believe in them. But, I know they aren’t all helpful and I need to reduce the list to the most important points and remove duplication. I need a simple list.

So, I switched to Opus 5, created a new session, and asked it to shorten the list for me.

Here’s a list of personal philosophies on software, coding & business. I’m building a list of philosophies to give to my Dark Software Factory. Reduce this list to a smaller set that would be useful to an LLM. Keep the most important items. Remove duplication.

[Pasted text +507 lines]

Once Opus had reduced it to the smaller list, I continued to edit manually, removing things I didn’t think made sense.

Here are the results after editing.

Rules for the Dark Software Factory

Build

Write the minimal viable program — the smallest thing that solves one problem, with nothing extra.
Prefer pure HTML, CSS, and vanilla JavaScript. No frameworks.
No build steps. Deploy with git push whenever possible.
Use semantic HTML and native browser components before custom ones — accessibility and SEO come free.
Default to static and local-first: no accounts, no backend, no sync. localStorage and PWAs over servers.
Choose boring, proven tech: Debian, Git, SQLite, Make, shell, plain text.
Minimize dependencies. Question every one. Small conveniences don’t justify them.
Build for 50 years. Plain text and standard formats outlive platforms.
Keep infrastructure visible and debuggable. No black boxes.
Simplicity scales. Complexity is what needs justifying. If you over-engineer, iterate back down to minimal.
Don’t over-engineer auth or enforcement up front. Basic Auth over HTTPS is good enough for internal tools; upgrade later if the thing succeeds.
Keep pages small. HTML under ~14kb compressed loads in one round trip.

Ship

Ship fast, ship small, iterate.
Do one problem really well instead of many mediocrely.
Half-baked is allowed. A rough thing now beats a polished thing later.
Trust users. Honor system over DRM. Charge even when you can’t enforce it.
Business is a long game. Execution and staying power beat the idea. Don’t shut down something that’s working.
Give a tool time to find its market before scaling it.

Write

Write “how I” stories, not “how to” instructions. Document what you did; don’t prescribe.
Write like a human writing to a friend. Personality over polish, value over decoration.
Hook in the first line with what’s in it for the reader. Be useful within 30 seconds.
Simplify to three steps. Threes are easier to understand, remember, and act on.
Start posts small and grow them only if they earn it.
Always include a byline and date.
Weave personal story into technical writing.

Own the Platform

The website is the hub and the durable asset. Everything starts there and gets pushed outward.
Markdown + Git + static hosting. No vendor lock-in, no security patches, near-free.
Boring templates outlive trendy designs.
Keep navigation minimal — a micro header and a home link. Heavy nav hurts comprehension and conversion.

Privacy and Data

Track only URL and timestamp. No IPs, no identifiers, no third-party pixels.
No tracking means no cookie banner and less code. Privacy engineering is cheaper than compliance.
Link to third-party forms; don’t embed them.

Working with AI

Break work into very small, tightly scoped steps. Small scope is where models are reliable.
Confidence is not correctness. Models hallucinate libraries and add bugs while fixing others. Verify.
Version everything with Git so changes can be correlated with results.

Working Style

Break big things into small tasks and start with the easiest one.
Reduce friction everywhere: aliases, one-liners, plain text files.
Minimize infrastructure to maximize creative bandwidth.