LLM patches collapse the contributor feedback loop

Open a pull request and somewhere between the diff and the final merge a human apprenticeship happens. The tiny comments — “why this approach, not that one?”, “you broke this edge case, did you consider X?”, “next time add a small benchmark” — are not incidental; they are the carrier wave for tacit knowledge about the codebase, the social contract of the project, and the developer’s mental model. Loris Cro, Zig Software Foundation’s VP of Community, put it succinctly when he described the project’s policy as a deliberate investment in contributors: “the primary goal of reviewing and accepting PRs isn't to land new code, it's to help grow new contributors who can become trusted and prolific over time.” That framing — contributor poker, not card counting — is why Zig has one of the strictest anti‑LLM policies in open source: No LLMs for issues. No LLMs for pull requests. No LLMs for comments on the bug tracker. It feels blunt, but it’s solving a precise problem. When a patch is produced by a generative model, the diagnostic trail collapses. The chain of intent, the incremental failures, and the conversational scaffolding that reviewers use to teach are replaced by a polished artifact with no history of iterative reasoning. Reviewers then face a binary choice: spend time verifying and correcting a finished artifact, or refuse the contribution and demand provenance — either way, the time spent does not increase the project’s human capital. The practical costs show up fast. As Cro noted, the Zig project saw an influx of drive‑by PRs that were either nonsense or enormous, including “insane 10 thousand line long first time PRs.” Those aren’t just annoying; they soak up reviewer hours in triage and correctness checks without leaving behind an apprentice. If the PR author used an LLM and never internalizes the feedback, the review is a one‑shot transaction: the project pays the cost, the model gets better, but the human contributor does not. That asymmetry is the heart of Zig’s decision: when contribution volume outstrips available reviewer attention, you have to choose whether each review is an investment in future returns or a sunk cost. LLM‑authored patches turn many reviews into the latter. This isn’t merely a cultural complaint. The software engineering literature treats code review as a learning mechanism. Recent empirical studies show that newcomers receive different review patterns, and that code review is a reliable site for onboarding and tacit knowledge transfer. Papers that analyze review dynamics find consistent evidence that review feedback supports socialization into a project’s norms and technical context; mentors use reviews to surface hidden invariants and design rationales that are not present in code alone. Remove the conversational partner who can learn, and you remove the mechanism that turns a review from corrective labor into mentorship. Think of it this way: when a student hands in a homework assignment, the value of marking isn’t simply the grade; it’s the teacher’s commentary, the pointer to the misunderstanding, and the follow‑up assignment that embeds the lesson. LLM patches are like graded homeworks where the student never sees the teacher’s notes — or worse, where the student hands in someone else’s homework. The teacher is left to verify answers they cannot reasonably trace back to a student’s mental model. There’s a second, subtler failure mode: conversational scaffolding matters for safety and maintainability. Reviewers don’t just check whether tests pass; they want to know why a particular implementation was chosen, what tradeoffs were considered, and what cases the author thought through. That reasoning is often communicated in PR descriptions, small iterative commits, and follow‑up comments. An LLM can generate a convincing “why” at the time of the PR, but without an iterative dialogue the authenticity of that rationale is unverifiable. Reviewers end up chasing provenance or rewriting the patch themselves — which is exactly what Cro observed: if the maintainer can get the same or better result by firing up their own LLM, why invest scarce mentoring bandwidth in an anonymous author who won’t benefit long‑term? This tension shows up in practice beyond policy essays. The Bun JavaScript runtime — now part of Anthropic — made heavy use of AI assistance and implemented a large performance improvement to its Zig fork that Bun said it would not upstream because Zig forbids LLM‑authored contributions. The juxtaposition is instructive: firms optimizing for immediate throughput (faster compile times, shipped features) will use LLMs aggressively; projects optimizing for sustainable community growth (trusted maintainers, repeat contributors) will refuse them until the social mechanics can be preserved. Where does this leave the middle ground? The right long‑term solution is not a permanent ban on machine help, but tooling and norms that restore the feedback loop. That means provenance: authenticated, auditable traces that show which lines were authored by a human, which by a model, and what prompts or iterative interactions produced them. It means conversational agents that can be part of the iterative review process rather than a one‑off patch generator — agents that can accept reviewer feedback and adapt, or that expose their chain of thought and the counterfactuals they considered. Finally, it means clear expectations: if contributors use models, they must treat them as pair‑programmers who are accountable to the same apprenticeship dynamic — show your work, respond to comments, and internalize feedback. Zig’s policy is therefore not technophobia; it’s a choice about capital allocation. Reviewer time is finite and reviews are investments. When those investments compound into future contributors, the project scales. When they dissipate into verifying sealed artifacts, the project pays the cost and gets nothing of long‑term value. The debate is an important sanity check for the broader ecosystem: if your project measures success by future maintainers rather than immediate merges, you should be skeptical of PRs that cannot participate in a dialogue. LLMs are powerful tools, but right now many of the workflows they enable are orthogonal to what large, mentor‑driven open source projects need. Until models and workflows explicitly preserve the diagnostic trail and make feedback a first‑class signal — not just a human afterthought — projects that care about the future of their contributor base are justified in prioritizing human learning over instantaneous throughput. That bet may look conservative in the short term, but it’s how you turn one‑off code into collective expertise. Pulling this back: code review has always been about more than correctness checks; it is how communities transmit judgement. Zig’s ban is a clear, operational verdict on whether current LLM‑authored patches participate in that transmission. If you care about the project’s next decade of maintainers, check the provenance before you check the patch.