The LLM ban is unenforceable, they must know this. Is it to scare off the most obvious stuff and have a way to kick people off easily in case of incomplete evidence?

Probably just an attempt to stop low effort LLM copy pasta.

It is enforceable, I think you mean to say that it cannot be prevented since people can attempt to hide their usage? Most rules and laws are like that, you proscribe some behavior but that doesn't prevent people from doing it. Therefore you typically need to also define punishments:

This policy is not open to discussion, any content submitted that is clearly labelled as LLM-generated (including issues, merge requests, and merge request descriptions) will be immediately closed, and any attempt to bypass this policy will result in a ban from the project.

What happens when the PR is clear, reasonable, short, checked by a human, and clearly fixes, implements, or otherwise improves the code base and has no alternative implementation that is reasonably different from the initially presented version?

If you're going to set a firm "no AI" policy, then my inclination would be to treat that kind of PR in the same way the US legal system does evidence obtained illegally: you say "sorry, no, we told you the rules and so you've wasted effort -- we will not take this even if it is good and perhaps the only sensible implementation". Perhaps somebody else will eventually re-implement it later without looking at the AI PR.

How funny would it be if the path to actually implement that thing is then cut off because of a PR that was submitted with the exact same patch. I'm honestly sitting here grinning at the absurdity demonstrated here. Some things can only be done a certain way. Especially when you're working with 3rd party libraries and APIs. The name of the function is the name of the function. There's no walking around it.

That's why I said "somebody else, without looking at it". Clean-room reimplementation, if you like. The functionality is not forever unimplementable, it is only not implementable by merging this AI-generated PR.

It's similar to how I can't implement a feature by copying-and-pasting the obvious code from some commercially licensed project. But somebody else could write basically the same thing independently without knowing about the proprietary-license code, and that would be fine.

You not realizing how ridiculous this is, is exactly why half of all devs are about to get left behind.

Like, this should be enshrined as the quintessential “they simply, obstinately, perilously, refused to get it” moment.

Shortly, no one is going to care about anyone’s bespoke manual keyboard entry of code if it takes 10 times as long to produce the same functionality with imperceptibly less error.

Shortly, no one is going to care about anyone’s bespoke manual keyboard entry of code if it takes 10 times as long to produce the same functionality with imperceptibly less error.

Well that day doesn't appear to be coming any time soon. Even after years of supposed improvements, LLMs make mistakes so frequently that you can't trust anything they put out, which completely negates any time savings from not writing the code.

no one is going to care about anyone’s bespoke manual keyboard entry of code if it takes 10 times as long to produce the same functionality with imperceptibly less error.

No one is going to care about anyone’s painstaking avoidance of chlorofluorocarbons if it takes ten times as long to style your hair with imperceptibly less ozone hole damage.

This is a non-argument. All of the cloud LLM's are going to move to things like micronuclear. And the scientific advances AI might enable may also help avoid downstream problems from the carbon footprint

This is where most reasonable people would say “OK, fine”

CLEARLY, a lot of developers are not reasonable

It is entirely reasonable for a project to require you to attest that the thing you are contributing is your own work.

The unreasonable ones are the ones with the oppositional-defiant “You can’t tell me I can’t use an LLM!” reaction.

It IS their own work.

The simplest refutation of your point of view is, who or what is responsible if the work submission is wrong?

It will always be the person’s, never the computer’s. Conveniently, AI always acts as if it has no skin in the game… because it literally and figuratively doesn’t… so for people to treat it like it does, should be penalized

If it’s the output of an LLM, it’s not their own work.

Who prompted the LLM?

Who vetted the output?

Who ensured there was adequate test coverage?

Who insisted on a certain design?

Who is to blame if it's bad code? That is the same entity that is responsible, and the same entity that "did it"

tl;dr your stance is full of poop, my dude

How would you tell that it's LLM-generated in that case?

If the submitter is prepared to explain the code and vouch for its quality then that might reasonably fall under "don't ask, don't tell".

However, if LLM output is either (a) uncopyrightable or (b) considered a derivative work of the source that was used to train the model, then you have a legal problem. And the legal system does care about invisible "bit colour".

It's (c) copyright of the operator.

For one simple reason. Intention.

Here's some code for example: https://i.imgur.com/dp0QHBp.png

Both sides written by an LLM. Both sides written based on my explicit prompts explaining exactly how I want it to behave, then testing, retesting, and generally doing all the normal software eng due diligence necessary for basic QA. Sometimes the prompts are explicitly "change this variable name" and it ends up changing 2 lines of code no different from a find/replace.

Also I'm watching it reason in real time by running terminal commands to probe runtime data and extrapolate the right code. I've already seen it fix basic bugs because an RFC wasn't adhered to perfectly. Even leaving a nice comment explaining why we're ignoring the RFC in that one spot.

Eventually these arguments are kinda exhausting. People will use it to build stuff and the stuff they build ends up retraining it so we're already hundreds of generations deep on the retraining already and talking about licenses at this point feels absurd to me.

I think you need to read the report from the US Copyright office that specifically says that it's *not* (c) copyright of the operator.

It doesn't matter if the "change this variable name" instruction ends up with the same result as a human operator using a text editor.

There is a big difference between "change this variable name" and "refactor this code base to extract a singleton".

You may as well be the MPAA right now throwing threats around sharing MP3s. We're past the point of caring and the laws will catch up with reality eventually. The US copyright office says things that get turned over in court all the time.

lol, ask the software industry whether or not their "past the point of caring" about the licenses on their software.

Whether it's an OSS license or a commercial license, both are dependent on copyright as the underlying IP Right.

The courts have so far (in the US) agreed with the Copyright office's reasoning.

Use an LLM as a tool, mostly OK.

Use it to create source from scratch, no copyright as the author isn't human.

Use it to modify existing software, the result is only copyright on whatever original remains.

Unenforceable means they can't actually enforce it since they can't discriminate high quality LLM code from hand typed

[flagged]

The LLM ban is unenforceable

Just require that the CLA/Certificate of Origin statement be printed out, signed, and mailed with an envelope and stamp, where besides attesting that they appropriately license their contributions ((A)GPL, BSD, MIT, or whatever) and have the authority to do so, that they also attest that they haven't used any LLMs for their contributions. This will strongly deter direct LLM usage. Indirect usage, where people whip up LLM-generated PoCs that they then rewrite, will still probably go on, and go on without detection, but that's less objectionable morally (and legally) than trying to directly commit LLM code.

As an aside, I've noticed a huge drop off in license literacy amongst developers, as well as respect for the license choices of other developers/projects. I can't tell if LLMs caused this, but there's a noticeable difference from the way things were 10 years ago.

As an aside, I've noticed a huge drop off in license literacy amongst developers

What do you mean by this? I always assumed this was the case anyway; MIT is, if I'm not mistaken, one of the mostly used licenses. I typically had a "fuck it" attitude when it came to the license, and I assume quite a lot of other people shared that sentiment. The code is the fun bit.

I always assumed this was the case anyway; MIT is, if I'm not mistaken, one of the mostly used licenses

No, it wasn't that way in the 2000s, e.g., on platforms like SourceForge, where OSS devs would go out of their way to learn the terms and conditions of the popular licenses and made sure to respect each other's license choices, and usually defaulted to GPL (or LGPL), unless there was a compelling reason not to: https://web.archive.org/web/20160326002305/https://redmonk.c...

