I'd open a Draft PR and an Issue to explain the problems you encountered and how you've solved them for your own use cases... then leave it up to them to learn from it or close it.

I get annoyed with "drive-by PRs" only when they lack context or are clearly just a way to get some commits into a project (typos and so on), but any findings that can improve my code or its performance is welcome, in my projects at least.

Creating the PR, doing the explanation you just did, and closing it yourself might be a good option. Then at least your code lives somewhere that someone else can reuse if desired. Ideally combined with a linked issue that you do keep open.

You can write a bug report for each problem and attach a patch with the corresponding hack. Best thing you can do short of providing clean fixes.

My suggestion is to do a “human summary” of what you asked the agent and what it found, maybe supply the code it generated, mayyybe.. but mostly recommend they not review it but instead, the reviewer give the PR to their own agent to do a reimplementation.

Since code is cheap now, why not replace reviewing with reimplementing!

You should be running your own fork before making pull requests. You don’t have to get other people to use it, you just need to get in the habit of rebasing regularly and cutting releases for yourself. Someday I hope maintainers get better visibility into downstream improvements without the politics of pull requests.

Id say ask AI to ‘describe the problem and solution from a high level. avoid code excerpts if possible.’ Submit as a bug report and mention you have an AI solution for reference if desired.

[dead]