Someone Still Has to Read It
A good patch still asks somebody to understand it, accept it, and live with it.
Published
Producing a patch and accepting responsibility for it are different jobs.
An agent can give you an implementation, tests, and a convincing explanation quickly. The person merging it still has to decide whether the change belongs in the system, whether the evidence is sufficient, and what they are agreeing to maintain afterwards.
I use these tools heavily. I’m not looking at this from outside the practice. I want them to produce good work, and I also have to live with the code that gets accepted.
The interesting problem is what happens when the work is good. Bad submissions are annoying, but at least the decision can be simple. A useful contribution deserves attention. Enough useful contributions can still exceed the attention available.
Quality doesn’t make the queue disappear
Daniel Stenberg’s April 2026 account of curl describes a shift in incoming reports: better material, including real vulnerabilities and useful bugs, arriving in a volume that still strains maintainers. Filtering out the rubbish does not solve that problem. The reports that deserve attention are themselves enough to fill the queue.1
If a report identifies a real problem, someone needs to reproduce it, establish its scope, decide how to fix it, review the change, and handle the release. The report being accurate is the beginning of that work.
Rejecting everything generated with assistance would throw away useful contributions. Accepting everything that looks plausible would transfer the risk to the users and maintainers. Neither decision becomes sensible because it is easy to automate.
A maintainer can change the deal
Curl made a concrete decision about this before that April account. It ended its bug bounty at the end of January 2026. Stenberg described the time spent disproving reports and arguing over findings; the project removed the financial reward rather than charging researchers an entry fee. Charging would have created payment disputes and administration, while potentially excluding people with legitimate reports.2
The reporting channel was a separate decision. Curl moved security reports to GitHub, then announced a return to HackerOne from 1 March, still without bounties. The team needed private discussion, internal notes, public disclosure after resolution, report classification and control over its own CVE assignments. Receiving a report was only the first step in the job.3
That sequence is useful because it separates three things people tend to bundle together: the incentive to submit, the tool used to receive the submission, and the work required to resolve it. You can improve one and still have a problem with the others.
By April, better reports were arriving in greater volume. The maintainer’s problem had changed. More correct findings meant more real decisions about fixes, releases and the users who needed to update.1
I think about this whenever a contribution is described only in terms of what it gives the project. It also asks the project to do something. The author ought to be able to say what that is.
The work hidden inside a small diff
A change can be short and still require understanding a large part of the system.
The reviewer needs to know what owns the behaviour. Is the patch correcting that owner, or adding an exception somewhere convenient? Does another implementation use the same contract? Is the new state scoped correctly? What does the test establish, and under which conditions?
These questions are not answered by the line count. A tiny option can create a lasting support obligation. A dependency can introduce release work. A compatibility path can become something the project is expected to maintain indefinitely.
That does not make new features bad. It makes the merge a decision about the project’s future, not just a judgment that today’s example runs.
This is why a strong report can be more useful than an ambitious patch. If someone has isolated a concrete problem and shown how to reproduce it, the maintainer can decide on the right fix. A large proposed solution built around an unconfirmed premise can require more work to evaluate than the original issue.
Consider a proposed legacyMode flag. Two branches, a default, a couple of tests. It can look like a generous way to avoid breaking anybody.
Now the project has two behaviours to explain. Every related bug report needs to identify the mode. Examples need to choose one. Future changes need to preserve both or announce when one ends. A five-line compatibility switch can commit somebody to years of answering questions about it.
That may be a good trade. A migration with thousands of users can deserve it. The contribution becomes easier to assess when it names who needs the old behaviour, how they will move, and when the flag can go away. Without those answers, the small diff has left its largest decision to the maintainer.
What helps the person reading it
State the behaviour you expected and what happened. Identify the relevant revision and conditions. Give the smallest useful reproduction. Explain where the responsibility appears to belong, while leaving room for the maintainer to correct that understanding.
Then describe the checks you actually ran and what they establish. A command that passes is useful evidence for its scope. It doesn’t need to become a claim that every possible interaction has been proved.
The explanation should make the review smaller. If it merely narrates every line of the diff, the reviewer has two versions of the same material to read. If it identifies the important decision and the evidence behind it, it can save them a great deal of searching.
Proportion matters. A typo does not need a dossier. A change to persistent state or an authority boundary needs more than “tests pass.” The useful standard depends on what the project is being asked to accept.
The contributor has a point too
It is easy to describe maintenance as though every contributor is demanding something unreasonable. That isn’t fair.
A person can put serious work into a patch and then wait weeks without knowing whether anyone wants it. A project can demand extensive evidence before giving even a basic indication of scope. A refusal can be correct and still be communicated badly.
Maintainers should make wanted work visible, explain the evidence needed for consequential changes, and give clear scope decisions. Contributors should not have to infer the project’s direction from silence.
There is a downstream user in the picture as well. They may have a real problem while the contributor and maintainer negotiate the implementation. That gives the discussion stakes beyond either person’s pride in the patch.
A rejection is sometimes the right decision. It should still answer the proposal that was made and leave the person understanding what happened.
Automation on the receiving side
There is no reason the maintainer should have to do everything manually while the contributor uses every available tool.
An agent can help locate the relevant code, reproduce a reported behaviour, inspect related implementations, or prepare a targeted review. A good use removes uncertainty the maintainer would otherwise have had to investigate.
A poor use creates another queue. Ten plausible objections are not automatically ten useful findings. Someone still has to decide which objections are real and relevant. The receiving side deserves the same quality standard as the submitted work.
I care about whether the assistance makes the next decision easier. Did it establish the affected version? Did it identify the existing owner? Did it exercise the condition the report describes? Did it notice that the proposed change is unnecessary?
That is a more useful measure than how many review comments the agent produced.
Someone owns the result after merge
A merged change becomes part of what users rely on. Its original author may move on. The person who accepted it still has to answer questions about how it fits, what it means, and what happens when the surrounding system changes.
There is an economic question here too. Cheap submission can shift work onto a project whose capacity has not grown at the same rate. A company benefiting from a dependency should think about the maintenance it relies on, rather than treating its stream of suggestions as a contribution simply because producing them cost something.
Paying maintainers can buy more time for that work. It still takes context and judgment to decide what belongs in the project. A contribution is easier to absorb when its author has done enough of the investigation to make that decision smaller.
Good contributions can increase capacity as well. A clear reproduction, a focused fix, or a maintained piece of documentation can leave the project in a better position than before. That is the work worth making easier to accept.
Before sending the patch
The standard I want for work produced with agents is the same standard I want when receiving it: understand what you are proposing well enough to explain why it belongs.
You don’t need to pretend you wrote every character unaided. You do need to take responsibility for the request you’re placing in front of another person. An agent’s confident summary is not a substitute for knowing the change.