Now the corporate-backed "MIT-EVERYTHING" mindvirus has ruined all of that: https://opensource.org/blog/top-open-source-licenses-in-2025

... you think It was good time?

Not being able to publish anything without sifting through all the libs licences? Remembering legalese, jurisprudence, edge cases, on top of everything else?

MIT became ubiquitous because it gives us peace of mind

You have to go through all the dependencies anyway, to roughly judge their quality, and the activity of their maintainers. Quickly looking at the license doesn't take any more effort.

Totally realistic expectation

Sarcasm? Nobody will be contributing with a complexe signing process like that, and it doesn't guarantee anything in the end, it's like a high tech pinky swear

Hm, wondering how to enforce this rule. Rules without any means to enforce them can put the honest people into a disadvantage.

This policy is not open to discussion, any content submitted that is clearly labelled as LLM-generated (including issues, merge requests, and merge request descriptions) will be immediately closed, and any attempt to bypass this policy will result in a ban from the project.

It sounds serious and strict, but it applies to content that's 'clearly labelled as LLM-generated'. So what about content that isn't as clear? I don't know what to make of it.

My guess is that the serious tone is to avoid any possible legal issues that may arise from the inadvertent inclusion of AI-generated code. But the general motivation might be to avoid wasting the maintainers' time on reviewing confusing and sloppy submissions that are made using the lazy use of AI (as opposed finely guided and well reviewed AI code).

Glad to see they are applying some rigor. I've started removing AI-heavy projects from my dependency tree.

Are you and Redox just going to fall behind? Projects that used to take months take days or hours.

It seems well intentioned, but lots of bad ideas are like this.

I was told by my customer they didn't need my help because Claude Code did the program they wanted me to quote. I sheepishly said, 'I can send an intern to work in-house if you don't want to spend internal resources on it.'

I can't really imagine what kind of code will be done by hand anymore... Even military level stuff can run large local models.

Projects that used to take months still take months. LLM’s are only useful for throwaway low-quality slop. Perhaps some times the sloperator will get lucky and the end result isn’t something that will bite them in the ass. But the rest of us foresee a mountain of tech debt that will come knocking one day.

This is like 2 months outdated.

I think this is a reasonable decision (although maybe increasingly insufficient).

It doesn't really matter what your stance on AI is, the problem is the increased review burden on OSS maintainers.

In the past, the code itself was a sort of proof of effort - you would need to invest some time and effort on your PRs, otherwise they would be easily dismissed at a glance. That is no longer the case, as LLMs can quickly generate PRs that might look superficially correct. Effort can still have been out into those PRs, but there is no way to tell without spending time reviewing in more detail.

Policies like this help decrease that review burden, by outright rejecting what can be identified as LLM-generated code at a glance. That is probably a fair bit today, but it might get harder over time, though, so I suspect eventually we will see a shift towards more trust-based models, where you cannot submit PRs if you haven't been approved in advance somehow.

Even if we assume LLMs would consistently generate good enough quality code, code submitted by someone untrusted would still need detailed review for many reasons - so even in that case it would like be faster for the maintainers to just use the tools themselves, rather than reviewing someone else's use of the same tools.

I feel like the pattern here is donate compute, not code. If agents are writing most of the software anyway, why deal with the overhead of reviewing other people's PRs? You're basically reviewing someone else's agent output when you could just run your own.

Maintainers could just accept feature requests, point their own agents at them using donated compute, and skip the whole review dance. You get code that actually matches the project's style and conventions, and nobody has to spend time cleaning up after a stranger's slightly-off take on how things should work.

Well, it's not quite that easy because someone still has to test the agent's output and make sure it works as expected, which it often doesn't. In many cases, they still need to read the code and make sure that it does what it's supposed to do. Or they may need to spend time coming up with an effective prompt, which can be harder than it sounds for complicated projects where models will fail if you ask them to implement a feature without giving them detailed guidance on how to do so.

Definitely, but that's kind of my point: the maintainers are still going to be way better at all of that than some random contributor who just wants a feature, vibe codes it, and barely tests it. The maintainers already know the codebase, they understand the implications of changes, and they can write much better plans for the agent to follow, which they can verify against. Having a great plan written down that you can verify against drastically lowers the risk of LLM-generated code

So your proposed solution to AI slop PRs is to "donate" compute, so the maintainers can waste their time by generating the AI slop themselves?

The point isn't that agent output is magically better; it's that reviewing your own agent's output is way cheaper (intellectually) than reviewing a stranger's, because you've written the plan by yourself. And 'slop' is mostly what you get when you don't have a clear plan to verify against. Maintainers writing detailed specs for their own agents is a very different thing from someone vibe coding a feature request

Isn't the obvious solution to not accept drive by changes?

That's eliminating of an important part of open source culture.

I don't think it really is - drive-by changes have been a net burden on maintainers long before LLMs started writing code. Someone who wants to put in the work to become a repeat contributor to a project is a different story.

How to differentiate between a drive-by contribution and a first contribution from a potentially long-time contrubutor.

And I would say especially for operating systems if it gets any adoption irregular contributions are pretty legit. E.g. when someone wants just one specific piece of hardware supported that no one else has or needs without being employed by the vendor.

This sounds complicated in theory, but it's easier in practice.

Potential long time contributor is somebody who was already asking annoying questions in the irc channel for a few months and helped with other stuff before shooting off th e PR. If the PR is the first time you hear from a person -- that's pretty drive-by ish.

Why would I ask annoying questions when I can identify, reproduce, pinpoint the bug, locate it in code, and fix it? Doing it alone should make it clear I don't need to ask to understand it. And why would I be interested in small talk? Doubt many people are when they patch up their work tools. It's a dispassionate kind of kindness.

Not to mention LLMs can be annoying, too. Demand this, and you'll only be inviting bots to pester devs on IRC.

Why would I ask annoying questions when I can identify, reproduce, pinpoint the bug, locate it in code, and fix it?

Because if the bug is sufficiently simple that an outsider with zero context to fix, there's a non-zero chance that the maintainers know about it and have a reason why it hasn't been addressed yet

i.e. the bug fix may have backwards-compatibility implications for other users which you aren't aware of. Or the maintainers may be bandwidth-limited, and reviewing your PR is an additional drain on that bandwidth that takes away from fixing larger issues

how in the heck do you disambiguate a first time long term contributor and a first time drive by contributor?

Mostly by whether they check in first to see if the fix is actually welcome?

Drive-by folks tend to blindly fix the issue they care about, without regard to how/whether it fits into the overall project direction

I've gotta disagree with you here - it's not uncommon for me to be diving into a library I'm using at work, find a small issue or something that could be improved (measurably, not stylistically), and open a PR to fix it. No big rewrites or anything crazy, but it would definitely fit the definition of "drive by change" that _thus far_ has been welcomed.

Hard disagree. Drive by's were the easiest to deal with, and the most welcome. Especially when the community tilted more to the side of non-amateurs and passionate people.

Project maintainers will always have the right to decide how to maintain their projects, and "owe" nothing to no one.

