Hacker News Reader

Comment by marginalia_nu | Hacker News Reader

Kdenlive has some unfortunate performance regression when working with larger projects with many clips.

I managed to track down a few of them while evaluating Claude Code a while back (mostly certain actions doing O(n) scans over all clips every mouse event needing debouncing), and got it mostly back down to tolerable levels again, but have been holding onto them because unsolicited drive by AI PRs are very annoying from a code project maintenance perspective, as the changes are almost certainly poorly factored.

Was half considering creating a Kdenvibe fork, but that would also be in bad taste. So right now I don't know what to do with the diff.

View on HN

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.

This is a great comment. As someone who has been involved in managing a large (business backed) OSS project I can say that even if we preferred to have our own solutions to issues, we really valued comprehensive issues and draft PRs to reference.

Sometimes you just don't have the time to get a PR to a projects mergeable standards, but the solution as a reference can have a ton of value for those that eventually get a PR across the finish line.

I would say, though, that agentic coding seriously complicates the entire situation...

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.

Reply on news.ycombinator.com