Hacker Newsnew | past | comments | ask | show | jobs | submit | more dack's commentslogin

I think it's the least hostile thing they can say, and I respect their decision for their own project.

That said, it still feels like they are unnecessarily hobbling their project. LLMs are tools and they can help you think, research, and code. You can overuse them, yes, but you should embrace them where they help.

not accepting bun's PR for other reasons is totally fine (sounds like it's a core change where more thinking needs to be done), but simply banning all LLM authored PRs is unnecessarily restrictive. Just focus on the quality of the work.


Why review thousands of lines of LLM generated code from some random person you don’t know when you could use an LLM yourself to do the same thing, except with probably a better design and more thoughtful approach?

Maintainers should get to spend their time developing stuff, not just reviewing low effort PRs. The flood of LLM code is changing the balance for the worse for maintainers, and I can totally see why they’d just want to ban it.


>Why review thousands of lines of LLM generated code from some random person you don’t know when you could use an LLM yourself to do the same thing

Because getting an LLM to do it yourself still takes time and attention bandwidth and tokens.


But at least you know how the sausage was made by the end. You have no idea how high or low quality any PR from a random person online is, and taking any amount of time to review a PR could be a total waste.


but that doesn't have anything to do with LLMs.

if someone made the same gigantic mess of a PR without LLMs, it would still be rejected, because it is a gigantic mess of a PR.

the low effort part is the problem. what if i made a great, focused, readable PR but had claude write it out? what if i carefully checked and deliberated each line, just as if i had written it myself?

granted, in the real world, 99.9% of slop PRs are written by LLMs. so i thought "okay, reasonable, ban the thing that is most likely to cause problems."

but then how does the "no LLM translators!" rule fit into that view?


It’s the lack of friction that LLMs bring. It’s easy to put in a couple of lines and generate 1000’s of lines of code. Whereas the person would never have done that without LLMs.

I think LLM dev needs to take a better spec driven approach. The vibing is getting to be annoying.


I think the only thing that will save us is smarter models. Slop coders are not going to stop making slop.

They’ll still use even smarter LLMs badly no doubt, but I’m thinking that maintainers of open source projects will be able to more effectively use LLMs to review potential PRs to weed out the truly bad ones quickly.


I guess they could setup a competent openclaw pr review agent. The problem is again - cost. Who is paying for the token usage by open source projects? How many tokens before they exhaust their quota with junk PRs?


Well previously lazy contributors simply would never have made a PR because it was too much work. Now they can have an LLM make a PR with virtually no effort at all.

It’s obviously an imperfect rule, and maybe it’ll change over time. But I am just saying that I understand why open source maintainers are doing this.

There is just no possibility for them to review all the low effort AI slop being thrown their way. Yes, some of it is going to actually be very high quality, but you don’t know that until you review it, which is the whole issue.


Agree, but "no LLMs" locks out good PRs and contributors too.

I hypothesize it may have roughly the same effect as denying all contributions where the author used intellisense 10y ago.

A substantial portion of people who write good code will be using some sort of LLM assistance, even if it is just something like Cursor Tab (autocomplete).

Yes, you'll also hit all of the spammy PR "contributors", but you'd also do so by prohibiting all contributions by people who have a belly button


Use AI to Fork it, add your own features, pull in upstream changes. What are the odds that the lazy contributor with AI is better in the long run?


I agree but I dont see a better way to achieve it.

Look at it this way. If a human has interpreted their LLM use so well that they can submit to zig and not get caught, then the LLM use is acceptable.

What they are doing in practice is filtering off all the submissions from lazy people who dont sit between the LLM and the PR.

If you cant be bothered to cover your tracks enough to make the LLM output into a good PR, thats no longer the maintainers problem.

In a decade all of these anti AI policies will go away as the costs go up, and LLMs become less detectable. In the mean time it seems very efficient.


it's a cool article but would immensely help from gifs or videos to go along with the explanation


i want 5.4 nano to decide whether my prompt needs 5.4 xhigh and route to it automatically


As per OpenAI themselves, xhigh is only necessary if the agent gets stuck on a long running task. Otherwise it’s thinking trades use so many tokens of context that it’s less effective than high for a great majority of tasks. This has also been my experience.


yes but didn't greg brockman say he just runs on xhigh at all times?


Like any work estimation, it will likely disappoint.


yeah there's way more demand, and at the same time, it's way easier for the company to build and maintain (with the help of AI). Great to see!


if you include "it turns out that", you're implying that maybe you thought the same as them in the past, but looked into it, and learned something interesting. if you omit that, you're just correcting them and subtly implying that they aren't as smart as you (e.g. it was obvious to you)


i don't know what else they can say about their own business.. but it's clearly cope.

sure, there's a lot of compliance/legal concerns, but AI is probably already better at reading all the relevant information and encoding that into a system than humans.

I don't think a non-technical person is going to one-shot it, but a technical person could today. The biggest issue would be marketing and maintenance (companies aren't going to buy from a single random person who might abandon the project at a moment's notice)


last i checked, you can't annotate inline with planning mode. you have to type a lot to explain precisely what needs to change, and then it re-presents you with a plan (which may or may not have changed something else).

i like the idea of having an actual document because you could actually compare the before and after versions if you wanted to confirm things changed as intended when you gave feedback


'Giving precise feedback on a plan' is literally annotating the plan.

It comes back to you with an update for verification.

You ask it to 'write the plan' as matter of good practice.

What the author is describing is conventional usage of claude code.


A plan is just a file you can edit and then tell CC to check your annotations


they have pretty fierce competition though, so i doubt this is intentional. my guess is they just have a million things to do and that isn't at the top of the list


if i were you @susam, i'd use claude code to parse all these submissions into your json file! i bet opus 4.5 would do it flawlessly


what are your goals? it's usually tough to sell things to developers because they are very particular about how they want their software to work, and also would rather build their own tools much of the time (which is increasingly true with AI now).

if you really want to sell it, you should probably make sure that you have customers willing to pay, which means talking to potential customers and getting them on a waitlist. i think it's usually more likely that other people don't care about your software like you do (because you built it to be exactly what you want and know how it works) and even then, aren't willing to pay to use it (or pay very much)

if you're not very concerned about making money and mostly just want something nice for yourself that other people _might_ care about, then sure, go for it! i build software like that all the time


that's pretty much my attitude... build it for me and if others like it and pay for it, great. if not, then i got myself a killer email client.

I already have it almost working with outlook and gmail accounts and have local AI working and analyzing emails and so on. it's really cool (at least for me) and can't wait to share it publicly.

I did setup a waitlist and a landing page https://www.nitroinbox.com/


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

Search: