Please Stop Pasting AI Code Into My Pull Requests
A pull request is a claim you own. If you paste AI code you haven't read, you're making that claim on a model's behalf, and the model isn't on the on-call rota when the thing breaks.
Pasting AI code into a pull request without reading it first is the fastest way to make your review my problem. If you can’t explain what a diff does, I can’t merge it, and no amount of confident model prose changes that. Paste the reasoning you actually stand behind, not the wall of text a chatbot handed you.
On 20 August 2026 a one-page site called dontpastetheai.com hit the front page of Hacker News with over a thousand points. One request: stop pasting a chatbot’s answer at someone who asked you a question. It admits at the bottom that it’s half satire, a spiritual cousin of nohello.net. The joke lands because it’s true, and the same etiquette applies to code.
Why pasting AI code unread breaks a team
A pull request is a claim. You’re telling me this change is correct, you understand it, and you’ll own it when it pages someone at 2am. When you paste code you haven’t read, you’re making that claim on a model’s behalf. The model isn’t on the rota. You are.
The trap is that generated code is plausible. It compiles. The tests you asked for pass, because the same model wrote those too. And it can still be wrong in a way that only surfaces under real load, on a Friday, three weeks after everyone forgot the PR existed. My review time is the thing standing between that diff and production, and I’d rather spend it on your judgement than on decoding a model’s.
I’ve reviewed changes where the author clearly couldn’t answer “why this and not the obvious alternative?” That’s the tell. Not that AI was used. That nobody was home.
What to paste, and what to synthesize
Paste code you’ve read line by line and can defend under questioning. That’s the whole bar. If a reviewer asks why you reached for a lock there, “the model suggested it” is not an answer, it’s a confession.
Synthesize the explanation in your own words. If the model’s summary genuinely helped, quote the useful two sentences and say why, the same way you’d cite a colleague. Don’t drop 800 words of generated rationale into the description and call it documentation. I will read exactly none of it, and neither will the next person.
Mark the parts you’re unsure about. “I let the model draft the retry logic and I’m not confident about the backoff” is worth more than a clean-looking PR that quietly hides the one bit you don’t understand. Honesty about the seams is how I know where to actually look.
What should never ship unread
Some things don’t get the benefit of the doubt. Database migrations, because a generated one can drop a column with total confidence. Anything touching auth or money, because plausible-and-wrong is catastrophic there. Regexes and date handling, because those are where models bluff hardest. And any dependency the model added on its own, because a hallucinated or typosquatted package name is a supply-chain incident waiting for a npm install.
Read those yourself. Every time. No exceptions for a tight deadline, because the deadline is exactly when the unread migration bites.
None of this is anti-AI. I use it all day. The line is simple: the model is a tool you’re accountable for, not a co-author you can blame. Bring me the version you’d defend if the model had never existed. That one I’ll merge.