That being said, to outright ban a technology in 2026 on pure "vibes" is not something I'd say is reasonable. Others have already commented that it's likely unenforceable, but I'd also say it's unreasonable for the sake of utility. It leaves stuff on the table in a time where they really shouldn't. Things like documentation tracking, regression tracking, security, feature parity, etc. can all be enhanced with carefully orchestrated assistance. To simply ban this is ... a choice, I guess. But it's not reasonable, in my book. It's like saying we won't use ci/cd, because it's automated stuff, we're purely manual here.

I think a lot of projects will find ways to adapt. Create good guidelines, help the community to use the best tools for the best tasks, and use automation wherever it makes sense.

At the end of the day slop is slop. You can always refuse to even look at something if you don't like the presentation. Or if the code is a mess. Or if it doesn't follow conventions. Or if a PR is +203323 lines, and so on. But attaching "LLMs aka AI" to the reasoning only invites drama, if anything it makes the effort of distinguishing good content from good looking content even harder, and so on. In the long run it won't be viable. If there's a good way to optimise a piece of code, it won't matter where that optimisation came from, as long as it can be proved it's good.

tl;dr; focus on better verification instead of better identification; prove that a change is good instead of focusing where it came from; test, learn and adapt. Dogma was never good.

Or if the code is a mess. Or if it doesn't follow conventions.

In my experience these things are very easily fixable by ai, I just ask it to follow the patterns found and conventions used in the code and it does that pretty well.

I've recently worked extensively with "prompt coding", and the model we're using is very good at following such instructions early on. However after deep reasoning around problems, it tends to focus more on solving the problem at hand than following established guidelines.

Still haven't found a good way to keep it on course other than "Hey, remember that thing that you're required to do? Still do that please."

A separate pre-planning step, so the context window doesn’t get too full too early on.

Off the shelf agentic coding tools should be doing this for you.

That being said, to outright ban a technology in 2026 on pure "vibes" is not something I'd say is reasonable.

To outright accept LLM contributions would be as much "pure vibes" as banning it.

The thing is, those that maintain open source projects have to make a decision where they want to spend their time. It's open source, they are not being paid for it, they should and will decide what it acceptable and what is not.

If you dislike it, you are free to fork it and make a "LLM's welcome" fork. If, as you imply, the LLM contributions are invaluable, your fork should eventually become the better choice.

Or you can complain to the void that open source maintainers don't want to deal with low effort vibe coded bullshit PRs.

Your reply is based on a 100% bad-faith, intellectually dishonest interpretation of the comment to which you’re replying. You know that. Nobody claimed that LLM code should be outright accepted. Also, nobody claimed that open source maintainers have the right to accept or decline based on whichever criteria they choose. To always come back to this point is so…American. It’s a cop-out. It’s a thought-terminating cliche. If you aren’t interested in discussing the merits of the decision, don’t bother joining the conversation. The world doesn’t need you to explain what consent is.

Most of all, I’m sick of the patronising “don’t forget that you can fork the project!” What’s the point of saying this? We all know. Nobody needs to be reminded. Nobody isn’t aware. You aren’t being clever. You aren’t adding anything to the conversation. You’re being snarky.

Or you can complain to the void that open source maintainers don't want to deal with low effort vibe coded bullshit PRs.

If you look back and think about what your saying for a minute, it's that low effort PRs are bad.

Using an LLM to assist in development does not instantly make the whole work 'low effort'.

It's also unenforceable and will create AI witch hunts. Someone used an em-dash in a 500 line PR? Oh the horror that's a reject and ban from the project.

2000 line PR where the user launched multiple agents going over the PR for 'AI patterns'? Perfectly acceptable, no AI here.

The entire basis of the OSS is licensing.

Licensing is dependent on IPR, primarily copyright.

It is very unclear whether the output of an AI tool is subject to copyright.

So if someone uses AI to refactor some code, that refactored code isn't considered a derivative work which means that the refactored source is no longer covered by the copyright, or the license that depends on that.

Even if we assume LLMs would consistently generate good enough quality code, code submitted by someone untrusted would still need detailed review for many reasons - so even in that case it would like be faster for the maintainers to just use the tools themselves, rather than reviewing someone else's use of the same tools.

Wouldn't an agent run by a maintainer require the same scrutiny? An agent is imo "someone else" and not a trusted maintainer.

For well-intended open source contributions using GenAI, my current rules of thumb are:

* Prefer an issue over a PR (after iterating on the issue, either you or the maintainer can use it as a prompt)

* Only open a PR if the review effort is less than the implementation effort.

Whether the latter is feasible depends on the project, but in one of the projects I'm involved in it's fairly obvious: it's a package manager where the work is typically verifying dependencies and constraints; links to upstream commits etc are a great shortcut for reviewers.

Unfortunately, LLMs generate useless word salad and nonsense even when working on issues text, you absolutely have to reword the writing from scratch otherwise it's just an annoyance and a complete waste of time. Even a good prompt doesn't help this all that much since it's just how the tool works under the hood: it doesn't have a goal of saying anything specific in the clearest possible way and inwardly rewording it until it does, it just writes stuff out that will hopefully end up seeming at least half-coherent. And their code is orders of magnitude worse than even their terrible English prose.

