Hacker News Reader

Comment by lou1306 | Hacker News Reader

> On top of that, there are a lot of personal and subjective aspects to code. You might have certain preferences about formatting, style, structure, dependencies, and approach, and I have mine.

95% of this is covered by a warning that says "I won't merge any PR that a) does not pass linting (configured to my liking) and b) introduces extra deps"

> With LLMs, it's easier for me to get my own LLM to make the change and then review it myself.

So this person is passing on free labour and instead prefers a BDFL schema, possibly supported by a code assistant they likely have to pay for. All for a supposed risk of malice?

I don't know. I never worked on a large (and/or widely adopted) open-source codebase. But I am afraid we would've never had Linux under this mindset.

View on HN

I'm with the author here; I don't really feel like dealing with people's PRs on my personal projects. The fact that GitHub only implemented a feature to disable PRs in February is absolutely baffling to me, but I'm glad it's there. Just because a project's source code is made available to the public under a permissive license does not mean the maintainer is under any obligation to merge other people's changes.

It feels like a lot of people assume a sense of entitlement because one platform vendor settled on a specific usage pattern early on.

No. When code is cheaper to generate than to review, it's cheaper to take a (well-written) bug report and generate the code yourself than to try to figure out exactly what the PR does and whether it has any subtle logical or architectural errors.

I find myself doing the same, nowadays I want bug reports and feature requests, not PRs. If the feature fits in with my product vision, I implement and release it quickly. The code itself has little value, in this case.

I definitely trust my local LLM where I know the prompt that was used. Even if the code generated ends up being near-identical, it'll be way faster to review a PR from someone or something I trust than from some rando on the Internet

> 95% of this is covered by a warning that says "I won't merge any PR that a) does not pass linting (configured to my liking) and b) introduces extra deps"

Maybe I'm not up to date with the bleeding edge of linters, but I've never seen one that adequately flags

    let out = []
    for(let x of arr){
      if(x > 3){
        out.append(x + 5)
      }
    }

Into

   let out = arr
             .filter(x => x > 3)
             .map(x => x + 3)

There's all sorts of architectural decisions at even higher levels than that.

Indeed, yours has both more allocations and a bug (+3 instead of +5)

More allocations is a good point but you're being pedantic about the bug... how do you know the +5 isn't the bug? :P

Reply on news.ycombinator.com