I think it’s important to distinguish between descriptive and normative claims here. Nobody is disputing that AI exists, or that people will continue to use AI. That observation, while factually correct, doesn’t meaningfully address the underlying concerns regarding review burden, maintainer workload, long-term software sustainability, or governance challenges. The existence of a technology does not, in and of itself, imply that existing institutions have already adapted to it, nor does it imply that adaptation is trivial, inevitable, or costless.

Similarly, I think there’s a tendency to frame this as a binary choice between “adapt” and “die,” when in reality the situation is substantially more nuanced than that. Adaptation itself is not a single event but rather an ongoing process involving changes to community norms, tooling, contributor expectations, trust mechanisms, and review workflows. The fact that this process is occurring says relatively little about whether it is succeeding, who bears the associated costs, or whether those costs are being distributed equitably across maintainers and contributors.

Regarding disclosure, I broadly agree that attempting to prohibit AI tooling outright is unlikely to be effective over the long term. However, that observation does not eliminate the practical challenges introduced by dramatically increasing the marginal cost asymmetry between producing code and reviewing it. Even if disclosure disappeared entirely tomorrow, maintainers would still need to invest substantial cognitive effort into understanding, validating, testing, and integrating incoming changes. In other words, removing disclosure changes the visibility of AI usage but does not meaningfully reduce the review burden itself.

Likewise, while I agree that individuals ultimately attach their identities to pull requests, identity alone should not necessarily be interpreted as a proxy for trustworthiness or software quality. Trust is not merely an intrinsic property of an individual contributor but rather an emergent property built over repeated interactions, demonstrated competence, consistency, responsiveness to review, architectural understanding, and alignment with project goals. Consequently, shifting emphasis toward contributor reputation may indeed form part of a broader governance strategy, but it should not be viewed as a comprehensive solution to the broader ecosystem-wide challenges associated with increasing contribution volume.

I also think it’s worth recognizing that contributor reputation systems themselves introduce additional complexities. Reputation requires accumulation, maintenance, interpretation, and governance. New contributors necessarily begin without reputation. Existing contributors can experience changes in quality over time. Organizations can rotate personnel while preserving identities. Accounts can change ownership. Even sophisticated trust models therefore require ongoing human oversight rather than eliminating the need for reviewer judgment altogether.

Ultimately, I think this discussion benefits from avoiding false dichotomies. The issue has never been whether AI exists, whether contributors will continue using AI, or whether maintainers should attempt to inspect people’s prompt histories. Rather, the central question is how finite pools of human attention are allocated in an environment where the cost of generating plausible-looking contributions has fallen dramatically while the cost of validating correctness, preserving architectural integrity, and preventing long-term maintenance debt remains comparatively unchanged. That seems to me to be the more interesting systems question, and one that likely cannot be answered solely through increased reliance on identity-based trust mechanisms.

.

I appreciate the feedback regarding verbosity, and I think that concern is both understandable and illustrative of the broader discussion we’re having. However, I would suggest that your response actually reinforces the systemic dynamics that I’m attempting to highlight. Specifically, while you are entirely correct that an individual response can simply be closed or ignored if it fails to meet project standards, that observation does not necessarily scale in environments where the overall volume of incoming communication increases by one or two orders of magnitude.

To elaborate, the issue isn’t that any individual AI-generated pull request, issue report, or discussion comment is impossible to dismiss. On the contrary, as you’ve demonstrated, a maintainer can absolutely review a single submission, determine that it lacks sufficient value, and reject it accordingly. The challenge emerges not at the level of individual interactions but at the aggregate systems level, where review capacity becomes the scarce resource rather than code generation capacity.

For example, if one contributor submits an unnecessarily verbose pull request, the cost of evaluating that submission may be relatively modest. If ten contributors do the same, the cost increases proportionally. If one hundred contributors begin submitting plausible-looking but low-value AI-assisted changes every week, each of which requires even a few minutes of human evaluation before being confidently rejected, the cumulative impact becomes substantially more significant. This isn’t because any individual submission is uniquely problematic but because the total review burden scales with submission volume while maintainer attention does not.

From a queueing theory perspective, this creates an interesting imbalance. Human review throughput remains relatively fixed, whereas AI-assisted content generation dramatically increases the arrival rate of new work. Once the arrival rate consistently exceeds the processing rate, backlog accumulates regardless of how efficient reviewers become at rejecting individual items. Consequently, “just reject it” is a locally optimal strategy that may nevertheless fail to address the global characteristics of the system.

Furthermore, I think it’s useful to distinguish between identifying low-quality contributions and doing so at scale. The cognitive effort required to conclude “this is not worth merging” is still non-zero. Every submission requires context switching, repository loading, architectural reasoning, verification that nothing subtle has been overlooked, and ultimately a decision. While each of these activities may appear trivial in isolation, their cumulative effect across hundreds or thousands of submissions represents a meaningful opportunity cost for maintainers who might otherwise be spending that same time reviewing genuinely valuable work or implementing new features.

For that reason, I don’t think the existence of a rejection mechanism meaningfully addresses the broader concern being discussed. Rather, it demonstrates that the cost of filtering remains attached to human reviewers even as the marginal cost of generating candidate contributions approaches zero.

In other words, I agree that you can close this thread.

Now imagine doing that another 699 times today…

It is actually not like a person learning at all. The only way you could believe this is if you have no grasp of the mathematics that are the basis of the multi-dimensional statistical analysis which is neural network training, and haven’t bothered to do any reading on it.

There’s a reason I referenced curve fitting.

Here is a better explanation than I could give, by someone who knows better than me:

Large Language Models explained briefly by 3Blue1Brown