Your contributors are AI-first now. Is your project?

When the Queue Fills With Agent Code

Maintainers are increasingly facing the same question: what happens when your pull request queue fills with work written by AI agents? Nicholas Tindle, founding AI engineer at AutoGPT, lives with this daily. When I spoke with him during Maintainer Month in May, AutoGPT had roughly 180,000 stars and about 150 open pull requests—a significant portion generated by tools like Copilot, OpenClaw, and AutoGPT's own internal agent tooling.

Most maintainers default to closing the door. Tindle sees it differently:

It's basically somebody else paying for your compute.

His logic: if a contributor wants to spend tokens improving your project, let them. Just design the entrance so that only contributions in the shape you want get through.

Meet Agents Where They Actually Look

AutoGPT started with the conventional approach—better contributor guidelines, richer docs, a dedicated wiki. None of it moved the needle. The discovery problem isn't documentation quality; it's that agentic tools read what's directly in front of them, not what lives elsewhere in your repository.

They shifted to dropping instructions where agents operate. First came CLAUDE.md files, since Claude's pull requests lacked repository context—identifiable through their commit trailers. Then Copilot and Codex ignored those files entirely, being tool-specific. The fix: a centralized AGENTS.md standard, with Claude files referencing it.

Scope matters here. AGENTS.md applies within a directory, but skills can be discovered outside one. A skill is an instruction file with a description telling an agent when to load it; the agent scans descriptions up front and loads full instructions when a task matches. AutoGPT's AGENTS.md sits beside the code it governs, a placement choice as important as the content.

If you're writing backend tests and you think about doing front-end stuff, a skill may load dynamically. It's not going to know what directory to go look in for an AGENTS.md file, but the skill can tell it that.

Their front-end engineer automated away recurring broken pull requests by writing a guide as a skill within the repo. Its description contained trigger phrasing: write a Storybook test if your component lives in these folders. Every tool touching the repo discovers it automatically. The backend enforces its own rule similarly: below 80% coverage means the pull request stays closed.

Gates That Sort the Signal

Make the pull request template mandatory, explicitly. AutoGPT informs agents that non-conforming pull requests get closed automatically, no hesitation. They built the enforcement tooling only to find it unnecessary—agents followed the template before the automation ever executed. Humans sometimes needed slack, which Tindle treats as a feature:

If you don't follow the template, I know you're probably a person, and I'm going to be kinder.

Trigger work with wording. The template requires a test plan, with language that casually mentions testing the pull request. That phrase activates the test PR skill: installs agent browser with permission, boots the app, runs the change. The agent starts filling in a checkbox and ends up executing the code. Result: almost no broken pull requests anymore. The remaining ones work but don't fit the roadmap—a far better problem.

CI as a wall. Codecov coverage thresholds run as required checks. Agents open pull requests, return minutes later to a blocked merge, load the testing skill, and write the tests. No maintainer intervention needed.

The CLA as human detector. AutoGPT is dual-licensed, but Tindle argues every project—MIT included—should adopt the pattern. Signing demands a browser and GitHub OAuth flow on a separate domain. Agents struggle here today, and rightly so: most maintainers don't want agents holding broad GitHub access in a browser session.

If your CLA is not signed after a week, we close the pull request with a comment that says sign the CLA, reopen when you're done.

The gate reintroduces a human checkpoint. A code-of-conduct checkbox could work similarly.

Require proof before resolving review threads. Some agents resolve every comment without fixing anything. AutoGPT shipped the pr-address skill declaring the one valid sequence: fix, commit, push, reply, resolve. The reply must link the fixing commit with the full SHA from git rev-parse HEAD after the commit, blocking reused hashes. The skill names anti-patterns explicitly: "Acknowledged" isn't a fix, nor is referencing a commit untouched by the flagged line.

Turn Off the Noise

AutoGPT's first attempt at automated failure analysis wired Claude Code into GitHub Actions with an in-workflow credential—another broad token in CI. Running Copilot in the workflow gives the same result without the extra exposure. Tindle's enthusiasm is concrete:

It's unbelievable. I'm so happy I never had to bother with YAML ever again. I'm never writing a workflow for an action ever.

They turned the commenting off anyway. Their CI fails often, and a robot narrating every failure degrades into noise. The lesson is measured restraint: keep what reduces maintainer load, shut off what adds to it.

Practical Caveats Worth Heeding

Bad agent instructions are worse than none. AutoGPT initially scattered AGENTS.md files everywhere, polluting context and diverting attention to irrelevant files. If agent behavior worsens, audit what you wrote.

GraphQL rate limits will bite. Team-wide CLI usage as individual users hits ceilings quickly. Create a GitHub App and authenticate through it.

Heavy review tooling isn't cheap. AutoGPT's pull request test rig clones branches, spawns eight agents with distinct jobs, executes the full stack, and uploads screenshots. It works—and it's expensive enough to run only on very small or very large pull requests now.

Audit your authorizations. AutoGPT participates in the Secure Open Source Fund, which surfaced a finding: every trial-and-drop tool left behind an OAuth token.

If you stop using a GitHub app, remove it from the authorized apps. Do a little audit right now after this stream and go see what you have. You'll be surprised.

Most of us have never revisited those settings after granting access. I checked mine during the interview. He was right.

Not Every Pull Request Deserves Merging

Two of Tindle's points weren't about tooling. First, you can decline any contribution. Accepting someone's LLM output is asymmetric: you carry maintenance forever. Closing the request and rebuilding the fix yourself is legitimate.

Platform controls exist to set boundaries: you can disable pull requests entirely or restrict issue creation to collaborators. Tindle emphasizes knobs. Sometimes fewer drive-by contributions is the right answer, sometimes issues-only, sometimes "talk to us first." SQLite takes no external code—only bug reports—and that's a defensible open source boundary. Your project can define its own.

Second, when you close a contribution you'll rebuild yourself, consider adding the contributor as a co-author where appropriate. AutoGPT counts around 800 contributors; one more costs them nothing. What matters to most contributors is that their problem got fixed and their attempt was acknowledged.

Rules Next to Code

Open source collaboration has evolved by making the implicit explicit. Licenses clarified permissions. Issues exposed work. Pull requests standardized review. Repository-level instructions look like the next turn, though the shape is still forming—AutoGPT's on its third version, arrived at by shipping imperfect iterations and watching what agents did.

The maintainer still decides what belongs and where the bar sits. The shift is placing that judgment beside the code, where contributors and their agents already work. Inspect the AutoGPT repo's agent-file structure, then join the Maintainer community if you want product input. As Tindle puts it, that's where he learned these patterns. In the meantime, expect AI-first contributors. Put the ground rules next to the code before the next automated pull request lands.