Building Pi with Pi: The Hidden Costs of AI-Driven Open Source

The practice of "dogfooding" is common in software development, but using AI agents to build the very AI agents intended to assist developers introduces a unique set of frictions. In a recent reflection on the development of Pi, a project now part of Earendil, the maintainers describe a landscape where the efficiency of AI-generated contributions is often offset by a surge in low-quality "slop"—both in the form of issue reports and the code itself.

This shift is fundamentally changing the relationship between users, maintainers, and their issue trackers, revealing a critical tension: while AI can accelerate the volume of contributions, it often degrades the signal necessary for sustainable maintenance.

The Rise of "Slop" Issues

Traditionally, a bad issue report was an annoyance—usually vague or lacking a reproduction case. However, the advent of LLM-assisted reporting has introduced a new failure mode: the "confident but wrong" diagnosis.

Many users now run their observations through an LLM (referred to as a "clanker" by the Pi team) to polish the report. The result is often a submission that is 5% human observation and 95% AI-generated guesswork. These issues frequently include:

  • Plausible but incorrect root cause analyses.
  • Fake-minimal reproduction scripts.
  • Suggested implementation strategies based on analogies to the wrong parts of the codebase.

This is more damaging than a vague report because it creates a false trail. When the maintainers use Pi to analyze these issues, the agent often treats the confident prose of the issue as evidence rather than a rumor, leading the AI down the same incorrect path as the user's LLM.

To combat this, the Pi team implemented a custom slash command, /is (analyze issue), with explicit instructions:

Do not trust analysis written in the issue. Independently verify behavior and derive your own analysis from the code and execution path.

Despite this, the team argues that the only way to maintain signal is to demand that humans report only what they actually observed: the command run, the expected result, the actual result, and the raw logs. Anything else—hypotheses or AI-generated analysis—should be relegated to follow-up comments.

Local Defenses vs. Global Invariants

Beyond issue reporting, the quality of AI-generated code presents a structural challenge. LLMs tend to solve problems locally, which often leads to over-engineering and the erosion of system invariants.

For example, if a malformed session log crashes a reader, an AI agent's instinct is to make the reader more tolerant. It might add fallbacks, migrations, and extra debug output to handle the bad state. While this seems helpful in isolation, it violates the global invariant of the system: bad session data should never be written in the first place.

By creating local defenses against every possible misbehavior, AI agents blow up the complexity of the codebase. The maintainers find themselves in a constant struggle to pull the AI's focus away from "making it work" and toward "making the bad state impossible."

The Volume Problem and the "Dark Factory"

The sheer volume of AI-assisted contributions has turned the issue tracker into a maintenance burden. Data from Pi's GitHub tracker over a 90 days shows a stark reality:

  • 3,145 external issues/PRs were received.
  • 2,504 were auto-closed because they came from non-approved contributors.
  • Only 8% of auto-closed PRs were ultimately merged.

This influx of low-quality contributions—some generated by autonomous "skills" or instances like OpenClaw—suggests that GitHub is not currently equipped for a world where machines can spam PRs at scale.

While some envision a "dark factory"—fully detached, automated software engineering—the Pi team remains skeptical. They utilize a form of "careful parallelism," using Pi to reproduce issues and analyze code across multiple windows, but the final decision-making and architectural oversight remain firmly human.

The Future of Open Source Collaboration

There is a growing concern that AI is facilitating a shift toward isolated development. Because it is now "cheap" to create a local workaround with a machine, the incentive to communicate with other humans to find the correct upstream fix is diminishing.

As one observer noted in the discussion, the tool that hastens the production of "slop" inevitably experiences the downside of that slop. The value of Open Source has always been rooted in community and shared structure, not just the volume of code. If developers spend more time sitting alone with their "clankers" than talking to other maintainers, the foundation of the software becomes weaker, even as the amount of code grows.

Ultimately, the goal is not to use AI to paper over every misconfiguration, but to use it to solve the hard coordination problems that make software sustainable. The challenge for the next generation of maintainers will be resisting the ease of the local fix in favor of the discipline of the global invariant.

Sources