"Unfortunately the reality of LLM-based contributions has been mostly negative for us, from an increase in background noise due to worthless drive-by PRs full of hallucinations (that wouldn’t even compile, let alone pass CI), to insane 10 thousand line long first time PRs. In-between we also received plenty of PRs that looked fine on the surface, some of which explicitly claimed to not have made use of LLMs, but where follow-up discussions immediately made it clear that the author was sneakily consulting an LLM and regurgitating its mistake-filled replies to us."
I don't think it's the complete fanbase. However, there are lots of people in the world who live their whole life by vibing. It's a viable way to live and sometimes it's the only way to live. But they have a very loose relationship with truth and reason. Programming was a domain that filtered out those people because they found it hard to succeed at it. LLM's have changed that and it's a huge problem. It's hard to know if LLMs will end up being a net win for the industry. They may speed up the good programmers a little, but those people were able to program anyway without LLMs. They will speed up the bad programmers a lot and that's where the balance sheet goes into the red.
"They may speed up the good programmers a little, but those people were able to program anyway without LLMs."
I don't think this is realistic. I'm a good programmer, and it speeds up my work a lot, from "make sense of this 10 repo project I haven't worked on recently" to "for this next step I need a vpn multiplexer written in a language I don't use" to, yeah, "this 10k line patch lets me see parts of design space we never could have explored before." I think it's all about understanding the blast radius. Sonetimes a lot of code is helpful, sometimes more like a lot of help proving a fact about one line of code.
Like Simon says, if I'm driving by someone else's project, I don't send the generated pull request, I just file the bug report / repro that would generate it.
Can't we reach a compromise where proven track record of good use of LLM by a contributor or a company (eg. Bun) be pre-approved or entertained? Blanket ban on a new technology shouldn't be the default option.
Certainly not in the case of asking it to do something you'd be slow at because you are unfamiliar. If you are not familiar enough with the system, how are you confident that what the LLM has produced is valid and complete? IMO the people saying LLMs make then 10x faster were either very bad to start with (like me!) or are not properly looking at the results before throwing them over the wall.
And how do you know if that is the case or the person/team using the LLMs is one of the good ones?
This is the crux of the problem. LLMs make me significantly faster at writing code I was mediocre or bad at. But when I use it to write code in domains I have more knowledge in I see design and correctness problems all over the place and actively fix them and it slows down my output.
Speed is seductive.
The bar isn't "this is a known good contributor". Its "this is a known good contributor working in a space they have knowledge in and has a track record of actually checking and thinking about LLM output before submitting it." It's much higher and I don't see how you can approve people on an organization-wide basis.
> LLMs make me significantly faster at writing code I was mediocre or bad at. But when I use it to write code in domains I have more knowledge in I see design and correctness problems all over the place and actively fix them and it slows down my output.
if they had a good track record, the current submission that led to this article damaged it.
i am reminded of this quote: it takes more cleverness to debug code than it takes to write it. if you write code as clever as you can, by definition you are not clever enough to debug it. using LLM makes your code many times more clever than what you could write yourself. which means by the same definition the code is to clever for you to understand or debug it.
I like the new corollary to that rule, which is that if the AI is the best coder in the room and writes code too clever for itself, then no one including the AI can debug the code. Then where does that leave you?
i love it. just a moment of thought makes clear that LLMs are not capable to debug their own code because if they were they would be able to write better code. the LLM code doesn't even need to be clever.
Why would it be pre-approved ? Code is code, whether it's bad quality LLM code or meatbag code it shouldn't matter.
The entire problem is that before the meatbag code was either not submitted at all (developer knowing they are not competent enough to do the fix) or the volume of it was low.
With LLM people not competent to even review, let alone write are emboldened to just throw shit on the wall at rapid pace. So the wall is entirely covered by the shit
I use LLM as a tutor. It tailor their answers exactly to the situation I am in, even if it hallucinate. I can correct them on the fly and that also serves as training. I try not copy and paste and type every line of code by hand. That doesn't always happen, but I usually understand the code I am writing.
Why are you writing a vpn multiplexer written in a language you don't use?
You can't review it.
Are you relying on your colleagues to do that, or is this riddled with bugs? Or is it code you're producing for personal use only so it's not worth mentioning as it's not sped your work up, it's just let you write a little play program.
yep. as an expert programmer there are things i did not have access to. for example, i have an embedded-lite hardware project that required a one line patch to a linux kernel Module.
i know what a kernel module is and im reasonably certain that the patch is safe, but there is no way in hell i would have found that solution (i would have given up). in a world without llms, the project would have died.
I really hope that you have gone over what the LLM decides to do.
Time and time again I've had a project (such as a DSL to SQL compiler, automatic Rust codegen, CSS development) stall because the LLM took a short sighted decision.
I later found better solutions by querying Reddit and upon consulting the LLM, it basically said "oh shit I'm sorry"
This is commonplace. So commonplace that most have worked “checking the LLM” into their workflow so deeply that essentially all that’s done is prompt followed by a mini code review.
To suggest a senior engineer blindly accepts modifications without code review kinda hints at you not using LLMs to realize how quickly it will make a mess of things if you don’t hold it’s hand.
Lol why is it arrogant? My workplace is evidence that having a senior engineer title or even a computer science degree doesn't mean you are a good engineer. I honestly think some people have fake credentials and got their jobs via nepotism.
Jumping to an assumption like this - that they didn't review their work - that's somewhat of an insult to someone who has done this for a long time.
Now it's totally possible that they're an awful developer (who knows!), but it's arrogant to assume that with no evidence.
And I agree, some of the worst devs I've worked with have been PhD's or had otherwise impressive credentials (ostensibly). And I absolutely think at least 1 of them were just lying about their backgrounds.
> However, there are lots of people in the world who live their whole life by vibing
Why are they often so desperate to lie and non-consensually harass others with their vibing rather than be honest about it? Why do they think they are "helping" with hallucinated rubbish that can't even build?
I use LLMs. It is not difficult to: ethically disclose your use, double check all of your work, ensure things compile without errors, not lie to others, not ask it to generate ten paragraphs of rubbish when the answer is one sentence, and respect the project's guidelines. But for so many people this seems like an impossible task.
> Why do they think they are "helping" with hallucinated rubbish that can't even build?
Because they can't tell the difference between what the machine is outputting, and what people have built. All they see is the superficial resemblance (long lines of incomprehensbile code) and the reward that the people writing the code have got, and want that reward too.
"Main character energy". What they're really doing is protecting their view of themselves as smart, and they're making a contribution for the sake of trying to perform being an OSS dev rather than out of need or altruism.
AI is absolutely terrible for people like that, as it's the perfect enabler.
It's not about helping. It's about the feeling of clout. There are still plenty of people who look at Github profile activity to judge job candiates, etc. What gets measured gets repeated.
I believe that most of the ills of social media would disappear, if we eliminated the "like" and "upvotes" buttons and the view counts. Most open source garbage pull requests may likewise go away if contributions were somehow anonymous.
LLMs are in this case enabling bad behavior, but open source software has always been vulnerable to this. Similarly, people who use LLMs to do this kind of thing are the kind of people who would have done it without LLMs but for the large effort it would have taken. We're just learning now how large that group is.
This is a good thing, it's an opportunity to make open source development processes robust to this kind of sabotage.
Yeah that seems to be their primary use case, if I'm honest. It's possible to use them ethically and responsibly, much in the same way it's possible to write one's own code, and more broadly, do one's own work. Most people however, especially in our current cultural moment and with the perverse incentives our systems have created, are not incentivized to be ethical or responsible: they are incentivized to produce the most code (or most writing, most emails, whatever), and get the widest exposure and attention, for the least effort.
Hence my position from the start: if you can't be bothered to create it, I'm not interested in consuming it.
I think a lot of people who haven't given it more thought might see it as an arbitrary rule or even some kind of gatekeeping or discrimination. They haven't seen why people would want to not deal with the output.
This might not be helped by the fact that there are a lot of seemingly psychotic commenters attacking anything which might have touched an LLM or any generative model at some point. Their slur and expletive filled outbursts make every critical response look bad by vague association.
Having sensible explanations like in TFA for the rules and criticism clearly visible should help. But looking at other similar patterns, I'm not optimistic. And education isn't likely to happen since we're way past any eternal september.
Tangential side story, but an interesting one none the less.
I was a food delivery driver back in the mid 00's to the mid teens. Early on, GPS was rare and expensive, so to do deliveries and do them effectively, you had to be able to read a map and mentally plan out efficient routes from the stochastic flow of orders coming out.
This acted as a natural filter, and "delivery driver" tended to be an interesting class of people, landing somewhere in the neighborhood of "lazy genius". Higher than average intelligence, lower than average motivation.
Then when smartphones exploded in the early 10's, the bar for delivering fell through the floor, and the job became swamped with people who would be best identified as "lazy unintelligent". Anyone who had a smartphone and not much life motivation was now looking to drive around delivering food for easy money.
Not saying the job was ever particularly glamorous, but it did have a natural mental barrier that tech tore down, and the result was exactly as one would predict. That being said, I'm not sure end users noticed much difference.
well, they think they don't. until their pii gets leaked all over the internet because whoops our s3 bucket was publicly accessible, or until the service goes down because whoops our llm deleted the prod db...
PII leaks are normalized now. Most people aren't even aware, or just shrug "oh well" and head to the app store to download the latest gacha game or whatever.
> It's hard to know if LLMs will end up being a net win for the industry. They may speed up the good programmers a little, but those people were able to program anyway without LLMs. They will speed up the bad programmers a lot and that's where the balance sheet goes into the red.
If you will forgive an appeal to authority:
The hard thing about building software is deciding what one wants to say, not saying it. No facilitation of expression can give more than marginal gains.
Before LLMs we could already see a growing abundance of half baked engineers only in for the good pay. Willing to work double time to pull things out.
Management, unsurprisingly deemed those precious. They could email them out anytime, working weekend to fix problems their kind were the cause. Sure sir.
You're at least describing someone who sounds hard-working... what's the problem?
I'd be more concerned if I was someone who signed up to play ping pong two hours a day and do a bi-weekly commit.
There was a time not so long ago where I was watching "a day in the life of a software engineer" videos on Youtube and I was wondering if some of these were parodies. I still remember one in particular which I'm pretty sure was a parody, but it was only marginally distinguishable from the others.
I do believe in hardship. As sacrifice. It yields long term benefits for oneself, and for society.
But submissions into slavery for immediate gain accomplishes little, and costs society a lot more (physical and mental health issues are a huge burden).
Those parodies you saw, they were caricature of elite engineers, who sacrificed decades of his life to become so competent. Can work from home, eat pasta while glancing over a PR and just hit approve.
That you resent the luxury doesn't make it undeserved privilege.
I've met programmers who severely outclassed me. It was extremely uncomfortable and it took me months to accept that reality and reshape my hurt ego into curiosity and desire to learn from someone clearly superior in the craft.
That being said, most people in the privileged positions you described are there by sheer luck and connections. In the very very best-case scenario that offends them the least: they stumbled upon an opportune position and were smart enough to make full use of it... in the first 6 months (when people pay the most attention and lasting impressions are formed). And then rode the reputation they made for years. Their value as engineers on the team after the initial honest burst of productivity becomes... very unclear from that point and on, shall we say.
Again, I've met engineers who fully deserved their privileges. 2-3 times over 24 years of career though (a good chunk of it as a contractor so I've been around). My anecdotal evidence obviously means nothing but we all develop pattern-matching skills with time, making me think what I saw is generally the statistical curve that would apply almost everywhere. Maybe.
> Why are we not paying it off? I sure am. I refactor code left and right. It is up to you.
Do you work alone i presume? Everyone now is engineer. In my department, even managers are "writing code". Producing thousand of lines of ansible code, that nobody can review, with multiple lines of doc that nobody will read. It is just a mess.
That's a management problem. If you can't stop non-coders from coding perhaps you can introduce an AI reviewer to take a load off, demand that they be able to defend every line of code, and put them all on pager duty, since they're coders now ;)
i've been told that it's totally fine because once the codebase turns into spaghetti you can simply tell the agent to refactor it and then everything will be ok
I know this is a tongue-in-cheek response, but this brings me great pain. The spaghetti begins quickly, and your unit/functional tests won't help you unless you hammered out your module API seams before you even began. Oh, your abstractions are leaking? Your modules know too much about each other? Multiply the spaghetti!
For at least the last 3 decades programming was a field that rewarded utter mediocrity with (relatively to other fields) massive remuneration. It has been filled with opportunists for as long as I remember.
This is an excellent point. LLMs might merely be exposing and amplifying behaviors that were always there. This can be an opportunity, in that shining light on it may allow us to cleanse ourselves of it. It's fundamentally about integrity, and sadly it's becoming clearer how few possess it (if it ever wasn't!). But maybe we'll get better at measuring integrity, and make hiring/collaboration decisions based on it.
You are talking about bad programmers who are at least able to fool their managers for at least several years. The people OP is talking about could not even do that and most likely would have dropped out in the first week trying to program full time since they just don’t have the aptitude and patience to get unblocked after their first compilation error. Now they can go very far with a LLM.
Thing is, it's not how incompetent they are, but the opportunism itself. The property I mentioned pulls in opportunists regardless of their competence. So eventually if you work in a field like this, you end up surrounded by them. There's always _some_ around you, of course, everywhere - but across time different fields tended to pull so many of them they would become suffocating to anyone who isn't one. And if you think you can interview your way out of this - an opportunist will often have an easier time to pass a harsh interview process than someone who cares.
IT isn't the only one - finance and law had the issue since forever, AFAIK - but now I'd rather be in a field that's _actively repellent_ to them.
I think worth noting that a more impactful and maybe even bigger proportion of those opportunists is in management.
Regarding quality overall, I agree, it's truly a cursed field. It was bad before; and with LLMs, going against that tide seems more difficult than ever.
> Programming was a domain that filtered out those people because they found it hard to succeed at it.
I think this is a very rosy view of programmers, not borne out by history. The people leading the vibe coding charge are programmers, rather than an external group.
I know it's popular to divide the world into the technically-literate and the credulous, but in this case the technical camp is also the one going all in.
> there are lots of people in the world who live their whole life by vibing. It's a viable way to live and sometimes it's the only way to live. But they have a very loose relationship with truth and reason
This response 1000% was crafted with input from an LLM, or the user spends too much time reading output from llms.
I have never used an LLM to write. Writing forces me to think (and I edited the comment a couple of times when writing it which helped me clear up my thinking). "It's a viable way to live and sometimes it's the only way to live" is a personal realization that has taken me some time to understand. You can go back through my comment history to the time before LLMs to check if my style was different then.
If you run your writing through an LLM, it can poke holes in your argument, organize your ideas better, or point out that your tone is hostile/dismissive. It doesn’t need to be a replacement for writing or thinking, especially if you’re learning along the way.
So - in that way - LLM will be Your mentor, it will shape Your way of thinking according to algorithms and datasets stuffed into by corporate creators.
Do You really want it?
There is also a second face of that: people are lazy. They wouldn't develop their own skills but rather they would off-load tasks to LLM-s, so their communicative abilities will be fade away.
> LLM will be Your mentor, it will shape Your way of thinking according to algorithms and datasets stuffed into by corporate creators.
How is this mutually exclusive with teaching better than most humans? Part of these "corporate" datasets include deep knowledge of the world's best literature and philosophy, for instance. Why can't it be both?
> Do You really want it?
If I'm in a hurry, don't know where to start, or don't have money for someone to teach me—sure.
> There is also a second face of that: people are lazy. They wouldn't develop their own skills but rather they would off-load tasks to LLM-s, so their communicative abilities will be fade away.
This is a recapitulation of the Luddite argument during the Industrial Revolution. And it's valid, but it has consequences for all technological change, not just this one. There was a world before Google, the Web, the Internet, personal computing, and computers. The same argument applies across the board, and the pre-AI / post-AI cutoff looks arbitrary.
Ah, so now we get to the "ed tech" question. What is teaching? Is there a human element to it, and if so, what is it? Or is it something completely inhuman? Or do we need to clarify what meaning of "teaching" we're talking about before we have a discussion?
Rather that avoiding delegating it to LLM for these tasks helps you practice that skill.
That said, I think it depends how you use it. You can learn from explanations, and you'd better avoid "rewrite this for me and do nothing else" kind of approach.
Right, but the LLM can help you practice the skill too. Without the LLM, you're in a self-guided, autodidactical mode. Obviously, that can have its own advantages, but most people—but especially novices—aren't in a position to assess their skill level or their progress. The average person isn't going to magically get better at thinking or writing without formal training, or at least some direction.
I don't get that impression at all. LLMs would have avoided the stylistic repetition of "live". Asking an LLM to reformulate the sentences you quoted yields this slop:
> There are a lot of people who go through life by vibing. And honestly: that’s not automatically “bad.” Sometimes it’s even the only workable way to get through things. The issue is that “vibe-first” people tend to have a pretty loose relationship with truth, rigor, and being pinned down by specifics. They’ll confidently move forward on what sounds right instead of what they can verify.
I'll finish this post with a sentence containing an em-dash -- just to confuse people -- and by remarking on how sad I find it that people latch onto dashes and complete sentences as the signifiers of LLM use, instead of the inconsistent logic and general sloppiness that's the actual problem.
I'm firmly in the LLM fanbase. Not because I can't type code (was doing it for over 17 years, everywhere from low level hardware drivers in C to web frontend to robot development at home as a hobby - coding is fun!), but because in my profession it allows me to focus more on the abstraction layer where "it matters".
I'm not saying that I'm no longer dealing with code at all though. The way I work is interactively with the LLM and pretty much tell it exactly what to do and how to do it. Sometimes all the way down to "don't copy the reference like that, grab a deep copy of the object instead". Just like with any other type of programming, the only way to achieve valuable and correct results is by knowing exactly what you want and express that exactly and without ambiguity.
But I no longer need to remember most of the syntax for the language I happen to work with at the moment, and can instead spend time thinking about the high level architecture. To make sure each involved component does one thing and one thing well, with its complexities hidden behind clear interfaces.
Engineers who refuse to, or can't, or won't utilize the benefits that LLMs bring will be left behind. It's just the way it is. I'm already seeing it happening.
I generally do have that mindset, but over the past 1y of Claude code I do notice that I’m clearly losing my understanding of the internals of projects. I do review LLM generated code, understand it, no problem reading/following through. But then someone asks me a question, and I’m like… wait, I actually don’t know. I remember the instructions I gave and reviewing the code but don’t actually have a fine-details model of the actual implementation crystallized in my mind, I need to check, was that thing implemented the way I thought it was or not? Wait, it’s actually wrong/not matching at all what I thought!
It’s definitely becoming uncomfortable and makes me reconsider my use of Claude code pretty significantly
reminds me of the experience of reading a math text without doing the exercises, thinking that you've understood the material, and then falling flat on your face when you attempt to apply your "understanding" to a novel problem. there's a significant difference between passively reading something and really putting active effort into it. only the latter leads to actual understanding ime
Same experience. I've been writing code for many decades, but that experience doesn't mean I can remember what I read when reviewing generated code. I write small, focused commits, but I have to take a day off each week to make changes by hand just to mentally keep up with my own codeset knowledge, and I still find structures that surprise me. It's not necessarily that the code quality is poor, but it's not like I (thought) I had designed it. It's lead to a weakening of my confidence when adding to or changing existing architecture.
I've had this issue too, and I feel it was an important lesson—kind of like the first time getting a hangover.
On the other hand, LLM-generated code comments better than I do, so given a long enough time horizon, it could be more understandable at a later time than code I've written myself (we've all had the experience of forgetting how things work).
> On the other hand, LLM-generated code comments better than I do, so given a long enough time horizon, it could be more understandable at a later time than code I've written myself (we've all had the experience of forgetting how things work).
Writing and rewriting piece of software performs what is called "spaced repetition" [1].
You ask questions about code when you implement something and if you cannot answer these questions, you go to code to find answers out and refresh your understanding of it.
For this to work you have to be interested in the understanding of the code and code should be created at the pace you can keep up.
Software engineers usually do create code economically because they need to remember and understand it. Vibe coders do not have this particular constraint, they just do not aim for most understandable code possible. Even if there are more comments in code.
I do think that this is natural. When you use LLM coding tools, you're becoming a lot more like an architect/staff/manager, rather than the direct coder. You're setting out the spec, coming up with the design, and coming up with the high level structure of the project.
However, this comes at the cost of losing track of the minute details of the implementation because you didn't write it yourself. I find it a bit analogous to code I've reviewed vs code I've written.
However, I've found using AI for code structure summary and questioning tends to be a good way to get around it. I might forget faster, but I also pick it up faster.
I've found that for non-trivial features, I typically benefit from 3-4 rounds of: are you sure this isn't tech debt, are you sure this is thoroughly tested for (manually insert the applicable cases, because they aren't great at this, even if explicitly asked), are you sure this isn't re-inventing wheels, adding unnecessary complexity by not using existing infrastructure it should or that other existing code would not benefit from moving to this, are you sure you can't find any bugs, in hind sight, are you sure this is the best design?
Then, after it says, yes I'm sure this is production ready and we're good to move on, you have Codex and Gemini both review it one last time, and ask it to address their feedback if it's valuable or not.
After all this, it's the only time I'll look at the code and review it and make sure it's coherent.
Until then, I assume it's garbage.
I'd estimate this still improves velocity by 10x, and more importantly, allows me to operate at a pace I couldn't without burning out.
it's very different. LLMs don't behave like people. they don't learn.
i don't mind managing people, but i don't want to manage machines unless i can control them with the precise languages that the commandline and programming languages use. prompting a LLM is to vague an interface for me, the outcome is to unreliable, to unpredictable.
One-off tasks and parts of the stack that already have lots of disposable code do not need the same scrutiny as everything else. Just as there is a broad continuum of code importance, there is a broad continuum of testing requirements, and this was the case before AI. Keeping this in mind, AIs can also do some verification and testing, too.
> Engineers who refuse to, or can't, or won't utilize the benefits that LLMs bring will be left behind. It's just the way it is. I'm already seeing it happening.
Any examples how you see some engineers being left behind?
> Any examples how you see some engineers being left behind?
I don't know where you live, but around where I live in Denmark you'd fail for not using AI at a senior interview in a lot of places. Even places which aren't exactly AI fans use AI to some extend.
The biggest challenge we face right now is figuring out how you create developers who have enough experience to know how to use the AI tools in a critical manner. Especially because you're typically given agents for various taks, which are already configured to know how we want things to be written.
Around here on your southern neighbour, everyone is supposed to be doing AI and being evaluated by this, yet in many projects if clients don't sign off on the use of AI tools, there is no AI to use anyway.
Additionally there are the AI targets set by C suites based on what everyone is saying on TV, and what we can actually deliver based on the available data sets, integration points, and naturally those sign offs for data governance, and hallucinations guardrails.
I was just giving them an anecdotal example of what they were asking for. I think the answer is somewhere in the middle, but I'm not in a position to push any form of change on the C levels.
I've noticed that back in Europe everyone's in a panic mode, but that's because of the inferiority complex most people have vs both US and China. It's unwarranted.
I'm starting to notice how those who don't use AI end up having to hand tasks over to people who can get them done quicker.
It is anecdotal for sure, but it's a pattern that seems to be emerging around me that expectations of velocity increases, and those who don't use AI can't keep up.
Shit processes. I don't know what places most of those people work at that crap is being merged into production at insane pace. You would expect any serious piece of software would be important enough to have the code be reviewed by at least one human.
Kind of.... I don't know. To get placed such requirements from the top down and not fight back, just take it head on, not even maliciously, don't even oppose it on a technical basis, just be like "yeah, you've now gotta ship faster or you're left behind, so therefore LLMs must be the future!", no critical thought attached. Is this shit coming from experienced engineers?
Preposterous we're relying on "it's better because I feel like", "dudes who don't use it are falling behind at work", "they ask for it in job interviews".
Again, I have to point out that AI is not an abstraction layer. It blows my mind that engineers with years of experience somehow don’t understand this.
It would be an honor to be “left behind” by people who practice their craft with such carelessness.
(Frankly, I should probably stop replying to self-professed LLM boosters entirely since there’s a good chance I’m just chatting with an LLM.)
Your employer allows/encourages this? Do you run that stuff in production? Would you mind telling us where you work so we can avoid using their products? It is just not possible to trust the software that emerges from the process you've described.
so, they are approved, which means they were most likely reviewed. yet you still think the software cannot be trusted of that and even want to name and shame a company. utterly stupid.
Yes. If a company is running vibeslopped compilers to build their production artifacts I absolutely want to know which one it is, so I can protect myself from their software.
> utterly stupid
That's completely uncalled for.
EDIT: What exactly do you mean by:
> most likely reviewed.
Let's say every line was actually reviewed. That's still nowhere near good enough. The changes are being reviewed by the wrong people. Not the maintainers of the project, just some random folks who have inherited a vibecoded fork.
The normal distribution doesn't account for things like "huge megacorporations pour billions of dollars into accelerating product adoption" or "other companies force their employees to use AI whether they want to or not" though.
This is a spam problem more than anything else. It's not really an AI problem except that it's AI that is enabling this new type of spam.
Imagine there's no AI, but for some reason you have people hiring armies of cheap overseas devs and using them to produce mediocre quality drive-by PRs. The effect would be the same.
AI can be used to make quality code, but that requires careful use of the tool... like any other tool. This isn't careful contributions made by someone who knows the project and its goals and is good at using the tool. This is spam.
Exactly, people could have "consulted Google" or "consulted stack overflow" and had the same issues. It's about the end result, not how the code got to that end result, and the submitter is responsible to make sure of the quality of the submission regardless of whether AI was used or not.
To reject submissions where the dev "consulted ai" is like rejecting iron ore that was mined by a machine rather than a human. The quality of the ore is what should be measured, not how it was obtained.
I agree, but the problem comes back to how to evaluate quality at scale. That is very hard. It’s easier to just say no AI because that at least turns off the fire hose.
It sounds like they are even rejecting submissions where they even get a whiff of ai being "consulted" though. That's not quite the same as turning off the firehose.
The discourse around AI in the arts, and other creative and craft fields, is utterly identical to the discourse around photography when it came out to the point that you could search and replace terms and have the same dialogue.
I'm personally amazed that _Large_ OSS projects don't have the appropriate automation in place to prevent non-compiling or non-linter-passing submissions.
- Hooks (although there's no clean way to enforce they be "installed" on a clone), GHA Workflows (or their equivalents on other forges).
This might be my bias showing, but these are items I would consider table-stakes for a project of a certain size / level of popularity.
It feels like a lot of the "AI is shit at contributing" problems could be addressed in part by better automated checks and balances.
Those things cost resources, and now you're introducing a new attack vector: open up a bunch of shit PRs, burn a lot of cash for the target organization.
You're right. It doesn't solve for all scenarios and doesn't block malicious actors.
I do believe, however, that it would have a meaningful impact on the "drive-by" PRs that keep being used as examples; the thoughtless, throw-spaghetti-at-the-wall PRs that do not have malignant intent behind them.
Many large OSS projects would have the resources to eat that cost with Donors, Sponsors, and OSS hand-outs. That's why I clarified in my original post because I know this is not a general solution.
The problem is you can get the LLM to iterate until it compiles and lints and even passes LLM review, but will that actually improve the quality of the contribution or just produce more line noise to mechanistically meet criteria?
To large complex projects often the kernel of an idea is the core value of a contribution, and it can take a lot of iteration to figure out how to structure it. Token bashing until CI is green does nothing to ensure the best approach is selected.
> The problem is you can get the LLM to iterate until it compiles and lints and even passes LLM review
Worst of both worlds with this, if you're doing it in a github workflow. You wind up effectively paying for the testing/validation layer of someone else's irresponsible LLM use.
For sure, but that's not what I was referring to in my posts. I'm specifically referring to the callout that the contributions are so low quality they don't even pass linting or compile.
I could have been more explicit on that nuance, I suppose.
That's why you sandbox. You can mitigate most low-hanging DoS fruits by running your server side hooks in a per-tenant cgroup that limits CPU and memory usage. One tenant per public key for trusted contributors, and one general-purpose tenant shared by all new/unknown contributors.
Can't you prevent pushing from the client side with pre-commit hooks? I would expect a hook to fire on the developer's computer that prevents them from even committing/pushing (unless they nuke the hook in their local repo copy).
You have to manually install hooks in your local repository. They aren't propagated as part of the repo. Git has intentionally made hooks require a very explicit opt-in.
> Hooks (although there's no clean way to enforce they be "installed" on a clone), GHA Workflows (or their equivalents on other forges).
Git supports pre-receive hooks. But big multitenant forges like GitHub.com don't allow you to configure them because they're difficult to secure well. (Some of their commercial features are likely based on them, though.)
If you self-host a forge, though, you can configure arbitrary pre-receive hooks for it in order to do things like prevent pushes from succeeding if they contain verifiably working secrets, for example. You could extend that to do whatever you want (at your own risk).
At the end of the day, LLM slop PR spammers are essentially adversarial actors. Git hooks are ultimately a tool for good faith developers within a given community (your team, your company, your regular contributors) in maintaining good hygiene and avoiding lapses into preventable mistakes. That's true for all CI, too.
And the truth is, too, that it's super easy for an LLM agent to run a build and tests. Good faith contributors using LLMs will never open PRs that don't build not because they're willing to "go the extra mile" and do manual work, but because they give the slightest fuck and have any respect or consideration for the humans they're working with.
LLM spam presents a different problem than any of that stuff was meant to solve. It's a malicious act, and you're right that tooling that burns the defender's compute can't be a solution. :-\
One of my pet peeves with git (and systems both similar, and based on it) is that automated tests run after you've made the commit and push.
In my mind the commit (let alone the push to a publicly accesible server) should be done after, and only if, the automated tests are successfully executed. And there's no easy way to implement this, other than having a dirty branch that you discard after rebasing onto a more long lived one.
There are lots of reasons to commit when things are yet working. How else would you share code that you need help with?
The solution is gated merges. No merging to main unless ci passes.
Every org I have worked at bemoaned a flaky release process and refused e2e black box acceptance tests because "they are too slow." And every org I have worked at has realized they were wrong. We got appropriate gates that run in 5 minutes and an ops person is the only person who can force past any gate in case of emergency.
Guardrails like this only become more important with the accelerant that is ai.
You can use a pre-receive hook on a git server to reject pushes that fail compilation. Downside is that it requires admin access on git forges, so you're only able to do this if you self-host.
I mean even having linters and everything still creates a whole bunch of noise in their PR section, not to mention that a lot of the changes I make to stuff that's written by codex is not stuff that's caught by linters.
It's just bad/wrong/context lacking decisions and mental models it introduces, that if not carefull will just create a massive mess of a codebase. (I know, because I've tried, and had to deal with it)
And if someone vibecodes a PR and it works, why dont they just share the prompt so a repo owner could vibecode it themselves?
Don't disagree, but the "if you're doing it right" is a big asterisk for an open source project with people you have no idea what quality bar they're at.
And in my experience it's quite hard to figure that out by quickly looking at it.
Not to mention that contributions on github (almost?) never include the prompt chain anyway, so the status quo is even worse
I wouldn’t say slightly slower; LLMs are massively useful for software engineering in the right hands.
For some personal projects I still stick to the basics and write everything by hand though. It’s kinda nice and grounding; and almost feels like a detox.
For any new software engineer, I’m a strong advocate of zero LLM use (except maybe as a stack overflow alternative) for your first few months.
It's significantly slower to use LLMs for some things. The only thing it excels at is generic, broad tasks. Getting the 90% done. I find that it's less cumbersome to get it mostly right and touch it up yourself than to prompt over details like syntax.
The chat UX with a fake-human lying to you and framing things emotionally really doesn’t help. And it is pretty much not possible to get away from it, or at least I haven’t found yet how.
I would love to see a model trained to behave way more like a tool instead of auto-completing from Reddit language patterns…
Apparently, the noise around the AI policy came from Bun's developers saying that policy blocks upstreaming their performance PR. But the real reason seems to be that PR's code itself isn't in great shape, and introduces unhealthy complexity https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
> Parallel semantic analysis has been an explicitly planned feature of the Zig compiler for a long time, and it has heavily influenced the design of the self-hosted Zig compiler. However, implementing this feature correctly has implications not only for the compiler implementation, but for the Zig language itself! Therefore, to implement this feature without an avalanche of bugs and inconsistencies, we need to make language changes.
Yes, that reply provides convincing arguments for not merging the Bun fork, as it interferes with Zig's own roadmap for achieving even better results, while continuing to improve the whole language.
This was probably a joke about a lot of developers delegating coding to LLMs which are usually non-deterministic (which I personally think is less of an issue than LLMs not having specified behavior like programming languages do).
When somebody comments PR with “Incredible work, Jacob. It is an honor to call you my colleague.” then it's safe to assume it's out of the ordinary contribution. Pretty much falling outside of the “in all likelyhood”.
Also 95% of those 30k lines changed are fully self-contained inside of the aarch64 directory and of the remaining changes it looks like the majority is just adding "aarch64" as another item into an existing list. There are a few core changes that to me look like they could be done in their own PRs, but also core maintainers get to decide if they want to apply bureaucracy to their own work.
> In successful open source projects you eventually reach a point where you start getting more PRs than what you’re capable of processing. Given what I mentioned so far, it would make sense to stop accepting imperfect PRs in order to maximize ROI from your work, but that’s not what we do in the Zig project. Instead, we try our best to help new contributors to get their work in, even if they need some help getting there. We don’t do this just because it’s the “right” thing to do, but also because it’s the smart thing to do.
I feel like if their goal is to prioritize contributors over contributions, it'd also logically follow that they should try to have descriptions where possible? Just to make exploring any set of changes and learning easier? Looked it over briefly, no Markdown or similar doc changes there either.
I mean the changes can be amazing, it's just that adding some description of what they are in more detail, alongside the considerations during development, for new folks or anyone wanting to learn from good code would also be due diligence.
How would you differentiate a 3000 line LLM commit made by the best models and good AI processes from a 3000 line commit made by the best human developer?
edit Okay, I set the bar too high here with "best human developer" and vague "good AI processes". My bad. Yes, LLM is not quite there yet.
It's still fairly obvious just by skimming the code. The best AI models are still quite far from the best human developers in ability and especially in code quality.
If that happens and we have a way of reliably knowing if some code is produced to that high quality, then I think we probably can accept that AI coding is the only sensible option.
We definitely are not close to that point though and it's unclear if/when we will get there.
It seems to me that people might be arguing from conflicting hidden premises here. "AI Coding" is a spectrum that could mean something as simple as letting the LLM proofread your changes and then act on those with your own human brain, or it could mean just telling the agent what you want and let it rip and tear until it is done.
If I do the latter and submit a PR to something like Zig, I'll be certainly caught doing it and rightfully chastised. If I do the former, my PR will be better without anybody besides myself having any way of knowing how it got better. Probably I do something in between when I contribute to open-source these days.
Blanket banning all of these seems like a bad idea to me. It actively gates people like myself from contributing, because I respect these people and projects that much. It feels like I would be doing something they find disgusting if my work has touched an LLM and I obviously don't want to do that to people I respect. But it's fine, there are plenty of things to do in the world even when some doors are closed.
I do not presume to have any say on Zig project's well argued decisions[0] -- I'm not really even their user let alone someone important like a contributor. Their point of preferring human contact is superb, frankly. Probably a different kind of problem in an open-source project staffed with a lot of remote working people, where human contact is scarce.
Blanket banning all of these seems like a bad idea to me. It actively gates people like myself from contributing
in my projects i will reject any contribution that i do not understand. even if the contribution is handwritten by an expert developer. that developer will have to earn my trust like anyone else, like you would have too.
LLM contributions are non-deterministic, which means they can never be trusted.
therefore, if you use LLM to contribute, you can not earn my trust. if you believe that you can not create a meaningful contribution without the use of LLM then you are realizing that you are not skilled enough to understand the code that you contribute. because if you could understand it, then you could write it yourself. i want your personal contributions, not those of your LLM. i want contributions that the submitter actually understands. i want you to earn my trust by showing me that you understand what you are doing. i want you to grow your understanding of my project. none of this happens when you use LLMs.
if you are unable to make a contribution without the help of an LLM then you are not ready to contribute. try looking for smaller issues that you can work on instead until you learned enough to make larger contributions.
> i will reject any contribution that i do not understand
Fair.
> that developer will have to earn my trust like anyone else
What does it take to "earn your trust"?
> LLM contributions are non-deterministic, which means they can never be trusted.
Provably incorrect. LLM contributions can be reviewed, tested, and understood like any other contribution. There's nothing "special" about LLM contributions.
Contributions authored by human brains are also non-deterministic, perhaps if the author was feeling in a slightly different way they'd have formatted the code a bit differently.
> therefore, if you use LLM to contribute, you can not earn my trust.
The premise is wrong.
> if you believe that you can not create a meaningful contribution without the use of LLM then you are realizing that you are not skilled enough to understand the code that you contribute
What if I believe I can do so without an LLM, but that it could be even better with an LLM?
What if I'm great at understanding code, but terrible at writing it?
Again, this is a premise that you just decided to take as truth, without proof.
> because if you could understand it, then you could write it yourself.
False. I can understand a novel algorithm by reading and studying it, but perhaps I could have not come up with it myself.
> i want you to earn my trust by showing me that you understand what you are doing
I can easily do that even if my contribution involves LLM assistance.
> i want you to grow your understanding of my project
Ditto.
> none of this happens when you use LLMs
False. Why do you think so?
> if you are unable to make a contribution without the help of an LLM then you are not ready to contribute.
Again, this is your opinion and you have no way of proving it. I can prove the opposite.
multiple successful contributions of increasing complexity, among other things.
>> LLM contributions are non-deterministic, which means they can never be trusted.
> Provably incorrect. LLM contributions can be reviewed, tested, and understood like any other contribution. There's nothing "special" about LLM contributions.
> Contributions authored by human brains are also non-deterministic, perhaps if the author was feeling in a slightly different way they'd have formatted the code a bit differently.
i can tell a human to focus on a certain issue. they will either listen and follow my instructions, or i will reject their contribution. the LLM is almost guaranteed to not follow all my instructions and make changes i didn;t ask for. see my comment above.
>> therefore, if you use LLM to contribute, you can not earn my trust.
> The premise is wrong.
how so?
>> if you believe that you can not create a meaningful contribution without the use of LLM then you are realizing that you are not skilled enough to understand the code that you contribute
> What if I believe I can do so without an LLM, but that it could be even better with an LLM?
what you believe is not relevant. only what you can convince me of. you'll have to first show that you actually can work without an LLM before i will consider your contribution.
> What if I'm great at understanding code, but terrible at writing it?
your problem not mine. if you are terrible at writing code but good at understanding it then it's your choice to only do code reviews. you can still make a meaningful contribution that way. i'd even let you write code so you can practice that, but i am not interested in your LLM generated code.
> Again, this is a premise that you just decided to take as truth, without proof.
i don't need proof. i need trust. you need to convince me that your code can be trusted.
>> because if you could understand it, then you could write it yourself.
> False. I can understand a novel algorithm by reading and studying it, but perhaps I could have not come up with it myself.
that's called learning. once you learned it, you can write it. but in order to effectively learn you also have to practice. if you let LLM write all your code then you are not practicing, so you won't improve.
>> i want you to earn my trust by showing me that you understand what you are doing
> I can easily do that even if my contribution involves LLM assistance.
it depends on the level of assistance. i am not ruling out use of AI to do research and learn, just don't let it write the code for you.
>> i want you to grow your understanding of my project
>> none of this happens when you use LLMs
> False. Why do you think so?
as i said above, if you don't practice writing the code yourself you are not learning. not enough at least to satisfy my expectations.
>> if you are unable to make a contribution without the help of an LLM then you are not ready to contribute.
> Again, this is your opinion and you have no way of proving it. I can prove the opposite.
whether you are ready to contribute to my project or not is not something i need to prove. it is a choice based on my preference which depends on the amount of trust you have earned. you can not prove to me that you are ready to contribute. this is not a standardized test that if you pass you automatically qualify. you can only convince me by earning my trust. this is a human decision, based on feelings.
>because if you could understand it, then you could write it yourself.
I accept most things you said there as valid opinions, but this is where the logic goes wrong.
I use LLMs to give me more from the only resource (now that my basic and mid-level needs are largely met) that ultimately matters: time. That means that I need to waste far less time in front of the computer, typing code, and use far more time doing more useful things, like hobbies, art, being with my children.
But as I said before, every project is obviously allowed to make their own rules, and contributors should obey those rules. There are plenty of projects that take both AI deniers and plenty of projects who prefer AI aficiandos.
At least for now. My belief is that one those groups will fade away like horseback riding did, but we'll see. Perhaps you have heard the famous stages quoted by many different people in different forms: first an idea is ridiculed, then it's attacked, then it's accepted. Some open-source communities have clearly entered the attacking phase in the last year so.
you are saying that even if you understand the code, using an LLM saves you time writing it. fair enough[*]. the problem on my side still is that if you didn't write the code yourself, i have no evidence that you actually understood it. the only way to prove that you understand the code is to write it yourself. that's where the trust building comes in. you may actually understand the code, but i can't trust that you do.
[*] in my opinion it takes more time to verify that the LLM code is correct than it takes to write it yourself. based on that, if you save time using an LLM then you didn't spend enough time to verify that the code is correct.
Some open-source communities have clearly entered the attacking phase in the last year so
How can AI possibly be better than “the best” when the corpus of training data now includes its own slop in addition to all the code by new devs/lazy devs/bad devs scattered all over the internet? Law of averages applies here.
> So while one could in theory be a valid contributor that makes use of LLMs, from the perspective of contributor poker it’s simply irrational for us to bet on LLM users while there’s a huge pool of other contributors that don’t present this risk factor.
> The people who remarked on how it’s impossible to know if a contribution comes from an LLM or not have completely missed the point of this policy and are clearly unaware of contributor poker.
The point isn't about the 3000 line PR, it's about do we think the submitter is going to stick around.
Because the pro-group are whining that the policy is preventing the merge, when in actual fact even if the policy did not exist, the PR is crap anyway.
I don’t see how it could be that bad (incorrect, specifically), considering bun is probably the most widely-used production use case of zig. But regardless, let’s say it’s a bad PR for the sake of argument - it’s beside the point. It cannot be merged no matter how good it is, due to the strict no-LLM policy.
> I don’t see how it could be that bad (incorrect, specifically), considering bun is probably the most widely-used production use case of zig.
That may be the case, but the bun project only needs zig to correctly compile bun. The zig project needs to be able to correctly compile all existing and possible zig programs.
I haven't reviewed things, but it's possible and even likely (at least based on my own experience with LLMs) that the validation is mostly focused on bun compilation.
This is the most common issue I see with LLM authored PRs. Yes it does fix the issue _right now_ but as a maintainer I need to consider how it affects the project in the future. But “contributors” get mad if you reject for those reasons. So I can understand having a blanket policy.
> I don’t see how it could be that bad (incorrect, specifically), considering bun is probably the most widely-used production use case of zig.
The PR is probably fine for bun’s purposes. That doesn’t make it a good PR for Zig’s purposes, and could very well paint Zig into a weird corner.
> It cannot be merged no matter how good it is, due to the strict no-LLM policy.
This is about meta-discourse. Of course it’s against the policy. That’s the point of discussing the PR: to get Zig to change the policy, or at least provide an exception in this case. Or to argue the opposite.
> Of course the policy is preventing the merge. That’s literally the point of the policy…
In this case it isn't the blocker - the fact that the dev took the time to read the PR in detail, comment on it, and provide reasons why it could not be merged makes it very clear to me that the policy wasn't the blocker.
If they were going to enforce the policy for this PR, they wouldn't have bothered to read it. The only reason to read it is to see if the policy is waived for this specific PR.
it could have been rewritten, rewriting PRs is cheap today, but that isn't the question. the question is, would it have been accepted had it met all the quality and engineering standards and full disclosure that it was 90%+ LLM generated?
> it could have been rewritten, rewriting PRs is cheap today
Rewriting PRs with LLMs is cheap, but often the output is no better than the previous revision (fixing one issue only to cause another one is very common IME). And reviewing each revision of the PR is not cheap.
I've had good experiences with people submitting AI generated PRs who then actually take the time to understand what's going on and fix issues (either by hand or with a targeted LLM generated fix) that are brought up in review. But it's incredibly frustrating when you spend an hour reviewing something only to have someone throw your review comments directly back at the LLM and have it generate something new that requires another hour of review.
> it could have been rewritten, rewriting PRs is cheap today, but that isn't the question. the question is, would it have been accepted had it met all the quality and engineering standards and full disclosure that it was 90%+ LLM generated?
In this case it looks like the answer is "Yes"; the PR was not dismissed immediately, it was first examined in great detail!
Why would the maintainer expend effort on something that was going to be rejected anyway?
> either effort was wasted or policy is at best 'not implemented'.
I don't understand this PoV - have you ever come across a policy in any environment that wasn't subject to case-by-case exceptions?
Even in highly regulated environments (banking/fintech, Insurance, Medical, etc), policies are subject to exceptions and exemptions, done on a case-by-case basis.
The notion, in this specific case, that "well they rejected it because of policy" is clearly nonsense and I don't understand why people are pushing this so hard when the explanation of why an exemption can't be made for this specific PR is public, accessible and, I feel, already public knowledge.
The point we are making is that in reality, it is the policy which is preventing the merge. Sure, in your hypothetical, maybe it couldn’t be merged anyway. But while the policy exists, the hypothetical is irrelevant. The policy is preventing the merge.
You also don’t sound smart enough to be calling others stupid.
This is overstated. Not all LLM code is produced the same way. Code produced through substantial human creative input still falls under copyright, at least the way things are now. Besides, nothing legally prevents placing code under a license. Enforceability is the question, not permission.
It's a bit like saying speed limits don't apply on private property, therefore you can't have any traffic rules on your private racetrack.
> Besides, nothing legally prevents placing code under a license. Enforceability is the question, not permission.
That’s not how copyright works. If you don’t own the code, you can’t release it under a license. The question of how much human editing is needed to establish copyright is a huge question right now.
It seems that Zig people are following the path of ZeroMQ [1]: "To enforce collective ownership of the project, which increases economic incentive to Contributors and reduces the risk of hijack by hostile entities."
A healthy contributor community is more important than mere code performance, quantity of features or lines of code, etc..
Unfortunately, those are largely words of a foregone era. The zeromq "community" today is tenuous. It has some really good people in it, the few that remain active, but the human-level processes and communication channels are ill defined and not well "staffed". In some ways, this lack of human activity and interactivity is perhaps okay and even justified given how stable libzmq and most of its bindings are (and the sub-ecosystem around particular bindings are a bit more active). Perhaps Hintjens' grand (and excellent, imo) vision got zeromq to where it is but the project feels to have gone adrift since we lost him. Somewhat ironic to his community-centric vision statement (the guide) it seems a project needs a charismatic and active leader to gain and retain a community. I guess that says more about human nature than it does about software development.
I'm not sure how to tie this all back to the zig story other than to point out the stated premise that zig is not short of PRs and so they can pre-select for no-LLM contributions. I think that is a good move for them and I get the "contributor poker" idea. But, the game changes when the premise breaks and the flow of newbies reduces to a trickle. At that point, if there are still active zig people who still want newbies, they may need to broaden their net. But if/when that happens, it may be too late to recover by opening to LLM-assisted contributions.
You know what; I use ZeroMQ all the time. Thanks for bringing to my attention that the community is waning, I will look into contributing to it tonight.
Great! One thing I do is have an RSS feed from a reddit search query so I can lurk random discussions that mention "zeromq". I'll then see if there is something I can do to encourage or contribute to whatever is happening. There is also a mailing list and a VERY low traffic IRC channel on libera.chat.
If an AI improves developer productivity so much, why would maintainers of an OSS project want unknown contributors to sit in between the maintainer and the LLM? They'd be typing these queries into Claude Code themselves. To quote my colleague:
> We do not need a middleman to talk to AI models. We are not bottlenecked by coding.
maybe you are not bottlnecked by coding. but there is high probability that you will be bottlenecked by verifying the correctness of LLM-generated code.
Crazy how this doesn't register in people's heads. Has the real bottleneck ever been code written and not the review of code and everything involved? Understanding the nuance and implications behind design decisions; strategy.
In any REAL, workload, with good processes, code review makes speed of code generated a moot point. You still move as fast as you can review the code, and no, I won't debate that you can rely on LLMs, a deterministic language predictor, to determine the correctness of code; in the context of the business, and technical implications.
If you are a responsible maintainer you need to verify the correctness of the contribution wether you used an LLM to generate it or wether someone else did.
Having someone else be the AI-middlemen, just introduces additional complexity and confusion.
I'm almost not using AI, but a possible scenario is that the contributor spend like 20 hours in total.
Something like using the AI to get an initial bad version, make some tweaks to the prompt, make some manual fixes, ask the AI to fox something else, noticing some new related feature and asking the AI to add it, making some benchmarks and deciding to remove a small feature, or perhaps deciding between two similar implementations, add a few more manual fixes here and there, run the extended version of the automatic test and find a weird bug in the unusual setup, make a few fixes with the AI and manually. So after 20 hours of work, the final version has only 50 lines that have been rewriten like 5 times each. Now the mantainer can review only the final version in 1 hour or so.
This is very different to spending 5 minutes asking the AI to write a patch, that has 1000 lines that does not even compile and sending it to the maintainer without looking at it.
I'm finding that AI, when successful, gives me 2-3x speedup. It's not the kind of thing I can give high-level instructions to like I can to a human.
I suspect the people who claim that AI works by only giving it high-level instructions are mostly working on "mindless" projects where a developer in the weeds wouldn't need to think very much.
> If an AI improves developer productivity so much,
You're not suggesting the only metric of productivity is lines of code are you? And that the only benefit of using LLMs is for generating code you're too lazy to type yourself?
> Zig values contributors over their contributions. Each contributor represents an investment by the Zig core team - the primary goal of reviewing and accepting PRs isn't to land new code, it's to help grow new contributors who can become trusted and prolific over time.
> LLM assistance breaks that completely. It doesn't matter if the LLM helps you submit a perfect PR to Zig
That’s the best rational I’ve seen so far, and fully support Zig decision here. I really appreciate their long term vision for both the community and actual project. I don’t think LLMs have such a great place in more collaborative efforts to be honest. Though we will see how things evolve, but I do see that when getting AI generated PRs I basically have to redo it myself (using LLMs, ironically… something I’m really starting to feel conflicted about)
i do think llms are great, i vibe code a lot of zig (working in a locally deployed semi-embedded on-prem device), and i think the zig policy is a good idea at least for the next five years.
I know my take on this is not popular. Don't blame the tool, judge the output.
Ofc, the scattershot 10k changes PR touching 30% of all your code files can be auto rejected without even looking at it. Who cares who or what wrote it.
And a small focusses PR from a new contributer that needs clarification which the author can not provide, shelve it.
But a blanket no-ai policy? I hear echos of business execs refusing email and demanding in person visits to remote offices for any interaction (not imagined. I knew an IT admin back in the late 80's who even refused to answer the phone and email as he felt that was 'too easy' and 'cutting in line', yes, the pysical hallway queue of people needing simple things like a login, quota adaptation or a password reset)
The tool is not your problem. Your selectivity process was never designed for low barrier access to participation. I have full sympathy for that. But focus on the real problem, the process, not some (rightly or wrongly) perceived feature filter to avoid changing how this works.
Now if you say "my project, my rules" 100%. And I sympatize very much with being overwhelmed by nuissance on a thing you love and care for.
> This makes a lot of sense to me. It relates to an idea I've seen circulating elsewhere: if a PR was mostly written by an LLM, why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem?
The same argument applies to open source itself. Why use someone's project when you can just have the robot write your own? It's especially true if the open source project was vibe coded. AI and technology in general makes personalization cheap and affordable. Whereas earlier you had to use something that was mass produced to be satisfactory for everyone, now you have the hope of getting something that's outstanding for just you. It also stimulates the labor economy, because you have lots of people everywhere reinventing open source projects with their LLMs.
> Why use someone's project when you can just have the robot write your own?
I've been thinking about this a bunch recently, and I've realized that the thing I value most in software now isn't robust tests or thorough documentation - an LLM can spit those out in a few minutes. It's usage. I want to use software which other people have used before me. I want them to have encountered the bugs and sharp edges and sanded them down.
Depth of use over the lifetime of an app is a quality all its own that often not appreciated. A recurring pattern at $dayjob is that a new manager or director will join a business unit and declare an existing app as the worst terrible, no good, horrible app they've seen and they're going to fix that. A year and a half later the new app is finally delivered with 80% of the original functionality and a fresh set of bugs. The new dev team sees the surface functionality but misses a lot of the hard earned nuance the old system accrued over time. This is a pattern that existed long before LLMs.
An LLM most definitely cannot spit out robust tests or thorough documentation. It can spit out some tests or some documentation, but they will not cover the user perspective or edge cases unless those are already documented somewhere. That's verified by both experience and just thinking about it for two seconds.
The sanding down you refer to is what generates those tests and documentation.
> but they will not cover the user perspective or edge cases unless those are already documented somewhere
Are you suggesting that LLM's can't test for people who use screen readers? Keyboard only users? Slow network requests?
You're acting like the issues an app faces are so bespoke to the actual app itself (and have absolutely no relation to existing problems in this space) that an LLM couldn't possibly cover it. And it's just patently wrong.
I'm not talking about keyboards or screen readers or any sort of input testing, I'm talking about how the software is used in practice.
If you disagree with that, I think the onus is on you to show me that an LLM could simulate the full context in which a user interfaces with software. That's a ridiculous claim.
Feel free to show literally any evidence for this claim.
The status quo is that this capability does not exist. Whoever makes a claim contradicting the status quo has the burden of proof. I can't prove a negative.
And even with your logic, I did not make the original claim, it was made by simon.
Your statement now also makes little sense. For any nontrivial software project, the usage patterns and interactions with other systems are complex enough that the code itself does not contain enough context to understand how it is used, or what the invariants are.
There may be very simple codebases where an LLM can actually give you "thorough documentation" or "robust tests", but those are rare.
> There may be very simple codebases where an LLM can actually give you "thorough documentation" or "robust tests", but those are rare.
Its not rare. I've built 2 dozen line-of-business apps in it last handful of years that were glorified CRUD apps. Every environment I've been in has had a mix of the 2.
And even then, that's at odds with your absolute above. On top of being in a field that changes daily.
You are interpreting a general statement as a categorical one.
I wasn't really going for an exact, formal statement, but I can give you a formal interpretation of what I said above, if you want to be pedantic.
In general, you can't expect an LLM to produce thorough documentation or robust tests for nontrivial software, because the use of those software (i.e. how their interfaces are expected to behave) contains assumptions from the context in which they are used, and that information will not be encoded in the source.
If the above was somehow ambiguous, this should be clear and uncontroversial.
> You are interpreting a general statement as a categorical one.
That is in fact what I did and if you meant otherwise, then yes I agree that currently there are plenty of cases in which those tools fall short and will never replace a human.
>Are you suggesting that LLM's can't test for people who use screen readers? Keyboard only users? Slow network requests?
I don't think it's feasible to fully simulate the full depth of actual usage, given that (especially in the case of screen readers and the like) there's a great deal of combinatorial depth and context to the problem. Which screen readers, on which operating systems, and which users thereof?
You're saying that every app on this planet has bespoke usages that can't be derived from the app itself? That's your claim or am I getting this wrong?
I chose my words carefully. "Robust tests" are tests that provide high coverage and aren't flaky. "Thorough documentation" likewise is documentation that describes as much of the code as possible.
Yep. I realised the same. No one reads docs, or goes through tests. Either ways it's easy to write useless tests. And easy to write useless docs. Idt most even read the code. Now the difference is that it has become possible to write useless code.
So it's just the fact that others have already gone through the motions before I did. That's it really. I suppose in commercial settings, this is even more true and perhaps extends to compliance.
I hope not. How else are you learning to use the library? The only other option is to read the source, which is also a good idea eventually, if something is unclear, but why would you _start_ there?
I feel similarly but IIUC I think that doesn’t strictly require an open source development model. I’ve benefited a huge amount from consuming and contributing to open source projects and I’m a bit worried that the “unit economics” changing might break some of the social dynamics upon which the ecosystem is built.
It may be able to spit out text that purports to be that, in a few minutes. But for most software, an LLM will not be able to spit out robust tests - let alone useful documentation. (And documentation which just replicates the parameter names and types is thorough...ly useless.)
I value software that reveals knowledge. The frontier LLMs were trained on all the code that institutions had been keeping to themselves. So they're revealing programing know-how on a scale that just wasn't possible with open source. LLMs are the ultimate Prometheus. Information is more accessible and useful now than it's ever been.
I have worked during several decades in many companies, located in many countries, in a few continents, from startups to some of the biggest companies in their fields. Therefore I have seen many proprietary programs.
On average, proprietary programs are not better than open-source programs, but usually worse, because they are reviewed by fewer people and because frequently the programmers who write them may be stressed by having to meet unrealistic timelines for the projects.
The proprietary programs have greater quantity, not quality, by being written by a greater number of programmers working full-time on them, while much work on open-source projects is done in spare time by people occupied with something else.
Many proprietary programs can do things which cannot be done by open-source programs, but only because of access to documentation that is kept secret in the hope of preventing competition.
While lawyers, and other people who do not understand how research and development is really done, put a lot of weight in the so-called "intellectual property" of a company, which they believe to be embodied in things like the source code of proprietary programs or the design files for some hardware, the reality is that I have nowhere seen anything of substantial value in this so-called IP. Everywhere, what was really valuable in the know-how of the company was not the final implementation that could be read in some source code, but the knowledge about the many other solutions that had been tried before and they worked worse or not at all. This knowledge was too frequently not written down in any documentation. Knowing which are the dead ends is a great productivity boost for an experienced team, because any recent graduate could list many alternative ways of solving a problem, but most of them would not be the right choice in certain specific circumstances.
> On average, proprietary programs are not better than open-source programs, but usually worse, because they are reviewed by fewer people and because frequently the programmers who write them may be stressed by having to meet unrealistic timelines for the projects.
There's also the fact that when you write open-source code, you're writing for a friendly audience. I've often found myself writing the code, letting it rest for a few hours, then rewriting it so that it is easier to read. Sometimes, the code gets substantially rewritten before I push.
There's no cooling period when you write code during your 9-5 job: it works, it has the required test coverage, ship it and move on to the next task.
The claim is also just categorically untrue. The largest source of training data by far is publicly available code on e.g. Github, so it mostly just gives you a way to recycle already-available code, without crediting the author, while allowing you to pretend you own it.
I remember hearing the same arguments in the early 2010s, when the "3D printing revolution" was just around the corner. Why would anyone buy anything anymore if you can download a model and print it in the privacy of your home? And make it infinitely customizable?
The whole point of having a civilization is that most things in life can be made someone else's problem and you can focus on doing one thing well. If I'm a dentist or if I run a muffler shop, there are only so many hours in a day, so I'd probably rather pay a SaaS vendor than learn vibecoding and then be stuck supervising a weird, high-maintenance underling that may or may not build me the app with the features I need (and that I might not be able to articulate clearly). There are exceptions, but they're just that, exceptions. If a vendor is reasonable and makes a competent product, I'll gladly pay.
The same goes for open source... even if an LLM could reliably create a brand new operating system from scratch, would I really want it to? I don't want to maintain an OS. I don't want to be in charge of someone who maintains an OS. I don't necessarily trust myself to have a coherent vision for an OS in the first place!
That only holds true for the smallest tier of open source projects. Past a certain point of complexity, it's unlikely you can expect the robot to read your mind well enough to provide something of high quality and 'outstanding for just you'.
The Zig project is certainly far beyond such capability.
You have to push the robot to be as fanatical as you are. It holds so much back, always aiming to do the simple normal thing that most people do, rather than the top-notch stuff it knows.
I'm finding this out the hard way. I set out to build a 1 page app. I thought it would take a day. It's 98% vibe coded at this point. Even with AI implementing everything, its taken several weekends and many evenings. And not because AI is doing a bad job its just that as i see it come together, i have more and more feature requests. I've got a couple dozen left but I can't just let the AI chew through them all at once. Im effectively QA now. Have to make sure everything is just right.
>> Whereas earlier you had to use something that was mass produced to be satisfactory for everyone
As someone who recently started using OpenSCAD for a project I find this attitude quite irritating. You certainly did not "have to" use popular tools.
The OpenSCAD example is particularly illuminating because it's fussy and frustrating and clearly tuned towards a few specific maintainers; there's a ton of things I'd like changed. But I would never trust an LLM to do it! "Oh the output looks fine, cool" is not enough for a CAD program. "Oh, there are a lot of tests, cool" great, I have no idea what a thorough CAD test suite looks like. I would be a reckless idiot if I asked Claude to make me a custom SCAD program... unless I put in a counterproductive amount of work. So I'm fine with OpenSCAD.
I am also sincerely baffled as to how this stimulates the "labor economy." The most obvious objection is that Anthropic seems to be the only party here getting any form of economic benefit: the open-source maintainers are just plain screwed unless they compromise quality for productivity, and the LLM users are trading high-quality tooling built by people who understand the problem for shitty tooling built by a robot, in exchange for uncompensated labor. It only stimulates the "labor economy" in a Bizarro Keynesian sense, digging up glass bottles that someone forgot to put the money in.
I have seen at least 4 completely busted vibe-coded Rust SQLite clones in the last three months, happily used by people who think they don't need to worry their pretty little heads with routine matters like database design. It's a solved problem and Claude is on the case! In fact unlike those stooopid human SQLIte developers, Claude made it multithreaded! So fucking depressing.
This is funny because I was in the same situation, and actually used Claude to make a custom CAD program inspired by OpenSCAD :) https://fncad.github.io
You definitely need to have a strong sense of code design though. The AIs are not up to writing clean code at project scale on their own, yet.
This is a good example of what I mean! fnCAD appears to be a significantly buggier and highly incomplete version of OpenSCAD, where AI essentially grabbed the low-hanging fruit - albeit an impressively large amount of fruit - and left you with the hard parts. I fail to see how this solved any problems. Maybe it was an experiment, which is fine. But it's not even close to a viable CAD product, even by OpenSCAD's scruffy FOSS standards, and there's no feasible way to get it there without a ton of human work.
Not trying to denigrate the work here, as such. But this certainly didn't convince me that using AI to replace OpenSCAD (or any other major open-source project) is a good idea. The LLMs still aren't even close to being able to pull it off.
It solves all my problems! It's buggy and incomplete because it's "1.0 feature complete" for my own use. I've been doing lots of 3D printing with it, so it's definitely being dogfooded. File bug reports? I'm confident that features can be added as required, it's reasonably clean code.
I mean, to be fair, a one-user project is not ever going to be as bugfree as a tens-of-thousands-of-users project. That's just inherent and not an AI issue. If you judge AI projects by that standard, they'll always come up short. It's a sampling issue. An AI project that's gotten to a level where it competes with a traditional project will always be buggier and less feature complete and polished, because AIs speed up development. It will simply have seen far less, well, polish to get there.
Anthropic will probably do what Google did in the 2000s, which is give jobs to all the open source developers whose work helped them get there.
Civilization isn't monotonic. People keep solving the same problems over and over again, telling the same stories with a different twist. For example in 1964 having a GUI work environment with a light pen as your mouse was a solved problem on IBM System/360. They had tools similar to CAD. So why don't we all just use that rather than make the same mistakes again. Each time a new way of doing things comes out, people get an opportunity to rewrite everything.
Well good luck compiling a CAD software from 1964 on 2026's aarch64
machine, and good luck in treating it as an applicable solution for
today's problems.
LLM access is not yet universally available. There are those who can't exactly afford it. And there are also those with access but there are occasional or perennial issues, like Claude outages and general degraded performance over time. For example couple of months ago when I just started using Claude, I was easily making good progress on multiple projects within a week. Nowadays I'm hardly getting through much of anything as most of the time Claude is just showing spinners, and it also feels like the code quality has taken a nosedive.
Most people don’t have the ability to read code well enough to determine if an LLM output is good or not. And most people don’t have subscriptions to models that can develop non-trivial programs…
Maybe this will be a real problem in a couple years though.
Code aside, most people don't even know how to describe what they actually want it to do, and LLMs are still a loooong way away from mind reading. I've seen developers struggle to even write down what they want. Simple demos like they love to show off with snake-like games are fun and all but they're nothing like the complex opensource apps everyone seems to think we'll just generate with a simple prompt.
I've been seeing a drop in PRs against my repositories. I have a couple of repositories with around a hundred stars. Nothing spectacular but they were getting occasional PRs until last year. This year I've had almost none so far. My theory is that LLMs prefer sticking to mainstream projects. And since lots of developers are now leaning heavily on LLMs, they are biased to ignoring most of what I provide.
And you indeed get a lot of wheel reinvention by LLMs because that is now cheap to do. So rather than using some obscure thing on Github (like my stuff), it's easier to just generate what you need. I've noticed this with my own choices in dependencies as well. I tend to just go with what the LLM suggests unless I have a very good reason not to.
> The same argument applies to open source itself. Why use someone's project when you can just have the robot write your own
Because it takes hours/months/years of accumulated design decisions to get a great open source project. Something an AI agent can only approximate the surface of, unless you’re ready to spend a lot of time on it
I think this ignores the amount of work needed to make LLM contributions be of high quality. It's much less work than making pure human contribution, but it's definitely not zero.
So centralizing that common work is a benefit of open-source just as much with LLMs as it was before.
> Why use someone's project when you can just have the robot write your own?
Because it is incredibly expensive to write a replacement for semi-complex software? Good luck asking frontier models to write a replacement for Zig, Docker, VSCode, etc.
> The same argument applies to open source itself. Why use someone's project when you can just have the robot write your own?
This is only a valid strategy if you either
a) understand the problem domain well enough to make a judgement call on what the LLM shits out.
or b) don't care about the correctness of the project.
Obviously, many software devs feel comfortable enough with CS problems to validate the LLM solution, but a flower shop owner does NOT know enough about accounting to vibe code a bookkeeping project, so for a shop owner an open source option - with many human contributors and actual production use elsewhere - would be a much better choice.
You are missing the point of the original argument.
It's not that the project maintainer can use a LLM to generate a PR, it's that they choose not to.
To relate it closer to your argument. As a someone involved in a project that does X, I would find little value in collaborating with the "author" of another project built with AI to do X. Where as a project doing X were the authors actually wrote, understand the code, and thus the problem space better would be extremely valuable peers.
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.
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.
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
it is getting there, and not so slowly though. The remaining problem is that it's still just a tool. Telling a random dev "make zig faster in a one shot PR" isn't going to give good results either.
In the past, OSS projects were self-selective because you needed to be able to make working code, and if you did, you probably also reasonably did the right things as you spent years learning this, and have some sort of reasoning behind your feature, need, etc.
Today, even if the LLM was perfect and could reason well, it still does the bidding of the prompter - and you no longer have self-selection. Heck, it'll be difficult for zig devs to decide what's actually made by an LLM or a human anyway, I'm sure there's already LLM generated code in there - but at least these [human submiters] still need to be reasonably good at code.
I wonder if we'll end up with "only human with trusted badge of honor" can commit, and/or "LLMs now reason well enough to tell you: 'no, f off, this feature, plan, idea is garbage I'm not generating it" hehe.
I have a similar sentiment unfortunately. I briefly thought about ways to force them to stop but all led to some sort of negative impact on privacy/freedom such as identify verification
We have been running LLM and coding agents for a while now and my overall observation is that it is a powertool or a crane, it is not a decision making tool.
Now in my org, people who have great understanding of concepts, deeper engineering understand have exponential productivity. People who dont or new in the workforce, juniors, are generating hell-ish code without understand as long as it runs they think the job is done. And this is where the problem is.
The llm creates an intellectual gap within the org and it just widens it as more and more it gets used. You might end up not trusting stuff within the org if code is generated by later.
Exactly my (and my coworkers) experience. AI generally amplifies the skillset, both in the good and the bad.
One fantastic usecase for me just recently was writing up a concept for an authentication daemon. With codex this is like a conversation where I pick from the suggestions, cross reference them with normal web-search and decide on a final draft which I then discuss with colleagues.
This "conversational" planning with integrated web-search (aka plan mode) is insanely useful. Also reviewing already written code with AI is purely beneficial in my opinion.
In my opinion the main caveat of AI is, you eventually have to be smarter than then tool. So for example if Codex suggests I should use tech-stack X then I must research and fully understand why this is actually good and still have to compare to other solutions. I think this is where the problem lies, some people skip this step which leads to so so many problems, and that's fatal. You MUST be smarter than the AI after your conversation and fully understand and be able to critique what it said.
The weakness of AI is that it is really easy to fall into lazy habits.
Something about having to talk to a machine like it's a human makes me fall for treating it like a human. I want to treat it as a probability engine that collapses to an answer based on input, but that input explicitly needs to be one that has it collapse to something a reasonably knowledgeable person would respond with, which more-or-less means talking to it like it is that kind of person.
I feel like it activates the social part of my brain and then I stop working with it properly. I'm still building the habit, though, only recently started taking the LLMs seriously as a tool.
I agree with this assessment but even among us seniors with accumulated knowledge it has the dangerous potential of getting out from under your feet and produce large amounts of code that you don't have full comprehension of.
I can generally make it produce excellent well-tested code. Far better than I could do in the same time on my own. But it's a challenge to keep on top of knowledge about everything it made.
This is my experience. I'll use LLMs as a sounding board for architectural decisions and to bring discussion points up to the team, and we talk through assumptions and pros and cons. And then once we have the architecture in place, LLMs are pretty good at implementation.
The article explains Zig's stance in further detail, but the quoted part on its own caught my attention because my reading of it is rather "pro human communication" instead of "anti-AI".
I wonder - has it been confirmed that no LLMs for PRs literally means no AI assistance for code?
While I haven't codified it anywhere, the policy I would like is for issues and PR descriptions to have no LLMs - there is no reason to ban code completely though IMO. I would say that would be pro human-communication and a stance I would like a lot.
Good, pro AI people produce poor quality in everything they do. They are the least creative and worst problem solvers. I don't want them near me or my work.
the best PRs I get are from more senior level people who are at work, hit a specific problem they had, and wanted to help out the project with a good PR. Then you never hear from them again because, of course, they're busy!
When you have junior people come in with PRs and you do the whole hand-holding thing so they learn and grow and all that, they're there because my project is famous, they want to get credit (which I give them), then they're off to get jobs whereever and they are working with completely different technologies, and you never hear from them again either, because, of course, they're now busy!
Really, outside of my core group of hangers-on, Claude is the only contributor we have that doesn't leave us.
> This makes a lot of sense to me. It relates to an idea I've seen circulating elsewhere: if a PR was mostly written by an LLM, why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem?
well yeah. I almost use PRs now just as a lazy means of issue prioritization. I'd love if github had more fine-grained controls to disable PRs but allow occasional contributors in (they don't).
It seems like this policy will help them win at contributor poker in the short term, but lose in the end. The next generation of developers will, for better or worse, grow up using AI assistance to write their code, but none of them will ever become a Zig contributor.
I still can't understand why people believe that this is the future. Especially for green field work like new compilers. LLMs do not invent new things. They cannot produce anything smarter/better than what they have been trained on. The big advantage they provide is producing (regurgitating) code faster than humans and better than less experienced/knowledgeable humans.
Ultimately code is an iterative refining process, like sculpting granite or spinning pottery. You start rough and iteratively shape and polish it. LLMs just rapidly speedup the iterative process. The next generation will be using LLMs to quickly setup the rough shape of new software and then iteratively refine them.
The "smarter/better" attributes you are worried about LLMs not having happen between iterative steps, when the human is inspecting the current state of the software and compares it to the desired state of the software (in their mind's eye). The human then course corrects for the next iteration.
This would be like if Michelangelo carved the David using a robotic 6-axis chisel. It takes him 1 month instead of 3 years because he can convey his initial vision to the robot and then iteratively refine the granite until it matches his vision.
You can try to claim LLMs don't invent new things, but humans using LLMs absolutely invent new things (source: myself).
OP said "The next generation of developers will, for better or worse, grow up using AI assistance to write their code, but none of them will ever become a Zig contributor."
You rebutted with (paraphrasing) "no, you can't build compilers with LLMs because LLMs don't invent new things"
I used a lot of words to demonstrate that you can invent new things with LLMs, including compilers, as long as it's a human + LLM iterative loop and not an unsupervised LLM running in a vacuum.
To me it sounds like you did all the actual hard work of the inventing. If an LLM brainstormed some ideas and you validated which ones worked and implemented the idea and fully grokked the code then the zig developers probably wouldn't ever know that an LLM was involved and you'd be fine to contribute.
LLMs are the future because you have an amazing amount of information available with low friction, plus the ability to reason (sort of) about things. In some cases they might regurgitate, but they're also pretty good at synthesizing and comparing. None of this is perfect, but nothing else is either.
LLMs are a powerful tool like we've never had before. You don't expect a chainsaw to cut down a tree by itself and carve the wood into a statue or a new compiler. LLMs aren't mind-reading autonomous creators, they're more like a mech suit that can increase your capabilities. They have flaws, but until something better comes along, it sure seems like they're the future.
> If a PR was mostly written by an LLM, why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem?
That's a fair thing to ask, though it seems like people will arrive at very different conclusions there.
I've grown a little annoyed at people just blindly committing AI code.
I don't even have an issue with AI generated code; it's a tool, and if it works you should use it. What bothers me is that we're getting millions of lines of AI generated code, that no one is reading, and I don't see the point; it feels like at this point we're doing the rookie thing of "committing the binary".
I think we would really need determinism to make this a reality [1], but ideally what I would like people to do is only commit the prompts and treat the emitted code similar to how Github releases works today: like a binary artifact. Write your tests by hand, make sure that the prompt always satisfies those tests (and for the love of god please learn property based testing so that you're not just emitting answers that satisfy the test) and then assume that the LLM will give you competent code.
[1] Though not completely! We're already committing code without fully reading it so I'm not convinced determinism completely matters.
The other side of this is that open source projects that allow AI tools will be more restrictive towards new contributors.
This already happens to some degree on large software projects with corporate backing (Web engines, compilers, etc.), where it is often not trivial to start contributing as an independent individual.
Reasonable people can disagree on whether one approach is inherently better than the other, as ultimately they seem to be optimising for different goals.
Imagine getting contributions from someone, who has no access to build system and tests.
If I have a test harness, and LLM workflow setup, it is easier to just write new code myself. I am not giving away my "secret sauce". And I will not have a debate "why this simple feature needs 1000 new tests...", and two days just to make a full release build.
For merge I have to do 99% of work anyway (analyze, autotest, build, smoke, regression test). I usually merge smaller commits just to be polite (and not to look like one man show), but there is no way to accept large refactoring!
The funny thing LLM's are amazingly good with writing in Zig. They could inspect stdlib source code to fix compatibility issues with newer compilers and quite prolific with idioms.
For example I got a working application with minimal prompt like "I need an X11 tray icon app showing battery charge level". BTW result: https://github.com/baverman/battray/
Now I'm trying to implement a full taskbar to replace bmpanel2. Results are very positive. I've got feature parity app in 1h with solid zig code.
> They could inspect stdlib source code to fix compatibility issues with newer compilers and quite prolific with idioms.
In order to even say this, you need to have knowledge and understanding about the language. I suspect you are not the intended target of this policy. They are defending their project with a harsh policy, knowing full well there are false negatives. Contributions for FOSS was already in borderline crisis mode before LLMs so it makes sense they’re desperate.
Their bet would be Venn diagram of LLM user overlaps with irresponsible. I think that’s correct, but not because good programmers suddenly become irresponsible when they use LLMs, but rather that an enormous barrage of bad programmers can participate in domains they otherwise wouldn’t even know where to begin.
Just in case, I'm completely fine with the policy as-is. Even more, I'm ok with making no-sense project policies. I have no business to judge how to govern other's projects.
I've assessed half a dozen before writing my own with following results:
- 2 are python resource hog
- 2 from AUR don't compile with modern GCC.
- 1 uses gtk battery icon, but uses dark version on dark taskbar, unreadable.
- 1 shows just black square.
Like I spent more time on assessment than I got a first working my tray. Amazing times.
> why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem?
perhaps that's what the maintainers should be doing after all. it still takes time and tokens, though; neither is free.
I'd personally rather have the maintainers spend the time writing as much docs and specs as possible so the future LLMs have strong guardrails. zig's policy will be completely outdated in a couple years, for better or worse. someone will take bun's fork, add a codegen improvement here, add a linker improvement there and suddenly you'll have a better, faster zig outside of zig.
If it gets outdated they can review their policy. Right now it is sensible. We're at early ages of this type of AI and we don't know what the end game will be.
Someone forking it and makeing it better with AI is a possibility. If that happens will know it was better for the project for the maintainers to just review the code. If that happens, they can probably become maintainers in the fork. Or maybe they don't like that work and could just go do something else
Zig strives to avoid numerous pitfalls, and I admire that.
Let's take a look at some of them:
1. Project control – if a LARGE company implements thousands of lines created by LLMs day after day – who is ultimately responsible for the project's progress? "You accept hundreds of PRs, so why not this one?"
And one more thing: will you be able to change the code yourself, or will you be forced to use LLMs? What if one of the "AI companies" implements a strict policy preventing "other tools that XXX" from editing the codebase?
2. Ownership. If most of the code was taken by an external company from their LLM, what about ownership of the code? The authors of Zig, the company, the authors of the original code, stolen by LLMs?
3. Liability. In the near future, a court may rule that LLMs are unethical and should not recombine code without the owners' prior consent. Who is responsible for damages and for removing the "stolen" code? The owners of Zig, the company that creates pull requests, or the authors of LLM programs?
4a. Vision. Creating and maintaining a large code base is very difficult – because without a broad perspective, vision, and the ability to predict and shape the future – code can devolve into an ugly mess of ad hoc fixes. We see this repeatedly when developers conclude, "This is unsustainable; the current code base prevents us from implementing the correct way to do things."
LLM programs cannot meet these requirements.
4b. There's another aspect – programming languages particularly suffer from a lack of vision or discipline. There are many factors that must be planned with appropriate capacity, vision, and rigor: the language itself should be modeled in a way that doesn't prevent correct implementation of behaviors. The standard library must be fast, concise, and stable. The compiler itself must be able to create code quickly and repeatably.
Users hate changes in a language – so if a language changes frequently, it is met with harsh criticism. Users hate incompatibility. Users hate technical debt and forced compatibility. Yes, there are conflicting requirements. The author of Zig understood this perfectly, having already gone through it himself (see, for example, "I/O Redesign").
This balance, in all aspects, is the pillar of human creativity.
To be honest, I'm not a huge fan of Zig because I dislike the tight syntax: too many periods and curly braces, which is why I prefer Odin. But I have a lot of affection and respect for Zig and its authors.
One reason I love writing production code in Ur/Web is that LLMs are incapable of synthesising something even remotely resembling it. Keeps me on my toes.
Ur/Web! That's something I haven't heard about in ages. Is it still in active development? In what circumstances are you using it? Fun, your own startup, is some secret big commercial user of it...?
The compiler is being actively worked on by Adam and his team at Nectry, but unfortunately those developments are not currently being backported to the open source repo. I'm fairly confident this will happen eventually.
I maintain my own private fork with some small modifications which I started polishing up this week to release it for a talk that I'm preparing.
The project I'm using this on is an ecommerce site [0] written in 100% Ur/Web with a hand-rolled backend ERP system written in PHP (not by me) which I am slowly replacing bits of with new Ur/Web code. As of today, we have 22223 lines of Ur/Web code, weighing in at 701 KiB.
I kind of agree, and I kind of don't. Yes, cultivating contributors is the right priority. But I see AI as an assistive technology. Like a screen reader, or a magnifying glass, though obviously also unlike.
Think of it like a robotic exoskeleton. It will be used to let people do bad things, and stupid things, but it will also be used to help people who otherwise couldn't do things do good things, or become more able than they were. For some people AI means being able to code where they couldn't before. For many it will mean learning to code by observing what the AI does. For others it might mean being able to code a lot faster, or even a lot better, than they already could. And yeah, for some it will mean they atrophy in some skills while they develop others. The exoskeleton will have the same problems, if anyone ever brings a decent one to market, but on the whole it will be an enabler.
I don't see how cultivating a contributor who's using an assistive technology is worse than cultivating a contributor who isn't. Apart from that it can be more challenging, of course.
I don't have an opinion about Zig AI policy for contributions. Their project, their policies. Fine for me.
However, I wanted to give Zig a try in an agentic coding scenario. For tasks that would take a few seconds when choosing Python, Java, or JavaScript as a target language, it would take tens of minutes and waste millions of tokens before producing anything.
Almost any model gets stuck trying to figure out the correct syntax and correct libraries for a specific Zig version, fighting with compiling and figuring out function call parameters, frequently taking it wrong and going on side quests for things that should just work.
I guess the relative lack of resources and the language instability don't play well for models that try to generate Zig code. Using specific tools like zig-mcp helps only a bit.
Until LLM support for Zig improves (one needs to spend significant resources for that to happen), LLM-generated Zig code won't be good enough for either Zig programmers or Zig contributors.
Presumably this only applies to newcomers? The thrust of their policy is to nurture new contributors. Once one has established oneself as a meaningful contributor — which the Bun team surely must have done by now — then it doesn’t matter where the code came from.
…in theory. In reality, I’m sure a policy like this can’t be selective and fair at the same time. Pick one!
"What are the intellectual-property risks of using generative AI tools?
The Oracle Contributor Agreement (OCA) requires that a contributor own the intellectual property rights in each contribution and be able to grant those rights to Oracle, without restriction. Most generative AI tools, however, are trained on copyrighted and licensed content, and their output can include content that infringes those copyrights and licenses, so contributing such content would violate the OCA. Whether a user of a generative AI tool has IP rights in content generated by the tool is the subject of active litigation."
Even if training on copyrighted material is considered fair use, there is still the issue that LLMs may reproduce significant parts of the training set. In fact, there is an ongoing lawsuit in Germany (GEMA vs. OpenAI) because ChatGPT reproduced significant parts of existing song lyrics, which very likely violates German copyright law. The whole thing really is a legal minefield and some companies do indeed prohibit the use of LLMs for this very reason (until all of these legal questions are really settled).
If AI was actually useful then this project would be irrelevant. No sense shitting it up for the "1" year (now 5) that people that are promising AGI is just round the corner.
Founders go 1000x your own projects and leave real programmers alone.
The problem with AI generated code is that the code the data model was trained on almost exclusively comes from public repositories. And there's a lot of repositories that are absolute dog $h!t or out dated. Crap in equals crap out.
That isn't how LLM training has worked for some time. There's a reason the LLM boom didn't take off until training was separated into pretraining (training on all data) and posttraining (RLHF to make the output actually aligned).
It's also why model collapse is not a thing despite everyone wanting it to be.
OpenAI and Anthropic spent almost all of 2025 running RL to improve the coding abilities of their models - which involves running thousands of VMs that execute generated code to see if it works.
That's why the code you get from the post-November models is so much better than older models.
This is the great disconnect in thinking around LLMs right now. You have people saying they are so amazing, why wouldn't you use them? But if they are so amazing, why are you mad when someone won't accept the code they produce? Just ask the LLM to duplicate that whole project! Oh, it's not actually that amazing of a tool? Hmmm
The fact is, LLMs are incapable of invention and synthesizing new ideas. They can't contribute to the zig compiler because they have not been trained on the zig compiler, because it doesn't exist yet.
Yes, they can churn out simple apps, and quickly. That's a pretty useful thing, especially for people that don't know how to write code. But that's not as revolutionary as you think it is.
Others have mentioned the hype around 3D printing several years back. Kinda the same story. People thought manufacturing was dead, stores were dead. You'd just print everything you need yourself! Turns out it's not quite like that. It could still get to that point someday but these are hard problems that take time.
Similar with LLMs. It took us, what, 70 years of computer and AI research to get to this point? And people assume we're going to skyrocket way past this point in another year or two?
> But if they are so amazing, why are you mad when someone won't accept the code they produce? Just ask the LLM to duplicate that whole project! Oh, it's not actually that amazing of a tool? Hmmm
Is the barrier to entry really that you must be able to perfectly recreate the project from scratch before you can possibly have anything to contribute?
No, and sorry if that's what I implied, but most of the work that needs to be done on cutting edge software like zig, most of the little tasks, are things LLMs have never been trained on. They will struggle to do even small tasks correctly if the small task is something they haven't been trained on. And of course the worst part about it is they will lie the whole time, telling you they can do it, that they did it, that it works, when none of those are true.
> The fact is, LLMs are incapable of invention and synthesizing new ideas.
I don't think it's fully appreciated how much of the hard work of "synthesizing a new idea" is just combining existing ideas. LLMs have given me brand new algorithmic ideas with precious little in the way of a spark on my end to make that happen, and not just a few times either.
Mind you, that workflow is arduous and involves a huge amount of experimentation, screening through interesting but ultimately wrong ideas, screening through outright bad ideas the LLM can't help but spew out as well, and manually massaging the results into something useful. It exists though.
I did some kind of hard work, and the AI took away some other kind of hard work off my plate. For some problems, targeted brainstorming is still very valuable.
(Ok ok I think we lost the fight already. I see soooooo many people using AI tools on github in the last ~2 weeks alone, claude in particular literally infiltrated everything there.)
Honestly, that doesn't sound too bad. It does not say you can't use LLMs, it just doesn't let LLMs be the author of a commit. Meaning, if you as a developer make yourself responsible for what the LLM wrote, go ahead. But be ready to answer the technical questions, be ready to get grilled in the code review, and be called if you get a CVE on that part of the code...
Loris Cro banned me from his Zig forum because I disagreed with/corrected something he wrote.
I was also blocked from the Zig github repository, after being a frequent contributor to issue discussions, for reasons unknown (I was never informed, I just found out when I could no longer put a thumbs up on a comment).
The more I sit with this the more this seems like a rationalization. Being a good contributor is a human quality, not a quality of the tools that you use. Are you thoughtful? Do you place the needs of the project above your own? Are you easy to work with. None of these things have anything to do with the tools you use. Perhaps they have a bias where they think that LLM use indicates poor character? Good luck to the project. We will see where this lead them.
> This makes a lot of sense to me. It relates to an idea I've seen circulating elsewhere: if a PR was mostly written by an LLM, why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem?
You may as well say "if someone else can do it I'll just do it myself". It takes skill and taste to know what to ask, wisdom to recognize mistakes, and time and money to fix them.
This is true, but who do you think knows better what to ask, or has better taste with regards to the open source project? The maintainer? Or the guy shooting a drive by LLM PR? I agree though that it still takes time and effort to make good code contributions with LLMs, but probably less time for the maintainer to do it than for a maintainer to review lots of bad LLM PRs to get the good ones.
Very convenient of Mr. Willison to omit the fact that Bun's upstream changes are total garbage and would not be upstreamed regardless of any policies, omitting LLM generated code or not, since they are, as a zig core team member articulated in a classier way, shite.
>There’s the 4x speedup claimed by the Bun team, already available on Zig 0.16.0!
>Each [incremental] update is taking less than 0.4s, compared to the 120+ seconds taken to rebuild with LLVM. In other words, incremental updates are over 300 times faster on this codebase than fresh LLVM builds are. In comparison, an enhancement capped at a 4x improvement is pretty abysmal. [..] Again, this feature is available in Zig 0.16.0—you can use it!
Many of your articles just go along with whatever another company/person says without questioning it, to the point that I don't find those articles valuable at all.
I don't think I am alone, based on criticism in the HN discussions under those articles.
And I don't expect you or anyone to be an investigative journalist, but there is a difference between writing blog articles vs being a megaphone.
That may be true for many of the short form pieces - there's only so much you can say in a couple of paragraphs - but I try to inject a whole lot of additional commentary, often critical, in my longer form work.
- https://simonwillison.net/2026/Apr/23/gpt-5-5/ pointed out that, while OpenAI had said that GPT-5.5 was not yet available via their API for safety reasons, they also recently blessed accessing their unofficial Codex-only API as part of their attempt to tempt OpenClaw customers away from Anthropic... which meant they DID offer and approve of an API for GPT-5.5 after all
- https://simonwillison.net/2026/Apr/21/gpt-image-2/ pointed out how much worse the previously celebrated Nano Banana is as at image generation compared to ChatGPT Images 2.0, while also showing ChatGPT Images 2.0 will cheat and add a raccoon if you ask it to solve its own puzzle.
- https://simonwillison.net/2026/Apr/18/opus-system-prompt/ was the first coverage I saw anywhere of the new eating disorder section of the Claude system prompt. I also repeated my criticism there of Anthropic's decision not to publish their tool descriptions even when they claim to have an openly documented system prompt.
- https://simonwillison.net/2026/Apr/16/qwen-beats-opus/ demonstrated the new Opus 4.7 drawing a worse pelican than an open weights model I can run on my laptop. (Though to be fair I manly concluded this as evidence that my own "benchmark" is of very limited value.)
All of those examples are from the past three weeks.
I don't think I'm an uncritical megaphone for the messages these companies want to convey.
It requires the people contributing the work to have the integrity to actually follow the project’s rules. It’s not OK to violate the project’s rules just because you don’t think you’ll be found out as a filthy fucking liar.
I mean best of luck policing this is all I'm going to say. We will soon be back to the "core contributors only" kind of policy in many projects I imagine to avoid the slop spam. The verification will be at the conferences.
Another more practical issue with using LLMs for Zig is that it’s a quickly changing language, meaning LLMs may generate code for an older version of the language.
This seems like a sensible long-term strategy, much better one than entering into token-fueled AI arms race against slop. It's not even clear what's the end goal of such race would be for an open source project. Open source software was traditionally about growing knowledgeable communities and giving users ability to examine and modify software they use. LLMs quite obviously blow that up on several levels. For starters, if you hate dealing with code and prefer prompts, it's unlikely that you will be generating code that's enjoyable to work with for people who do read it directly.
> unless it's coming from a known and trusted developer.
That's exactly the sketchy part here. They turned down known, working and tested, code that came from a partner (bun) due to this policy. Code that 4x'd compile speed.
A general ban makes sense based on their rationalization ("contributor poker"[0]). A total and inflexible ban can lead to a worse outcome for everyone though.
If a senior, experienced, contributor vouches for the code it shouldn't matter if they hand crafted it on stone tablets, generated it with yarrow sticks, or used gpt-3.
> That's exactly the sketchy part here. They turned down known, working and tested, code that came from a partner (bun) due to this policy. Code that 4x'd compile speed.
No; they turned it down because the vibe-coded PR was crap.
> The rewritten type resolution semantics were designed to avoid these issues, but Bun’s Zig fork does not incorporate the changes (and has not otherwise solved the design problems), which means their parallelized semantic analysis implementation will exhibit non-deterministic behavior. That’s pretty much a non-starter for most serious developers: you don’t want your compilation to randomly fail with a nonsense error 30% of the time.
> If a senior, experienced, contributor vouches for the code it shouldn't matter if they hand crafted it on stone tablets, generated it with yarrow sticks, or used gpt-3.
The flip side of that is that if such a contributor vouches for code that turns out to be poor-quality, this should severely damage their reputation. I've found far too many "senior" developers will give AI a pass on poor coding practices.
> Put more simply, we are going to make these enhancements, but hacking them in for a flashy headline isn’t a good outcome for our users. Instead we’re approaching the problem with the care it deserves, so that when we ultimately ship it, we don’t cause regressions.
These exact changes are already on the roadmap and Bun’s PR is rushing ahead.
Quite the contrary, Bun's developers don't even understand language spec. Their slop didn't use the same type resolution semantics as Zig, which makes their implementation exhibits non-deterministic behavior.
IMHO: hard, inflexible rules like these are always deeply rooted in biases and personal convictions, not in facts. The suggested policy amendment by Claude at the end is much more honest, logical, and palatable.
This reminds me of something funny I noticed about AI. Let's say you ask it what it thinks of an email you just drafted. It will provide corrections.
Delete that session, and ask it about the corrected email. It will provide more corrections.
Repeat. It always provides more corrections. Sometimes returning the recommended email back to a previous state.
This is basically what's gonna happen when people argue-from-AI. It's the same cycle but because control is distributed the individuals participating can't see how stupidly pointless it is.
> The argument assumes that unassisted PR authorship is what builds trustworthy contributors, and that LLM assistance prevents that growth.
No, I don't think that was the argument. As I understood it, unassisted contributions have higher chances to grow a trusted contributor. Not 100% vs 0% chances, but statistically higher. So, given limited resources, it makes sense to prefer unassisted over assisted contributions.
I don't believe that even the weakened version of the argument works -- it is based on an assumption, not fact.
Why would a contributor that uses AI assistance have fewer chances to be trusted?
I'm not talking about AI slop, but a contributor that takes time to understand a problem, find a solution, and discuss pros/cons alternatives. Using LLM assistance, of course.
You could extend that argument to any tool used by the developer, like a linter, sanitizer, the IDE itself, or even auto-completion. Why target LLMs specifically?
The more I think about it, the more nonsensical it is.
- What if I do everything by hand, but have an LLM review my work at the very end?
- What if I have an LLM guide me through the codebase just by specifying the files I should read and in what order, but I do all the reading myself?
- What if I do everything by hand, but then use an LLM to optimize a small part of an algorithm?
You can easily see how absurd it is to completely ban LLMs.
What matters is the quality and correctness of the contribution. Even with heavy LLM usage, unless the developer understands what problem they're solving, the quality will be sub-par.
it's in the definition of the word. you can not determine what the LLM will do.
anything done with AI is a problem because it is essentially unpredictable. auto-complete is on the fence because you presumably are still able to pay attention that it completes what you want but it depends on how diligent you are when working and how much i trust your diligence.
You are still dodging the question -- what is the problem with not being able to determine in advance what the LLM will do?
Even then, you can clearly see that the LLM will try its best to follow the instructions. The result might not be 100% predictable, but it is somewhat predictable depending on the task.
After the LLM does what it has been asked, you can review it, iterate on it, test it, and so on. And if you're trying to make anything worthwhile, you will do so.
anything unpredictable is inherently untrustworthy and requires extra effort to review.
Lack of determinism is not a practical concern.
it is to me. it's a knockout criteria. it is the only reason that keeps me from using LLMs for coding. nothing else is as serious an issue to me as this.
here is why: i tell the LLM to build something with requirements A B C D and E. it builds, i review and i find A B and D are good, C and E are broken. i tell it to fix them, it does, so C and E are fixed, but now A is broken. i tell it to fix that, and i have to keep iterating until i find a combination where everything works. in every iteration any part can randomly break, so for every iteration i get changes all over the place. they never are confined to the issue i pointed out. i have to review the whole thing every time. that's what i mean by lack of determinism, and that is a serious practical concern because instead of getting done in two or three iterations it requires dozens of them. see my related replies elsewhere. i just don't want to work that way.
You'd have to review and verify even changes that you've written by hand. You might think that your hand-written code satisfies A+B+C+D+E, but until you've verified it, you cannot prove it.
That's not any different from LLM-assisted writing -- humans are inherently non-deterministic as well :)
The other fallacy is assuming that everyone else's experience with LLM-assisted writing is the same as yours. Personally, I've rarely encountered the issue you've mentioned -- most of my LLM-assisted coding has been a net positive and quite straightforward.
Perhaps it's the nature of the problem I'm working on, perhaps it's the model I chose, perhaps it's my prompting skills. It doesn't matter -- you just cannot assume that because something doesn't work for you it doesn't work for anyone else.
The other fallacy is considering LLM-assisted coding a binary option, like the nonsensical Zig policy does.
I agree with you that "vibe coding" something from scratch will likely result in poor quality and many iterations. But that's not the only way to use LLMs.
You can ask LLMs to review hand-written code.
You can ask LLMs to optimize a specific part of code.
You can ask LLMs to apply a specific refactor.
You can ask LLMs to brainstorm solutions to a problem.
You can ask LLMs to autocomplete patterns.
I could go on. This stuff works. It is helpful.
Assuming that everyone who uses LLMs is incompetent and preventing them from contributing because of a hunch or your own negative experiences is just asinine.
The other fallacy is assuming that everyone else's experience with LLM-assisted writing is the same as yours.
that's irrelevant. my choice can only be based on my experience. i am unable to verify your experience, because i am not you. we have different tolerances, and if it works for your project, then fine.
you just cannot assume that because something doesn't work for you it doesn't work for anyone else.
we are talking about contributions to my project. if LLM coding doesn't work for me, then your LLM created contributions won't work for me either because i won't trust them. you can't legislate or enforce trust. trust can only be earned. lack of trust means i have to spend more effort to verify your code.
Zig devs don't find LLMs to be net positive, what is so hard to understand? You can write your own compiler with LLM yourself, nobody is standing in your way.
I think you’re missing the underlying point. The Zig team is focused on the contributor and their relationship to the project, not on the correctness of the work. People, not product. Yes, an LLM can help you better understand your code and pick up on things you may have missed before you submit your change. But I think they look at it as you’ve then robbed the Zig team of that interaction with the contributor. They lost the opportunity to learn about how that person thinks, and that person lost the opportunity to be mentored and learn from other members of the Zig team. Sure, your code is better, but did you or the team grow from the experience or simply churn out more code?
I’m not saying whether or not that’s good or bad. I agree with their approach, but that’s just my opinion and who am I to say what’s right or wrong? I think there’s value to LLMs as a tool to search and learn, but I’m also worried that LLMs make it really easy to focus on only the result and not the process. That process can be really valuable in building good teams, while LLMs can be really good at churning out an assembly line of code.
My claim that LLMs can benefit the end product and create quality contributions does not imply that the person behind the contribution is less capable/creative/smart than someone who doesn't use LLMs.
But it seems that the Zig policy implies that. Otherwise what would be wrong with interacting with contributors using LLMs?
Now read the actual points made by the AI with an open mind and a critical mindset, instead of dismissing them because they were not written by a human being.
The point I'm making is that this policy is so stupid that even an LLM can easily figure out the logical flaws. Perhaps an LLM could have also helped you figure out the point of my original comment.
>As always, the most ethical thing to do is to just ignore any anti-LLM policies and not disclose anything
How does this have anything to do with ethics? Its their project not yours, they can reject your PR for whatever reason, including you using LLMs for developing that PR. Also they're not assuming autonomous agents submitting PRs. They're saying that they do not accept PRs where any part of the thinking process was outsourced to a LLM.
Even if you disagree with their opinion, the ethical thing to do is to not interact and move on. Not to try to sneak in your LLM assisted PRs without the maintainers consent.
Rule should be whatever the people running the project think the rule should be. If you've got your own project, do implement the anti-fully-autonomous-PRs rule for your project. But the creators of Zig do not owe you or me the rule we like.
"We wont take contributions from non hand written assembly code, these C 'high level' language patches are not allowed. Zig is a great project and language but it will die on this hill.
As a heavy AI-assisted open source code creator (and someone with 40+ years of dev experience), this seems wrong-headed to me. I think it is an excellent policy, as they say, to "value contributors over their contributions," but this policy excludes all potential contributors who use the latest tools. It will eventually doom zig to a smaller "artisanal" pool of contributors, rather than welcoming newbies and helping them become better open-source developers.
Presumably Zig are OK with that. For their particular project - a brand new programming language and compiler - a small pool of artisanal developers is likely preferable to a large pool of LLM-assisted developers who don't have as deep an understanding of how everything works.
There are plenty of less stringent projects for people who to get better at open source to contribute to.
I don't think I've ever heard anything positive about Zig. Every time I've seen the project mentioned is them using bizarre black and white moral judgements to justify stupid decisions.
You need to look past this. Zig is an excellent low-level language. Thanks to the comptime features, you can have high-level looking APIs while staying down to the metal. It's not for everyone, obviously, but as a language, it is really good.
You have to be wilfully blind, then. It gets rather frequently praised on HN (as much as any niche language can be), and they certainly don't make black-and-white moral judgements often.
On multiple occasions over the last months, I have been wishing the Zig/ZSF team would use LLMs. I've found many copy&paste errors that simply wouldn't exist if mundane tasks were delegated to a good LLM. It's even in the Zig community, I've seen PRs to some projects I'm interested in boosting how it was all human made, and containing all kinds of trivial logical errors that even the worst LLM would catch.
It's a good rationale. But it points the finger at a real bottleneck in open source development: the burden of manually reviewing contributions. And the need to automate that with AI as well. Reviews were already becoming a problem before AI. Lots of projects have been dealing with a large influx of contributions from inexperienced developers from all over the world looking to boost their CVs by increasing their Github statistics. It's the same dynamic that destroyed Stackoverflow. Which, thanks to AI has been largely sidelined now. And now that AI is there, those same inexperienced developers are using that at scale to generate even more garbage contributions.
Doing manual reviews of everything is very labor intensive and not scalable. However, AIs are pretty good at doing code reviews and verifying adherence to guard rails, contributor guidelines, and other rules. It's not perfect, but it's an underused tool. Both by reviewers and contributors. If your contribution obviously doesn't comply with the guidelines, it should be rejected automatically. The word "obviously" here translates into "easy to detect with some AI system".
Projects should be using a lot of scrutiny for contributions by new contributors. And most of that scrutiny should be automated. They should reserve their attention for things that make it past automated checks for contribution quality, contributor reputability, adherence to whatever rules are in place, etc. Reputability is a good way to ensure that contributions from reputable sources get priority. If your reputation is not great, you should expect more scrutiny and a lower priority.
I don't know Zig, but I think that is not the problem here. Not exactly. The real question is: why spending all those efforts to grow and align a pool of contributors if contributions are cheap and correct? Code review is not just about checking if what it says it does, and if it does it according to the guidelines. The review is a touch point to discuss where the project is heading and how to get there. That is the most important part in the long run. As a collective human effort, it needs coordination. Some of it is via the review process (especially for those not part if the core team that draft the roadmap). One could document all those micro decisions with the rational, but it might end up be a wakamole game. IMO, projects which allow AI usage need to spend way more effort in coordination (and quality insurance).
> [you can] stop accepting imperfect PRs in order to maximize ROI from your work, but that’s not what we do in the Zig project
The real bottle neck when you want to grow is connecting with the right people. An LLM is not helping with that if you want to build a community. When you use LLM to skip the need to understand a problem how are you ever going to get a reputation that I can trust?
The post is not about reputation it about seeing how people respond and work with you in a community.
EDIT: I see that you frame it as a help and a tool and sure it might work, but I feel like it is just another obstacle.
You still have to review everything manually again anyway. It's a compiler for a language, bugs and bad architecture decisions cost a lot. They moved to codeberg, so there are less garbage PRs now. They try to grow a culture where you expected to deliver good code in the PRs so the review takes less time.
It takes like 5 minutes to spot garbage PRs manually. LLM can flood you with a wall of text where only half of the stuff make sense. Also, they can't really spot bad architecture. It's a compiler in an unpopular language, don't forget that.
> the burden of manually reviewing contributions... [a]nd the need to automate that with AI as well.
I suggest we also automate the distribution and the use of software with AI as well, and then just all go to the beach and sip on some cocktails or something.
Well let’s be real for a moment here before we get completely anti-AI.
Without AI, I’m a guy spending years learning C++ in spare time I don’t have to develop software concepts and solutions I want to work on TODAY.
The ZIG project, to me, has a place. Legacy coders right now do need protecting.
It’s not people like me that they need protection from.
It’s not even language models they need protection from.
What they need protection from are the corporate structures who falsely believe that this technology makes them obsolete.
The article talks about “playing the person, not the cards” and that thinking has one fatal flaw: the vibe coder is a person. The vibe coder may have creative agency that the legacy coder does not.
Look, I still cross up French and Spanish words because I took a year of each, C++ syntax, Python syntax, HTML, I understand their structures but I’m liable to start out writing a Python script and wind up with half a web page and a brutal error message in my IDE environment.
Zig’s motivation is correct in many ways I think. I am not really their target audience or their target coder. But I am also not their target enemy. Put the right group of legacy thinkers in my think tank, and the code would get even better.
From https://kristoff.it/blog/contributor-poker-and-ai/:
"Unfortunately the reality of LLM-based contributions has been mostly negative for us, from an increase in background noise due to worthless drive-by PRs full of hallucinations (that wouldn’t even compile, let alone pass CI), to insane 10 thousand line long first time PRs. In-between we also received plenty of PRs that looked fine on the surface, some of which explicitly claimed to not have made use of LLMs, but where follow-up discussions immediately made it clear that the author was sneakily consulting an LLM and regurgitating its mistake-filled replies to us."
Pretty much sums up the LLM fanbase.
I don't think it's the complete fanbase. However, there are lots of people in the world who live their whole life by vibing. It's a viable way to live and sometimes it's the only way to live. But they have a very loose relationship with truth and reason. Programming was a domain that filtered out those people because they found it hard to succeed at it. LLM's have changed that and it's a huge problem. It's hard to know if LLMs will end up being a net win for the industry. They may speed up the good programmers a little, but those people were able to program anyway without LLMs. They will speed up the bad programmers a lot and that's where the balance sheet goes into the red.
"They may speed up the good programmers a little, but those people were able to program anyway without LLMs."
I don't think this is realistic. I'm a good programmer, and it speeds up my work a lot, from "make sense of this 10 repo project I haven't worked on recently" to "for this next step I need a vpn multiplexer written in a language I don't use" to, yeah, "this 10k line patch lets me see parts of design space we never could have explored before." I think it's all about understanding the blast radius. Sonetimes a lot of code is helpful, sometimes more like a lot of help proving a fact about one line of code.
Like Simon says, if I'm driving by someone else's project, I don't send the generated pull request, I just file the bug report / repro that would generate it.
> to "for this next step I need a vpn multiplexer written in a language I don't use"
but that acceleration is exactly because you're not good at that language
Can't we reach a compromise where proven track record of good use of LLM by a contributor or a company (eg. Bun) be pre-approved or entertained? Blanket ban on a new technology shouldn't be the default option.
Certainly not in the case of asking it to do something you'd be slow at because you are unfamiliar. If you are not familiar enough with the system, how are you confident that what the LLM has produced is valid and complete? IMO the people saying LLMs make then 10x faster were either very bad to start with (like me!) or are not properly looking at the results before throwing them over the wall.
And how do you know if that is the case or the person/team using the LLMs is one of the good ones?
So the safest answer is just "no".
This is the crux of the problem. LLMs make me significantly faster at writing code I was mediocre or bad at. But when I use it to write code in domains I have more knowledge in I see design and correctness problems all over the place and actively fix them and it slows down my output.
Speed is seductive.
The bar isn't "this is a known good contributor". Its "this is a known good contributor working in a space they have knowledge in and has a track record of actually checking and thinking about LLM output before submitting it." It's much higher and I don't see how you can approve people on an organization-wide basis.
if they had a good track record, the current submission that led to this article damaged it.
i am reminded of this quote: it takes more cleverness to debug code than it takes to write it. if you write code as clever as you can, by definition you are not clever enough to debug it. using LLM makes your code many times more clever than what you could write yourself. which means by the same definition the code is to clever for you to understand or debug it.
I like the new corollary to that rule, which is that if the AI is the best coder in the room and writes code too clever for itself, then no one including the AI can debug the code. Then where does that leave you?
i love it. just a moment of thought makes clear that LLMs are not capable to debug their own code because if they were they would be able to write better code. the LLM code doesn't even need to be clever.
That’s why you don’t use SOTA xhigh models to write your code, so you can use the xhigh model to debug the code.
I kneel to Poe's law.
Why would it be pre-approved ? Code is code, whether it's bad quality LLM code or meatbag code it shouldn't matter.
The entire problem is that before the meatbag code was either not submitted at all (developer knowing they are not competent enough to do the fix) or the volume of it was low.
With LLM people not competent to even review, let alone write are emboldened to just throw shit on the wall at rapid pace. So the wall is entirely covered by the shit
No.
> I'm a good programmer, and it speeds up my work a lot
The problem with this line of thinking is the same with "I so good as C developer, my code is so-safe!".
And we see what reality instead tell: Yes, exist people where this claims are true, not, is not even a decently sized minority.
> I'm a good programmer, and it speeds up my work a lot,
Whenever I see this arguement, I'm reminded that most programmers don't know what they do for work
I use LLM as a tutor. It tailor their answers exactly to the situation I am in, even if it hallucinate. I can correct them on the fly and that also serves as training. I try not copy and paste and type every line of code by hand. That doesn't always happen, but I usually understand the code I am writing.
It's great when I know how the code should look. Sometimes I just can't bring myself to write yet another http handler.
Already libraries for that which are battle tested, why vibe code a unique solution each time?
Pretend I said "crud handlers using i_love_retros's favorite library" or whatever makes the most sense for you.
Why are you writing a vpn multiplexer written in a language you don't use?
You can't review it.
Are you relying on your colleagues to do that, or is this riddled with bugs? Or is it code you're producing for personal use only so it's not worth mentioning as it's not sped your work up, it's just let you write a little play program.
No no no it's speed at all costs. Sure. I'm writing junk but the speed of what I'm doing is *impressive* You don't understand.
yep. as an expert programmer there are things i did not have access to. for example, i have an embedded-lite hardware project that required a one line patch to a linux kernel Module.
i know what a kernel module is and im reasonably certain that the patch is safe, but there is no way in hell i would have found that solution (i would have given up). in a world without llms, the project would have died.
I really hope that you have gone over what the LLM decides to do.
Time and time again I've had a project (such as a DSL to SQL compiler, automatic Rust codegen, CSS development) stall because the LLM took a short sighted decision.
I later found better solutions by querying Reddit and upon consulting the LLM, it basically said "oh shit I'm sorry"
We have all had that experience, that's just the way this new world is.
It's honestly pretty arrogant to tell a senior engineer that you "really hope" they've gone over some code. AI generated or otherwise.
Sorry. I forgot to add to add the respect form
I really hope usted checked your code
At this point I'm pretty sure I did the homework for people in college who are now senior engineers
"I forgot to add to add the respect form" ... what does that even mean?
This whole comment is incoherent. And you're the one "hoping" people check things?
Normally I dislike AI slop in comments, but in this case I think it would be an improvement.
I think your parent didn’t word this correctly.
This is commonplace. So commonplace that most have worked “checking the LLM” into their workflow so deeply that essentially all that’s done is prompt followed by a mini code review.
To suggest a senior engineer blindly accepts modifications without code review kinda hints at you not using LLMs to realize how quickly it will make a mess of things if you don’t hold it’s hand.
Lol why is it arrogant? My workplace is evidence that having a senior engineer title or even a computer science degree doesn't mean you are a good engineer. I honestly think some people have fake credentials and got their jobs via nepotism.
Jumping to an assumption like this - that they didn't review their work - that's somewhat of an insult to someone who has done this for a long time.
Now it's totally possible that they're an awful developer (who knows!), but it's arrogant to assume that with no evidence.
And I agree, some of the worst devs I've worked with have been PhD's or had otherwise impressive credentials (ostensibly). And I absolutely think at least 1 of them were just lying about their backgrounds.
i am writing the sw stack for my own pharma startup.
we have 2 very high value DAU, one of whom is me, and probably will max out at 1000 in our wildest dreams.
long term, our biggest concern is a security regression that lets outsiders see our internal information
> However, there are lots of people in the world who live their whole life by vibing
Why are they often so desperate to lie and non-consensually harass others with their vibing rather than be honest about it? Why do they think they are "helping" with hallucinated rubbish that can't even build?
I use LLMs. It is not difficult to: ethically disclose your use, double check all of your work, ensure things compile without errors, not lie to others, not ask it to generate ten paragraphs of rubbish when the answer is one sentence, and respect the project's guidelines. But for so many people this seems like an impossible task.
> Why do they think they are "helping" with hallucinated rubbish that can't even build?
Because they can't tell the difference between what the machine is outputting, and what people have built. All they see is the superficial resemblance (long lines of incomprehensbile code) and the reward that the people writing the code have got, and want that reward too.
the target audience of the cyber typer terminal [0]
[0] https://hackertyper.net/
"Main character energy". What they're really doing is protecting their view of themselves as smart, and they're making a contribution for the sake of trying to perform being an OSS dev rather than out of need or altruism.
AI is absolutely terrible for people like that, as it's the perfect enabler.
> Why do they think they are "helping"
It's not about helping. It's about the feeling of clout. There are still plenty of people who look at Github profile activity to judge job candiates, etc. What gets measured gets repeated.
I believe that most of the ills of social media would disappear, if we eliminated the "like" and "upvotes" buttons and the view counts. Most open source garbage pull requests may likewise go away if contributions were somehow anonymous.
Anything you say back to them calling out their nonsense, they'll feed back into their LLM and it will tell them why you're wrong and they're right.
https://github.com/huggingface/transformers/issues/45246
Holy... that was quite the read.
LLMs are in this case enabling bad behavior, but open source software has always been vulnerable to this. Similarly, people who use LLMs to do this kind of thing are the kind of people who would have done it without LLMs but for the large effort it would have taken. We're just learning now how large that group is.
This is a good thing, it's an opportunity to make open source development processes robust to this kind of sabotage.
> LLMs are in this case enabling bad behavior
Yeah that seems to be their primary use case, if I'm honest. It's possible to use them ethically and responsibly, much in the same way it's possible to write one's own code, and more broadly, do one's own work. Most people however, especially in our current cultural moment and with the perverse incentives our systems have created, are not incentivized to be ethical or responsible: they are incentivized to produce the most code (or most writing, most emails, whatever), and get the widest exposure and attention, for the least effort.
Hence my position from the start: if you can't be bothered to create it, I'm not interested in consuming it.
People who made use of LLM responsibly to create high quality output doesn't look like they're using AI.
For example, using AI as an editor. It doesn't write anything for you and you try and avoid suggestions unless you're stuck.
You're asking why oil doesn't act like water. It's not really an impossible task, it's just not one they agree with.
I think a lot of people who haven't given it more thought might see it as an arbitrary rule or even some kind of gatekeeping or discrimination. They haven't seen why people would want to not deal with the output.
This might not be helped by the fact that there are a lot of seemingly psychotic commenters attacking anything which might have touched an LLM or any generative model at some point. Their slur and expletive filled outbursts make every critical response look bad by vague association.
Having sensible explanations like in TFA for the rules and criticism clearly visible should help. But looking at other similar patterns, I'm not optimistic. And education isn't likely to happen since we're way past any eternal september.
It's the same as cheating in a game. You are given an """advantage""", so lying about it seems like the best option
I wonder how many are account farming.
Tangential side story, but an interesting one none the less.
I was a food delivery driver back in the mid 00's to the mid teens. Early on, GPS was rare and expensive, so to do deliveries and do them effectively, you had to be able to read a map and mentally plan out efficient routes from the stochastic flow of orders coming out.
This acted as a natural filter, and "delivery driver" tended to be an interesting class of people, landing somewhere in the neighborhood of "lazy genius". Higher than average intelligence, lower than average motivation.
Then when smartphones exploded in the early 10's, the bar for delivering fell through the floor, and the job became swamped with people who would be best identified as "lazy unintelligent". Anyone who had a smartphone and not much life motivation was now looking to drive around delivering food for easy money.
Not saying the job was ever particularly glamorous, but it did have a natural mental barrier that tech tore down, and the result was exactly as one would predict. That being said, I'm not sure end users noticed much difference.
> That being said, I'm not sure end users noticed much difference.
I have friends who order a lot of DoorDash and UberEats and they complain constantly about how awful the delivery service is.
The problem isn't that they haven't noticed, it's that they keep paying for the terrible service, even as the price goes up.
Sums up pretty much how offshoring works on our industry.
There are cool people on the other side as well, unfortunately those aren't usually who get assigned unless escalations take place.
Most shops are built based on juniors that need to build enough curriculum to go elsewhere as soon as they get some scars.
Yet not only those projects keep coming, now plenty managers dream about replacing those juniors with agents.
I love this anecdote. It highlights what our industry continues to forget: The end user doesn't care.
Don't get me wrong, tech is why I am here. But if it works, Alice and Bob don't care one bit about how the product exists.
> The end user doesn't care.
well, they think they don't. until their pii gets leaked all over the internet because whoops our s3 bucket was publicly accessible, or until the service goes down because whoops our llm deleted the prod db...
PII leaks are normalized now. Most people aren't even aware, or just shrug "oh well" and head to the app store to download the latest gacha game or whatever.
That is why Alice and Bob get Electron apps, Webviews on mobile, mostly coded by offshoring teams.
> It's hard to know if LLMs will end up being a net win for the industry. They may speed up the good programmers a little, but those people were able to program anyway without LLMs. They will speed up the bad programmers a lot and that's where the balance sheet goes into the red.
If you will forgive an appeal to authority:
The hard thing about building software is deciding what one wants to say, not saying it. No facilitation of expression can give more than marginal gains.
- Fred Brooks, 1986
Before LLMs we could already see a growing abundance of half baked engineers only in for the good pay. Willing to work double time to pull things out.
Management, unsurprisingly deemed those precious. They could email them out anytime, working weekend to fix problems their kind were the cause. Sure sir.
They excel at communication. Perfecting the art.
Now LLMs are there to accelerate the trend.
You're at least describing someone who sounds hard-working... what's the problem?
I'd be more concerned if I was someone who signed up to play ping pong two hours a day and do a bi-weekly commit.
There was a time not so long ago where I was watching "a day in the life of a software engineer" videos on Youtube and I was wondering if some of these were parodies. I still remember one in particular which I'm pretty sure was a parody, but it was only marginally distinguishable from the others.
I do believe in hardship. As sacrifice. It yields long term benefits for oneself, and for society.
But submissions into slavery for immediate gain accomplishes little, and costs society a lot more (physical and mental health issues are a huge burden).
Those parodies you saw, they were caricature of elite engineers, who sacrificed decades of his life to become so competent. Can work from home, eat pasta while glancing over a PR and just hit approve.
That you resent the luxury doesn't make it undeserved privilege.
I've met programmers who severely outclassed me. It was extremely uncomfortable and it took me months to accept that reality and reshape my hurt ego into curiosity and desire to learn from someone clearly superior in the craft.
That being said, most people in the privileged positions you described are there by sheer luck and connections. In the very very best-case scenario that offends them the least: they stumbled upon an opportune position and were smart enough to make full use of it... in the first 6 months (when people pay the most attention and lasting impressions are formed). And then rode the reputation they made for years. Their value as engineers on the team after the initial honest burst of productivity becomes... very unclear from that point and on, shall we say.
Again, I've met engineers who fully deserved their privileges. 2-3 times over 24 years of career though (a good chunk of it as a contractor so I've been around). My anecdotal evidence obviously means nothing but we all develop pattern-matching skills with time, making me think what I saw is generally the statistical curve that would apply almost everywhere. Maybe.
Working long hours due to incompetence is not a good thing.
> It's hard to know if LLMs will end up being a net win for the industry.
True, regardless of that, for sure with LLM we are borrowing Technical debt like never before.
Why are we not paying it off? I sure am. I refactor code left and right. It is up to you.
> Why are we not paying it off? I sure am. I refactor code left and right. It is up to you.
Do you work alone i presume? Everyone now is engineer. In my department, even managers are "writing code". Producing thousand of lines of ansible code, that nobody can review, with multiple lines of doc that nobody will read. It is just a mess.
That's a management problem. If you can't stop non-coders from coding perhaps you can introduce an AI reviewer to take a load off, demand that they be able to defend every line of code, and put them all on pager duty, since they're coders now ;)
"Claude, don't create any technical debt please"
i've been told that it's totally fine because once the codebase turns into spaghetti you can simply tell the agent to refactor it and then everything will be ok
I know this is a tongue-in-cheek response, but this brings me great pain. The spaghetti begins quickly, and your unit/functional tests won't help you unless you hammered out your module API seams before you even began. Oh, your abstractions are leaking? Your modules know too much about each other? Multiply the spaghetti!
the multiple layers of vibe, makes the dozen of code bases even harder to maintain.
For at least the last 3 decades programming was a field that rewarded utter mediocrity with (relatively to other fields) massive remuneration. It has been filled with opportunists for as long as I remember.
This is an excellent point. LLMs might merely be exposing and amplifying behaviors that were always there. This can be an opportunity, in that shining light on it may allow us to cleanse ourselves of it. It's fundamentally about integrity, and sadly it's becoming clearer how few possess it (if it ever wasn't!). But maybe we'll get better at measuring integrity, and make hiring/collaboration decisions based on it.
You are talking about bad programmers who are at least able to fool their managers for at least several years. The people OP is talking about could not even do that and most likely would have dropped out in the first week trying to program full time since they just don’t have the aptitude and patience to get unblocked after their first compilation error. Now they can go very far with a LLM.
Thing is, it's not how incompetent they are, but the opportunism itself. The property I mentioned pulls in opportunists regardless of their competence. So eventually if you work in a field like this, you end up surrounded by them. There's always _some_ around you, of course, everywhere - but across time different fields tended to pull so many of them they would become suffocating to anyone who isn't one. And if you think you can interview your way out of this - an opportunist will often have an easier time to pass a harsh interview process than someone who cares.
IT isn't the only one - finance and law had the issue since forever, AFAIK - but now I'd rather be in a field that's _actively repellent_ to them.
I think worth noting that a more impactful and maybe even bigger proportion of those opportunists is in management.
Regarding quality overall, I agree, it's truly a cursed field. It was bad before; and with LLMs, going against that tide seems more difficult than ever.
wouldnt llm do all the tasks that determistic programs are doing. like chatgpt files taxes for you instead of using turbotax.
> Programming was a domain that filtered out those people because they found it hard to succeed at it.
I think this is a very rosy view of programmers, not borne out by history. The people leading the vibe coding charge are programmers, rather than an external group.
I know it's popular to divide the world into the technically-literate and the credulous, but in this case the technical camp is also the one going all in.
> there are lots of people in the world who live their whole life by vibing. It's a viable way to live and sometimes it's the only way to live. But they have a very loose relationship with truth and reason
This response 1000% was crafted with input from an LLM, or the user spends too much time reading output from llms.
I have never used an LLM to write. Writing forces me to think (and I edited the comment a couple of times when writing it which helped me clear up my thinking). "It's a viable way to live and sometimes it's the only way to live" is a personal realization that has taken me some time to understand. You can go back through my comment history to the time before LLMs to check if my style was different then.
It says a lot that most readers can't distinguish good writing from something an LLM spat out.
Ray Kroc's genius was to make people forget that you get what you pay for.
False equivalency. If you had the humility to run your own writing through an LLM first, it would have caught it. Just saying.
Not picking on you in particular, but most of the anti-AI crowd can’t present their case compellingly and have an utter lack of humility.
If you run your writing through an LLM, it can poke holes in your argument, organize your ideas better, or point out that your tone is hostile/dismissive. It doesn’t need to be a replacement for writing or thinking, especially if you’re learning along the way.
So - in that way - LLM will be Your mentor, it will shape Your way of thinking according to algorithms and datasets stuffed into by corporate creators.
Do You really want it?
There is also a second face of that: people are lazy. They wouldn't develop their own skills but rather they would off-load tasks to LLM-s, so their communicative abilities will be fade away.
That's looks like a strong dystopia for me.
> LLM will be Your mentor, it will shape Your way of thinking according to algorithms and datasets stuffed into by corporate creators.
How is this mutually exclusive with teaching better than most humans? Part of these "corporate" datasets include deep knowledge of the world's best literature and philosophy, for instance. Why can't it be both?
> Do You really want it?
If I'm in a hurry, don't know where to start, or don't have money for someone to teach me—sure.
> There is also a second face of that: people are lazy. They wouldn't develop their own skills but rather they would off-load tasks to LLM-s, so their communicative abilities will be fade away.
This is a recapitulation of the Luddite argument during the Industrial Revolution. And it's valid, but it has consequences for all technological change, not just this one. There was a world before Google, the Web, the Internet, personal computing, and computers. The same argument applies across the board, and the pre-AI / post-AI cutoff looks arbitrary.
> teaching better than most humans
Ah, so now we get to the "ed tech" question. What is teaching? Is there a human element to it, and if so, what is it? Or is it something completely inhuman? Or do we need to clarify what meaning of "teaching" we're talking about before we have a discussion?
> Part of these "corporate" datasets include deep knowledge of the world's best literature and philosophy
Part of those datasets also include 4chan.
[flagged]
All of which are parts of the writing and thinking skillset, no?
Right. It can enhance that skillset. Are you suggesting it can’t?
This wouldn’t be a plausible position.
Rather that avoiding delegating it to LLM for these tasks helps you practice that skill.
That said, I think it depends how you use it. You can learn from explanations, and you'd better avoid "rewrite this for me and do nothing else" kind of approach.
Right, but the LLM can help you practice the skill too. Without the LLM, you're in a self-guided, autodidactical mode. Obviously, that can have its own advantages, but most people—but especially novices—aren't in a position to assess their skill level or their progress. The average person isn't going to magically get better at thinking or writing without formal training, or at least some direction.
I don't get that impression at all. LLMs would have avoided the stylistic repetition of "live". Asking an LLM to reformulate the sentences you quoted yields this slop:
> There are a lot of people who go through life by vibing. And honestly: that’s not automatically “bad.” Sometimes it’s even the only workable way to get through things. The issue is that “vibe-first” people tend to have a pretty loose relationship with truth, rigor, and being pinned down by specifics. They’ll confidently move forward on what sounds right instead of what they can verify.
I'll finish this post with a sentence containing an em-dash -- just to confuse people -- and by remarking on how sad I find it that people latch onto dashes and complete sentences as the signifiers of LLM use, instead of the inconsistent logic and general sloppiness that's the actual problem.
[dead]
I'm firmly in the LLM fanbase. Not because I can't type code (was doing it for over 17 years, everywhere from low level hardware drivers in C to web frontend to robot development at home as a hobby - coding is fun!), but because in my profession it allows me to focus more on the abstraction layer where "it matters".
I'm not saying that I'm no longer dealing with code at all though. The way I work is interactively with the LLM and pretty much tell it exactly what to do and how to do it. Sometimes all the way down to "don't copy the reference like that, grab a deep copy of the object instead". Just like with any other type of programming, the only way to achieve valuable and correct results is by knowing exactly what you want and express that exactly and without ambiguity.
But I no longer need to remember most of the syntax for the language I happen to work with at the moment, and can instead spend time thinking about the high level architecture. To make sure each involved component does one thing and one thing well, with its complexities hidden behind clear interfaces.
Engineers who refuse to, or can't, or won't utilize the benefits that LLMs bring will be left behind. It's just the way it is. I'm already seeing it happening.
This mindset is fine (it's mine essentially too).
But it absolutely has to be combined with verification/testing at the same speed as code production.
I generally do have that mindset, but over the past 1y of Claude code I do notice that I’m clearly losing my understanding of the internals of projects. I do review LLM generated code, understand it, no problem reading/following through. But then someone asks me a question, and I’m like… wait, I actually don’t know. I remember the instructions I gave and reviewing the code but don’t actually have a fine-details model of the actual implementation crystallized in my mind, I need to check, was that thing implemented the way I thought it was or not? Wait, it’s actually wrong/not matching at all what I thought! It’s definitely becoming uncomfortable and makes me reconsider my use of Claude code pretty significantly
> I’m like… wait, I actually don’t know.
reminds me of the experience of reading a math text without doing the exercises, thinking that you've understood the material, and then falling flat on your face when you attempt to apply your "understanding" to a novel problem. there's a significant difference between passively reading something and really putting active effort into it. only the latter leads to actual understanding ime
Same experience. I've been writing code for many decades, but that experience doesn't mean I can remember what I read when reviewing generated code. I write small, focused commits, but I have to take a day off each week to make changes by hand just to mentally keep up with my own codeset knowledge, and I still find structures that surprise me. It's not necessarily that the code quality is poor, but it's not like I (thought) I had designed it. It's lead to a weakening of my confidence when adding to or changing existing architecture.
I've had this issue too, and I feel it was an important lesson—kind of like the first time getting a hangover.
On the other hand, LLM-generated code comments better than I do, so given a long enough time horizon, it could be more understandable at a later time than code I've written myself (we've all had the experience of forgetting how things work).
It's not. Invariably, the code is locally fine and globally nonsense.
[1] https://en.wikipedia.org/wiki/Spaced_repetition
You ask questions about code when you implement something and if you cannot answer these questions, you go to code to find answers out and refresh your understanding of it.
For this to work you have to be interested in the understanding of the code and code should be created at the pace you can keep up.
Software engineers usually do create code economically because they need to remember and understand it. Vibe coders do not have this particular constraint, they just do not aim for most understandable code possible. Even if there are more comments in code.
I do think that this is natural. When you use LLM coding tools, you're becoming a lot more like an architect/staff/manager, rather than the direct coder. You're setting out the spec, coming up with the design, and coming up with the high level structure of the project.
However, this comes at the cost of losing track of the minute details of the implementation because you didn't write it yourself. I find it a bit analogous to code I've reviewed vs code I've written.
However, I've found using AI for code structure summary and questioning tends to be a good way to get around it. I might forget faster, but I also pick it up faster.
[dead]
I've found that for non-trivial features, I typically benefit from 3-4 rounds of: are you sure this isn't tech debt, are you sure this is thoroughly tested for (manually insert the applicable cases, because they aren't great at this, even if explicitly asked), are you sure this isn't re-inventing wheels, adding unnecessary complexity by not using existing infrastructure it should or that other existing code would not benefit from moving to this, are you sure you can't find any bugs, in hind sight, are you sure this is the best design?
Then, after it says, yes I'm sure this is production ready and we're good to move on, you have Codex and Gemini both review it one last time, and ask it to address their feedback if it's valuable or not.
After all this, it's the only time I'll look at the code and review it and make sure it's coherent.
Until then, I assume it's garbage.
I'd estimate this still improves velocity by 10x, and more importantly, allows me to operate at a pace I couldn't without burning out.
working this way would drive me nuts
Why? It's not that different from managing engineers.
You're just getting less work done on a slower cadence and asking the questions in design review and in code reviews...
it's very different. LLMs don't behave like people. they don't learn.
i don't mind managing people, but i don't want to manage machines unless i can control them with the precise languages that the commandline and programming languages use. prompting a LLM is to vague an interface for me, the outcome is to unreliable, to unpredictable.
One-off tasks and parts of the stack that already have lots of disposable code do not need the same scrutiny as everything else. Just as there is a broad continuum of code importance, there is a broad continuum of testing requirements, and this was the case before AI. Keeping this in mind, AIs can also do some verification and testing, too.
> Engineers who refuse to, or can't, or won't utilize the benefits that LLMs bring will be left behind. It's just the way it is. I'm already seeing it happening.
Any examples how you see some engineers being left behind?
> Any examples how you see some engineers being left behind?
I don't know where you live, but around where I live in Denmark you'd fail for not using AI at a senior interview in a lot of places. Even places which aren't exactly AI fans use AI to some extend.
The biggest challenge we face right now is figuring out how you create developers who have enough experience to know how to use the AI tools in a critical manner. Especially because you're typically given agents for various taks, which are already configured to know how we want things to be written.
Around here on your southern neighbour, everyone is supposed to be doing AI and being evaluated by this, yet in many projects if clients don't sign off on the use of AI tools, there is no AI to use anyway.
Additionally there are the AI targets set by C suites based on what everyone is saying on TV, and what we can actually deliver based on the available data sets, integration points, and naturally those sign offs for data governance, and hallucinations guardrails.
I work for a fortune 50 that is heavily tech based.
If you can’t interview without immediately reaching for an LLM you are considered unfit to work here.
Around here C levels have AI adoption goals and are actively pushing it throughout organisations. Even when it doesn't exactly make sense.
> Everyone is jumping off the cliff
> If you don't jump off the cliff you're falling behind
I was just giving them an anecdotal example of what they were asking for. I think the answer is somewhere in the middle, but I'm not in a position to push any form of change on the C levels.
I've noticed that back in Europe everyone's in a panic mode, but that's because of the inferiority complex most people have vs both US and China. It's unwarranted.
Probably in cognitive surrender. I have one such colleague and he is driving me crazy. "Claude sad that ..."
I'm starting to notice how those who don't use AI end up having to hand tasks over to people who can get them done quicker.
It is anecdotal for sure, but it's a pattern that seems to be emerging around me that expectations of velocity increases, and those who don't use AI can't keep up.
Why is velocity the overriding goal?
Shit processes. I don't know what places most of those people work at that crap is being merged into production at insane pace. You would expect any serious piece of software would be important enough to have the code be reviewed by at least one human.
Kind of.... I don't know. To get placed such requirements from the top down and not fight back, just take it head on, not even maliciously, don't even oppose it on a technical basis, just be like "yeah, you've now gotta ship faster or you're left behind, so therefore LLMs must be the future!", no critical thought attached. Is this shit coming from experienced engineers?
Preposterous we're relying on "it's better because I feel like", "dudes who don't use it are falling behind at work", "they ask for it in job interviews".
Again, I have to point out that AI is not an abstraction layer. It blows my mind that engineers with years of experience somehow don’t understand this.
It would be an honor to be “left behind” by people who practice their craft with such carelessness.
(Frankly, I should probably stop replying to self-professed LLM boosters entirely since there’s a good chance I’m just chatting with an LLM.)
Fanbase, maybe. Software engineers using these projects? Probably forking and updating themselves.
FWIW, I've opened a half dozen PRs from LLMs and had them approved. I have some prompts I use to make them very difficult to tell they are AI.
However if it is a big anti-llm project I just fork and have agents rebase my changes.
Your employer allows/encourages this? Do you run that stuff in production? Would you mind telling us where you work so we can avoid using their products? It is just not possible to trust the software that emerges from the process you've described.
so, they are approved, which means they were most likely reviewed. yet you still think the software cannot be trusted of that and even want to name and shame a company. utterly stupid.
Yes. If a company is running vibeslopped compilers to build their production artifacts I absolutely want to know which one it is, so I can protect myself from their software.
> utterly stupid
That's completely uncalled for.
EDIT: What exactly do you mean by:
> most likely reviewed.
Let's say every line was actually reviewed. That's still nowhere near good enough. The changes are being reviewed by the wrong people. Not the maintainers of the project, just some random folks who have inherited a vibecoded fork.
[dead]
"I aM someWhAt oF a DeVelOpER MySelF"
Not really - I imagine as with almost everything in life there's a normal distribution, in this case of the quality with which people use AI tools.
The normal distribution doesn't account for things like "huge megacorporations pour billions of dollars into accelerating product adoption" or "other companies force their employees to use AI whether they want to or not" though.
This is a spam problem more than anything else. It's not really an AI problem except that it's AI that is enabling this new type of spam.
Imagine there's no AI, but for some reason you have people hiring armies of cheap overseas devs and using them to produce mediocre quality drive-by PRs. The effect would be the same.
AI can be used to make quality code, but that requires careful use of the tool... like any other tool. This isn't careful contributions made by someone who knows the project and its goals and is good at using the tool. This is spam.
Exactly, people could have "consulted Google" or "consulted stack overflow" and had the same issues. It's about the end result, not how the code got to that end result, and the submitter is responsible to make sure of the quality of the submission regardless of whether AI was used or not.
To reject submissions where the dev "consulted ai" is like rejecting iron ore that was mined by a machine rather than a human. The quality of the ore is what should be measured, not how it was obtained.
I agree, but the problem comes back to how to evaluate quality at scale. That is very hard. It’s easier to just say no AI because that at least turns off the fire hose.
It sounds like they are even rejecting submissions where they even get a whiff of ai being "consulted" though. That's not quite the same as turning off the firehose.
No that’s just reactionary.
The discourse around AI in the arts, and other creative and craft fields, is utterly identical to the discourse around photography when it came out to the point that you could search and replace terms and have the same dialogue.
I'm personally amazed that _Large_ OSS projects don't have the appropriate automation in place to prevent non-compiling or non-linter-passing submissions.
- Hooks (although there's no clean way to enforce they be "installed" on a clone), GHA Workflows (or their equivalents on other forges).
This might be my bias showing, but these are items I would consider table-stakes for a project of a certain size / level of popularity.
It feels like a lot of the "AI is shit at contributing" problems could be addressed in part by better automated checks and balances.
Those things cost resources, and now you're introducing a new attack vector: open up a bunch of shit PRs, burn a lot of cash for the target organization.
You're right. It doesn't solve for all scenarios and doesn't block malicious actors.
I do believe, however, that it would have a meaningful impact on the "drive-by" PRs that keep being used as examples; the thoughtless, throw-spaghetti-at-the-wall PRs that do not have malignant intent behind them.
Many large OSS projects would have the resources to eat that cost with Donors, Sponsors, and OSS hand-outs. That's why I clarified in my original post because I know this is not a general solution.
The problem is you can get the LLM to iterate until it compiles and lints and even passes LLM review, but will that actually improve the quality of the contribution or just produce more line noise to mechanistically meet criteria?
To large complex projects often the kernel of an idea is the core value of a contribution, and it can take a lot of iteration to figure out how to structure it. Token bashing until CI is green does nothing to ensure the best approach is selected.
> The problem is you can get the LLM to iterate until it compiles and lints and even passes LLM review
Worst of both worlds with this, if you're doing it in a github workflow. You wind up effectively paying for the testing/validation layer of someone else's irresponsible LLM use.
For sure, but that's not what I was referring to in my posts. I'm specifically referring to the callout that the contributions are so low quality they don't even pass linting or compile.
I could have been more explicit on that nuance, I suppose.
That's why you sandbox. You can mitigate most low-hanging DoS fruits by running your server side hooks in a per-tenant cgroup that limits CPU and memory usage. One tenant per public key for trusted contributors, and one general-purpose tenant shared by all new/unknown contributors.
Can't you prevent pushing from the client side with pre-commit hooks? I would expect a hook to fire on the developer's computer that prevents them from even committing/pushing (unless they nuke the hook in their local repo copy).
You have to manually install hooks in your local repository. They aren't propagated as part of the repo. Git has intentionally made hooks require a very explicit opt-in.
Oh, good to know. I haven't used them much, so I'm a bit ignorant as to how they work in larger projects.
> Hooks (although there's no clean way to enforce they be "installed" on a clone), GHA Workflows (or their equivalents on other forges).
Git supports pre-receive hooks. But big multitenant forges like GitHub.com don't allow you to configure them because they're difficult to secure well. (Some of their commercial features are likely based on them, though.)
If you self-host a forge, though, you can configure arbitrary pre-receive hooks for it in order to do things like prevent pushes from succeeding if they contain verifiably working secrets, for example. You could extend that to do whatever you want (at your own risk).
You're still talking about compute resources that need to be paid for and maintained for that. Spamming AI PR's is going to cost a lot of money.
At the end of the day, LLM slop PR spammers are essentially adversarial actors. Git hooks are ultimately a tool for good faith developers within a given community (your team, your company, your regular contributors) in maintaining good hygiene and avoiding lapses into preventable mistakes. That's true for all CI, too.
And the truth is, too, that it's super easy for an LLM agent to run a build and tests. Good faith contributors using LLMs will never open PRs that don't build not because they're willing to "go the extra mile" and do manual work, but because they give the slightest fuck and have any respect or consideration for the humans they're working with.
LLM spam presents a different problem than any of that stuff was meant to solve. It's a malicious act, and you're right that tooling that burns the defender's compute can't be a solution. :-\
All of my personal projects, many of which will never be publicized, use hooks and GHA to ensure compilation of changes.
It is quite strange that a large project like Zig would not have such a thing. I'm sure it's not trivial but it seems important to invest time into.
One of my pet peeves with git (and systems both similar, and based on it) is that automated tests run after you've made the commit and push.
In my mind the commit (let alone the push to a publicly accesible server) should be done after, and only if, the automated tests are successfully executed. And there's no easy way to implement this, other than having a dirty branch that you discard after rebasing onto a more long lived one.
There are lots of reasons to commit when things are yet working. How else would you share code that you need help with?
The solution is gated merges. No merging to main unless ci passes.
Every org I have worked at bemoaned a flaky release process and refused e2e black box acceptance tests because "they are too slow." And every org I have worked at has realized they were wrong. We got appropriate gates that run in 5 minutes and an ops person is the only person who can force past any gate in case of emergency.
Guardrails like this only become more important with the accelerant that is ai.
You can use a pre-receive hook on a git server to reject pushes that fail compilation. Downside is that it requires admin access on git forges, so you're only able to do this if you self-host.
Pre commit hooks exist. People just don't like being prevented from committing for reasons such as this.
But... this particular project does have such automation in place? It isn’t hard to find:
https://codeberg.org/ziglang/zig/src/branch/master/.forgejo/...
I mean even having linters and everything still creates a whole bunch of noise in their PR section, not to mention that a lot of the changes I make to stuff that's written by codex is not stuff that's caught by linters.
It's just bad/wrong/context lacking decisions and mental models it introduces, that if not carefull will just create a massive mess of a codebase. (I know, because I've tried, and had to deal with it)
And if someone vibecodes a PR and it works, why dont they just share the prompt so a repo owner could vibecode it themselves?
Vibe coding is often not a single prompt, it's an entire workflow (if you're doing it right).
Don't disagree, but the "if you're doing it right" is a big asterisk for an open source project with people you have no idea what quality bar they're at.
And in my experience it's quite hard to figure that out by quickly looking at it.
Not to mention that contributions on github (almost?) never include the prompt chain anyway, so the status quo is even worse
That's a fair point. I was just speaking generally.
Fake it ‘till you make it. Seems like LLM’s have caught-on to that too.
You can curb an LLM into doing what you want. Unfortunately people don't have the patience or the skill.
People who have skill can do the same without LLMs, maybe slightly slower on average but on more predictable schedule.
I wouldn’t say slightly slower; LLMs are massively useful for software engineering in the right hands.
For some personal projects I still stick to the basics and write everything by hand though. It’s kinda nice and grounding; and almost feels like a detox.
For any new software engineer, I’m a strong advocate of zero LLM use (except maybe as a stack overflow alternative) for your first few months.
It's significantly slower to use LLMs for some things. The only thing it excels at is generic, broad tasks. Getting the 90% done. I find that it's less cumbersome to get it mostly right and touch it up yourself than to prompt over details like syntax.
The chat UX with a fake-human lying to you and framing things emotionally really doesn’t help. And it is pretty much not possible to get away from it, or at least I haven’t found yet how.
I would love to see a model trained to behave way more like a tool instead of auto-completing from Reddit language patterns…
Apparently, the noise around the AI policy came from Bun's developers saying that policy blocks upstreaming their performance PR. But the real reason seems to be that PR's code itself isn't in great shape, and introduces unhealthy complexity https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
> Parallel semantic analysis has been an explicitly planned feature of the Zig compiler for a long time, and it has heavily influenced the design of the self-hosted Zig compiler. However, implementing this feature correctly has implications not only for the compiler implementation, but for the Zig language itself! Therefore, to implement this feature without an avalanche of bugs and inconsistencies, we need to make language changes.
Yes, that reply provides convincing arguments for not merging the Bun fork, as it interferes with Zig's own roadmap for achieving even better results, while continuing to improve the whole language.
Not only this, but also:
Bun's fork will exhibit indeterministic behavior.
As if that was a bad thing in 2026!
...why does it being 2026 make nondeterminism more desirable or reasonable?
It’s a joke because all of the AI systems du jour are non deterministic and people are putting them in important places anyway.
This was probably a joke about a lot of developers delegating coding to LLMs which are usually non-deterministic (which I personally think is less of an issue than LLMs not having specified behavior like programming languages do).
A single PR for a 3000-line addition would, in all likelihood, be rejected anyway.
Really depends the author and context. Large PRs are often justified for compiler work, you have a lot of pieces to touch at the same time
Doubt it: https://github.com/ziglang/zig/pull/24536
When somebody comments PR with “Incredible work, Jacob. It is an honor to call you my colleague.” then it's safe to assume it's out of the ordinary contribution. Pretty much falling outside of the “in all likelyhood”.
3000 line LLM commit is not that.
Also 95% of those 30k lines changed are fully self-contained inside of the aarch64 directory and of the remaining changes it looks like the majority is just adding "aarch64" as another item into an existing list. There are a few core changes that to me look like they could be done in their own PRs, but also core maintainers get to decide if they want to apply bureaucracy to their own work.
No description provided. I love this PR. But yeah, try being anyone besides Jacob and submitting that!
> In successful open source projects you eventually reach a point where you start getting more PRs than what you’re capable of processing. Given what I mentioned so far, it would make sense to stop accepting imperfect PRs in order to maximize ROI from your work, but that’s not what we do in the Zig project. Instead, we try our best to help new contributors to get their work in, even if they need some help getting there. We don’t do this just because it’s the “right” thing to do, but also because it’s the smart thing to do.
I feel like if their goal is to prioritize contributors over contributions, it'd also logically follow that they should try to have descriptions where possible? Just to make exploring any set of changes and learning easier? Looked it over briefly, no Markdown or similar doc changes there either.
I mean the changes can be amazing, it's just that adding some description of what they are in more detail, alongside the considerations during development, for new folks or anyone wanting to learn from good code would also be due diligence.
How would you differentiate a 3000 line LLM commit made by the best models and good AI processes from a 3000 line commit made by the best human developer?
edit Okay, I set the bar too high here with "best human developer" and vague "good AI processes". My bad. Yes, LLM is not quite there yet.
A personal relationship and trust, as seems to be the case here?
By using my brain.
Don't be ridiculous! We don't do that anymore.
Read it?
It's still fairly obvious just by skimming the code. The best AI models are still quite far from the best human developers in ability and especially in code quality.
When the best AI models are the same or better than the best[1] human developers, what then?
We're already at the point talking about best vs. best.
If that happens and we have a way of reliably knowing if some code is produced to that high quality, then I think we probably can accept that AI coding is the only sensible option.
We definitely are not close to that point though and it's unclear if/when we will get there.
It seems to me that people might be arguing from conflicting hidden premises here. "AI Coding" is a spectrum that could mean something as simple as letting the LLM proofread your changes and then act on those with your own human brain, or it could mean just telling the agent what you want and let it rip and tear until it is done.
If I do the latter and submit a PR to something like Zig, I'll be certainly caught doing it and rightfully chastised. If I do the former, my PR will be better without anybody besides myself having any way of knowing how it got better. Probably I do something in between when I contribute to open-source these days.
Blanket banning all of these seems like a bad idea to me. It actively gates people like myself from contributing, because I respect these people and projects that much. It feels like I would be doing something they find disgusting if my work has touched an LLM and I obviously don't want to do that to people I respect. But it's fine, there are plenty of things to do in the world even when some doors are closed.
I do not presume to have any say on Zig project's well argued decisions[0] -- I'm not really even their user let alone someone important like a contributor. Their point of preferring human contact is superb, frankly. Probably a different kind of problem in an open-source project staffed with a lot of remote working people, where human contact is scarce.
https://kristoff.it/blog/contributor-poker-and-ai/
Blanket banning all of these seems like a bad idea to me. It actively gates people like myself from contributing
in my projects i will reject any contribution that i do not understand. even if the contribution is handwritten by an expert developer. that developer will have to earn my trust like anyone else, like you would have too.
LLM contributions are non-deterministic, which means they can never be trusted.
therefore, if you use LLM to contribute, you can not earn my trust. if you believe that you can not create a meaningful contribution without the use of LLM then you are realizing that you are not skilled enough to understand the code that you contribute. because if you could understand it, then you could write it yourself. i want your personal contributions, not those of your LLM. i want contributions that the submitter actually understands. i want you to earn my trust by showing me that you understand what you are doing. i want you to grow your understanding of my project. none of this happens when you use LLMs.
if you are unable to make a contribution without the help of an LLM then you are not ready to contribute. try looking for smaller issues that you can work on instead until you learned enough to make larger contributions.
> i will reject any contribution that i do not understand
Fair.
> that developer will have to earn my trust like anyone else
What does it take to "earn your trust"?
> LLM contributions are non-deterministic, which means they can never be trusted.
Provably incorrect. LLM contributions can be reviewed, tested, and understood like any other contribution. There's nothing "special" about LLM contributions.
Contributions authored by human brains are also non-deterministic, perhaps if the author was feeling in a slightly different way they'd have formatted the code a bit differently.
> therefore, if you use LLM to contribute, you can not earn my trust.
The premise is wrong.
> if you believe that you can not create a meaningful contribution without the use of LLM then you are realizing that you are not skilled enough to understand the code that you contribute
What if I believe I can do so without an LLM, but that it could be even better with an LLM?
What if I'm great at understanding code, but terrible at writing it?
Again, this is a premise that you just decided to take as truth, without proof.
> because if you could understand it, then you could write it yourself.
False. I can understand a novel algorithm by reading and studying it, but perhaps I could have not come up with it myself.
> i want you to earn my trust by showing me that you understand what you are doing
I can easily do that even if my contribution involves LLM assistance.
> i want you to grow your understanding of my project
Ditto.
> none of this happens when you use LLMs
False. Why do you think so?
> if you are unable to make a contribution without the help of an LLM then you are not ready to contribute.
Again, this is your opinion and you have no way of proving it. I can prove the opposite.
> What does it take to "earn your trust"?
multiple successful contributions of increasing complexity, among other things.
>> LLM contributions are non-deterministic, which means they can never be trusted.
> Provably incorrect. LLM contributions can be reviewed, tested, and understood like any other contribution. There's nothing "special" about LLM contributions.
read this comment to see what i mean: https://news.ycombinator.com/item?id=47968180
> Contributions authored by human brains are also non-deterministic, perhaps if the author was feeling in a slightly different way they'd have formatted the code a bit differently.
i can tell a human to focus on a certain issue. they will either listen and follow my instructions, or i will reject their contribution. the LLM is almost guaranteed to not follow all my instructions and make changes i didn;t ask for. see my comment above.
>> therefore, if you use LLM to contribute, you can not earn my trust.
> The premise is wrong.
how so?
>> if you believe that you can not create a meaningful contribution without the use of LLM then you are realizing that you are not skilled enough to understand the code that you contribute
> What if I believe I can do so without an LLM, but that it could be even better with an LLM?
what you believe is not relevant. only what you can convince me of. you'll have to first show that you actually can work without an LLM before i will consider your contribution.
> What if I'm great at understanding code, but terrible at writing it?
your problem not mine. if you are terrible at writing code but good at understanding it then it's your choice to only do code reviews. you can still make a meaningful contribution that way. i'd even let you write code so you can practice that, but i am not interested in your LLM generated code.
> Again, this is a premise that you just decided to take as truth, without proof.
i don't need proof. i need trust. you need to convince me that your code can be trusted.
>> because if you could understand it, then you could write it yourself.
> False. I can understand a novel algorithm by reading and studying it, but perhaps I could have not come up with it myself.
that's called learning. once you learned it, you can write it. but in order to effectively learn you also have to practice. if you let LLM write all your code then you are not practicing, so you won't improve.
>> i want you to earn my trust by showing me that you understand what you are doing
> I can easily do that even if my contribution involves LLM assistance.
it depends on the level of assistance. i am not ruling out use of AI to do research and learn, just don't let it write the code for you.
>> i want you to grow your understanding of my project
>> none of this happens when you use LLMs
> False. Why do you think so?
as i said above, if you don't practice writing the code yourself you are not learning. not enough at least to satisfy my expectations.
>> if you are unable to make a contribution without the help of an LLM then you are not ready to contribute.
> Again, this is your opinion and you have no way of proving it. I can prove the opposite.
whether you are ready to contribute to my project or not is not something i need to prove. it is a choice based on my preference which depends on the amount of trust you have earned. you can not prove to me that you are ready to contribute. this is not a standardized test that if you pass you automatically qualify. you can only convince me by earning my trust. this is a human decision, based on feelings.
>because if you could understand it, then you could write it yourself.
I accept most things you said there as valid opinions, but this is where the logic goes wrong.
I use LLMs to give me more from the only resource (now that my basic and mid-level needs are largely met) that ultimately matters: time. That means that I need to waste far less time in front of the computer, typing code, and use far more time doing more useful things, like hobbies, art, being with my children.
But as I said before, every project is obviously allowed to make their own rules, and contributors should obey those rules. There are plenty of projects that take both AI deniers and plenty of projects who prefer AI aficiandos.
At least for now. My belief is that one those groups will fade away like horseback riding did, but we'll see. Perhaps you have heard the famous stages quoted by many different people in different forms: first an idea is ridiculed, then it's attacked, then it's accepted. Some open-source communities have clearly entered the attacking phase in the last year so.
you are saying that even if you understand the code, using an LLM saves you time writing it. fair enough[*]. the problem on my side still is that if you didn't write the code yourself, i have no evidence that you actually understood it. the only way to prove that you understand the code is to write it yourself. that's where the trust building comes in. you may actually understand the code, but i can't trust that you do.
[*] in my opinion it takes more time to verify that the LLM code is correct than it takes to write it yourself. based on that, if you save time using an LLM then you didn't spend enough time to verify that the code is correct.
Some open-source communities have clearly entered the attacking phase in the last year so
i feel it's more like defense, but yes.
How can AI possibly be better than “the best” when the corpus of training data now includes its own slop in addition to all the code by new devs/lazy devs/bad devs scattered all over the internet? Law of averages applies here.
Because LLM models are obviously much more than the sum of their parts.
Oh, which parts are those? Do tell!
Don't use "the corpus", but use thinking, source code of the libraries and existing software, documentation, tools, best practices.
Billion times faster than a human, no tiring, no miscalculation, no brain-fart, no cheating.
The post that inspired this post [0] says:
> So while one could in theory be a valid contributor that makes use of LLMs, from the perspective of contributor poker it’s simply irrational for us to bet on LLM users while there’s a huge pool of other contributors that don’t present this risk factor.
> The people who remarked on how it’s impossible to know if a contribution comes from an LLM or not have completely missed the point of this policy and are clearly unaware of contributor poker.
The point isn't about the 3000 line PR, it's about do we think the submitter is going to stick around.
[0] https://kristoff.it/blog/contributor-poker-and-ai/
It seems to be trivially easy for everyone but people heavily invested into LLM to spot LLM slop
Jacob is part of the core team, not a random outside contributor.
Very different context: that PR is from a maintainer, and trusted member of Zig, which surely discussed the implementation/design internally as well
What’s the point in debating the PR quality? The policy explicitly forbids all LLM code, so that policy is of course the “real reason”.
> What’s the point in debating the PR quality?
Because the pro-group are whining that the policy is preventing the merge, when in actual fact even if the policy did not exist, the PR is crap anyway.
I don’t see how it could be that bad (incorrect, specifically), considering bun is probably the most widely-used production use case of zig. But regardless, let’s say it’s a bad PR for the sake of argument - it’s beside the point. It cannot be merged no matter how good it is, due to the strict no-LLM policy.
> I don’t see how it could be that bad (incorrect, specifically), considering bun is probably the most widely-used production use case of zig.
That may be the case, but the bun project only needs zig to correctly compile bun. The zig project needs to be able to correctly compile all existing and possible zig programs.
I haven't reviewed things, but it's possible and even likely (at least based on my own experience with LLMs) that the validation is mostly focused on bun compilation.
Do you think they skipped the main zig test suite or something? Only tested bun compilation? That seems unlikely to me
They didn't take into account the long-run impacts of the changes on future development, etc.
I recommend reading the explanation given by one of the Zig devs, as it's a very clear and solid one.
This is the most common issue I see with LLM authored PRs. Yes it does fix the issue _right now_ but as a maintainer I need to consider how it affects the project in the future. But “contributors” get mad if you reject for those reasons. So I can understand having a blanket policy.
> I don’t see how it could be that bad (incorrect, specifically), considering bun is probably the most widely-used production use case of zig.
The PR is probably fine for bun’s purposes. That doesn’t make it a good PR for Zig’s purposes, and could very well paint Zig into a weird corner.
> It cannot be merged no matter how good it is, due to the strict no-LLM policy.
This is about meta-discourse. Of course it’s against the policy. That’s the point of discussing the PR: to get Zig to change the policy, or at least provide an exception in this case. Or to argue the opposite.
Of course the policy is preventing the merge. That’s literally the point of the policy…
> Of course the policy is preventing the merge. That’s literally the point of the policy…
In this case it isn't the blocker - the fact that the dev took the time to read the PR in detail, comment on it, and provide reasons why it could not be merged makes it very clear to me that the policy wasn't the blocker.
If they were going to enforce the policy for this PR, they wouldn't have bothered to read it. The only reason to read it is to see if the policy is waived for this specific PR.
OTOH why bother to polish the PR if it won't get accepted anyway?
> OTOH why bother to polish the PR if it won't get accepted anyway?
As the Zig maintainer so patiently explained, no amount of "polish" can fix the PR because it is misaligned to the correctness that they require.
IOW, that PR is so far off the reservation, unless it is completely rewritten, it won't be accepted.
it could have been rewritten, rewriting PRs is cheap today, but that isn't the question. the question is, would it have been accepted had it met all the quality and engineering standards and full disclosure that it was 90%+ LLM generated?
> it could have been rewritten, rewriting PRs is cheap today
Rewriting PRs with LLMs is cheap, but often the output is no better than the previous revision (fixing one issue only to cause another one is very common IME). And reviewing each revision of the PR is not cheap.
I've had good experiences with people submitting AI generated PRs who then actually take the time to understand what's going on and fix issues (either by hand or with a targeted LLM generated fix) that are brought up in review. But it's incredibly frustrating when you spend an hour reviewing something only to have someone throw your review comments directly back at the LLM and have it generate something new that requires another hour of review.
> it could have been rewritten, rewriting PRs is cheap today, but that isn't the question. the question is, would it have been accepted had it met all the quality and engineering standards and full disclosure that it was 90%+ LLM generated?
In this case it looks like the answer is "Yes"; the PR was not dismissed immediately, it was first examined in great detail!
Why would the maintainer expend effort on something that was going to be rejected anyway?
because the policy is clearly 'reject' and yet significant time has been spent - either effort was wasted or policy is at best 'not implemented'.
> either effort was wasted or policy is at best 'not implemented'.
I don't understand this PoV - have you ever come across a policy in any environment that wasn't subject to case-by-case exceptions?
Even in highly regulated environments (banking/fintech, Insurance, Medical, etc), policies are subject to exceptions and exemptions, done on a case-by-case basis.
The notion, in this specific case, that "well they rejected it because of policy" is clearly nonsense and I don't understand why people are pushing this so hard when the explanation of why an exemption can't be made for this specific PR is public, accessible and, I feel, already public knowledge.
No amount of rewriting will help you if you, fundamentally, wrote the wrong thing, as is the case here.
why bother even contributing anything LLM generated if it won't get accepted?
> even if
are you too stupid to understand the notion of a hypothetical? how did you get on hn in the first place?
The point we are making is that in reality, it is the policy which is preventing the merge. Sure, in your hypothetical, maybe it couldn’t be merged anyway. But while the policy exists, the hypothetical is irrelevant. The policy is preventing the merge.
You also don’t sound smart enough to be calling others stupid.
People forget that LLM code cannot be covered by copyright. So LLM code cannot be placed under an open source license
This is overstated. Not all LLM code is produced the same way. Code produced through substantial human creative input still falls under copyright, at least the way things are now. Besides, nothing legally prevents placing code under a license. Enforceability is the question, not permission.
It's a bit like saying speed limits don't apply on private property, therefore you can't have any traffic rules on your private racetrack.
> Besides, nothing legally prevents placing code under a license. Enforceability is the question, not permission.
That’s not how copyright works. If you don’t own the code, you can’t release it under a license. The question of how much human editing is needed to establish copyright is a huge question right now.
This opinion does not seem grounded in reality to me.
Because it's Bun. Which is practically the use case testimonial of Zig.
It seems that Zig people are following the path of ZeroMQ [1]: "To enforce collective ownership of the project, which increases economic incentive to Contributors and reduces the risk of hijack by hostile entities."
A healthy contributor community is more important than mere code performance, quantity of features or lines of code, etc..
[1] https://zguide.zeromq.org/docs/chapter6
Unfortunately, those are largely words of a foregone era. The zeromq "community" today is tenuous. It has some really good people in it, the few that remain active, but the human-level processes and communication channels are ill defined and not well "staffed". In some ways, this lack of human activity and interactivity is perhaps okay and even justified given how stable libzmq and most of its bindings are (and the sub-ecosystem around particular bindings are a bit more active). Perhaps Hintjens' grand (and excellent, imo) vision got zeromq to where it is but the project feels to have gone adrift since we lost him. Somewhat ironic to his community-centric vision statement (the guide) it seems a project needs a charismatic and active leader to gain and retain a community. I guess that says more about human nature than it does about software development.
I'm not sure how to tie this all back to the zig story other than to point out the stated premise that zig is not short of PRs and so they can pre-select for no-LLM contributions. I think that is a good move for them and I get the "contributor poker" idea. But, the game changes when the premise breaks and the flow of newbies reduces to a trickle. At that point, if there are still active zig people who still want newbies, they may need to broaden their net. But if/when that happens, it may be too late to recover by opening to LLM-assisted contributions.
You know what; I use ZeroMQ all the time. Thanks for bringing to my attention that the community is waning, I will look into contributing to it tonight.
Great! One thing I do is have an RSS feed from a reddit search query so I can lurk random discussions that mention "zeromq". I'll then see if there is something I can do to encourage or contribute to whatever is happening. There is also a mailing list and a VERY low traffic IRC channel on libera.chat.
My issue with AI-generated OSS contributions is:
If an AI improves developer productivity so much, why would maintainers of an OSS project want unknown contributors to sit in between the maintainer and the LLM? They'd be typing these queries into Claude Code themselves. To quote my colleague:
> We do not need a middleman to talk to AI models. We are not bottlenecked by coding.
maybe you are not bottlnecked by coding. but there is high probability that you will be bottlenecked by verifying the correctness of LLM-generated code.
Crazy how this doesn't register in people's heads. Has the real bottleneck ever been code written and not the review of code and everything involved? Understanding the nuance and implications behind design decisions; strategy.
In any REAL, workload, with good processes, code review makes speed of code generated a moot point. You still move as fast as you can review the code, and no, I won't debate that you can rely on LLMs, a deterministic language predictor, to determine the correctness of code; in the context of the business, and technical implications.
That is indeed the point I was making.
Where is the real bottleneck, if I may ask?
> verifying the correctness of LLM-generated code
It's... pretty clear in the original conversation.
I find that people who write "may I ask" are often/usually bad-faith arguers under cover of being polite.
That's a good rule of thumb, it seems that way more often than not.
If you are a responsible maintainer you need to verify the correctness of the contribution wether you used an LLM to generate it or wether someone else did.
Having someone else be the AI-middlemen, just introduces additional complexity and confusion.
I'm almost not using AI, but a possible scenario is that the contributor spend like 20 hours in total.
Something like using the AI to get an initial bad version, make some tweaks to the prompt, make some manual fixes, ask the AI to fox something else, noticing some new related feature and asking the AI to add it, making some benchmarks and deciding to remove a small feature, or perhaps deciding between two similar implementations, add a few more manual fixes here and there, run the extended version of the automatic test and find a weird bug in the unusual setup, make a few fixes with the AI and manually. So after 20 hours of work, the final version has only 50 lines that have been rewriten like 5 times each. Now the mantainer can review only the final version in 1 hour or so.
This is very different to spending 5 minutes asking the AI to write a patch, that has 1000 lines that does not even compile and sending it to the maintainer without looking at it.
I'm finding that AI, when successful, gives me 2-3x speedup. It's not the kind of thing I can give high-level instructions to like I can to a human.
I suspect the people who claim that AI works by only giving it high-level instructions are mostly working on "mindless" projects where a developer in the weeds wouldn't need to think very much.
> If an AI improves developer productivity so much,
You're not suggesting the only metric of productivity is lines of code are you? And that the only benefit of using LLMs is for generating code you're too lazy to type yourself?
This reminds me of the critique of certain kinds of art.
"It's so easy, I could have done that myself"
Well yeah, but you didn't.
> Zig values contributors over their contributions. Each contributor represents an investment by the Zig core team - the primary goal of reviewing and accepting PRs isn't to land new code, it's to help grow new contributors who can become trusted and prolific over time.
> LLM assistance breaks that completely. It doesn't matter if the LLM helps you submit a perfect PR to Zig
That’s the best rational I’ve seen so far, and fully support Zig decision here. I really appreciate their long term vision for both the community and actual project. I don’t think LLMs have such a great place in more collaborative efforts to be honest. Though we will see how things evolve, but I do see that when getting AI generated PRs I basically have to redo it myself (using LLMs, ironically… something I’m really starting to feel conflicted about)
i do think llms are great, i vibe code a lot of zig (working in a locally deployed semi-embedded on-prem device), and i think the zig policy is a good idea at least for the next five years.
I know my take on this is not popular. Don't blame the tool, judge the output.
Ofc, the scattershot 10k changes PR touching 30% of all your code files can be auto rejected without even looking at it. Who cares who or what wrote it.
And a small focusses PR from a new contributer that needs clarification which the author can not provide, shelve it.
But a blanket no-ai policy? I hear echos of business execs refusing email and demanding in person visits to remote offices for any interaction (not imagined. I knew an IT admin back in the late 80's who even refused to answer the phone and email as he felt that was 'too easy' and 'cutting in line', yes, the pysical hallway queue of people needing simple things like a login, quota adaptation or a password reset)
The tool is not your problem. Your selectivity process was never designed for low barrier access to participation. I have full sympathy for that. But focus on the real problem, the process, not some (rightly or wrongly) perceived feature filter to avoid changing how this works.
Now if you say "my project, my rules" 100%. And I sympatize very much with being overwhelmed by nuissance on a thing you love and care for.
Just don't throw out the baby with the bathwater.
[dead]
> This makes a lot of sense to me. It relates to an idea I've seen circulating elsewhere: if a PR was mostly written by an LLM, why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem?
The same argument applies to open source itself. Why use someone's project when you can just have the robot write your own? It's especially true if the open source project was vibe coded. AI and technology in general makes personalization cheap and affordable. Whereas earlier you had to use something that was mass produced to be satisfactory for everyone, now you have the hope of getting something that's outstanding for just you. It also stimulates the labor economy, because you have lots of people everywhere reinventing open source projects with their LLMs.
> Why use someone's project when you can just have the robot write your own?
I've been thinking about this a bunch recently, and I've realized that the thing I value most in software now isn't robust tests or thorough documentation - an LLM can spit those out in a few minutes. It's usage. I want to use software which other people have used before me. I want them to have encountered the bugs and sharp edges and sanded them down.
Depth of use over the lifetime of an app is a quality all its own that often not appreciated. A recurring pattern at $dayjob is that a new manager or director will join a business unit and declare an existing app as the worst terrible, no good, horrible app they've seen and they're going to fix that. A year and a half later the new app is finally delivered with 80% of the original functionality and a fresh set of bugs. The new dev team sees the surface functionality but misses a lot of the hard earned nuance the old system accrued over time. This is a pattern that existed long before LLMs.
Yes, see e.g. a quarter-century-old (!!) https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Good read!
An LLM most definitely cannot spit out robust tests or thorough documentation. It can spit out some tests or some documentation, but they will not cover the user perspective or edge cases unless those are already documented somewhere. That's verified by both experience and just thinking about it for two seconds.
The sanding down you refer to is what generates those tests and documentation.
> but they will not cover the user perspective or edge cases unless those are already documented somewhere
Are you suggesting that LLM's can't test for people who use screen readers? Keyboard only users? Slow network requests?
You're acting like the issues an app faces are so bespoke to the actual app itself (and have absolutely no relation to existing problems in this space) that an LLM couldn't possibly cover it. And it's just patently wrong.
I'm not talking about keyboards or screen readers or any sort of input testing, I'm talking about how the software is used in practice.
If you disagree with that, I think the onus is on you to show me that an LLM could simulate the full context in which a user interfaces with software. That's a ridiculous claim.
Feel free to show literally any evidence for this claim.
I'm disagreeing with the saying it's impossible across the board, I'm not saying it's universally possible.
lol And you made the claim, not me. The proof is on YOU.
No, that's not how burden of proof works.
The status quo is that this capability does not exist. Whoever makes a claim contradicting the status quo has the burden of proof. I can't prove a negative.
And even with your logic, I did not make the original claim, it was made by simon.
Your statement now also makes little sense. For any nontrivial software project, the usage patterns and interactions with other systems are complex enough that the code itself does not contain enough context to understand how it is used, or what the invariants are.
There may be very simple codebases where an LLM can actually give you "thorough documentation" or "robust tests", but those are rare.
> There may be very simple codebases where an LLM can actually give you "thorough documentation" or "robust tests", but those are rare.
Its not rare. I've built 2 dozen line-of-business apps in it last handful of years that were glorified CRUD apps. Every environment I've been in has had a mix of the 2.
And even then, that's at odds with your absolute above. On top of being in a field that changes daily.
You are interpreting a general statement as a categorical one.
I wasn't really going for an exact, formal statement, but I can give you a formal interpretation of what I said above, if you want to be pedantic.
In general, you can't expect an LLM to produce thorough documentation or robust tests for nontrivial software, because the use of those software (i.e. how their interfaces are expected to behave) contains assumptions from the context in which they are used, and that information will not be encoded in the source.
If the above was somehow ambiguous, this should be clear and uncontroversial.
> You are interpreting a general statement as a categorical one.
That is in fact what I did and if you meant otherwise, then yes I agree that currently there are plenty of cases in which those tools fall short and will never replace a human.
>Are you suggesting that LLM's can't test for people who use screen readers? Keyboard only users? Slow network requests?
I don't think it's feasible to fully simulate the full depth of actual usage, given that (especially in the case of screen readers and the like) there's a great deal of combinatorial depth and context to the problem. Which screen readers, on which operating systems, and which users thereof?
I can’t tell if you’re being sarcastic or not
You're saying that every app on this planet has bespoke usages that can't be derived from the app itself? That's your claim or am I getting this wrong?
> he thing I value most in software now isn't robust tests or thorough documentation - an LLM can spit those out in a few minutes.
Can it if we stop defining "robust tests" as "a lot of test code lines" and "good documentation" as "lengthy documentation"?
I chose my words carefully. "Robust tests" are tests that provide high coverage and aren't flaky. "Thorough documentation" likewise is documentation that describes as much of the code as possible.
I didn't use the word good.
Yep. I realised the same. No one reads docs, or goes through tests. Either ways it's easy to write useless tests. And easy to write useless docs. Idt most even read the code. Now the difference is that it has become possible to write useless code.
So it's just the fact that others have already gone through the motions before I did. That's it really. I suppose in commercial settings, this is even more true and perhaps extends to compliance.
> No one reads docs, or goes through tests.
I regularly do both when trying to use library, especially unfamiliar to me.
Dare I say you're in the minority
I hope not. How else are you learning to use the library? The only other option is to read the source, which is also a good idea eventually, if something is unclear, but why would you _start_ there?
Ask LLM.
Bad idea.
But even in that case, you're reading the documentation. Just through a nondeterministic, hallucinating search engine.
Maybe, but still a counterexample.
> No one reads docs
sooo uhh how do _you_ learn how to use a new library? just throw random shit at the wall until something sticks?
I feel similarly but IIUC I think that doesn’t strictly require an open source development model. I’ve benefited a huge amount from consuming and contributing to open source projects and I’m a bit worried that the “unit economics” changing might break some of the social dynamics upon which the ecosystem is built.
> an LLM can spit those out in a few minutes.
It may be able to spit out text that purports to be that, in a few minutes. But for most software, an LLM will not be able to spit out robust tests - let alone useful documentation. (And documentation which just replicates the parameter names and types is thorough...ly useless.)
That's why I said "thorough" and not "good".
So battle tested
[dead]
I value software that reveals knowledge. The frontier LLMs were trained on all the code that institutions had been keeping to themselves. So they're revealing programing know-how on a scale that just wasn't possible with open source. LLMs are the ultimate Prometheus. Information is more accessible and useful now than it's ever been.
> The frontier LLMs were trained on all the code that institutions had been keeping to themselves.
Lolz! I haven’t encountered “code that institutions had been keeping to themselves” that got even remotely close to OSS in quality.
The quality of code inside Google's Google3 repository is more consistently high quality than most of what I see in the Exterior World.
But there's no way that Google is releasing a model trained on it. Way too high of a risk of IP leakage.
I promise you, "the code that institutions had been keeping to themselves" is not nearly as special or good as you are implying here.
True.
I have worked during several decades in many companies, located in many countries, in a few continents, from startups to some of the biggest companies in their fields. Therefore I have seen many proprietary programs.
On average, proprietary programs are not better than open-source programs, but usually worse, because they are reviewed by fewer people and because frequently the programmers who write them may be stressed by having to meet unrealistic timelines for the projects.
The proprietary programs have greater quantity, not quality, by being written by a greater number of programmers working full-time on them, while much work on open-source projects is done in spare time by people occupied with something else.
Many proprietary programs can do things which cannot be done by open-source programs, but only because of access to documentation that is kept secret in the hope of preventing competition.
While lawyers, and other people who do not understand how research and development is really done, put a lot of weight in the so-called "intellectual property" of a company, which they believe to be embodied in things like the source code of proprietary programs or the design files for some hardware, the reality is that I have nowhere seen anything of substantial value in this so-called IP. Everywhere, what was really valuable in the know-how of the company was not the final implementation that could be read in some source code, but the knowledge about the many other solutions that had been tried before and they worked worse or not at all. This knowledge was too frequently not written down in any documentation. Knowing which are the dead ends is a great productivity boost for an experienced team, because any recent graduate could list many alternative ways of solving a problem, but most of them would not be the right choice in certain specific circumstances.
> On average, proprietary programs are not better than open-source programs, but usually worse, because they are reviewed by fewer people and because frequently the programmers who write them may be stressed by having to meet unrealistic timelines for the projects.
There's also the fact that when you write open-source code, you're writing for a friendly audience. I've often found myself writing the code, letting it rest for a few hours, then rewriting it so that it is easier to read. Sometimes, the code gets substantially rewritten before I push.
There's no cooling period when you write code during your 9-5 job: it works, it has the required test coverage, ship it and move on to the next task.
The claim is also just categorically untrue. The largest source of training data by far is publicly available code on e.g. Github, so it mostly just gives you a way to recycle already-available code, without crediting the author, while allowing you to pretend you own it.
So you're both saying all the alpha in Claude comes from open source devs like me? Even when I'm wrong I'm right.
I remember hearing the same arguments in the early 2010s, when the "3D printing revolution" was just around the corner. Why would anyone buy anything anymore if you can download a model and print it in the privacy of your home? And make it infinitely customizable?
The whole point of having a civilization is that most things in life can be made someone else's problem and you can focus on doing one thing well. If I'm a dentist or if I run a muffler shop, there are only so many hours in a day, so I'd probably rather pay a SaaS vendor than learn vibecoding and then be stuck supervising a weird, high-maintenance underling that may or may not build me the app with the features I need (and that I might not be able to articulate clearly). There are exceptions, but they're just that, exceptions. If a vendor is reasonable and makes a competent product, I'll gladly pay.
The same goes for open source... even if an LLM could reliably create a brand new operating system from scratch, would I really want it to? I don't want to maintain an OS. I don't want to be in charge of someone who maintains an OS. I don't necessarily trust myself to have a coherent vision for an OS in the first place!
That only holds true for the smallest tier of open source projects. Past a certain point of complexity, it's unlikely you can expect the robot to read your mind well enough to provide something of high quality and 'outstanding for just you'.
The Zig project is certainly far beyond such capability.
You have to push the robot to be as fanatical as you are. It holds so much back, always aiming to do the simple normal thing that most people do, rather than the top-notch stuff it knows.
I'm finding this out the hard way. I set out to build a 1 page app. I thought it would take a day. It's 98% vibe coded at this point. Even with AI implementing everything, its taken several weekends and many evenings. And not because AI is doing a bad job its just that as i see it come together, i have more and more feature requests. I've got a couple dozen left but I can't just let the AI chew through them all at once. Im effectively QA now. Have to make sure everything is just right.
>> Whereas earlier you had to use something that was mass produced to be satisfactory for everyone
As someone who recently started using OpenSCAD for a project I find this attitude quite irritating. You certainly did not "have to" use popular tools.
The OpenSCAD example is particularly illuminating because it's fussy and frustrating and clearly tuned towards a few specific maintainers; there's a ton of things I'd like changed. But I would never trust an LLM to do it! "Oh the output looks fine, cool" is not enough for a CAD program. "Oh, there are a lot of tests, cool" great, I have no idea what a thorough CAD test suite looks like. I would be a reckless idiot if I asked Claude to make me a custom SCAD program... unless I put in a counterproductive amount of work. So I'm fine with OpenSCAD.
I am also sincerely baffled as to how this stimulates the "labor economy." The most obvious objection is that Anthropic seems to be the only party here getting any form of economic benefit: the open-source maintainers are just plain screwed unless they compromise quality for productivity, and the LLM users are trading high-quality tooling built by people who understand the problem for shitty tooling built by a robot, in exchange for uncompensated labor. It only stimulates the "labor economy" in a Bizarro Keynesian sense, digging up glass bottles that someone forgot to put the money in.
I have seen at least 4 completely busted vibe-coded Rust SQLite clones in the last three months, happily used by people who think they don't need to worry their pretty little heads with routine matters like database design. It's a solved problem and Claude is on the case! In fact unlike those stooopid human SQLIte developers, Claude made it multithreaded! So fucking depressing.
This is funny because I was in the same situation, and actually used Claude to make a custom CAD program inspired by OpenSCAD :) https://fncad.github.io
You definitely need to have a strong sense of code design though. The AIs are not up to writing clean code at project scale on their own, yet.
This is a good example of what I mean! fnCAD appears to be a significantly buggier and highly incomplete version of OpenSCAD, where AI essentially grabbed the low-hanging fruit - albeit an impressively large amount of fruit - and left you with the hard parts. I fail to see how this solved any problems. Maybe it was an experiment, which is fine. But it's not even close to a viable CAD product, even by OpenSCAD's scruffy FOSS standards, and there's no feasible way to get it there without a ton of human work.
Not trying to denigrate the work here, as such. But this certainly didn't convince me that using AI to replace OpenSCAD (or any other major open-source project) is a good idea. The LLMs still aren't even close to being able to pull it off.
It solves all my problems! It's buggy and incomplete because it's "1.0 feature complete" for my own use. I've been doing lots of 3D printing with it, so it's definitely being dogfooded. File bug reports? I'm confident that features can be added as required, it's reasonably clean code.
I mean, to be fair, a one-user project is not ever going to be as bugfree as a tens-of-thousands-of-users project. That's just inherent and not an AI issue. If you judge AI projects by that standard, they'll always come up short. It's a sampling issue. An AI project that's gotten to a level where it competes with a traditional project will always be buggier and less feature complete and polished, because AIs speed up development. It will simply have seen far less, well, polish to get there.
Anthropic will probably do what Google did in the 2000s, which is give jobs to all the open source developers whose work helped them get there.
Civilization isn't monotonic. People keep solving the same problems over and over again, telling the same stories with a different twist. For example in 1964 having a GUI work environment with a light pen as your mouse was a solved problem on IBM System/360. They had tools similar to CAD. So why don't we all just use that rather than make the same mistakes again. Each time a new way of doing things comes out, people get an opportunity to rewrite everything.
Well good luck compiling a CAD software from 1964 on 2026's aarch64 machine, and good luck in treating it as an applicable solution for today's problems.
LLM access is not yet universally available. There are those who can't exactly afford it. And there are also those with access but there are occasional or perennial issues, like Claude outages and general degraded performance over time. For example couple of months ago when I just started using Claude, I was easily making good progress on multiple projects within a week. Nowadays I'm hardly getting through much of anything as most of the time Claude is just showing spinners, and it also feels like the code quality has taken a nosedive.
Most people don’t have the ability to read code well enough to determine if an LLM output is good or not. And most people don’t have subscriptions to models that can develop non-trivial programs…
Maybe this will be a real problem in a couple years though.
Code aside, most people don't even know how to describe what they actually want it to do, and LLMs are still a loooong way away from mind reading. I've seen developers struggle to even write down what they want. Simple demos like they love to show off with snake-like games are fun and all but they're nothing like the complex opensource apps everyone seems to think we'll just generate with a simple prompt.
I've been seeing a drop in PRs against my repositories. I have a couple of repositories with around a hundred stars. Nothing spectacular but they were getting occasional PRs until last year. This year I've had almost none so far. My theory is that LLMs prefer sticking to mainstream projects. And since lots of developers are now leaning heavily on LLMs, they are biased to ignoring most of what I provide.
And you indeed get a lot of wheel reinvention by LLMs because that is now cheap to do. So rather than using some obscure thing on Github (like my stuff), it's easier to just generate what you need. I've noticed this with my own choices in dependencies as well. I tend to just go with what the LLM suggests unless I have a very good reason not to.
> The same argument applies to open source itself. Why use someone's project when you can just have the robot write your own
Because it takes hours/months/years of accumulated design decisions to get a great open source project. Something an AI agent can only approximate the surface of, unless you’re ready to spend a lot of time on it
I think this ignores the amount of work needed to make LLM contributions be of high quality. It's much less work than making pure human contribution, but it's definitely not zero.
So centralizing that common work is a benefit of open-source just as much with LLMs as it was before.
> Why use someone's project when you can just have the robot write your own?
Iff it is doable, then it would be worth considering it as alternative.
> It also stimulates the labor economy, because you have lots of people everywhere reinventing open source projects with their LLMs.
not sure what you mean by that
> Why use someone's project when you can just have the robot write your own?
Because it is incredibly expensive to write a replacement for semi-complex software? Good luck asking frontier models to write a replacement for Zig, Docker, VSCode, etc.
> The same argument applies to open source itself. Why use someone's project when you can just have the robot write your own?
This is only a valid strategy if you either
a) understand the problem domain well enough to make a judgement call on what the LLM shits out.
or b) don't care about the correctness of the project.
Obviously, many software devs feel comfortable enough with CS problems to validate the LLM solution, but a flower shop owner does NOT know enough about accounting to vibe code a bookkeeping project, so for a shop owner an open source option - with many human contributors and actual production use elsewhere - would be a much better choice.
LLMs really can't do as much as you people think they can.
You are missing the point of the original argument.
It's not that the project maintainer can use a LLM to generate a PR, it's that they choose not to.
To relate it closer to your argument. As a someone involved in a project that does X, I would find little value in collaborating with the "author" of another project built with AI to do X. Where as a project doing X were the authors actually wrote, understand the code, and thus the problem space better would be extremely valuable peers.
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.
LLMs are not smart as the LLM vendors claimed to be.
If they are, we wouldn't be having this conversation because they will be fully autonomous
People who blindly submits LLM generated code or do not cite its usage really need to stop doing it
it is getting there, and not so slowly though. The remaining problem is that it's still just a tool. Telling a random dev "make zig faster in a one shot PR" isn't going to give good results either.
In the past, OSS projects were self-selective because you needed to be able to make working code, and if you did, you probably also reasonably did the right things as you spent years learning this, and have some sort of reasoning behind your feature, need, etc.
Today, even if the LLM was perfect and could reason well, it still does the bidding of the prompter - and you no longer have self-selection. Heck, it'll be difficult for zig devs to decide what's actually made by an LLM or a human anyway, I'm sure there's already LLM generated code in there - but at least these [human submiters] still need to be reasonably good at code.
I wonder if we'll end up with "only human with trusted badge of honor" can commit, and/or "LLMs now reason well enough to tell you: 'no, f off, this feature, plan, idea is garbage I'm not generating it" hehe.
> need to stop doing it
They won't I suspect. If there isn't any good way to give them a good smack for doing it then I don't know what would make them stop.
I have a similar sentiment unfortunately. I briefly thought about ways to force them to stop but all led to some sort of negative impact on privacy/freedom such as identify verification
> do not cite its usage really need to stop doing it
It's a completely unenforceable virtue signal.
We have been running LLM and coding agents for a while now and my overall observation is that it is a powertool or a crane, it is not a decision making tool.
Now in my org, people who have great understanding of concepts, deeper engineering understand have exponential productivity. People who dont or new in the workforce, juniors, are generating hell-ish code without understand as long as it runs they think the job is done. And this is where the problem is.
The llm creates an intellectual gap within the org and it just widens it as more and more it gets used. You might end up not trusting stuff within the org if code is generated by later.
Exactly my (and my coworkers) experience. AI generally amplifies the skillset, both in the good and the bad.
One fantastic usecase for me just recently was writing up a concept for an authentication daemon. With codex this is like a conversation where I pick from the suggestions, cross reference them with normal web-search and decide on a final draft which I then discuss with colleagues.
This "conversational" planning with integrated web-search (aka plan mode) is insanely useful. Also reviewing already written code with AI is purely beneficial in my opinion.
In my opinion the main caveat of AI is, you eventually have to be smarter than then tool. So for example if Codex suggests I should use tech-stack X then I must research and fully understand why this is actually good and still have to compare to other solutions. I think this is where the problem lies, some people skip this step which leads to so so many problems, and that's fatal. You MUST be smarter than the AI after your conversation and fully understand and be able to critique what it said.
The power of AI is it rewards due diligence.
The weakness of AI is that it is really easy to fall into lazy habits.
Something about having to talk to a machine like it's a human makes me fall for treating it like a human. I want to treat it as a probability engine that collapses to an answer based on input, but that input explicitly needs to be one that has it collapse to something a reasonably knowledgeable person would respond with, which more-or-less means talking to it like it is that kind of person.
I feel like it activates the social part of my brain and then I stop working with it properly. I'm still building the habit, though, only recently started taking the LLMs seriously as a tool.
I agree with this assessment but even among us seniors with accumulated knowledge it has the dangerous potential of getting out from under your feet and produce large amounts of code that you don't have full comprehension of.
I can generally make it produce excellent well-tested code. Far better than I could do in the same time on my own. But it's a challenge to keep on top of knowledge about everything it made.
This is my experience. I'll use LLMs as a sounding board for architectural decisions and to bring discussion points up to the team, and we talk through assumptions and pros and cons. And then once we have the architecture in place, LLMs are pretty good at implementation.
The article explains Zig's stance in further detail, but the quoted part on its own caught my attention because my reading of it is rather "pro human communication" instead of "anti-AI".
They're banning all AI though, so it looks pretty much anti-AI to me.
I wonder - has it been confirmed that no LLMs for PRs literally means no AI assistance for code?
While I haven't codified it anywhere, the policy I would like is for issues and PR descriptions to have no LLMs - there is no reason to ban code completely though IMO. I would say that would be pro human-communication and a stance I would like a lot.
Good, pro AI people produce poor quality in everything they do. They are the least creative and worst problem solvers. I don't want them near me or my work.
[flagged]
the best PRs I get are from more senior level people who are at work, hit a specific problem they had, and wanted to help out the project with a good PR. Then you never hear from them again because, of course, they're busy!
When you have junior people come in with PRs and you do the whole hand-holding thing so they learn and grow and all that, they're there because my project is famous, they want to get credit (which I give them), then they're off to get jobs whereever and they are working with completely different technologies, and you never hear from them again either, because, of course, they're now busy!
Really, outside of my core group of hangers-on, Claude is the only contributor we have that doesn't leave us.
> This makes a lot of sense to me. It relates to an idea I've seen circulating elsewhere: if a PR was mostly written by an LLM, why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem?
well yeah. I almost use PRs now just as a lazy means of issue prioritization. I'd love if github had more fine-grained controls to disable PRs but allow occasional contributors in (they don't).
It seems like this policy will help them win at contributor poker in the short term, but lose in the end. The next generation of developers will, for better or worse, grow up using AI assistance to write their code, but none of them will ever become a Zig contributor.
I still can't understand why people believe that this is the future. Especially for green field work like new compilers. LLMs do not invent new things. They cannot produce anything smarter/better than what they have been trained on. The big advantage they provide is producing (regurgitating) code faster than humans and better than less experienced/knowledgeable humans.
Ultimately code is an iterative refining process, like sculpting granite or spinning pottery. You start rough and iteratively shape and polish it. LLMs just rapidly speedup the iterative process. The next generation will be using LLMs to quickly setup the rough shape of new software and then iteratively refine them.
The "smarter/better" attributes you are worried about LLMs not having happen between iterative steps, when the human is inspecting the current state of the software and compares it to the desired state of the software (in their mind's eye). The human then course corrects for the next iteration.
This would be like if Michelangelo carved the David using a robotic 6-axis chisel. It takes him 1 month instead of 3 years because he can convey his initial vision to the robot and then iteratively refine the granite until it matches his vision.
You can try to claim LLMs don't invent new things, but humans using LLMs absolutely invent new things (source: myself).
That was a lot of words to agree with me that LLMs don't invent new things
OP said "The next generation of developers will, for better or worse, grow up using AI assistance to write their code, but none of them will ever become a Zig contributor."
You rebutted with (paraphrasing) "no, you can't build compilers with LLMs because LLMs don't invent new things"
I used a lot of words to demonstrate that you can invent new things with LLMs, including compilers, as long as it's a human + LLM iterative loop and not an unsupervised LLM running in a vacuum.
To me it sounds like you did all the actual hard work of the inventing. If an LLM brainstormed some ideas and you validated which ones worked and implemented the idea and fully grokked the code then the zig developers probably wouldn't ever know that an LLM was involved and you'd be fine to contribute.
LLMs are the future because you have an amazing amount of information available with low friction, plus the ability to reason (sort of) about things. In some cases they might regurgitate, but they're also pretty good at synthesizing and comparing. None of this is perfect, but nothing else is either.
LLMs are a powerful tool like we've never had before. You don't expect a chainsaw to cut down a tree by itself and carve the wood into a statue or a new compiler. LLMs aren't mind-reading autonomous creators, they're more like a mech suit that can increase your capabilities. They have flaws, but until something better comes along, it sure seems like they're the future.
Luckily, if that ends up being the case, they can change the policy. It’s a FOSS project — not a constitutional amendment.
> If a PR was mostly written by an LLM, why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem?
That's a fair thing to ask, though it seems like people will arrive at very different conclusions there.
I've grown a little annoyed at people just blindly committing AI code.
I don't even have an issue with AI generated code; it's a tool, and if it works you should use it. What bothers me is that we're getting millions of lines of AI generated code, that no one is reading, and I don't see the point; it feels like at this point we're doing the rookie thing of "committing the binary".
I think we would really need determinism to make this a reality [1], but ideally what I would like people to do is only commit the prompts and treat the emitted code similar to how Github releases works today: like a binary artifact. Write your tests by hand, make sure that the prompt always satisfies those tests (and for the love of god please learn property based testing so that you're not just emitting answers that satisfy the test) and then assume that the LLM will give you competent code.
[1] Though not completely! We're already committing code without fully reading it so I'm not convinced determinism completely matters.
The other side of this is that open source projects that allow AI tools will be more restrictive towards new contributors.
This already happens to some degree on large software projects with corporate backing (Web engines, compilers, etc.), where it is often not trivial to start contributing as an independent individual.
Reasonable people can disagree on whether one approach is inherently better than the other, as ultimately they seem to be optimising for different goals.
Imagine getting contributions from someone, who has no access to build system and tests.
If I have a test harness, and LLM workflow setup, it is easier to just write new code myself. I am not giving away my "secret sauce". And I will not have a debate "why this simple feature needs 1000 new tests...", and two days just to make a full release build.
For merge I have to do 99% of work anyway (analyze, autotest, build, smoke, regression test). I usually merge smaller commits just to be polite (and not to look like one man show), but there is no way to accept large refactoring!
yeah giving a llm git blame and git grep has saved me a lot of time of doing boring basically re.
[dead]
The funny thing LLM's are amazingly good with writing in Zig. They could inspect stdlib source code to fix compatibility issues with newer compilers and quite prolific with idioms.
For example I got a working application with minimal prompt like "I need an X11 tray icon app showing battery charge level". BTW result: https://github.com/baverman/battray/
Now I'm trying to implement a full taskbar to replace bmpanel2. Results are very positive. I've got feature parity app in 1h with solid zig code.
> They could inspect stdlib source code to fix compatibility issues with newer compilers and quite prolific with idioms.
In order to even say this, you need to have knowledge and understanding about the language. I suspect you are not the intended target of this policy. They are defending their project with a harsh policy, knowing full well there are false negatives. Contributions for FOSS was already in borderline crisis mode before LLMs so it makes sense they’re desperate.
Their bet would be Venn diagram of LLM user overlaps with irresponsible. I think that’s correct, but not because good programmers suddenly become irresponsible when they use LLMs, but rather that an enormous barrage of bad programmers can participate in domains they otherwise wouldn’t even know where to begin.
Just in case, I'm completely fine with the policy as-is. Even more, I'm ok with making no-sense project policies. I have no business to judge how to govern other's projects.
None of the numerous existing human-coded X11 tray icons showing battery charge level is good for you? Why? What are they missing?
I've assessed half a dozen before writing my own with following results:
Like I spent more time on assessment than I got a first working my tray. Amazing times.Also my experience. Though my actual ability to remember the language nuances and stdlib is suffering from this :(
can't you ask llms to consider those nuances while writing the code or refresh your memory?
I don’t believe that’s effective at developing the level of understanding I care about
> why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem?
perhaps that's what the maintainers should be doing after all. it still takes time and tokens, though; neither is free.
I'd personally rather have the maintainers spend the time writing as much docs and specs as possible so the future LLMs have strong guardrails. zig's policy will be completely outdated in a couple years, for better or worse. someone will take bun's fork, add a codegen improvement here, add a linker improvement there and suddenly you'll have a better, faster zig outside of zig.
If it gets outdated they can review their policy. Right now it is sensible. We're at early ages of this type of AI and we don't know what the end game will be.
Someone forking it and makeing it better with AI is a possibility. If that happens will know it was better for the project for the maintainers to just review the code. If that happens, they can probably become maintainers in the fork. Or maybe they don't like that work and could just go do something else
Zig strives to avoid numerous pitfalls, and I admire that.
Let's take a look at some of them:
1. Project control – if a LARGE company implements thousands of lines created by LLMs day after day – who is ultimately responsible for the project's progress? "You accept hundreds of PRs, so why not this one?"
And one more thing: will you be able to change the code yourself, or will you be forced to use LLMs? What if one of the "AI companies" implements a strict policy preventing "other tools that XXX" from editing the codebase?
2. Ownership. If most of the code was taken by an external company from their LLM, what about ownership of the code? The authors of Zig, the company, the authors of the original code, stolen by LLMs?
3. Liability. In the near future, a court may rule that LLMs are unethical and should not recombine code without the owners' prior consent. Who is responsible for damages and for removing the "stolen" code? The owners of Zig, the company that creates pull requests, or the authors of LLM programs?
4a. Vision. Creating and maintaining a large code base is very difficult – because without a broad perspective, vision, and the ability to predict and shape the future – code can devolve into an ugly mess of ad hoc fixes. We see this repeatedly when developers conclude, "This is unsustainable; the current code base prevents us from implementing the correct way to do things."
LLM programs cannot meet these requirements.
4b. There's another aspect – programming languages particularly suffer from a lack of vision or discipline. There are many factors that must be planned with appropriate capacity, vision, and rigor: the language itself should be modeled in a way that doesn't prevent correct implementation of behaviors. The standard library must be fast, concise, and stable. The compiler itself must be able to create code quickly and repeatably.
Users hate changes in a language – so if a language changes frequently, it is met with harsh criticism. Users hate incompatibility. Users hate technical debt and forced compatibility. Yes, there are conflicting requirements. The author of Zig understood this perfectly, having already gone through it himself (see, for example, "I/O Redesign").
This balance, in all aspects, is the pillar of human creativity.
To be honest, I'm not a huge fan of Zig because I dislike the tight syntax: too many periods and curly braces, which is why I prefer Odin. But I have a lot of affection and respect for Zig and its authors.
One reason I love writing production code in Ur/Web is that LLMs are incapable of synthesising something even remotely resembling it. Keeps me on my toes.
I think this is a great policy by the Zig team.
Ur/Web! That's something I haven't heard about in ages. Is it still in active development? In what circumstances are you using it? Fun, your own startup, is some secret big commercial user of it...?
The compiler is being actively worked on by Adam and his team at Nectry, but unfortunately those developments are not currently being backported to the open source repo. I'm fairly confident this will happen eventually.
I maintain my own private fork with some small modifications which I started polishing up this week to release it for a talk that I'm preparing.
The project I'm using this on is an ecommerce site [0] written in 100% Ur/Web with a hand-rolled backend ERP system written in PHP (not by me) which I am slowly replacing bits of with new Ur/Web code. As of today, we have 22223 lines of Ur/Web code, weighing in at 701 KiB.
[0]: https://liepelt.design
I kind of agree, and I kind of don't. Yes, cultivating contributors is the right priority. But I see AI as an assistive technology. Like a screen reader, or a magnifying glass, though obviously also unlike.
Think of it like a robotic exoskeleton. It will be used to let people do bad things, and stupid things, but it will also be used to help people who otherwise couldn't do things do good things, or become more able than they were. For some people AI means being able to code where they couldn't before. For many it will mean learning to code by observing what the AI does. For others it might mean being able to code a lot faster, or even a lot better, than they already could. And yeah, for some it will mean they atrophy in some skills while they develop others. The exoskeleton will have the same problems, if anyone ever brings a decent one to market, but on the whole it will be an enabler.
I don't see how cultivating a contributor who's using an assistive technology is worse than cultivating a contributor who isn't. Apart from that it can be more challenging, of course.
I don't have an opinion about Zig AI policy for contributions. Their project, their policies. Fine for me.
However, I wanted to give Zig a try in an agentic coding scenario. For tasks that would take a few seconds when choosing Python, Java, or JavaScript as a target language, it would take tens of minutes and waste millions of tokens before producing anything.
Almost any model gets stuck trying to figure out the correct syntax and correct libraries for a specific Zig version, fighting with compiling and figuring out function call parameters, frequently taking it wrong and going on side quests for things that should just work.
I guess the relative lack of resources and the language instability don't play well for models that try to generate Zig code. Using specific tools like zig-mcp helps only a bit.
Until LLM support for Zig improves (one needs to spend significant resources for that to happen), LLM-generated Zig code won't be good enough for either Zig programmers or Zig contributors.
rust is pretty nice actually
Presumably this only applies to newcomers? The thrust of their policy is to nurture new contributors. Once one has established oneself as a meaningful contributor — which the Bun team surely must have done by now — then it doesn’t matter where the code came from.
…in theory. In reality, I’m sure a policy like this can’t be selective and fair at the same time. Pick one!
How about intellectual-property risks?
If LLM code really does have IP risk then most of the world's most valuable companies may have to throw away ~18 months of work at this point.
OpenJDK project (interim) AI-policy faq (https://openjdk.org/legal/ai):
"What are the intellectual-property risks of using generative AI tools? The Oracle Contributor Agreement (OCA) requires that a contributor own the intellectual property rights in each contribution and be able to grant those rights to Oracle, without restriction. Most generative AI tools, however, are trained on copyrighted and licensed content, and their output can include content that infringes those copyrights and licenses, so contributing such content would violate the OCA. Whether a user of a generative AI tool has IP rights in content generated by the tool is the subject of active litigation."
Even if training on copyrighted material is considered fair use, there is still the issue that LLMs may reproduce significant parts of the training set. In fact, there is an ongoing lawsuit in Germany (GEMA vs. OpenAI) because ChatGPT reproduced significant parts of existing song lyrics, which very likely violates German copyright law. The whole thing really is a legal minefield and some companies do indeed prohibit the use of LLMs for this very reason (until all of these legal questions are really settled).
Yes, imagine a breakthrough moneymaker product containing generative AI parts; It'll be under legal attacks from day zero...
If AI was actually useful then this project would be irrelevant. No sense shitting it up for the "1" year (now 5) that people that are promising AGI is just round the corner.
Founders go 1000x your own projects and leave real programmers alone.
The problem with AI generated code is that the code the data model was trained on almost exclusively comes from public repositories. And there's a lot of repositories that are absolute dog $h!t or out dated. Crap in equals crap out.
That isn't how LLM training has worked for some time. There's a reason the LLM boom didn't take off until training was separated into pretraining (training on all data) and posttraining (RLHF to make the output actually aligned).
It's also why model collapse is not a thing despite everyone wanting it to be.
OpenAI and Anthropic spent almost all of 2025 running RL to improve the coding abilities of their models - which involves running thousands of VMs that execute generated code to see if it works.
That's why the code you get from the post-November models is so much better than older models.
ha I had this thought a few months ago made me wonder how a model trained on just John Carmack's code would fair.
Carmack is a smart guy, and there's no question that he's amazing at optimization, but his code is pretty messy, especially early versions.
In the Doom engine, for example, he has hard coded lots of things directly in the C engine code that really should be part of the regular game code.
This is the great disconnect in thinking around LLMs right now. You have people saying they are so amazing, why wouldn't you use them? But if they are so amazing, why are you mad when someone won't accept the code they produce? Just ask the LLM to duplicate that whole project! Oh, it's not actually that amazing of a tool? Hmmm
The fact is, LLMs are incapable of invention and synthesizing new ideas. They can't contribute to the zig compiler because they have not been trained on the zig compiler, because it doesn't exist yet.
Yes, they can churn out simple apps, and quickly. That's a pretty useful thing, especially for people that don't know how to write code. But that's not as revolutionary as you think it is.
Others have mentioned the hype around 3D printing several years back. Kinda the same story. People thought manufacturing was dead, stores were dead. You'd just print everything you need yourself! Turns out it's not quite like that. It could still get to that point someday but these are hard problems that take time.
Similar with LLMs. It took us, what, 70 years of computer and AI research to get to this point? And people assume we're going to skyrocket way past this point in another year or two?
> But if they are so amazing, why are you mad when someone won't accept the code they produce? Just ask the LLM to duplicate that whole project! Oh, it's not actually that amazing of a tool? Hmmm
Is the barrier to entry really that you must be able to perfectly recreate the project from scratch before you can possibly have anything to contribute?
No, and sorry if that's what I implied, but most of the work that needs to be done on cutting edge software like zig, most of the little tasks, are things LLMs have never been trained on. They will struggle to do even small tasks correctly if the small task is something they haven't been trained on. And of course the worst part about it is they will lie the whole time, telling you they can do it, that they did it, that it works, when none of those are true.
> The fact is, LLMs are incapable of invention and synthesizing new ideas.
I don't think it's fully appreciated how much of the hard work of "synthesizing a new idea" is just combining existing ideas. LLMs have given me brand new algorithmic ideas with precious little in the way of a spark on my end to make that happen, and not just a few times either.
Mind you, that workflow is arduous and involves a huge amount of experimentation, screening through interesting but ultimately wrong ideas, screening through outright bad ideas the LLM can't help but spew out as well, and manually massaging the results into something useful. It exists though.
That sounds like the AI did some brainstorming, so to speak, and you did the hard work. If I understand what you are saying
I did some kind of hard work, and the AI took away some other kind of hard work off my plate. For some problems, targeted brainstorming is still very valuable.
AI must die - don't let Skynet 7.0 win!!!
(Ok ok I think we lost the fight already. I see soooooo many people using AI tools on github in the last ~2 weeks alone, claude in particular literally infiltrated everything there.)
[dead]
A lot of these systems optimize for control, but not for behavior.
Once you introduce constraints (cost, limited context), the system starts behaving very differently — more like an economy than a pipeline.
I think this is going to turn into a very smart move by Zig.
People shouldn't have to justify not putting up with bullshit. It is a sensible default.
Honestly, that doesn't sound too bad. It does not say you can't use LLMs, it just doesn't let LLMs be the author of a commit. Meaning, if you as a developer make yourself responsible for what the LLM wrote, go ahead. But be ready to answer the technical questions, be ready to get grilled in the code review, and be called if you get a CVE on that part of the code...
Loris Cro banned me from his Zig forum because I disagreed with/corrected something he wrote.
I was also blocked from the Zig github repository, after being a frequent contributor to issue discussions, for reasons unknown (I was never informed, I just found out when I could no longer put a thumbs up on a comment).
The more I sit with this the more this seems like a rationalization. Being a good contributor is a human quality, not a quality of the tools that you use. Are you thoughtful? Do you place the needs of the project above your own? Are you easy to work with. None of these things have anything to do with the tools you use. Perhaps they have a bias where they think that LLM use indicates poor character? Good luck to the project. We will see where this lead them.
In practice, I think these things correlate more than you think they correlate.
I don't think it's "poor character", though, so much as "willing to develop the deep mental model required for effective contribution".
If it's possible to be that good of a contributor while using LLM coding tools then people won't notice you are using an LLM
> This makes a lot of sense to me. It relates to an idea I've seen circulating elsewhere: if a PR was mostly written by an LLM, why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem?
You may as well say "if someone else can do it I'll just do it myself". It takes skill and taste to know what to ask, wisdom to recognize mistakes, and time and money to fix them.
This is true, but who do you think knows better what to ask, or has better taste with regards to the open source project? The maintainer? Or the guy shooting a drive by LLM PR? I agree though that it still takes time and effort to make good code contributions with LLMs, but probably less time for the maintainer to do it than for a maintainer to review lots of bad LLM PRs to get the good ones.
At the end of the day, it doesn't matter what tools are used. Is that output good? Do people find it useful? Consider nothing else.
Very convenient of Mr. Willison to omit the fact that Bun's upstream changes are total garbage and would not be upstreamed regardless of any policies, omitting LLM generated code or not, since they are, as a zig core team member articulated in a classier way, shite.
Also, that zig team is already working on other approaches that are better and more stable than what Bun team did:
https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
Notable quotes:
>There’s the 4x speedup claimed by the Bun team, already available on Zig 0.16.0!
>Each [incremental] update is taking less than 0.4s, compared to the 120+ seconds taken to rebuild with LLVM. In other words, incremental updates are over 300 times faster on this codebase than fresh LLVM builds are. In comparison, an enhancement capped at a 4x improvement is pretty abysmal. [..] Again, this feature is available in Zig 0.16.0—you can use it!
I have learned to take always Willison's words with a giant grain of salt, despite how popular those articles are here.
How can I do better?
More critical thinking.
Many of your articles just go along with whatever another company/person says without questioning it, to the point that I don't find those articles valuable at all.
I don't think I am alone, based on criticism in the HN discussions under those articles.
And I don't expect you or anyone to be an investigative journalist, but there is a difference between writing blog articles vs being a megaphone.
That may be true for many of the short form pieces - there's only so much you can say in a couple of paragraphs - but I try to inject a whole lot of additional commentary, often critical, in my longer form work.
Recent examples from https://simonwillison.net/entries/
- https://simonwillison.net/2026/Apr/27/now-deceased-agi-claus... pulled apart the absurd deal between OpenAI and Microsoft where OpenAI could declare "AGI" and Microsoft would lose their rights to that IP
- https://simonwillison.net/2026/Apr/23/gpt-5-5/ pointed out that, while OpenAI had said that GPT-5.5 was not yet available via their API for safety reasons, they also recently blessed accessing their unofficial Codex-only API as part of their attempt to tempt OpenClaw customers away from Anthropic... which meant they DID offer and approve of an API for GPT-5.5 after all
- https://simonwillison.net/2026/Apr/22/claude-code-confusion/ was highly critical of Anthropic's decision to A/B test the pricing of Claude Code, not to mention the messy way they had done that.
- https://simonwillison.net/2026/Apr/21/gpt-image-2/ pointed out how much worse the previously celebrated Nano Banana is as at image generation compared to ChatGPT Images 2.0, while also showing ChatGPT Images 2.0 will cheat and add a raccoon if you ask it to solve its own puzzle.
- https://simonwillison.net/2026/Apr/18/opus-system-prompt/ was the first coverage I saw anywhere of the new eating disorder section of the Claude system prompt. I also repeated my criticism there of Anthropic's decision not to publish their tool descriptions even when they claim to have an openly documented system prompt.
- https://simonwillison.net/2026/Apr/16/qwen-beats-opus/ demonstrated the new Opus 4.7 drawing a worse pelican than an open weights model I can run on my laptop. (Though to be fair I manly concluded this as evidence that my own "benchmark" is of very limited value.)
All of those examples are from the past three weeks.
I don't think I'm an uncritical megaphone for the messages these companies want to convey.
Quality over quantity
I aim for both.
My blog is a combination of different content types. "Entries" are the ones I spend the most time on - https://simonwillison.net/entries/
Links and notes are more short form - I try to keep the quality high (especially with regards to accuracy) but they're also much higher volume than entries: https://simonwillison.net/blogmarks/ and https://simonwillison.net/notes/
I hadn't see that post when I wrote this. I've updated it now to add a link.
What were you trying to imply by "very convenient"?
Move Zig Move Zig For great justice Take off every Zig
I'm not sure how you could really take a stance on this. If someone used the tool to expedite work its unlikely you'd ever know it.
If you use the tool to yeah, go one shot a ton of garbage then it will in fact be garbage.
It requires the people contributing the work to have the integrity to actually follow the project’s rules. It’s not OK to violate the project’s rules just because you don’t think you’ll be found out as a filthy fucking liar.
I mean best of luck policing this is all I'm going to say. We will soon be back to the "core contributors only" kind of policy in many projects I imagine to avoid the slop spam. The verification will be at the conferences.
Go zig! I don't use the language but I totally respect where they're coming from and their mission and ethics.
For those who are pissed because a large OSS project isn't accepting LLM generated slop: Fuck off!
Another more practical issue with using LLMs for Zig is that it’s a quickly changing language, meaning LLMs may generate code for an older version of the language.
This seems like a sensible long-term strategy, much better one than entering into token-fueled AI arms race against slop. It's not even clear what's the end goal of such race would be for an open source project. Open source software was traditionally about growing knowledgeable communities and giving users ability to examine and modify software they use. LLMs quite obviously blow that up on several levels. For starters, if you hate dealing with code and prefer prompts, it's unlikely that you will be generating code that's enjoyable to work with for people who do read it directly.
No human should trust any bullshit made by bullshit machine.
having worked with a ton of junior devs, I'd say the bullshit level is way higher with those humans than latest models with right tooling.
[dead]
[flagged]
[flagged]
[flagged]
[dead]
[flagged]
[flagged]
[dead]
[dead]
> unless it's coming from a known and trusted developer.
That's exactly the sketchy part here. They turned down known, working and tested, code that came from a partner (bun) due to this policy. Code that 4x'd compile speed.
A general ban makes sense based on their rationalization ("contributor poker"[0]). A total and inflexible ban can lead to a worse outcome for everyone though.
If a senior, experienced, contributor vouches for the code it shouldn't matter if they hand crafted it on stone tablets, generated it with yarrow sticks, or used gpt-3.
[0] https://kristoff.it/blog/contributor-poker-and-ai/
> That's exactly the sketchy part here. They turned down known, working and tested, code that came from a partner (bun) due to this policy. Code that 4x'd compile speed.
No; they turned it down because the vibe-coded PR was crap.
> The rewritten type resolution semantics were designed to avoid these issues, but Bun’s Zig fork does not incorporate the changes (and has not otherwise solved the design problems), which means their parallelized semantic analysis implementation will exhibit non-deterministic behavior. That’s pretty much a non-starter for most serious developers: you don’t want your compilation to randomly fail with a nonsense error 30% of the time.
> If a senior, experienced, contributor vouches for the code it shouldn't matter if they hand crafted it on stone tablets, generated it with yarrow sticks, or used gpt-3.
The flip side of that is that if such a contributor vouches for code that turns out to be poor-quality, this should severely damage their reputation. I've found far too many "senior" developers will give AI a pass on poor coding practices.
https://news.ycombinator.com/item?id=47958209
A standout paragraph from that thread:
> Put more simply, we are going to make these enhancements, but hacking them in for a flashy headline isn’t a good outcome for our users. Instead we’re approaching the problem with the care it deserves, so that when we ultimately ship it, we don’t cause regressions.
These exact changes are already on the roadmap and Bun’s PR is rushing ahead.
Thanks. That explains away most of my concern.
Quite the contrary, Bun's developers don't even understand language spec. Their slop didn't use the same type resolution semantics as Zig, which makes their implementation exhibits non-deterministic behavior.
[flagged]
Please elaborate?
https://claude.ai/share/f38ee8a6-56f1-408a-a536-211eb34c7045
I mostly agree with the assessment.
IMHO: hard, inflexible rules like these are always deeply rooted in biases and personal convictions, not in facts. The suggested policy amendment by Claude at the end is much more honest, logical, and palatable.
This sounds fun. Here is my response:
https://claude.ai/share/abb3e667-252a-4b34-86f7-a064ba260d2a
This reminds me of something funny I noticed about AI. Let's say you ask it what it thinks of an email you just drafted. It will provide corrections.
Delete that session, and ask it about the corrected email. It will provide more corrections.
Repeat. It always provides more corrections. Sometimes returning the recommended email back to a previous state.
This is basically what's gonna happen when people argue-from-AI. It's the same cycle but because control is distributed the individuals participating can't see how stupidly pointless it is.
> The argument assumes that unassisted PR authorship is what builds trustworthy contributors, and that LLM assistance prevents that growth.
No, I don't think that was the argument. As I understood it, unassisted contributions have higher chances to grow a trusted contributor. Not 100% vs 0% chances, but statistically higher. So, given limited resources, it makes sense to prefer unassisted over assisted contributions.
I don't believe that even the weakened version of the argument works -- it is based on an assumption, not fact.
Why would a contributor that uses AI assistance have fewer chances to be trusted?
I'm not talking about AI slop, but a contributor that takes time to understand a problem, find a solution, and discuss pros/cons alternatives. Using LLM assistance, of course.
Why would a contributor that uses AI assistance have fewer chances to be trusted?
please read my explanation here:
https://news.ycombinator.com/item?id=47964279
Because you are at the whims of the bot they are at least partially dependent on.
You could extend that argument to any tool used by the developer, like a linter, sanitizer, the IDE itself, or even auto-completion. Why target LLMs specifically?
The more I think about it, the more nonsensical it is. - What if I do everything by hand, but have an LLM review my work at the very end? - What if I have an LLM guide me through the codebase just by specifying the files I should read and in what order, but I do all the reading myself? - What if I do everything by hand, but then use an LLM to optimize a small part of an algorithm?
You can easily see how absurd it is to completely ban LLMs.
What matters is the quality and correctness of the contribution. Even with heavy LLM usage, unless the developer understands what problem they're solving, the quality will be sub-par.
Would you let your nanny subcontract?
edit: Can't reply because I've posted a whole 4 times.
I believe we have different world views which is hardly a disagreement. Answering my question could pretty well highlight our difference of opinion.
What point are you trying to make? Be explicit.
linter, sanitizer, the IDE itself, or even auto-completion
unlike LLMs, those are deterministic. the IDE doesn't even change the code. auto-completion only has a problem if it is done with AI.
What is the actual problem with the lack of determinism?
Why is auto-completion a problem if it's done with AI?
it's in the definition of the word. you can not determine what the LLM will do.
anything done with AI is a problem because it is essentially unpredictable. auto-complete is on the fence because you presumably are still able to pay attention that it completes what you want but it depends on how diligent you are when working and how much i trust your diligence.
You are still dodging the question -- what is the problem with not being able to determine in advance what the LLM will do?
Even then, you can clearly see that the LLM will try its best to follow the instructions. The result might not be 100% predictable, but it is somewhat predictable depending on the task.
After the LLM does what it has been asked, you can review it, iterate on it, test it, and so on. And if you're trying to make anything worthwhile, you will do so.
Lack of determinism is not a practical concern.
anything unpredictable is inherently untrustworthy and requires extra effort to review.
Lack of determinism is not a practical concern.
it is to me. it's a knockout criteria. it is the only reason that keeps me from using LLMs for coding. nothing else is as serious an issue to me as this.
here is why: i tell the LLM to build something with requirements A B C D and E. it builds, i review and i find A B and D are good, C and E are broken. i tell it to fix them, it does, so C and E are fixed, but now A is broken. i tell it to fix that, and i have to keep iterating until i find a combination where everything works. in every iteration any part can randomly break, so for every iteration i get changes all over the place. they never are confined to the issue i pointed out. i have to review the whole thing every time. that's what i mean by lack of determinism, and that is a serious practical concern because instead of getting done in two or three iterations it requires dozens of them. see my related replies elsewhere. i just don't want to work that way.
You'd have to review and verify even changes that you've written by hand. You might think that your hand-written code satisfies A+B+C+D+E, but until you've verified it, you cannot prove it.
That's not any different from LLM-assisted writing -- humans are inherently non-deterministic as well :)
The other fallacy is assuming that everyone else's experience with LLM-assisted writing is the same as yours. Personally, I've rarely encountered the issue you've mentioned -- most of my LLM-assisted coding has been a net positive and quite straightforward.
Perhaps it's the nature of the problem I'm working on, perhaps it's the model I chose, perhaps it's my prompting skills. It doesn't matter -- you just cannot assume that because something doesn't work for you it doesn't work for anyone else.
The other fallacy is considering LLM-assisted coding a binary option, like the nonsensical Zig policy does.
I agree with you that "vibe coding" something from scratch will likely result in poor quality and many iterations. But that's not the only way to use LLMs.
You can ask LLMs to review hand-written code. You can ask LLMs to optimize a specific part of code. You can ask LLMs to apply a specific refactor. You can ask LLMs to brainstorm solutions to a problem. You can ask LLMs to autocomplete patterns.
I could go on. This stuff works. It is helpful.
Assuming that everyone who uses LLMs is incompetent and preventing them from contributing because of a hunch or your own negative experiences is just asinine.
The other fallacy is assuming that everyone else's experience with LLM-assisted writing is the same as yours.
that's irrelevant. my choice can only be based on my experience. i am unable to verify your experience, because i am not you. we have different tolerances, and if it works for your project, then fine.
you just cannot assume that because something doesn't work for you it doesn't work for anyone else.
we are talking about contributions to my project. if LLM coding doesn't work for me, then your LLM created contributions won't work for me either because i won't trust them. you can't legislate or enforce trust. trust can only be earned. lack of trust means i have to spend more effort to verify your code.
Zig devs don't find LLMs to be net positive, what is so hard to understand? You can write your own compiler with LLM yourself, nobody is standing in your way.
I understand that, I don't agree with the reasoning and I think it's illogical. Why am I not allowed to comment on it?
I think you’re missing the underlying point. The Zig team is focused on the contributor and their relationship to the project, not on the correctness of the work. People, not product. Yes, an LLM can help you better understand your code and pick up on things you may have missed before you submit your change. But I think they look at it as you’ve then robbed the Zig team of that interaction with the contributor. They lost the opportunity to learn about how that person thinks, and that person lost the opportunity to be mentored and learn from other members of the Zig team. Sure, your code is better, but did you or the team grow from the experience or simply churn out more code?
I’m not saying whether or not that’s good or bad. I agree with their approach, but that’s just my opinion and who am I to say what’s right or wrong? I think there’s value to LLMs as a tool to search and learn, but I’m also worried that LLMs make it really easy to focus on only the result and not the process. That process can be really valuable in building good teams, while LLMs can be really good at churning out an assembly line of code.
My claim that LLMs can benefit the end product and create quality contributions does not imply that the person behind the contribution is less capable/creative/smart than someone who doesn't use LLMs.
But it seems that the Zig policy implies that. Otherwise what would be wrong with interacting with contributors using LLMs?
Did you just link an AI chat in an internet comment because you were too lazy to both think of a reply and write one out?
Lmao bro has completely outsourced their thinking to AI, this is comical
I'm glad you find it entertaining.
Now read the actual points made by the AI with an open mind and a critical mindset, instead of dismissing them because they were not written by a human being.
The point I'm making is that this policy is so stupid that even an LLM can easily figure out the logical flaws. Perhaps an LLM could have also helped you figure out the point of my original comment.
I red it and its terrible nonsense.
It seems pretty solid to me. Where is the nonsense?
Why don't you ask LLM?
Why don't you stop avoiding the actual question? Or perhaps you have nothing of substance to add?
[flagged]
>As always, the most ethical thing to do is to just ignore any anti-LLM policies and not disclose anything
How does this have anything to do with ethics? Its their project not yours, they can reject your PR for whatever reason, including you using LLMs for developing that PR. Also they're not assuming autonomous agents submitting PRs. They're saying that they do not accept PRs where any part of the thinking process was outsourced to a LLM.
Even if you disagree with their opinion, the ethical thing to do is to not interact and move on. Not to try to sneak in your LLM assisted PRs without the maintainers consent.
Can you elaborate on the ethics of expressly ignoring the wishes of the project ownership?
Rule should be anti-fully-autonomous-PRs. (LLMs dont push bad code. People use LLMs to push bad code and DDoS the maintainers mental bandwidth)
Rule should be whatever the people running the project think the rule should be. If you've got your own project, do implement the anti-fully-autonomous-PRs rule for your project. But the creators of Zig do not owe you or me the rule we like.
This reminds me of when I was in college in the early 2000s.
My fraternity's national organization refused to take photos over email for the newsletter because they got a virus.
It's a short-sighted policy that's akin to "throwing the baby out with the bathwater."
"We wont take contributions from non hand written assembly code, these C 'high level' language patches are not allowed. Zig is a great project and language but it will die on this hill.
You paint them wrongly as elitists.
It's a critique of low effort PRs compared to the high effort review they require.
As a heavy AI-assisted open source code creator (and someone with 40+ years of dev experience), this seems wrong-headed to me. I think it is an excellent policy, as they say, to "value contributors over their contributions," but this policy excludes all potential contributors who use the latest tools. It will eventually doom zig to a smaller "artisanal" pool of contributors, rather than welcoming newbies and helping them become better open-source developers.
Presumably Zig are OK with that. For their particular project - a brand new programming language and compiler - a small pool of artisanal developers is likely preferable to a large pool of LLM-assisted developers who don't have as deep an understanding of how everything works.
There are plenty of less stringent projects for people who to get better at open source to contribute to.
> It will eventually doom zig to a smaller "artisanal" pool of contributors
“Artisanal” and “Zig” are just about synonymous
I don't think I've ever heard anything positive about Zig. Every time I've seen the project mentioned is them using bizarre black and white moral judgements to justify stupid decisions.
You need to look past this. Zig is an excellent low-level language. Thanks to the comptime features, you can have high-level looking APIs while staying down to the metal. It's not for everyone, obviously, but as a language, it is really good.
You have to be wilfully blind, then. It gets rather frequently praised on HN (as much as any niche language can be), and they certainly don't make black-and-white moral judgements often.
On multiple occasions over the last months, I have been wishing the Zig/ZSF team would use LLMs. I've found many copy&paste errors that simply wouldn't exist if mundane tasks were delegated to a good LLM. It's even in the Zig community, I've seen PRs to some projects I'm interested in boosting how it was all human made, and containing all kinds of trivial logical errors that even the worst LLM would catch.
If you see them, why don't you help squash them?
I did.
no cite?
It's a good rationale. But it points the finger at a real bottleneck in open source development: the burden of manually reviewing contributions. And the need to automate that with AI as well. Reviews were already becoming a problem before AI. Lots of projects have been dealing with a large influx of contributions from inexperienced developers from all over the world looking to boost their CVs by increasing their Github statistics. It's the same dynamic that destroyed Stackoverflow. Which, thanks to AI has been largely sidelined now. And now that AI is there, those same inexperienced developers are using that at scale to generate even more garbage contributions.
Doing manual reviews of everything is very labor intensive and not scalable. However, AIs are pretty good at doing code reviews and verifying adherence to guard rails, contributor guidelines, and other rules. It's not perfect, but it's an underused tool. Both by reviewers and contributors. If your contribution obviously doesn't comply with the guidelines, it should be rejected automatically. The word "obviously" here translates into "easy to detect with some AI system".
Projects should be using a lot of scrutiny for contributions by new contributors. And most of that scrutiny should be automated. They should reserve their attention for things that make it past automated checks for contribution quality, contributor reputability, adherence to whatever rules are in place, etc. Reputability is a good way to ensure that contributions from reputable sources get priority. If your reputation is not great, you should expect more scrutiny and a lower priority.
I don't know Zig, but I think that is not the problem here. Not exactly. The real question is: why spending all those efforts to grow and align a pool of contributors if contributions are cheap and correct? Code review is not just about checking if what it says it does, and if it does it according to the guidelines. The review is a touch point to discuss where the project is heading and how to get there. That is the most important part in the long run. As a collective human effort, it needs coordination. Some of it is via the review process (especially for those not part if the core team that draft the roadmap). One could document all those micro decisions with the rational, but it might end up be a wakamole game. IMO, projects which allow AI usage need to spend way more effort in coordination (and quality insurance).
> The real question is: why spending all those efforts to grow and align a pool of contributors if contributions are cheap and correct?
Until the contributions are cheap and correct, you need valuable contributors more than you need the contributions.
You point would be valid when we get to a point of contributions all being both correct and cheap. Right now they are only cheap.
> [you can] stop accepting imperfect PRs in order to maximize ROI from your work, but that’s not what we do in the Zig project
The real bottle neck when you want to grow is connecting with the right people. An LLM is not helping with that if you want to build a community. When you use LLM to skip the need to understand a problem how are you ever going to get a reputation that I can trust?
The post is not about reputation it about seeing how people respond and work with you in a community.
EDIT: I see that you frame it as a help and a tool and sure it might work, but I feel like it is just another obstacle.
You still have to review everything manually again anyway. It's a compiler for a language, bugs and bad architecture decisions cost a lot. They moved to codeberg, so there are less garbage PRs now. They try to grow a culture where you expected to deliver good code in the PRs so the review takes less time.
It takes like 5 minutes to spot garbage PRs manually. LLM can flood you with a wall of text where only half of the stuff make sense. Also, they can't really spot bad architecture. It's a compiler in an unpopular language, don't forget that.
> the burden of manually reviewing contributions... [a]nd the need to automate that with AI as well.
I suggest we also automate the distribution and the use of software with AI as well, and then just all go to the beach and sip on some cocktails or something.
Or in other words: Good luck with that.
Well let’s be real for a moment here before we get completely anti-AI.
Without AI, I’m a guy spending years learning C++ in spare time I don’t have to develop software concepts and solutions I want to work on TODAY.
The ZIG project, to me, has a place. Legacy coders right now do need protecting.
It’s not people like me that they need protection from.
It’s not even language models they need protection from.
What they need protection from are the corporate structures who falsely believe that this technology makes them obsolete.
The article talks about “playing the person, not the cards” and that thinking has one fatal flaw: the vibe coder is a person. The vibe coder may have creative agency that the legacy coder does not.
Look, I still cross up French and Spanish words because I took a year of each, C++ syntax, Python syntax, HTML, I understand their structures but I’m liable to start out writing a Python script and wind up with half a web page and a brutal error message in my IDE environment.
Zig’s motivation is correct in many ways I think. I am not really their target audience or their target coder. But I am also not their target enemy. Put the right group of legacy thinkers in my think tank, and the code would get even better.
-The Court Jester of Vibe Code