Why Quality, DCO Compliance, and Ethics Beat Volume in AI-Driven Engineering

AI-assisted tooling makes it trivial to generate a pull request. It does not make it trivial to generate a pull request a maintainer should actually want to review. Those are different problems, and conflating them is how open-source maintainer queues end up full of low-signal noise. This is what I found auditing a set of Tier-1 infrastructure projects, and why the right ending for that work was closing PRs rather than shipping them.

The audit

The scope covered 25+ Tier-1 open-source infrastructure repositories: vLLM, Qdrant, Ray, Temporal, OpenTelemetry, Dify, Meilisearch, DataFusion, and LiteLLM among them. These are projects with real production usage and, correspondingly, real review bandwidth constraints on the maintainer side. Static and dynamic analysis across that set surfaced concrete issues: atomic memory-budget overflows in Rust-based vector database components, circuit-breaker race conditions in Ray Serve’s request handling, and missing retry handling on OTLP HTTP export paths in telemetry code.

Each of those is a legitimate finding. None of them is automatically worth a pull request.

Why I closed 25 PRs instead of shipping them

Drafting a fix for a race condition in someone else’s production system is not the same as understanding the invariants that code was written to protect. A patch that resolves the symptom in a local repro can still be wrong for reasons that are only visible to someone who has lived in that codebase’s history and knows why a particular lock ordering or retry ceiling was chosen in the first place. Shipping 25 PRs of that quality onto Tier-1 maintainers, most of whom are already reviewing a queue that skews AI-generated, is not a contribution. It is cost-shifting: the effort of writing the patch moves to me, and the effort of verifying it moves to someone with far less time to spare.

So the PRs got closed, deliberately, rather than left open or merged. That included being explicit about DCO (Developer Certificate of Origin) and CLA compliance on anything that had progressed far enough to need a sign-off decision: if a contribution cannot be legally attributed and verified, it does not go in, no matter how correct the underlying fix looks.

What “responsible” actually means here

It is tempting to read “closed 25 PRs” as a failure metric. It is closer to the opposite. The value of the audit was in the findings, and the findings are useful with or without an attached patch, whether that means writing them up, raising them in a maintainer’s preferred channel, or simply confirming that a suspected class of bug does not affect a given version. Volume of merged PRs is a bad proxy for engineering judgment. It measures how much a maintainer’s time got spent, not how much value they received.

The standard I’m holding myself to

High-throughput analysis is a real capability, and AI-assisted tooling makes it more accessible than it used to be. But throughput without architectural context, without verification against the codebase’s actual invariants, and without respect for the review bandwidth on the other end is not a contribution. It is noise with a green checkmark. The bar I use going forward: if I would not want to review this PR as the maintainer, I should not be opening it as the contributor.