LLM-assisted pull requests and CLA friction
The friction usually starts after the code does its job. A contributor submits a non-trivial fix, then hits a CLA requirement, a ban on LLM-generated code, or a disclosure rule that was not obvious at the point of merge. The patch may be good enough for production, but the paperwork side can still block acceptance or force a rollback.
That is where code review policy stops being a formality. A project that treats contributor provenance as a hard boundary has to decide whether the patch can stay, whether it needs a clean-room reimplementation, or whether the whole thing gets dropped. None of those choices are cheap.
The pull request looks ordinary until the licence check bites
A pull request is easy to handle when it is just code. The awkward bit arrives when the contributor refuses the CLA, or when the project only accepts code that is 100% human-created and the submission does not fit that rule. At that point the maintainer is not reviewing a bug fix any more. They are dealing with a contribution that may be useful, but not mergeable under the project’s own conditions.
That creates a neat little denial pattern. The contributor gets the fix in front of maintainers, then leaves them with a legal or policy task that consumes time regardless of whether the code lands. For small patches, the cost is tolerable. For invasive security fixes, the cost can be ugly.
LLM-generated code changes the review burden before it changes the merge decision
LLM-generated code does not just affect authorship questions. It changes the shape of review work. Large patches often touch several files, alter control flow, and pull in adjacent changes that are harder to separate from the actual fix. Reviewers then spend time checking whether the change is safe, whether it follows project style, and whether it can survive provenance scrutiny.
If the project has a strict no-LLM rule, the review burden grows before the merge decision does. The patch might be technically fine, but the reviewer still has to decide whether accepting it would break policy, create inconsistent enforcement, or force later remediation. Security fixes are worse because delays and reversals hit the same code paths that were supposed to reduce risk.
Clean-room reimplementation is the expensive response
Clean-room work is the obvious answer when a patch cannot be accepted as submitted. It is also the slow answer. One person has to read the submitted change and write a specification from it, then a different person has to reimplement the fix from that specification without copying the original structure.
That separation matters. If the replacement code is too close to the submitted patch, the project can end up arguing about whether the clean-room step was real or just theatre. For a simple bug, that argument may be manageable. For a security patch with a lot of moving parts, it wastes time the project probably does not have.
Separate the specification from the submitted patch
The clean-room process only works if the spec and implementation roles stay apart. The first reader should describe behaviour, inputs, outputs, edge cases, and any security constraints without handing over the original code shape. The second person then writes fresh code from that description.
That sounds tidy on paper. In practice, the more invasive the patch, the more detail the specification needs, and the more room there is for the reimplementation to drift into something recognisably derived. A small fix can be rewritten quickly. A large security patch can turn into a week of careful rewriting and argument over whether the result is similar enough.
Rebuild the fix without copying the original structure
A clean-room reimplementation should aim for the same behaviour, not the same mechanics. Different function layout, different helper names, different ordering of checks, different file boundaries if the project permits it. If the original patch grouped the logic one way, the replacement should not simply mirror it line for line with new variable names.
That matters because the work is not just technical. It is also a defence against later dispute. If the project has to show that the fix was independently rebuilt, a patch that looks like a thin rewrite will not help much. With security fixes, that can become a waste of the only thing maintainers usually lack: time.
Keeping merge trust boundaries intact after disclosure
Delayed disclosure is where the mess gets expensive. A contributor can let a patch sit in the tree for weeks or months, then reveal later that it involved LLM assistance or that the authorship story is not as clean as it looked. At that point the project has a merged change, a shipped release, and a trust problem.
The boundary here is simple: provenance is part of the merge decision, not a separate editorial preference. If the project has a rule about human-only code or disclosure of AI assistance, the rule has to be enforced before merge or treated as a policy event afterwards. Pretending it is just a style argument is a good way to end up with selective enforcement.
Treat delayed LLM disclosure as a policy event, not a style argument
Late disclosure changes the status of the change set. It is no longer only about code quality or readability. It becomes a matter of whether the contribution met the project’s acceptance rules at the time it was merged.
That is awkward, because the practical options are all unpleasant. The project can keep the code and weaken the rule, remove the code and absorb the reversal cost, or apply the rule unevenly and invite trouble. A security fix makes that sharper, because the patch may already be protecting real users by the time the disclosure lands.
Re-run security patch review when authorship or provenance is unclear
If authorship is uncertain, security patch review needs to happen again. Not because the code automatically becomes unsafe, but because the trust boundary moved. Reviewers should check whether the change still matches the intended fix, whether the implementation differs from the original enough to matter, and whether the project can stand behind the merge decision under its own policy.
That review should be narrower than a full re-audit, but it should not be casual. If the fix is invasive, the cost of proving provenance can rival the cost of writing the patch in the first place. That is exactly where policy friction becomes a denial-of-service shape: cheap code in, expensive compliance out.
