The close lands before any maintainer has an opinion about the code. Flue's contributor guide says the project is going to "try to reimagine things," and names what it is reimagining away from: "Drive-by AI slop PRs" [4]. Schott puts it more kindly. "If you submit a PR, no hard feelings, we're just going to go and represent it for you as issues and discussions" [5]. The report describes the effect as treating incoming requests as leads rather than as a piece of work a maintainer feels obliged to review [6]. What the contributor loses in that translation is the diff as evidence of competence.
Vercel's version keeps pull requests open and changes who writes them. The agents are split by task, one reproducing a bug, another applying a fix, another reviewing it [10], with a human doing the merge at the end [7]. The reason Vercel gives is trust rather than throughput [11]. "If we have a very specific agent with a very specific prompt that we optimized, and we know that, over history, it was very successful in fixing a certain category of bugs, then we develop trust in that particular agent configuration," engineer Lars Grammel said [12]. His advice to other maintainers was to run their own agents and setup "and not necessarily trusting the community, because it can actually cut down your time to review" [13]. Flue's guide describes the same pairing from the other end, the team's own expertise plus "the best available SOTA LLMs that we have access to" [21].
The percentages are Vercel's own, measured four weeks in on a package it puts at over 20 million npm downloads a week [8]. Subtract the authorship range from 100 and the other side of it appears: 65 to 75 percent of merged pull requests still come from somewhere other than the factory [1]. The issue number is the louder claim and the vaguer one, because closing 70 to 80 percent of issues [15] says the queue moved, not that the reporter ended up with working code. Astro is more specific on that point, since its automation gets the user to verify the bot's suggested fix before maintainers look at it [18], and Schott's stated win is scheduling rather than volume, treating issues as "a thing that every week, you prioritize" instead of a backlog under constant trimming [19]. That auto-triage work, on a project with 62,000 GitHub stars [16], is what led him to build Flue [20]. The shape of the backlog it grew out of is worth noting too: almost 800 pull requests against just over 1,000 issues is about four patches for every five reports [2].
Two axes sort this for a project smaller than either of them. The first is where review time actually goes, into reproducing what users report or into deciding whether to trust code nobody on the team wrote. The second is whether the project has an agent configuration with a history on the bug class in front of it. Reproduction cost plus a tuned agent is Vercel's cell, and the factory earns its keep there. Trust cost plus a tuned agent is Flue's cell, where closing the pull request removes the expensive step and the maintainers' own agent writes the patch instead. Reproduction cost with no tuned agent means building the infrastructure first and getting relief later. Trust cost with no tuned agent is the cell to be careful in, because closing pull requests there relabels the same backlog as issues, with less code attached and the same people reading it.
