# How do AI-native developers recommend generating less "sloppy" contributions?

> **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:
>
> 1. **Keep PRs small.** Reviewers catch far fewer problems past about 200 to 400 lines.
> 2. **Write structured descriptions**, including what you *didn't* change.
> 3. **Show evidence, not explanation**, like tests that fail before the fix and pass after.
> 4. **Use visuals to orient**, and screenshots or logs to prove behavior.
> 5. **Review the plan before the code.**

A recent [Linux Foundation Research survey](https://www.linuxfoundation.org/press/new-lf-research-survey-shows-generative-ai-cuts-open-source-coding-time-in-half-but-25-of-incoming-pull-requests-are-considered-ai-slop) (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](https://www.linkedin.com/in/mapocock/), of [/grill-me skill](https://www.aihero.dev/skills-grill-me) fame, asked the other side of the question in a [LinkedIn thread](https://lnkd.in/p/gKiC-H3F): how can AI-native developers make their PRs easier to review? Here are the takeaways, with concrete tools for contributors and maintainers.

![](https://cdn.hashnode.com/uploads/covers/60d6c5bcde92ef110afdd45b/df5d2124-59a7-4d2e-8104-c406098b4a15.png align="center")

## 1\. Keep contributions small

The most common advice in the thread, and the best-supported: reduce what the reviewer has to look at.

[![Scatter plot: defects found per 1,000 lines fall sharply as the number of lines under review rises past about 200.](https://cdn.hashnode.com/uploads/covers/60d6c5bcde92ef110afdd45b/97317ada-8e9b-4599-a64b-50062e5b115c.jpg align="center")](https://www.stickyminds.com/article/largest-case-study-code-reviews-ever)

*Defects found per 1,000 lines drop sharply once a review goes past about 200 lines. (*[*Cohen/SmartBear, Cisco study, 2006*](https://www.stickyminds.com/article/largest-case-study-code-reviews-ever)*: 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](https://docs.github.com/en/pull-requests/get-started/about-stacked-prs), with the [gh-stack skill](https://github.com/github/gh-stack) 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](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/disabling-pull-requests), and [cap open PRs per outside contributor](https://github.blog/open-source/maintainers/how-pull-request-limits-are-cutting-down-the-noise/), with a bypass list for trusted contributors. |

This works in practice: [Homebrew](https://scientific-python-cookie.readthedocs.io/en/latest/guides/ai) 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."](https://github.blog/open-source/maintainers/how-pull-request-limits-are-cutting-down-the-noise/) <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](https://docs.github.com/en/copilot/how-tos/copilot-on-github/copilot-for-github-tasks/create-a-pr-summary) from the diff, but it captures the *what*, so you'll still need to add the *why*. Then run [/unslop](https://github.com/cursor/plugins/blob/main/pstack/skills/unslop/SKILL.md) 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](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository) (GitHub) or [merge request description template](https://docs.gitlab.com/user/project/description_templates/) (GitLab), and point to it from your [`AGENTS.md`](https://agents.md/) so agents fill it in automatically. |

Some projects go further and ship the skill themselves: [Sanity](https://github.com/sanity-io/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`](https://git.terata.org/eessppeelllloo/processing4/src/branch/main/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](https://stryker-mutator.io/docs/) (does breaking the code make tests fail?) and [CRAP](https://testing.googleblog.com/2011/02/this-code-is-crap.html) and [complexity](https://en.wikipedia.org/wiki/Cyclomatic_complexity) metrics (is the risky code complex *and* poorly tested?).

| Contributors | Maintainers |
| --- | --- |
| Matt Pocock's [/tdd skill](https://www.aihero.dev/skills-tdd) 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](https://stryker-mutator.io/docs/) (JavaScript, TypeScript, C#, Scala), [Infection](https://infection.github.io/) (PHP) or [PIT](https://pitest.org) (Java) on the code you changed. | Run mutation testing in CI on changed code only, the way [Google does in code review](https://research.google/pubs/state-of-mutation-testing-at-google/), 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](https://github.com/masoncl/review-prompts), and [invite contributors to run the same review locally](https://netdev-ai.bots.linux.dev/ai-local.html) 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 sequence diagram generated by HumanLayer's /show-me skill, tracing how an editor restores scroll position after new content arrives.](https://cdn.hashnode.com/uploads/covers/60d6c5bcde92ef110afdd45b/ef0c8f27-bce6-4332-8e82-b91f11eff3b5.png align="center")

*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](https://humanlayer.com/blog/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](https://gist.github.com/geoffreylitt/a29df1b5f9865506e8952488eac3d524) 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](https://www.aihero.dev/skills-grill-me) has the agent question *you* until the plan's gaps are filled in, and [/to-issues](https://www.aihero.dev/skills-to-issues) turns the plan into small, reviewable slices. [/show-me](https://humanlayer.com/blog/show-me-skill) 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](https://learn.scientific-python.org/development/guides/ai) collects ready-made policies modeled on projects like the Linux kernel and NumPy. For larger changes, use a design-doc process: [Kubernetes' KEPs](https://github.com/kubernetes/enhancements) 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](https://github.com/mitchellh/vouch) asks newcomers to introduce themselves in an issue first. [Ghostty](https://ghostty.org) 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.md` that points to it.

Found a technique that works for your open source project? I'd love to hear about it! :D