Why Software Factories Fail (or: harness engineering is not enough)
AI-powered “software factories” that aim to generate and ship code with minimal human involvement are running into hard limits around code quality, maintainability, and long‑term design. Commenters argue that while modern models can produce impressive features and refactors, they tend to accumulate architectural “slop” without strict human-guided planning, verification, and taste — especially in large, evolving codebases. Many see the most promising path as high-discipline teams using agents as force multipliers within strong specs, testing, and review processes, rather than fully “lights‑off” automation.
State of “software factories” and StrongDM context
- Some commenters note StrongDM’s AI work spun out into a consulting firm, interpreted either as success (ideas valuable) or as a sign the product needed heavy services.
- A StrongDM lab member clarifies their “weather report” has seen regular updates and claims most software problems yield to their factory techniques, especially with newer models.
- Others argue we’re still in early, experimental days; no stable “standard methodology” yet.
Rigor, maintainability, and specs
- Broad agreement: teams that get the most from AI already had high discipline, clean code, tests, and hygiene.
- Many see maintainability as the core unsolved problem: models can implement features but slowly degrade architecture and coupling over time.
- People explore RFC‑style, normative specs and typed constraints to bound agents, but note that very detailed specs start to resemble code and don’t clearly save effort.
- Some propose RL setups that reward long‑term codebase health, but note there is no fast, objective oracle for “good design.”
Code review, PRs, and process
- Strong split on code review:
- One camp believes human review is essential for knowledge sharing, taste, design oversight, and compliance; using LLMs to fake reviews is seen as dereliction.
- Another camp automates reviews and claims organizations mostly care about bug prevention and speed; argues we should review running software, not diffs.
- Many complain about PR UX, oversized agent‑generated diffs, and “LLMese” comments.
- Some advocate minimizing PR gates via heavy automated checks, tests, linters, and easy rollback; others argue these still miss architecture and backwards‑compatibility issues.
Model capabilities, RL, and long‑context
- Disagreement on how much frontier models (Opus, Fable, GPT‑5.6, etc.) changed the game. Some report handing agents whole features; others say lights‑off attempts still produced slop or self‑reinforcing bad designs.
- Several observe models can refactor well when explicitly asked, but don’t autonomously notice when refactors are needed.
- Long‑context behavior is mixed: some see little degradation; others show examples of models forgetting simple workflows in large contexts.
- Many emphasize that RL today mostly optimizes for task success, not design quality, so reward hacking and brittle tests are common.
Role of engineers and “taste”
- Multiple comments frame a software engineer’s main job as system ownership, long‑term design, and taste, not just typing code.
- Good architecture is described as subtle, hard to measure, and learned through painful experience; commenters doubt current models can reliably make these design judgments.
- A recurring theme: codebase patterns act as “implicit prompts,” so humans must vigilantly guard abstractions and patterns or slop accumulates.
Where factories may work today
- Many see “dark factories” as more viable for:
- Small, low‑stakes or hobby apps.
- Short‑lived experiments and scripts.
- For complex, revenue‑bearing, or regulated systems, most argue for human‑in‑the‑loop factories, with more upfront planning (product, system, program design) and tighter constraints, not full autonomy.