Pull requests with LLM attribution are predatory behavior

My understanding of the codebase is shallow

It’s okay to have a shallow understanding of the codebase. As humans, we are not required to know everything. It’s pretty common for a contributor to only understand the part they’re touching. If I’m not confident I understand the entire codebase, disclosing LLM usage is redundant.

There’s a licensing risk

This seems the most reasonable to me so far. But OTOH, I’m not sure it’s actionable. The only sensible action for a maintainer who takes licensing risks seriously would be to reject my contribution. So maybe I should’ve just saved everybody’s time and not opened my PR in the first place.

My understanding of the PR is shallow

This is an extreme version of the first implication. I’ve seen many such PRs on Github and I have opened a few myself. Usually in such cases, the change is very small and localized, there’s a well-defined test/reproduce scenario, and the author can observe the change solving the issue for them, but can’t speak to the bigger impact of the change.

In this case, it’s better to state exactly that: "I’m not sure if this is the right fix, but it works for me in the following scenario…​". Mentioning LLM here is again redundant.

However, with LLMs people can submit enormous thousand-line PRs with this exact implication. And this is a case of horrific asymmetry. If I as a contributor don’t understand my enormous PR and expect a reviewer to understand it, then I’m basically expressing a lack of basic respect.

My code contribution is of low quality

LLM disclosure doesn’t help here in any way. If it’s a low-quality contribution, just improve it.

Reviewer’s perspective

As a reviewer (switching hats now), I don’t care about:

None of this info helps me review your PR.

Unclear focus

All codebases are different. All PRs are different. Some PRs should be carefully inspected for race conditions. Others should be inspected from a security angle. From my experience, an LLM should be explicitly instructed to focus on certain important aspects. Otherwise the output is not much different from a linter or a more advanced static analyzer.

Of course, we may be willing to throw money at the problem and let LLMs scrutinize all PRs from all possible angles (which we’ll have to explicitly enumerate anyway). But then, as reviewers, we get a lot of noise, and the noise matters, because human involvement is likely needed anyway.

Product focus

If a PR contributes a feature, one of the angles to scrutinize the PR is how the feature fits the whole product.

Understanding the product requires context that can’t be derived from the code.

An LLM might understand whether a feature fits, given it has a detailed roadmap in its context. In my 15+ years of experience, I’ve never encountered a product having such a detailed roadmap. Even products which used to have roadmaps had them sketched in broad strokes, marking the general direction and key features. But that alone wouldn’t be nearly enough to understand whether a small feature contributed by a user fits the big picture.

Where LLM-powered reviews could actually work

I can imagine a codebase with a perfectly written specification and a set of blackbox tests. In this case, an LLM-powered PR review may work wonders, as long as the PR does not mutate blackbox tests. At the same time, I’d imagine the contribution model at such projects implies a focused dedicated team and no external contributions, so this whole post doesn’t apply.

It’s all about accountability

There’s a great quote from a 1979 IBM internal training slide[5]:

At the end of the day, it’s the maintainer of the project who will pay for the sloppy PR — with their sleepless nights during outages, their headaches during bug hunting, or their money if they employ LLMs to fix the issue.

Should contributors avoid LLMs?

Absolutely not.

To me, LLMs have proven to be invaluable research assistants and decent coders. With their help, I can research and understand a large, unfamiliar legacy codebase in a matter of hours instead of days. LLMs are predictably great at generating exhaustive test suites with all possible edge cases from existing code or even from a vague description of the algorithm. They can do magic in analyzing huge amounts of data and detecting anomalies.

I use LLMs extensively, and I encourage you to use them too.

And if I ignore the concern of slipping into technofeudalism, I’d say LLMs (or more broadly, AI) are an invaluable part of our future. I’m not an AI skeptic, and I subscribe to the opinion expressed by Richard W. Hamming in his 1997 book "The Art of Doing Science and Engineering: Learning to Learn"[6]. Hamming argues that there’s nothing inherently different between artificial intelligence and organic intelligence (the term is not Hamming’s). I wouldn’t be surprised if we’ll soon have fully automated sustainable and reliable AI-powered software engineering systems.

But here’s the thing: LLM attribution is not relevant. The only author that matters is the one recorded in the VCS log. And with the current state of AI when you contribute to a project maintained by other people, it’s still you.

Attribution becomes an escape hatch, a way to avoid accountability. It’s a preemptive excuse that says "don’t blame me, the LLM wrote this." This is precisely what makes it predatory behavior.

Put effort into your contributions and make them your own. Show some care, understand them deeply, polish them until they’re indistinguishable from what a responsible, meticulous human would produce. Then be proud to have your name next to them in the git log. If you can’t be proud of your contribution and feel the need to cower behind a "Co-authored by Claude" attribution, then perhaps you shouldn’t be contributing at all.

Best regards.

P.S. em-dashes are mine.