DOP 361: When Code Got Cheap, Reviewing Got Expensive

Episode 361

Show Notes

#361: Picture a 6,000-line pull request landing in your project from someone you’ve never heard of. Every test passes - yours, theirs, all of it. And you can tell it was generated. Not assisted. Generated. What do you do with it? Viktor’s first move is to poke the premise: how do you even know it was generated and not assisted? You can’t. Nobody can. That distinction is already gone.

So the real question isn’t whether AI wrote it. It’s what a maintainer is for. Viktor’s answer is blunt - a maintainer’s first job is to guide people in and help them contribute, and if you think your job is mainly to write code, you picked the wrong role. The moment you allow PRs, you stopped being an individual contributor and became a manager. That’s the job. You don’t get to complain about the job you signed up for. Don’t want it? Fine - do what Ghostty did, do what curl did, turn PRs off and say so out loud. Just don’t hide behind unknown contributors, because every single person on your project was an unknown contributor on their first commit, including you.

A software developer says send me anything but a PR and lists four reasons: unknown contributors are a security risk, supply chain attacks are real, style disagreements eat maintainer time across time zones, and LLMs killed code-writing as the bottleneck so the stranger’s PR doesn’t help with the parts that are still hard. Viktor grants the security point and then points at XZ - social engineering, a long con, zero AI required. The risk was always there. What changed is quantity, not the percentage. And the maintainer who thinks a manual, line-by-line review still works in 2026 is, in his words, terribly wrong.

Viktor guesses he can review 6,000 lines in about the time it takes to hand-review 600. CodeRabbit and Greptile clear the obvious junk so he can spend his attention on architecture and the feature itself - the stuff he never had energy for after slogging through nitpicks by hand. His read on the whole backlash: there’s a new third group of maintainers now, the ones who aren’t good enough with agents to fight agents, and they’re the ones falling behind. Writing code is cheap. Reviewing it well is the expensive part - and the ones who refuse to use agents to review are drowning while blaming the contributors. There’s a cost angle too. If you don’t have tokens, you’re in trouble, and not everyone can afford them. Tokens are becoming table stakes, like an internet connection. Which raises the question: what happens to open source when the reviewing tools cost money the maintainer doesn’t have?

Frequently Asked Questions

Should open source maintainers accept AI-generated pull requests?

Viktor Farcic’s position on DevOps Paradox episode 361 is yes. He argues a maintainer’s first responsibility is to guide and help and bring people in to contribute, and that the moment you allow pull requests you have moved from individual contributor to manager. Maintainers who do not want that role should close pull requests outright and say so plainly, rather than blaming unknown contributors for a job they signed up for.

How long does it take to review a 6,000-line AI-generated pull request?

Viktor Farcic estimates on DevOps Paradox episode 361 that he can work through a 6,000-line pull request with Claude in roughly the time someone would spend manually reviewing 600 lines, about one tenth. His process runs CodeRabbit and Greptile first to clear obvious issues, then a second guided pass where he directs the AI toward specific concerns instead of letting it work from the pull request context alone.

Are unknown contributors a good reason to reject pull requests?

Viktor Farcic rejects that reasoning on DevOps Paradox episode 361, pointing out that unless you started a project yourself, everyone on it was an unknown contributor once, the maintainer included. He grants the security risk is real, then points at the XZ backdoor as social engineering that predated AI and needed none of it. What changed, he argues, is the quantity of pull requests, not the percentage that are malicious.

Is manual line-by-line code review still workable?

Viktor Farcic argues on DevOps Paradox episode 361 that a maintainer counting on a manual review process today is, in his words, terribly wrong. He describes a third group of maintainers who are not good enough with agents to fight agents, and says they are the ones falling behind. His own attention moves up a level, to architecture and to the feature itself, once tooling has cleared the nitpicks.

Can open source maintainers afford AI code review tools?

Darin Pope raises the cost problem on DevOps Paradox episode 361, noting that developers outside the United States generally have less cash flow, and that paid subscriptions or hardware to run open models both cost money a volunteer maintainer may not have. Viktor Farcic answers that a good deal is available free, citing Greptile and a free open source option from CodeRabbit, and predicts tokens will become as assumed as internet access.

What happens to an open source project that stops accepting pull requests?

Viktor Farcic’s answer on DevOps Paradox episode 361 is that users leave. He says a rejected pull request, as opposed to one he is guided through and improves, leaves him two options: maintain his own fork, or rebuild the thing from scratch. Darin Pope pushes the case harder by asking what would happen if Kubernetes accepted contributions from only two people. Viktor’s answer is an immediate switch to something else.

What is the DevOps Paradox podcast?

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 361, “When Code Got Cheap, Reviewing Got Expensive,” works through why some open source maintainers are turning away AI-generated pull requests, and what that does to the economics of reviewing code. Every episode page carries the audio, the video, and a full transcript.

Share and Download

Hosts

Viktor Farcic

Viktor Farcic

Viktor Farcic is a member of the Google Developer Experts and Docker Captains groups, and published author.

His big passions are DevOps, Containers, Kubernetes, Microservices, Continuous Integration, Delivery and Deployment (CI/CD) and Test-Driven Development (TDD).

He often speaks at community gatherings and conferences.

He has published DevOps Paradox and Test-Driven Java Development.

His random thoughts and tutorials can be found in his blog The DevOps Toolkit.