AI-assisted pull requests raise review cost
A patch that looks useful can still be expensive to assess when it arrives as a full rewrite, a broad refactor, or a suspiciously tidy fix for a messy problem. Reviewers do not just check whether the change compiles. They have to work out whether the shape of the code makes sense, whether the logic has edge cases, and whether the author actually understood the thing they changed.
That cost rises when the submission is obviously machine-assisted but edited enough to pass as hand-written. The reviewer still has to read every line. A weak patch does not save time just because it was cheap to generate.
Triage takes longer when the patch is already invasive
Small changes are quick to reject or approve. Large changes are not. If a pull request arrives with broad file churn, a new abstraction layer, or a full replacement of working code, triage turns into a proper inspection job.
That matters in projects that get bug fixes through issue trackers and pull requests from people who may never come back. A maintainer has to decide whether the patch is worth the risk before they even start checking the logic. If the change is invasive, the burden is front-loaded and dull, which is a fine way to burn volunteer time.
Low-effort AI code still creates high-effort reading
Machine-generated code can be grammatically clean and technically wrong in exactly the sort of way that wastes time. It may follow naming conventions, avoid syntax errors, and still hide assumptions that do not survive contact with reality.
That leaves review in an awkward place. The patch is not obviously bad enough to bin, but not trustworthy enough to merge without a slow read. The result is the same as with any low-quality submission, only faster to produce and cheaper for the author to abandon.
Clean-room reimplementation turns policy into labour
A strict human-authored code policy does not stop at rejecting an AI-tainted patch. If the submission is useful, the project may need a clean-room reimplementation instead. That means one person extracts a specification from the suspect code, then another person writes new code from that specification alone.
That is a lot of labour for one patch. It is worse when the change is non-trivial, security-sensitive, or tied to a release candidate. The policy may be tidy on paper and expensive in practice.
The spec has to be stripped back from the submitted diff
Clean-room work depends on removing implementation detail from the tainted change. The person writing the spec has to describe behaviour, not code shape. Anything too close to the original patch invites arguments over contamination and similarity.
That is tedious when the patch is small and miserable when it is not. A large fix can carry enough structure that the maintainer ends up reverse-engineering intent from the diff, then translating it into a separate specification, then checking the reimplementation against it. The original submitter spent minutes. The project spent hours.
Security fixes and licence checks make the work slower still
Security patch review already moves under pressure. Add a human-authored code requirement, and every line gets extra scrutiny. If the fix touches authentication, parsing, permissions, or any other fragile path, the clean-room process becomes a delay machine.
Licence compliance introduces its own mess. If a contributor refuses to sign a contributor licence agreement after posting a useful patch, the project can end up with a fix it cannot safely use. The same applies when a merged change later turns out to have been produced with an LLM. Either way, the project has to decide whether to reimplement, revert, or live with the policy exception.
When merged code is later flagged as AI-written
Late disclosure is worse than a bad pull request, because the code is already in the tree. The project may have shipped it, built on it, or backported it. At that point the problem is not just authorship. It is the cost of tearing out something that has already sunk into other work.
Re-reviewing old patches is not free
Once a merged change is challenged, someone has to read it again from scratch. That means reopening old review notes, checking commit history, and deciding whether the code was ever acceptable under the policy in force at the time.
If the code was invasive, the second pass is nearly as painful as the first. The project still has to establish what the patch does, what else it touched, and whether any later work depends on it. The fact that the disclosure arrived months later does not make the labour smaller. It just makes the backlog noisier.
The real damage is the trust repair, not the disclosure note
A note saying a patch was LLM-written is easy to write and hard to unwind. The damage sits in the gap between the claim and the code already merged. If the project leaves the change in place, the human-authored policy starts looking selective. If it removes the change, it pays the cost of replacement and any regressions that come with it.
That is the awkward part of these policies. They are often framed as a simple boundary, but they create a maintenance obligation as soon as a useful patch lands. The review burden does not disappear when the author disappears. It just lands on the people left holding the repository.
