More and more often, I find a bug in some code that is not mine — often in a language or codebase I barely master. My reflex used to be to hack a fix anyway and send a pull request. But recently I spontaneously began to do the opposite: I let an AI agent fix the bug on a local copy, and instead of a pull request, I submitted the prompt I used — the one that seemed to fix the issue for me, passing the tests. An evolution of my AI without AI?
I did this twice, recently: for the Apollo Zola theme and the Openfox AI harness.
Which prompted me to wonder whether this practice already had a name. I found the CodeRabbit post on prompt requests, which was right on the spot, but nothing else. Hence this post, to draw attention to the matter.
What?🔗
The idea, in short: when you find a bug in a project, and you use an AI coding agent to fix it, do not submit the AI-generated pull request. Submit the prompt you used to fix the bug, with a comment that it seems to fix the bug on your setup, and passes the tests. Plus an overview of the useful info your AI investigation produced: the root cause analysis, the edge cases, the alternative paths tried.
The maintainers can then run the prompt themselves, in the harness and the LLM they are comfortable with — not the one you happened to have at hand — refine it, grill the AI with a grill-me style interrogation, and adjust it to their codebase. Instead of having the pain to review an unfamiliar PR.
This is not my invention, the name already exists: prompt requests. The CodeRabbit article traces the idea to a debate between Peter Steinberger, creator of the self-hosted AI agent Clawdbot, and Gergely Orosz of Pragmatic Engineer. At first I was going to call it "PS" for Prompt Suggest, but let's not reinvent the wheel.
Why?🔗
Maintainers are drowning in PR slop: AI-generated code that compiles, passes CI, and is utterly wrong for the codebase — style drift, redundant helpers, subtle architectural shortcuts. The asymmetric velocity problem: an agent generates code in seconds that takes a human hours to review.
The numbers are staggering: GitHub merged pull requests went from 25 million a month in January 2023 to 90 million a month in March 2026. A 3.6x increase, in an era where the number of human developers did not triple.
The most spectacular example was the 13,000-line AI-generated pull request on the OCaml compiler, rejected by the maintainers, who cited the lack of review resources. The author, Joel Reymont, had "carefully shepherded AI over the course of several days", and, asked why some files credited a maintainer as author, answered "Beats me. AI decided to do so and I didn't question it."
This is so bad that GitHub now lets maintainers disable pull requests entirely, or restrict them to collaborators. Open source projects are starting to close their front door rather than drown.
The root problem: code is now cheap. As Jeremiah Lowin writes in An Open-Source Maintainer's Guide to Saying No: "Historically, we could assume that since writing code is an expensive, high-effort activity, contributors would engage in discussion before doing the work. Today, LLMs have inverted this. Code is now cheap, and we see it offered in lieu of discourse."
Which prompted me to think: if the code is the cheap part, then the value of my contribution is not the diff — it is the investigation. The bug I found, the root cause my AI uncovered, the proof that a fix exists and passes the tests. And the prompt, which is the recipe to reproduce the investigation.
How?🔗
So here is what I think I will put from now on in a bug report instead of a pull request:
**Bug**: [short description, with a reproduction]
**Prompt** (tested, fixes the bug on my setup, tests pass):
> [the exact prompt(s) I gave to the agent]
**Harness / model**: opencode / DeepSeek v4 flash (or Claude Code / ...)
**Root cause**: [what the AI found]
**Edge cases**: [what the AI's analysis surfaced]The exact prompt is the key: like a minimal reproduction, it lets the maintainer run the fix in his environment — the harness and model he trusts, in the context of his codebase. He can refine it, ask the AI questions, interrogate it about edge cases. I have a grill-me skill in my own setup, I know it works :-)
Why do maintainers should like it?🔗
- No trust question: the code is generated in the maintainer's own sandbox, by his own model, with his own system prompts. The question is no longer "do I trust this stranger's code?" but "does my setup produce a good fix for this prompt?"
- Architecture control: the generated code follows the codebase conventions, because it is generated in the codebase.
- The maintainer stays the author: he is not inheriting 800 lines of alien code, he is applying an insight to his own project.
And the contributor still gets the satisfaction of having found and fixed the bug — which is the valuable part anyway.
Am I reinventing the wheel?🔗
Partly. The CodeRabbit article is more cautious than me: it argues prompt requests and pull requests are not in conflict, and prompt requests work best before pull requests — review the intent before generating, then still review the code that ships. That makes sense within a team, where you will have to maintain the result, and where determinism, git blame and accountability matter.
My point is narrower, and for a different case: the drive-by contribution. When you fix a bug in a project that is not yours, and you have no intention to maintain the result — which is most bug reports — the prompt is a better unit of exchange than the diff. It is the AI without AI of bug fixing: I provide the prompt, you run it in your own wetware (or your own GPU).
There are cases where a PR is still better: the trivial one-line fix, the case where you will maintain the fix, or the project that explicitly asks for PRs. Use your judgment.
So, next time your AI agent fixes a bug in somebody else's project: resist the urge to git push. Open an issue, and give the maintainers the prompt. They will be grateful, and the code will be better for it.
Maybe a modern twist on the old saying "dont give fishes, show how to fish".