Inspecting the Spaghetti Software Factory

As the Factorio review described it, development with AI agents has come to resemble running a factory. Starting with a single Claude Code session, scaling to two, then four, and attaching worktrees, CLAUDE.md, skills, and MCP raises productivity, but the structure easily turns into spaghetti.

The problem isn't the speed of producing more code, but the fact that this code becomes input for the next agent session, teaching it to produce even worse code. As in the bookstore app example pointed out by Shriram Krishnamurthi, minor flaws pile up—using floating point for money calculations, building a new CSV parser instead of using the standard library, implementing actual search under a name like filterByTitle—and the entire codebase ends up reproducing slop. The write-only code problem raised by Joseph Ruscio follows the same pattern.

The core of the solution isn't just adding more documentation, but turning checks into an executable form. Markdown such as AGENTS.md, specs, skills, and plans is useful for writing down standards, but it can't enforce them. What's needed instead is a check that verifies each standard individually, structured so that an AI agent—rather than a human—reads it, examines the files, runs commands, and proposes a fix if it fails.

This approach is essentially the same as testing. For example, rules like "attach auth middleware to new endpoints," "leave a rationale when adding a dependency," or "check the dashboard if you touch the metrics pipeline" are verified at the semantic level rather than in code. In practice, agent checks catch issues that humans and CI tend to miss—such as a check that caught a telemetry event name change, or one that blocked hardcoded colors from entering the design system.

However, checks that only run locally soon reveal their limits. Prompt composition, context length, and tool configuration differ from person to person, and things get forgotten or skipped. An even bigger problem is silent drift. Once a few PRs pass with a bad pattern, the next agent writes more code that conforms to that pattern as the baseline.

So checks need to run on top of PRs, before merge, and visibly to the whole team. As Martin Fowler emphasized about CI, failures should be shared immediately and caught before a single warning accumulates into more. Only then can you prevent the codebase from slowly rotting from within.

As a next step, it's natural to think of putting these checks into CI. You can spin up Claude Code via GitHub Actions to evaluate .continue/checks/, and at first around 80 lines of YAML seems to be enough. But over time you end up needing background process management, stdout separation, avoiding API rate limits, JSON parsing fallbacks, debugging of terminated sessions, dashboards, auth, diff viewers, approval buttons, loop detection, and storage.

The problem doesn't end there. As the quality of checks becomes more important, a feedback loop becomes essential for knowing which checks actually catch real problems and which ones are just false alarms. Without metrics, checks quickly become fossilized or turn into pure noise, and eventually get turned off. On top of that, once you consider org-wide policies, integration with external signals like Sentry or Snyk, full-codebase scans, and triggers after PR merge, building it all yourself quickly becomes yet another spaghetti factory.

So the final conclusion is simple: write your standards into .continue/checks/, and run those standards as an engineering system. The authors present this as the direction of Mission Control. The complex nondeterminism, result parsing, concurrency, auth isolation, and loop detection are handled underneath, while the user focuses on creating checks, getting feedback, and improving them.

This flow ultimately converges on the Toyota Production System. Jidoka is automation with a human touch, kaizen is continuous improvement, and andon is the warning cord that stops the line. The structure itself—where code quality checks prevent a corrupted dashboard, get better through user feedback, and humans make the final call—is its modern implementation.

In conclusion, the faster the factory built by AI agents grows, the stronger the quality control it needs. The factory should grow—but growing for its own sake just turns it into spaghetti. To grow the factory properly, you have to put checks in place and keep inspecting.