Armin Ronacher’s latest post on lucumr.pocoo.org looks at what happens when Pi is used to build Pi, and the answer appears to be a lot messier than a tidy dogfooding story. He argues that issue reports now arrive not just as human observations, but as machine-rewritten narratives that can introduce confident but inaccurate diagnoses before anyone has verified the bug.
From there, Ronacher turns to the knock-on effects inside the codebase itself. He warns that LLM-assisted fixes often try to “handle” bad states by adding tolerant readers, fallbacks, migrations, and extra tests, when the better move may be to make the bad state impossible in the first place. In his telling, that tendency pushes systems toward needless complexity rather than toward clearer invariants.
The post also points to a growing volume problem. Ronacher cites the last 90 days of public GitHub tracker data for Pi, excluding Earendil members, and notes 3,145 external issues and pull requests, with 2,504 auto-closed as coming from non-approved contributors. He adds that 17% were reopened, or 26% if commits and merged PRs are counted, while only 60 of 714 auto-closed PRs were eventually merged.
He also sketches how Pi tries to cope with that workload using parallel investigations. A custom /is prompt, a URL widget, and a matching wrap-up flow are used to keep issue reproduction and follow-up work organized across multiple sessions. Ronacher’s larger argument is that open source now faces more code, more projects, and more noise — and that the answer is shared foundations and human coordination, not isolated machine-driven workarounds.
