Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Trust me when I say that in the hands of someone who doesn't have your experience, the LLMs would not be getting the results you get.

https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/23049

So there's this 11 year old issue in a forgotten ffmpeg plugin and I fixed it with deepseek by putting it into a self-testing loop. Probably would have taken me a few weeks to even understand the initial code to begin with. I haven't done C work in a long ass time and have zero knowledge of even what sub pixel sampling means.

With DS4 took me a few days and a couple of dollars. And by few days I mean I checked on it a few minutes every half hour or so a few times.

I don't understand the code it wrote but it's been in production for a while now and no issues so it's good. Ended up speeding up our video processing pipeline by 20-30%.



So while I do agree that it is cool you were able to do this, I‘ll say:

Sending in the patches but refusing to take responsibility for them is a surefire way to contribute to maintainer burnout. Please don’t do this. Either commit to fixing something and driving the PR to merge, or abstain from it entirely.

The bottleneck isn’t the speed of coding, and what you’re doing here is actively worsening the situation.


idk if it's really worsening, someone who has the same issue can apply the patch. I understand why they rejected it but also I'm not willing to learn everything that DS4 did there since I don't plan on working on ffmpeg filters and the knowledge is pretty much useless to me outside this patch. Too much time commitment for.. fixing a filter no one really cared about for 11 years.

But you can see how the parent's comment doesn't really hold, I was able to achieve this while not knowing anything other than what I need fixed and making the LLM test itself towards that goal.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: