Dark Factory LLM Wiki

This wiki is a curated synthesis; source cards remain the provenance layer for checking exact claims.

The initial ingest compiles point-in-time repository snapshots; repository claims should be refreshed before current operational decisions.

Independent convergence is plausible from the sources, but the evidence is a small cluster of related implementations and specs.

Dark factory rhetoric minimizes human code reading, but practical systems still need humans to define intent, gates, threat models, and acceptable risk.

Human gates may be necessary, but too many gates recreate the manual bottleneck.

Disposable generated code sounds freeing, but the runner, tests, and observability stack become critical infrastructure.

"Do not read code" creates a security problem unless validation can catch unsafe behavior and supply-chain drift.

DOT is simple and inspectable, but complex software lifecycle graphs can still become hard to reason about without schema validation and visual conventions.

LLM-maintained synthesis compounds learning, but can also compound stale or mistaken synthesis unless source cards and logs stay current.

Natural language specs are accessible to agents and humans, but ambiguity must be controlled with validation and examples.

A software factory can still include human reading and manual approval; dark factory is a more aggressive variant.

It automates worker feedback loops, but its README still reserves merge/review and portability decisions for human judgment.

The runner can be considered disposable relative to the graph, but runner correctness is still load-bearing for safety and reproducibility.

Observability can diagnose failures after the fact, but it does not by itself prove generated code is safe.

Simulation can improve validation fidelity, but it can also hide production-only failure modes if the twin is stale or incomplete.

Repair loops reduce human debugging burden, but a wrong diagnosis can send agents into repeated ineffective fixes.

Attractor is described as a system, but the cited repository is primarily a specification corpus.

Human code review catches design and security issues that tests may miss; dark factory systems try to move that assurance into automated gates and independent review.

A wiki preserves synthesis but can go stale; RAG preserves access to raw material but can repeatedly miss the same synthesis.

Treating code as disposable is useful for generated implementations, but production systems still depend on correct executable code at runtime.

Overusing tools can make the graph rigid; overusing LLM nodes can make runs expensive, nondeterministic, and hard to debug.

The post says the factory code is disposable, but its examples also show substantial runner architecture and validation behavior that must be implemented carefully.

This source mixes product narrative, implementation notes, and advocacy. Treat claims about what is "the product" as a position, not a settled industry standard.

The post says pipelines are the durable artifact, while dan-shapiro-you-dont-write-code-2026-02-13 emphasizes validation systems and factory operation.

The article argues humans must stop reading generated code, while also foregrounding security and quality problems that require stronger validation systems.

This source is narrative and observational. It reports specific StrongDM practices but does not provide formal specifications or implementation details.

It presents an aspirational lights-off model, but the examples still imply human judgment at the level of factory design, bootcamps, validation policy, and tool building.

The fork is framed as zero-touch automation, but the README still reserves review/merge and portability decisions for human judgment.

This source is a fork README plus architecture doc, not a stable API contract.

The fork has environment-specific assumptions; future agents should not copy its defaults without checking portability.

The README describes runner code as disposable, but the repository contains substantial engine, validation, observability, and benchmark code that future implementations should study.

This is an implementation repository and contains claims about its own state of the art; use it as implementation evidence, not as independent proof that the pattern is universally validated.

The observed commit is a point-in-time snapshot. Re-run repository inspection before making current operational claims.

The gist encourages LLM-owned wiki maintenance, but durable usefulness still depends on human source selection and review.

The gist is an idea file, not a formal standard.

The pattern does not eliminate the need for source verification, contradiction handling, or human correction.

The repository is framed as Attractor, but the visible artifact is a set of natural-language specifications rather than a runnable implementation.

The source is a repository with specifications, not proof that any particular generated implementation is correct.

Claims about production use need separate operational evidence beyond this repo.

Automated validation can reduce code reading, but security-sensitive changes still need human-owned policy and periodic audit.

DOT can describe both agent work and deterministic tooling, so the mapping is not one node equals one agent.

Different sources emphasize different durable layers: DOT graphs, specs, validation systems, observability, or the whole factory.