Live data from Hacker News

I don't want your PRs anymore

dpc.pw

121–130 of 148 posts

Re: I don't want your PRs anymore

#121
post #116

Earlier quoted context omitted.

I'm currently running on a fork of Helix text editor, which I heavily gutted to replace the block cursor with a beam-style (like one in insert mode, but just all the time). Since the maintainers are drowning in PRs (472 open ATM), I understandably don't expect them to have time for my weird ideas. Then I pile on top whatever PRs I want that I find useful out of these 472, and with a little bit of LLM help I have a ve…

That's exactly the same viewpoint I have. How do you like Helix as a starting point? Currently, I'm having Claude write a little personal text editor with CodeEditTextView as a starting point and now that I saw your comment I suddenly realized I mostly like using a modal editor and only didn't do it here because I'm moving from a webpage (where Vimium style stuff never appealed to me). Good hint that. I wonder if neo…

From UX perspective modal editing is all I care about and I just got used to Helix. And it's very feature complete and relatively stable, so hacking it and maintaining bunch of patches is not a lot of churn in practice.

Re: I don't want your PRs anymore

#122
This is the best articulation of this viewpoint I have seen so far so I tip my hat to your writing skills.

I've been sitting with this post for a bit and something about the framing keeps bugging me.

I keep coming back to one question: are you planning to add Co-authored-by trailers to these commits?

The pitch is: don't send me code, send me the prompt you used to produce it. And on the surface that sounds like a lighter ask — a prompt is a small thing, one sentence maybe, versus a whole diff. But that's the sleight of hand. The prompt that produced a working patch is almost never one prompt. My PR is the compressed output of all of that work.

So "just send me the prompt" is doing two things at once. It's reframing the contributor's work as a small artifact (one prompt, how hard could that be), and it's reassigning the result of that work to whoever re-runs it. If I send you the actual thing that produced the patch — the whole transcript, the rejected attempts, the corrections — that's not a smaller contribution than a PR, it's a more complete one. And you're going to land the commit under your name.

This is the same shape of argument the model labs made about training data. Individual contribution is "too insignificant" to be worth crediting, but the aggregate is valuable and belongs to whoever assembled it. I don't love it there and I don't love it here.

The other thing I keep thinking about: to anyone who hasn't used these tools seriously, an engineer landing a high volume of clean commits under their own name looks like a very productive author. That gap between how it looks and what's actually happening is going to close eventually, but in the meantime it's a real incentive to set things up this way.

None of this is an argument against the workflow. Review is expensive, untrusted code is risky, I get it. I just want to make an argument for Co-authored-by being part of the deal.

Re: I don't want your PRs anymore

#123
I wrote an article a few months ago about how I expect open-source development to shift toward people no longer contributing code, but just contributing money, for the maintainers to purchase tokens to have AI ship a given feature request.

It wasn't popular but I think it will hold: https://essays.johnloeber.com/p/31-open-source-software-in-t...

Re: I don't want your PRs anymore

#124
Off-topic question about this:

> It's increasingly apparent that "the source code" is less "source" and more "code"

(How) does this affect the GPL and what it defines as "source code" (the preferred means of modification to a program)?

Re: I don't want your PRs anymore

#125

Somehow, this seems like a serious negative consequence of LLMs to me. We should consider how security patches move through the ecosystem. Changes like this are understandable but only because PRs from LLMs are so bad and prolific. When a new exploit is discovered, the number of sites that require a change goes up exponentially due to LLMs not using libraries. At the same time, the library contributors will likely no…

> When a new exploit is discovered, the number of sites that require a change goes up exponentially due to LLMs not using libraries

Conversely, if there's a supply chain attack in a library it's not being immediately spread to thousands of production servers.

Re: I don't want your PRs anymore

#126
post #86
post #27

I think every maintainer should be able to say how they want or don't want others to contribute. But i feel like it was always true that patches from the internet at large were largely more trouble then they were worth most of the time. The reason people accept them is not for the sake of the patch itself but because that is how you get new contributors who eventually become useful.

> But i feel like it was always true that patches from the internet at large were largely more trouble then they were worth most of the time. Oh god, I needed to add a feature to an open source project (kind of a freemium project) about fifteen years ago. I had no experience with professional software development nor did I have any understanding of pull requests. I sent one over after explaining what I was trying to…

I mean, that sounds more like you were setup to fail.

Re: I don't want your PRs anymore

#127
post #109
post #86

Earlier quoted context omitted.

> But i feel like it was always true that patches from the internet at large were largely more trouble then they were worth most of the time. Oh god, I needed to add a feature to an open source project (kind of a freemium project) about fifteen years ago. I had no experience with professional software development nor did I have any understanding of pull requests. I sent one over after explaining what I was trying to…

curious, what happened, and what did you learn? if they merge something blindly, then it's really on them if it makes a mess.

If I recall correctly I sent the PR as just a way to ship a blob of code, intending to use it to demo a specific UI feature that I wanted them to look at.

Meanwhile I was tinkering with the schema in the database and messing about deep in the guts of the software. I didn't really know how to separate the two so I just shipped the whole PR thinking they would just run it on the side to demo the thing I was talking to them about.

Well they just deployed it to their production instance and fucked everything up on their end.

I recall being horrified when I was tinkering with their customer-facing instance and seeing evidence of the other work I was doing. I immediately emailed them and said whoa whoa whoa. xD

Found the email that I sent to the founder, from 2014:

>It looked like may have got a few surprises in the code she merged from the 2.1M1br branch yesterday. I've just been committing basically all the tinkering i do to that branch, so it may have a few landmines in it.

>Hope i didn't create any headaches for anyone. Sorry!

Re: I don't want your PRs anymore

#128
post #55
post #47

This is only going to get worse with LLMs. Now people can "contribute" garbage code at 10x the speed. We're entering the era of the "read only" maintainer focused on self-defense.

...that assumes LLMs will contribute garbage code in the first place. Will they, though?

I heard a quote recently that I really like.

"AI sucks at most peoples' jobs. If you think AI is good at something, chances are you suck at it too."

Re: I don't want your PRs anymore

#129
> For these reasons, it's just easier if I make the code changes myself (with the help of an LLM).

Most git hosting providers allow maintainer to checkout a PR, commit changes to it, and merge with co-authoring. Might be a good workflow in this case.

Re: I don't want your PRs anymore

#130
post #79

Realistically, there are a much larger set of things that I don't mind forking these days. It is quite a bit of effort to get to a set of things that mostly don't have bugs, but in the past I might fork a few things[0] but these days, I vendor everything, and some things I just look at the feature list and have Claude rebuild it for me. So I totally understand why actual project maintainers and authors wouldn't want…

I'm currently running on a fork of Helix text editor, which I heavily gutted to replace the block cursor with a beam-style (like one in insert mode, but just all the time). Since the maintainers are drowning in PRs (472 open ATM), I understandably don't expect them to have time for my weird ideas. Then I pile on top whatever PRs I want that I find useful out of these 472, and with a little bit of LLM help I have a ve…

I do exactly that also, like ten thousand of other emacs users. We can customize our editor with a proper language, no need for forks.
Post reply on HN