How do AI-native developers recommend generating less "sloppy" contributions?
Improving open source maintainer sustainability by stopping slop at the source
TL;DR: AI made writing code cheap, but reviewing it is as expensive as ever. Five ways to make AI-authored PRs easier to review, with tools for both contributors and maintainers:
- Keep PRs small. Reviewers catch far fewer problems past about 200 to 400 lines.
- Write structured descriptions, including what you didn't change.
- Show evidence, not explanation, like tests that fail before the fix and pass after.
- Use visuals to orient, and screenshots or logs to prove behavior.
- Review the plan before the code.
A recent Linux Foundation Research survey (Oct 2026) found that AI boosts productivity by up to 50% for both contributors and maintainers. But maintainers estimate that around 25% of incoming pull requests are AI "slop", and more in large projects. That lands on real humans who were edging toward burnout long before "vibe coding" was a term. :P
Matt Pocock, of /grill-me skill fame, asked the other side of the question in a LinkedIn thread: how can AI-native developers make their PRs easier to review? Here are the takeaways, with concrete tools for contributors and maintainers.
1. Keep contributions small
The most common advice in the thread, and the best-supported: reduce what the reviewer has to look at.
Defects found per 1,000 lines drop sharply once a review goes past about 200 lines. (Cohen/SmartBear, Cisco study, 2006: 2,500 reviews, 3.2 million lines of code.)
In practice, aim for one coherent change per PR: ideally under about 200 lines, and rarely over 400. If your agent produces more than that, split it up before asking anyone to review it.
| Contributors | Maintainers |
|---|---|
| Stacked pull requests, with the gh-stack skill for agents, break large changes into a chain of smaller PRs that are reviewed independently and merged in order. Stacks don't work across forks yet, so this mainly helps contributors with push access. | GitHub lets you disable pull requests or restrict them to collaborators, and cap open PRs per outside contributor, with a bypass list for trusted contributors. |
This works in practice: Homebrew allows only one open AI-assisted PR per contributor at a time, and AutoGPT's maintainers say GitHub's PR caps have "helped us want to review pull requests again." <3
2. Write structured descriptions
Help the reviewer quickly understand the What, Why, and How. Useful fields:
- What changed, and why
- What was deliberately not changed, so scope decisions don't hide in a large diff
- What would prove this wrong, such as a test or behavior the reviewer can check
- What was deferred, which issues it closes, and what docs need updating
- The test plan, with the commands run and their output
The same Cisco study found that reviews went more efficiently when authors annotated their changes first, partly because the authors caught their own mistakes while explaining them. An agent can draft this for you, but you should read it and be able to stand behind it.
| Contributors | Maintainers |
|---|---|
| Ask your agent to fill in the project's template. GitHub Copilot can also draft a PR summary from the diff, but it captures the what, so you'll still need to add the why. Then run /unslop over the result to strip filler, vague claims, and other AI writing tics, so the reviewer reads facts, not padding. | Add a pull request template (GitHub) or merge request description template (GitLab), and point to it from your AGENTS.md so agents fill it in automatically. |
Some projects go further and ship the skill themselves: Sanity includes a pr-description skill in its repo that asks contributors to list the alternatives they considered and rejected, so reviewers don't suggest paths already ruled out.
One example of setting norms for agents is Processing's AGENTS.md, which asks AI assistants to act more like guides than code generators.
3. Show evidence instead of explanation
Agents explain convincingly. And as Tu Chu pointed out in the thread, tests written by the same agent can share its blind spots. Give reviewers evidence they can check:
- Red before green. New tests fail on the base branch and pass with the fix, and the PR shows both runs.
- Write tests in a separate pass that sees only the ticket, not the implementation.
- Commit tests first, separately, so anyone can check out that commit and watch it fail.
- Measure test quality with mutation testing (does breaking the code make tests fail?) and CRAP and complexity metrics (is the risky code complex and poorly tested?).
| Contributors | Maintainers |
|---|---|
| Matt Pocock's /tdd skill keeps the agent in a fail-then-pass loop, one behavior at a time. Before opening a PR, run a mutation testing tool such as Stryker (JavaScript, TypeScript, C#, Scala), Infection (PHP) or PIT (Java) on the code you changed. | Run mutation testing in CI on changed code only, the way Google does in code review, and fail builds on high complexity or CRAP scores. Strong tests also filter out slop: curl gets far less slop in PRs than in bug reports, which Daniel Stenberg credits to its extensive tests. |
The Linux kernel offers a nice model here: the networking and BPF subsystems run automated AI reviews using Chris Mason's review-prompts, and invite contributors to run the same review locally before they submit. Contributors see the problems a maintainer's tools would flag before a maintainer has to.
4. Use visuals to orient, and screenshots to prove behavior
Example /show-me output (via HumanLayer's docs).
Visuals do two different jobs. Diagrams orient. Sequence diagrams, call trees, and before/after data models show the shape of a change and where to look, but they don't prove it's correct. Screenshots and logs prove. They give before/after evidence a reviewer can check.
Narrated videos were popular in the thread, but Shan Huang pointed out that you can't grep, diff, or skim one, and that a confident voiceover can make a change feel understood. As Valentyn Bondar put it, that isn't the same as making it reviewable. If you record one, keep it short, caption it, pin it to the exact commit, and pair it with something checkable.
| Contributors | Maintainers |
|---|---|
| HumanLayer's /show-me skill has your agent explain changes with compact diagrams, call trees, and pseudocode instead of prose. Playwright and similar tools can capture before/after screenshots automatically. | On the reviewing side, Geoffrey Litt's explain-diff turns a PR into a page with background, intuition, a code walkthrough, and a short quiz to check you actually understood the change. GitHub and GitLab render Mermaid diagrams in PR descriptions, so reviewers need no extra tools to see them. Ask for before/after screenshots in your PR template, and consider per-PR preview environments so reviewers can try changes themselves. |
5. Move review earlier
A one-page plan takes minutes to review; the 2,000-line diff it becomes takes hours. Review the plan before the code, so the diff is a confirmation rather than a discovery. Then, because agents drift, ask the agent to list the design choices and assumptions it made along the way. That list shows where the code left the agreed plan.
| Contributors | Maintainers |
|---|---|
| Matt Pocock's /grill-me has the agent question you until the plan's gaps are filled in, and /to-issues turns the plan into small, reviewable slices. /show-me can sketch the shape of the code before any of it exists. | Ask for an issue, and agreement on the approach, before non-trivial PRs. The Scientific Python AI guide collects ready-made policies modeled on projects like the Linux kernel and NumPy. For larger changes, use a design-doc process: Kubernetes' KEPs are the full-size version, but even a one-page proposal in an issue does the job. To limit who can open PRs at all, Vouch asks newcomers to introduce themselves in an issue first. Ghostty runs it in production with 250+ vouched contributors. |
The common thread
As Abhillash Jadhav put it, the PR is shifting from a diff to an evidence package. Writing code got cheap; reviewing it didn't. So point your agent at the reviewer's problem too: make it spend tokens so reviewers save minutes or hours.
Contributors and maintainers have to work together on this; neither side can fix it alone. If you want somewhere to start:
- Contributors: keep your next PR under about 400 lines, and add a "what I deliberately didn't change" line.
- Maintainers: add a PR template and an
AGENTS.mdthat points to it.
Found a technique that works for your open source project? I'd love to hear about it! :D
About the author
- Product, Developer Experience, AI, and Open Source. I explore how humans and agents discover, adopt, and use complex developer platforms. Drupal core committer, O'Reilly author, longtime open-source builder.
Comments
Join the discussionNo comments yet. Be the first to comment.