I feel like every person stating things of this nature are literally not able to communicate effectively (though this is not a barrier anymore, you can get a dog to vibe code games with the right workflow, which to me seems like quite an intellectual thing to be able to do.

Despite that, you will make this argument when trying to use copilot to do something, the worst model in the entire industry.

If an AI can replace you at your job, you are not a very good programmer.

Copilot isn't a model. Currently it's giving me a choice of 15 different models. By all evidence, AI is nowhere close to replacing me, but to hear other people tell it, it is weeks or maybe months away.

I'll just wait and see.

Remember when copilot released? It was running some openai thing at the time, now you can choose from many models sure, but if you want a BMW, buy a BMW, don't buy a Nissan with badly strapped on BMW decals.

If an AI can replace you at your job, you are not a very good programmer.

Me and millions of other local yokel programmers who work in regional cities at small shops, in house at businesses, etc are absolutely COOKED. No I cant leet code, no I didnt go to MIT, no I dont know how O(n) is calculated when reading a function. I can scrap together a lot of useful business stuff but no I am not a very good programmer.

no I dont know how O(n) is calculated when reading a function

   1. Confidently state "O(n)"
   2. If they give you a look, say "O(1) with some tricks"
   3. If they still give you a look, say "Just joking! O(nlogn)"

no I dont know how O(n) is calculated when reading a function

This is really, honestly not hard. Spend a few minutes reading about this, or even better, ask a LLM to explain it to you and clear your misconceptions if regular blog posts don't do it for you. This is one of the concepts that sounds scarier than it is.

edit: To be clear there are tough academic cases where complexity is harder to compute, with weird functions in O(sqrt(n)) or O(log(log(n)) or worse, but most real world code complexity is really easy to tell at glance.

I don’t think you’re being serious. Claude and GPT regularly write programs that are way better than what I would’ve written. Maybe you haven’t used a decent harness or a model released in the last year? It’s usually verbose, whereas I would try the simplest thing that could possibly work. However, it can knock out but would have taken me multiple weekends in a few minutes. The value proposition isn’t even close.

It’s fine to write things by hand, in the same way that there’s nothing wrong with making your own clothing with a sewing machine when you could have bought the same thing for a small fraction of the value of your time. Or in the same fashion, spending a whole weekend, modeling and printing apart, you could’ve bought for a few dollars. I think we need to be honest about differentiating between the hobby value of writing programs versus the utility value of programs. Redox is a hobby project, and, while it’s very cool, I’m not sure it has a strong utility proposition. Demanding that code be handwritten makes sense to me for the maintainer because the whole thing is just for fun anyway. There isn’t an urgent need to RIIR Linux. I would not apply this approach to projects where solving the problem is more important than the joy of writing the solution.

Claude and GPT regularly write programs that are way better than what I would’ve written

Is that really true? Like, if you took the time to plan it carefully, dot every i, cross every t?

The way I think of LLM's is as "median targeters" -- they reliably produce output at the centre of the bell curve from their training set. So if you're working in a language that you're unfamiliar with -- let's say I wanted to make a todo list in COBOL -- then LLM's can be a great help, because the median COBOL developer is better than I am. But for languages I'm actually versed in, the median is significantly worse than what I could produce.

So when I hear people say things like "the clanker produces better programs than me", what I hear is that you're worse than the median developer at producing programs by hand.

It can certainly be true for several reasons. Even in domains I'm familiar with, often making a change is costly in terms of coding effort.

For example just recently I updated a component in one of our modules. The work was fairly rote (in this project we are not allowed to use LLMs). While it was absolutely necessary to do the update here, it was beneficial to do it everywhere else. I didn't do it in other places because I couldn't justify spending the effort.

There are two sides to this - with LLMs, housekeeping becomes easy and effortless, but you often err on the side of verbosity because it costs nothing to write.

But much less thought goes into every line of code, and I often am kinda amazed that how compact and rudimentary the (hand-written) logic is behind some of our stuff that I thought would be some sort of magnum opus.

When in fact the opposite should be the case - every piece of functionality you don't need right now, will be trivial to generate in the future, so the principle of YAGNI applies even more.

I can agree with that. So essentially: "Claude and GPT regularly write programs that are way better than what I would’ve written given the amount of time I was willing to spend."

A lot of computer users are domain experts in something like chemistry or physics or material science. Computing to them is just a tool in their field, e.g. simulating molecular dynamics, or radiation transfer. They dot every i and cross every t _in_their_competency_domain_, but the underlying code may be a horrible FORTRAN mess. LLMs potentially can help them write modern code using modern libraries and tooling.

My go-to analogy is assembly language programming: it used to be an essential skill, but now is essentially delegated to compilers outside of some limited specialized cases. I think LLMs will be seen as the compiler technology of the next wave of computing.

The difference is that compilers involve rules we can enumerate, adjust, etc.

Consider calculators: Their consistency and adherence to requirements was necessary for adoption. Nobody would be using them if they gave unpredictable wrong answers, or where calculations involving 420 and 69 somehow keep yielding 5318008. (To be read upside-down, of course.)

Have you tried the latest models at best settings?

I've been writing software for 20 years. Rust since 10 years. I don't consider myself to be a median coder, but quite above average.

Since the last 2 years or so, I've been trying out changes with AI models every couple months or so, and they have been consistently disappointing. Sure, upon edits and many prompts I could get something useful out of it but often I would have spent the same amount of time or more than I would have spent manually coding.

So yes, while I love technology, I'd been an LLM skeptic for a long time, and for good reason, the models just hadn't been good. While many of my colleagues used AI, I didn't see the appeal of it. It would take more time and I would still have to think just as much, while it be making so many mistakes everywhere and I would have to constantly ask it to correct things.

Now 5 months or so ago, this changed as the models actually figured it out. The February releases of the models sealed things for me.

The models are still making mistakes, but their number and severity is lower, and the output would fit the specific coding patterns in that file or area. It wouldn't import a random library but use the one that was already imported. If I asked it to not do something, it would follow (earlier iterations just ignored me, it was frustrating).

At least for the software development areas I'm touching (writing databases in Rust), LLMs turned into a genuinely useful tool where I now am able to use the fundamental advantages that the technology offers, i.e. write 500 lines of code in 10 minutes, reducing something that would have taken me two to three days before to half a day (as of course I still need to review it and fix mistakes/wrong choices the tool made).

Of course this doesn't mean that I am now 6x faster at all coding tasks, because sometimes I need to figure out the best design or such, but

I am talking about Opus 4.6 and Codex 5.3 here, at high+ effort settings, and not about the tab auto completion or the quick edit features of the IDEs, but the agentic feature where the IDE can actually spend some effort into thinking what I, the user, meant with my less specific prompt.

I am talking about Opus 4.6 and Codex 5.3 here, at high+ effort settings

So you have to burn tokens at the highest available settings to even have a chance of ending up with code that's not completely terrible (and then only in very specific domains), but of course you then have to review it all and fix all the mistakes it made. So where's the gain exactly? The proper goal is for those 500 lines to be almost always truly comparable to what a human would've written, and not turn into an unmaintainable mess. And AI's aren't there yet.

You really do need to try the latest ones. You can’t extrapolate from your previous experiences.

I feel like we're talking about different things. You seem to be describing a mode of working that produces output that's good enough to warrant the token cost. That's fine, and I have use cases where I do the same. My gripe was with the parent poster's quote:

Claude and GPT regularly write programs that are way better than what I would’ve written

What you're describing doesn't sound "way better" than what you would have written by hand, except possibly in terms of the speed that it was written.

Having reviewed a lot of Ai-written python code, I think it's absolute nonsense.

It never picks a style, it'll alternate between exceptions and then return codes.

It'll massively overcomplicate things. It'll reference things that straight up don't exist.

But boy is it brilliant at a fuzzy find and replace.

if it wasn't so maddening it would be funny when you literally have to tell it to slow down, focus and think. My tinfoil hat suggests this is intentional to make me treat it like a real, live junior dev!

"you literally have to tell it to slow down, focus and think" - This soo much! When I get an unexpected result from claude, I ask it why - what caused it to do such-and-such. After one back and forth session like this putting up tons of guardrails on a prompt, claude literally said "you shouldn't have to teach me to think every session" !!

My rules of thumb is much shorter: don't.

The open source world has already been ripped off by AI the last thing they need is for AI to pollute the pedigree of the codebase.

Suppose almost all work in the future is done via LLMs, just like almost all transportation is done today via cars instead of horses.

Do you think your worldview is still a reasonable one under those conditions?

I say let people hold this stance. We, agentic coders, can easily enough fork their project and add whatever the features or refinements we wanted, and use that fork for ourselves, but also make it available for others in case other people want to use it for the extra features and polish as well. With AI, it's very easy to form a good architectural understanding of a large code base and figure out how to modify it in a sane, solid way that matches the existing patterns. And it's also very easy to resolve conflicts when you rebase your changes on top of whatever is new from upstream. So, maintaining a fork is really not that serious of and endeavor anymore. I'm actually maintaining a fork of Zed with several additional features (Claude Code style skills and slash commands, as well as a global agents.md file, instead of the annoying rules library system, which I removed, as well as the ability to choose models for sub-agents instead of always inheriting the model from the parent thread; and yes, master branch Zed has subagents! and another tool, jjdag)

That seems like a win-win in a sense: let the agentic coders do their thing, and the artisanal coders do their thing, and we'll see who wins in the long run.

We, agentic coders, can easily enough fork their project

And this is why eventually you are likely to run the artisanal coders who tend to do most of the true innovation out of the room.

Because by and large, agentic coders don't contribute, they make their own fork which nobody else is interested in because it is personalized to them and the code quality is questionable at best.

Eventually, I'm sure LLM code quality will catch up, but the ease with which an existing codebase can be forked and slightly tuned, instead of contributing to the original, is a double edged sword.

Maybe! Or maybe there is really a competitive advantage to "artisanal" coding.

Personally, I would not currently expect a fork of RedoxOS that is AI-implemented to become more popular than RedoxOS itself.

"make their own fork which nobody else is interested in because it is personalized to them"

Isn't that literally how open-source works, and why there's so many Linux distros?

Code quality is a subjective term as well, I feel like everyone dunking on AI coding is a defensive reaction - over time this will become an entirely acceptable concept.

For a human to be able to do any customization, they have to dive into the code and work with it, understand it, gain intuition for it. Engage with the maintainers and community. In the process, there's a good chance that they'll be encouraged to contribute improvements upstream even if they have their own fork.

Vibe coders don't have to do any of this. They don't have to understand anything, they can just have their LLMs do some modifications that are completely opaque to the vibe coder.

Perhaps the long term steady state will be a goldilocks renaissance of open source where lots of new ideas and contributors spring up, made capable with AI assistance. But so far what I've seen is the opposite. These people just feed existing work into their LLMs, produce derivative works and never bother to engage with the original authors or community.

> but also make it available for others in case other people want to use it for the extra features and polish as well.

this feels like the place where your approach breaks down. I have had very poor results trying to build a foundation that CAN be polished, or where features don't quickly feel like a jenga tower. I'm wondering if the success we've seen is because AI is building on top of, or we're early days in "foundational" work? Is anyone aware of studies comparing longer term structural aspects? is it too early?

We, agentic coders, can easily enough fork their project and add whatever the features

Bold of you to assume that people won’t move (and their code along with it) to spaces where parasitic behaviour like this doesn’t occur, locking you out.

In addition to just being a straight-up rude, disrespectful and parasite position to take, you’re effectively poisoning your own well.

Since when is maintaining a personal patch set / fork parasitic? And in what way does it harm them, such that they should move to spaces where it doesn't happen, as a result? Also, isn't the entire point of open source precisely to enable people to make and use modifications of code if they want even if they don't want to hand code over? Also, that would be essentially making code closed source — do you think OSS is just going to die completely? Or would people make alternative projects? Additionally, this assumes coders who are fine with AI can't make anything new themselves, when if anything we've seen the opposite (see the phenomenon of reimplementing other projects that's been going around).

Additionally, if they accept AI contributions, I try, when I have the time and energy, make sure my PRs are high quality, and provide them. If they don't, then I'll go off and do my own thing, because that's literally what they asked me to do, and I wasn't going to contribute otherwise. I fail to see how that's rude or parasitic or disrespectful in any way except my assumption that the more featureful and polished forks might eventually win out.

Its only parasitic if you are tricking users into thinking you are the original or providing something better. You could be providing something different (which would be valuable) but if you are not, you are just scamming users for your own benefit.

But all work isn't done by LLMs at the moment and we can't be sure that it will be so the question is ridiculous.

Maybe one day it will be.. And then people can reevaluate their stance then. Until that time, it's entirely reasonable to hold the position that you just don't

This is especially true with how LLM generated code may affect licensing and other things. There's a lot of unknowns there and it's entirely reasonable to not want to risk your projects license over some contributions.

I use them all the time at work because, rightly or wrongly, my company has decided that's the direction they want to go.

For open source, I'm not going to make that choice for them. If they explicitly allow for LLM generated code, then I'll use it, but if not I'm not going to assume that the project maintainers are willing to deal with the potential issues it creates.

For my own open source projects, I'm not interested in using LLM generated code. I mostly work on open source projects that I enjoy or in a specific area that I want to learn more about. The fact that it's functional software is great, but is only one of many goals of the project. AI generated code runs counter to all the other goals I have.

Basically all of my actual programming work has been done by LLMs since January. My team actually demoed a PoC last week to hook up Codex to our Slack channel to become our first level on-call, and in the case of a defect (e.g. a pagerduty alert, or a question that suggests something is broken), go debug, push a fix for review, and suggest any mitigations. Prior to that, I basically pushed for my team to do the same with copy/paste to a prompt so we could iterate on building its debugging skills.

People might still code by hand as a hobby, but I'd be surprised if nearly all professional coding isn't being done by LLMs within the next year or two. It's clear that doing it by hand would mostly be because you enjoy the process. I expect people that are more focused on the output will adopt LLMs for hobby work as well.

Sounds like a company on the verge of creating a mess that will require a rewrite in a year or so. Maybe an llm can do it.

I suspect this is more true than most people think. Today's bad code will be cleaned up by tomorrow's agents.

The other factor that gets glossed over is that llms create a financial incentive to create cleaner code, with tests, because the agent that you pay for will be more efficient when the code is easier to understand, and has clear patterns for extensibility. When I do code with llms, a big part of it is demonstration, i.e. pseudocoding a pattern/structure, asking the model if it understands, and then having it complete the pattern. I've had a lot of success with this approach.

That would only be a world where the copyright and other IP uncertainties around the output (and training!) of LLMs were a solved and known question. So that's not the world we currently live in.

even if this was true or someday will be (big IF), is it worth looking for valid counter workflows? example: in many parts of the US and Canada the Mennonites are incredibly productive farmers and massive adopters of technology while also keeping very strict limits on where/how and when it is used. If we had the same motivations and discipline in software could we walk a line that both benefited from and controlled AI? I don't know the answer.

Another great take I found online: "Don't send us a PR, send us the prompt you used to generate the PR."

It doesn't really matter what your stance on AI is, the problem is the increased review burden on OSS maintainers.

But the maintainers can use AI too, for their reviewing.

Even if we assume LLMs would consistently generate good enough quality code, code submitted by someone untrusted would still need detailed review for many reasons

Wait but under that assumption - LLMs being good enough - wouldn't the maintainer also be able to leverage LLMs to speed up the review?

Often feels to me like the current stance of arguments is missing something.

Wait but under that assumption - LLMs being good enough - wouldn't the maintainer also be able to leverage LLMs to speed up the review?

This assumes that AI capable of writing passable code is also capable of a passable review. It also assumes that you save any time by trusting that review, if it missed something wrong then it's often actually more effort to go back and fix than it would've been to just read it yourself the first time.

We need LLMs that have a certificate of origin.

For instance a GPL LLM trained only on GPL code where the source data is all known, and the output is all GPL.

It could be done with a distributed effort.

Honestly, given that that GPL model would be far below SOTA in capabilities, what exactly would be its use-case? Why would anyone try to use an inferior LLM if they can get away with using a superior one?

    > any content submitted that is clearly labelled as LLM-generated (including issues, merge requests, and merge request descriptions) will be immediately closed

Note the word "clearly". Weirdly, as a native English speaker this term makes the policy less strict. What about submarine LLM submissions?

I have no beef with Redox OS. I wish them well. This feels like the newest form of OSS virtue signaling.

As a native English speaker I read this as two parts. If it's obvious, the response is immediate and not up for debate. If it's not obvious then it falls in the second part - "any attempt to bypass this policy will result in a ban from the project".

A submarine submission, if discovered, will result in a ban.

Using the phrase "virtual signaling" long ago became a meaningless term other than to indicate one's views in a culture war. 10 years ago David Shariatmadari wrote "The very act of accusing someone of virtue signalling is an act of virtue signalling in itself", https://www.theguardian.com/commentisfree/2016/jan/20/virtue... .

Somewhat off topic, but I can’t believe someone got paid to write that article, what a load of crap. It’s like saying that fallacies don’t exist because sometimes people incorrectly claim the other side is arguing fallaciously.

If you go by the literal definition in the article, it’s very clear what OP meant when he said the AI policy is virtue-signaling, and it has absolutely nothing to do with the culture war.

It's not a useful phrase because a "we accept AI-generated contributions" is also virtue signalling.

You have no doubt heard claims that AI "democratizes" software development. This is an argument that AI use for that case is virtuous.

You have no doubt heard claims that AI "decreases cognition ability." This is an argument that not using AI for software development is virtuous.

Which is correct depends strongly on your cultural views. If both are correct then the term has little or no weight.

From what I've seen, the term "virtue signalling" is almost always used by someone in camp A to disparage the public views of someone in camp B as being dishonest and ulterior to the actual hidden reason, which is to improve in-group social standing.

I therefore regard it as conspiracy theory couched as a sociological observation, unless strong evidence is given to the contrary. As a strawman exaggeration meant only to clarify my point, "all right-thinking people use AI to write code, so these are really just gatekeepers fighting to see who has the longest neckbeard."

Further, I agree with the observation at https://en.wikipedia.org/wiki/Virtue_signalling that "The concept of virtue signalling is most often used by those on the political right to denigrate the behaviour of those on the political left". I see that term as part of "culture war" framing, which makes it hard to use that term in other frames without careful clarification.

Ok, the replace virtue signaling with: This is the latest popular action from performative OSS projects.

What about submarine LLM submissions?

That would constitute an attempt to circumvent their policy, with the consequence of being banned from the project. In other words, it makes not clearly labeling any LLM use a bannable offense.

Not sure how they can expect to make a viable full OS without massive use of LLMs, so this makes no sense.

What makes sense if that of course any LLM-generated code must be reviewed by a good programmer and must be correct and well written, and the AI usage must be precisely disclosed.

What they should ban is people posting AI-generated code without mentioning it or replying "I don't know, the AI did it like that" to questions.

Not sure how they can expect to make a viable full OS without massive use of LLMs, so this makes no sense.

Why not?

Because it takes a massive amount of developer work (perhaps more than anything else), and it's very unlikely they either have the ability to attract enough human developers to be able to do it without LLM assistance.

Not to mention that even finding good developers willing to develop without AI (a significant handicap, even more so for coding things like an OS that are well represented in LLM training) seems difficult nowadays, especially if they aren't paying them.

Because it takes a massive amount of developer work

You know what else takes "a massive amount of developer work"?

"any LLM-generated code must be reviewed by a good programmer"

And this is the crux of the matter with using LLMs to generate code for everything but really simple greenfield projects: They don't really speed things up, because everything they produce HAS TO be verified by someone, and that someone HAS TO have the necessary skill to write such code themselves.

LLMs save time on the typing part of programming. Incidentially that part is the least time consuming.

The submitter is supposed to be the good programmer; if not, then maintainers may or may not review it themselves depending on the importance of the feature.

And yes of course they need to be able to write the code themselves, but that's the easy part: any good developer could write a full production OS by themselves given access to documentation and literature and an enormous amount of time. The problem is the time.

The LLM has brainwashed so many devs that they now think they are nothing without it.

Not sure how they can expect to make a viable full OS without massive use of LLMs, so this makes no sense.

Every single production OS, including the one you use right now, was made before LLMs even existed.

What makes sense if that of course any LLM-generated code must be reviewed by a good programmer

The time of good programmers, especially ones working for free in their spare time on OSS projects, is a limited resource.

The ability to generate slop using LLMs, is effectively unlimited.

This discrepancy can only be resolved in one way: https://itsfoss.com/news/curl-ai-slop/

There are only 4 successful general purpose production OSes (GNU/Linux, Android/Linux, Windows, OS X/iOS) and only one of those made by the open source community (GNU/Linux).

And a new OS needs to be significantly better than those to overcome the switching costs.

None of this counters the argument I made above :-)

