Building Pi With Pi

Two posts in one from Armin Ronacher: what agent-generated contributions are doing to an open source tracker, and how he uses his own agent, Pi, to cope with them. Pi is now part of Earendil, and it auto-closes issues and pull requests from non-approved accounts, which gave him a clean number to pull.

Over 90 days, 3,145 external issues and PRs arrived from outside the team. 2,504 were auto-closed. 17% were reopened, rising to 26% if you count issues later referenced by a merged PR or main-branch commit. For pull requests specifically it is worse: 60 of 714 auto-closed PRs were eventually merged, about 8%. So the blunt filter throws away real work, and he is clear that it still beats the alternative.

The Pi-on-Pi workflow is three custom prompts. /is analyses a GitHub issue by independently reproducing the behaviour and deriving a diagnosis from the code, deliberately ignoring the reporter’s own analysis, because the analysis is the part most likely to be machine-generated and wrong. A prompt-url-widget extension surfaces issue metadata and keeps several parallel investigations visually distinct. /wr wraps up: changelog, draft comment, commit with the right references. He runs several Pi windows at once and then works through the results sequentially.

The line that carries the argument puts the responsibility on the submitter rather than the platform:

If your clanker shits on someone else’s issue tracker then it’s not the fault of GitHub, it’s yours alone.

What he wants is issue reports condensed to what the human actually observed, with the speculation stripped out. Read alongside DHH on letting agents in, which argues the opposite from principle rather than from tracker data.