Just because they have been made before LLMs doesn't mean it can be done again, since there was just one success (GNU/Linux) and that success makes it much harder for new OSes since they need to better then it

There are only 4 successful general purpose production OSes

Feel like you are using a very narrow definition of "success" here. Is BSD not successful? It is deployed on 10s of millions of routers/firewalls/etc in addition to being the ancestor of both modern MacOS and PlaystationOS...

While I appreciate the morality and ethics of this choice, the current trend means projects going in this direction are making themselves irrelevant (don't bother quipping at how relevant redox is today, thanks). E.g. top security researches are now using LLMs to find new RCEs and local privilege escalations; no reason why the models couldn't fix these, too - and it's only the security surface.

IOW I think this stance is ethically good, but technically irresponsible.

I think we will be getting into an interesting situation soon, where project maintainers use LLMs because they truly are useful in many cases, but will ban contributors for doing so, because they can't review how well did the user guide the LLM.

Maybe a future direction will be the submission of detailed research, specifications and change plans for feature requests. Something that can be assessed by a human and turned into working code by both slides.

The bottlenecks today are:

* understanding the problem

* modelling a solution that is consistent with the existing modelling/architecture of the software and moves modelling and architecture in the right direction

* verifying that the the implementation of the solution is not introducing accidental complexity

These are the things LLMs can't do well yet. That's where contributions will be most appreciated. Producing code won't be it, maintainers have their own LLM subscriptions.

I still think there is value in external contributors solving problems using LLMs, assuming they do the research and know what they are doing. Getting a well written and tested solution from LLM is not as easy as writing a good prompt, it's a much longer/iterative process.

If an author of a PR just generated code with an LLM, the GitHub PR becomes an incredibly inefficient interface between a repository owner and the LLM. A much better use of the owner time would be to interact with LLM directly instead of responding to LLM generated PR, waiting for updates, responding again, etc.

The GPL talks about "the preferred form for modification of the software", and I'm starting to think that anything which involves any kind of LLM agent should be including all the text that the user gave to it as well. Prompts, etc.

Of course, even then it's not reproducible and requires proprietary software!

Some sort of LLM audit trail is needed (containing prompts used, model identifier and marking all code written by LLM). It could be even signed by LLM providers (but that wouldn't work with local models). Append only standard format that is required to be included in PR. It wouldn't be perfect (e.g. deleting the log completely), but it might help with code reviews.

This would probably be more useful to help you see what (and how) was written by LLMs. Not really to catch bad actors trying to hide LLM use.

I am 100% certain that code that Redox OS relies on in upstream already has LLM code in it.

While I am more on the AI-hater side, I don't consider this to be a good idea:

"any content submitted that is clearly labelled as LLM-generated (including issues, merge requests, and merge request descriptions) will be immediately closed"

For example:

- What if a non-native English speaker uses the help of an AI model in the formulation of some issue/task?

- What about having a plugin in your IDE that rather gives syntax and small code fragment suggestions ("autocomplete on steroids")? Does this policy mean that the programmers are also restricted on the IDE and plugins that they are allowed to have installed if they want to contribute?

What if a non-native English speaker uses the help of an AI model in the formulation of some issue/task?

Unfortunately, when I have seen this in the context of the Rust project, the result has still been the typical verbose word salad that is typical of chat style LLMs. It is better to use a dedicated translation tool, and post the original along with the translation.

What about having a plugin in your IDE that rather gives syntax and small code fragment suggestions ("autocomplete on steroids")?

Very good question, I myself consider this sort of AI usage benign (unlike agent style usage), and is the only style of AI I use myself (since I have RSI it helps having to type less). You could turn the feature off for just this project though.

Does this policy mean that the programmers are also restricted on the IDE and plugins that they are allowed to have installed if they want to contribute?

I don't think that follows, but what features you have active in the current project would definitely be affected. From what I have seen all IDEs allow turning AI features on and off as needed.

What if a non-native English speaker uses the help of an AI model in the formulation of some issue/task?

Firefox has direct translation built in. One can self-host libretranslate. There are many free sites to paste in language input and get a direct translation sans filler and AI "interpretation". Just write in your native language or your imperfect English.

Translation software does not solve the problem that the tone that you have to use in English is often very different from the tone in your native language. What I would write in German would sometimes not be socially acceptable for English speakers.

If the native language is very different from English, this problem gets much worse.

This is a problem that LLM claim to partially mitigate (and is one reason why non-native speakers could be tempted to use them), but hardly any classical translation tool can.

What would constitute "clearly llm generated" though

  if (foo == true) { // checking foo is true (rocketship emoji)
    20 lines of code;
  } else {
    the same 20 lines of code with one boolean changed in the middle;
  }

Description:

(markdown header) Summary (nerd emoji):

This PR fixes a non-existent issue by adding an *if statement** that checks if a variable is true. This has the following benefits:

  - Improves performance (rocketship emoji)
  - Increases code maintainability (rising bar chart emoji)
  - Helps prevent future bugs (detective emoji)

(markdown header) Conclusion:

This PR does not just improve performance, it fundamentally reshapes how we approach performance considerations. This is not just design --- it's architecture. Simple, succinct, yet powerful.

The clearly LLM PRs I receive are formatted similarly to:

    ## Summary
    ...

    ## Problem
    ...

    ## Solution
    ...

    ## Verification
    ...

They're too methodical, and duplicate code when they're longer than a single line fix. I've never received a pull request formatted like that from a human.

I see a lot of oss forks in the future where people just fork to fix their issues with LLMs without going through maintainers. Or even doing full LLM rewrites of smaller stuff.

Probably, but on the other hand, this is almost literally the definition of technical debt -- it's great to get fixes uptreamed precisely so that you don't have to maintain your own fork, keep it in sync, etc. an LLM can likely lower the burden of that but the burden still exists.

Yeah, but what can you do if you need a thing done and now there's an option to have it done.

Let someone from the Redox team go read [1], [2], and [3]. If they still insist on keeping their position then ... well. The industry is being redefined as we speak and everyone doing the push-back are pushing against themselves really.

[1] https://www.datadoghq.com/blog/ai/harness-first-agents/

[2] https://www.datadoghq.com/blog/ai/fully-autonomous-optimizat...

[3] https://www.datadoghq.com/blog/engineering/self-optimizing-s...

P.S. I know this will be downvoted to death but I'll leave it here anyway for folks who want to keep their eyes wide open.

That’s such a silly take.

“Our approach is harness-first engineering: instead of reading every line of agent-generated code, invest in automated checks that can tell us with high confidence, in seconds, whether the code is correct. “

that’s literally what The whole industry has been doing for decades, and spoiler: you still need to review code! it just gives you confidence that you didn’t miss anything.

Also, without understanding the code, it’s difficult to see its failure modes, and how it should be tested accordingly.

So you read the three-part series of blogs that are packed in details in 3 minutes after I shared the link and put yourself into a position of entitled opinion and calling my position a silly take? Sure thing.

They probably used an AI to summarise those blog posts for them and it told them with high confidence, in seconds, whether they were correct.

Obviously not, I skimmed through the first two, and it’s not difficult to assess that it’s just fluff that sounds interesting but is actually not.

Zig has a similar stance on no-LLM policy

https://codeberg.org/ziglang/zig#strict-no-llm-no-ai-policy

Yep, that’s why my forks of all their libraries with bugs fixed such as https://github.com/pmarreck/zigimg/commit/52c4b9a557d38fe1e1... will never ever go back to upstream, just because an LLM did it. Lame, but oh well- their loss. Also, this is dumb because anyone who wants fixes like this will have to find a fork like mine with them, which is an increased maintenance burden.

Hugely unpopular opinion on HN, but I'd rather use code that is flawed while written by a human, versus code that has been generated by a LLM, even if it fixes bugs.

I'd gladly take a bug report, sure, but then I'd fix the issues myself. I'd never allow LLM code to be merged.

Any thoughts on why you have that preference?

Because human errors are, well, human. And producing code that contains those errors is a human endeavor. It bases on years, decades of learning. Mistakes were made, experience was gained, skills were improved. Reasoning by humans is relatable.

Generating slop using LLMs takes seconds, has no human element, no work goes into it. Mistakes made by an LLM are excused without sincerity, without real learning, without consequence. I hate everything about that.

just like... don't tell them a LLM did it?

That's a dick move because you are opening up an open source project to claims of infringement without recourse.

Why on earth would you force stuff on a party that has said they don't want that?

Sure, but back in reality no you’re not? No more than any other contributor?

If I want to use an auto-complete then I can, and I will? Restricting that is as regressive as a project trying to specify that I write code from a specific country or… standing on my head.

Sure, if they want me to add a “I’m writing this standing on my head” message in the PR then I will… but I’m not.

No, you can't. See, that's where you are just wrong: when you don't respect the boundaries an open source project sets that you want to contribute to then you are a net negative.

Restricting this is their right, and it is not for you to attempt to overrule that right. Besides the fact that you do not oversee the consequences it also makes you an asshole.

They're not asking for you to write standing on your head, they are asking for you to author your contributions yourself.

They are asking me to author my contributions in a way that they approve of. The essence of the request is the same as asking someone to author them whilst standing on their head.

Except they don’t, won’t and can’t control that: the very request is insulting.

I’ll make a change any way I choose, upright, sideways, using AI. My choice. Not theirs.

Their choice is to accept it or reject it based purely on the change itself, because that’s all there is.

So, "might makes right", essentially?

If you’re going to lie and say there was no LLM involved, what else are you going to lie about? Copying code from another codebase with incompatible license terms, perhaps?

I would say people should be wary of any contributions whatsoever from a filthy fucking liar.

I am authoring my contributions, using Clause Code as a tool. It doesn't make me an asshole.

If the maintainers don't want to accept it, fine. Someone will eventually fork and advance and we move on. The Uncles can continue to play in their no AI playground, and show each other how nice their code is.

The world is moving on from the "AI is bad" crowd.

[flagged]

Never? That would be tax avoidance and theft, both crimes.

The commit you listed was merged upstream.

https://github.com/zigimg/zigimg/pull/313

So does that mean they contradicted their own no LLM policy?

Dunno but a commenter already noted that some begins to say: "No LLM generated PR, but we'll accept your prompt" and another person answered he saw that too.

It makes lots of sense to me.

If you know there's a bug, why not just properly fix it and get it merged, instead of outsourcing that fix?

Also, this is dumb because anyone who wants fixes like this will have to find a fork like mine with them

Or a human will provide the fix?

a human who looks at the AI generated fix but ‘types it out, the old fashioned way’?

If you rely on llms, you're simply not going to make it. The person who showed their work on the math test is 9/10 times is doing better in life than the person that only knew how to use a calculator. Now how do we think things are going to turn out for the person that doesn't even think they need to learn how to use a calculator.

Just like when people started losing their ability to navigate without a GPS/Maps app, you will lose your ability to write solid code, solve problems, hell maybe even read well.

I want my brain to be strong in old age, and I actually love to write code unlike 99% in software apparently (like why did you people even start doing this career.. makes no sense to me).

I'm going to keep writing the code myself! Stop paying Billionaires for their thinking machines, its not going to work out well for you.

I went into software because I like building things and coming up with solid solutions to business problems that are of use to society. I would not describe myself with "love to code". It's a means to an end to pay bills and have a meaningful career. I think of myself more like a carpenter or craftsman.

I used a coding agent for the majority of my current project and I still got the "build stuff" itch scratched because Engineers are still responsible for the output and they are needed to interface between technical teams, UX, business people etc

I think of myself more like a carpenter or craftsman.

I used a coding agent for the majority of my current project and I still got the "build stuff" itch scratched because Engineers are still responsible for the output and they are needed to interface between technical teams, UX, business people etc

Then you are the opposite of a carpenter or a craftsman, no matter what you think about it yourself.

What term would you use for that "opposite"?

Yeah could you imagine a project manager saying they are like a carpenter or a craftsman lmfao

I went into software because I love to code.

And yet, I find a coding agent makes it even more fun. I spend less time working on the boilerplate crap that I hate, and a lot less time searching Google and trying to make sense of a dozen half-arsed StackOverflow posts that don't quite answer my question.

I just went through that yesterday with Unity. I did all the leg work to figure out why something didn't work like I expected. Even Google's search engine agent wasn't answering the question. It was a terrible, energy-draining experience that I don't miss at all. I did figure it out in the end, though.

Prior to yesterday, I was thinking that using AIs to do that was making it harder for me to learn things because it was so easy. But comparing what I remember from yesterday to other things I did with the AI, I don't really think that. The AI lets me do it repeatedly, quickly, and I learn by the repetition, and a lot of it. The slow method has just 1 instance, and it takes forever.

This is certainly an exciting time for coders, no matter why they're in the game.

The person who showed their work on the math test is 9/10 times is doing better in life than the person that only knew how to use a calculator

Sure but once you learn long multiplication/division algorithms by hand there's not much point in using them. By high school everyone is using a calculator.

Just like when people started losing their ability to navigate without a GPS/Maps app

Are you suggesting people shouldn't use Google Maps? Seems kind of nuts. Similar to calculators, the lesson here is that progress works by obviating the need to think about some thing. Paper maps and compasses work the same way, they render some older skill obsolete. The written word made memorization infinitely less valuable (and writing had its critics).

I don't think "LLMs making us dumber" is a real concern. Yes, people will lose some skills. Before calculators, adults were probably way better at doing arithmetic. But this isn't something worth prioritizing.

However, it is worth teaching people to code by hand, just like we still teach arithmetic and times tables. But ultimately, once we've learned these things, we're going to use tools that supercede them. There's nothig new or scary about this, and it will be a significant net win.

I don't think "LLMs making us dumber" is a real concern. Yes, people will lose some skills. Before calculators, adults were probably way better at doing arithmetic.

But it's a problem of scale.

Calculators are very specific tools. If you are trying to run a computation of some arithmetic/algebraic expression, then they are a great tool. But they're not going to get you far if you need help understanding how to file your taxes.

LLMs are multi-faceted tools. They can help with math, doing taxes, coding, doing research, writing essays, summarizing text, etc. Basically anything that can be condensed into an embedding that the LLM can work with is fair game.

If you're willing to accept that using a tool slowly erodes the skill that tool was made for, then you should also accept that you will see an erosion of MANY skill you currently have.

So the question is whether this is all worth it? Is an increase in productivity worth eroding a strong foundation of general purpose knowledge? Perhaps even the ability to learn in the first place?

I would argue no a million times over, but I'm starting to think that I'm an outlier.

Yeah, I agree. However, people use llms for the same reason people drive 3 blocks to a store rather than walk. Laziness and convenience. They simply don't care if their leg muscles atrophy. However, I think people aren't taking into account how much more important your thinking "muscles" are and its way more consequential to let those atrophy.

Everyone is vulnerable to the allure of taking shortcuts in life, but I've learned over the years that there is no free lunch. This is going too be quite an expensive trade off for many.

People will have to be more intentional about using their increased leisure time in a healthy way. There was no point in exercising if you were a peasant who worked the field all day. Today, if you sit down in an office all day, you need to exercise intentionally. People have figured this out!

Along the same lines, AI will necessitate a shift where people intentionally use their extra intellectual leisure time. Reading, writing, chess, learning a new language, etc.

Not everyone will do this. Some people will be the intellectual equivalent of obese. But people will figure it out eventually.

But people will figure it out eventually.

Will they? >50% of US adults are overweight or obese. Is this the example you want to hang your hat on?

People are figuring it out in real time. The next generation is going to be way less fat than the current one, because everyone exercises. It took time for people to adjust to a world where physical exertion is optional and delicious food is cheap, but we are getting there. I see no reason to assume the same thing won't happen with AI.

The written word isn't a very specific tool. Before writing, people had to memorize things. In some sense, writing has made us dumber as memorization has been deemphasized. But was it worth the trade? Yes.

If you want a more recent example, google search is an extremely broad tool that has operated similarly.

I think AI will be another rung in the ladder of abstraction. Something will be lost, but it's worth the trade.

I don't agree that writing, or Google search are on the same level here. A problem about having this argument on HN is that I think most people are already firmly entrenched in the pro-AI position, and will not consider any possible downsides.

There are lots of anti-AI commenters on HN. Also, I didn't say there are no downsides. There are downsides to writing! And some people were against writing, like Socrates.

You should ask yourself why you're okay with innovations that happened in the past but not okay with innovations happening now. It could just be reflexive conservativism.

Of course there's no guarantee that AI will be more positive than negative, but I see no compelling reason to believe that. Most of the anti-AI sentiment is just people not liking new things.

You should ask yourself why you're okay with innovations that happened in the past but not okay with innovations happening now.

Because these innovations are not congruent with our most important biological advantage! We are here precisely because we developed the capacity to think critically about hard problems. To relegate our critical faculties to an activity you engage with during a small window of time each day similar to a muscle you exercise at the gym is asinine in my opinion. I firmly believe in the future, people like you will become a new underclass as they have willingly given up their ability to think.

when i was in school we were graded (yes, actually given a letter grade) on our handwriting. mine was pretty terrible. i think i’m doing alright now.