[neomantra]

One non-obvious reason is that an important aspect of their community is to shepherd new contributors [1]. LLMs crushing everything would reduce that. More obvious is all the toil for maintainers dealing with LLM PRs (broadly it’s an issue). The Zig maintainers prefer to put their energy into improving people and fostering those relationship.

[1] https://kristoff.it/blog/contributor-poker-and-ai/

[heavyset_go]

It's important that developers have an accurate mental model of how things work, are structured and why.

LLMs promote a decoupling of mental models and the actual codebase.

As much as some may want to believe, just reviewing what the LLM outputs is not equivalent to thinking about implementation details, motivations, exactly how and why things are, and how and why they work the way they do, and then writing it yourself. The process itself is what instills that knowledge in you.

[sucrosesucrose]

Exactly. This is what many ai-sloppers ignore. Mental models are crucial. Nothing substitutes for having the program itself in your brain and being able to "mentally debug" it when something breaks.

[bbor]

Well said! I don't think either party is really at fault here, but if Anthropic wanted to contribute non-negligible amounts of code over time then it's an absolute dealbreaker.

Sucks for people who were invested in contributing to Bun and don't like working with AI tools to be sure, but I think the writing was on the wall for them pretty much immediately post-acquisition. You must admit, it's hard to predict that 100% of source lines will be written by AI if you're not walking the walk!

[Dylan16807]

That's a solid reason to keep LLMs away from the kind of tasks that help with onboarding. But a patch series from a competent team that changes 3000 lines should probably be evaluated on its own merits. Or at least, the collaboration-based reasons to reject AI don't apply and the real reason would be something else.

(Though I don't know if this particular patch series would get accepted on its own merits.)

[riffraff]

The recent article explained the bun patch would have been refused on technical merits as it's intrinsically incorrect, to be able to work properly it required some language changes.

[bboozzoo]

> patch series from a competent team that changes 3000 lines should probably be

split into a bunch of much smaller changes?

[Dylan16807]

I don't understand your suggestion. If you take an ugly patch series that changes 3000 lines and organize it into small quality changes, it's still a patch series that changes 3000 lines.

There's no reason to assume my generic statement was talking about the ugly version rather than the nicely organized version.

[wolfi1]

perhaps not all of these 3000 line changes make sense?

[moomoo11]

I mean in an authoritarian system you wouldn’t make a one off exception like that.

[lowbloodsugar]

Yeah, I remember when the lazy bastards started writing programs using compilers instead of learning assembly language. Now I don’t have a single colleague who can write assembly. There’s whole generations now who can’t code assembly. Most don’t even know what a register is. Hope Zig holds against this latest attempt to make everyone stupid.

[uncircle]

To add to the other commenters, loads of people don’t know assembly, which speaks to the quality of the average developer. The ones that still understand assembly to this day tend to be better developers, writing faster and more efficient code.

[crysin]

I'd be very surprised if the "average" developer across the board was in fact not just a JavaScript / TypeScript only developer. I have no expectations or really even hope that the average developer I work with has ever written a line of assembly.

[DeathArrow]

>The ones that still understand assembly to this day tend to be better developers, writing faster and more efficient code.

That is if you use something like C, C+=, Java, .NET, Go. With Javascript and Python I don't think knowing assembly would make any difference because it's hard to optimize the code in these languages for how the CPU and memory works.

[uncircle]

Knowing assembly in this day and age is the result of being curious and wanting to understand how computers work, which means knowledge of algorithms, data structures, etc.

The same applies to vibe coding: the best "vibe coder" will paradoxically be the person with enough knowledge and curiosity to understand programming, how computer works and the subject at hand; one that could write the whole thing from scratch so they have enough judgement to review generated code.

Of course the vast majority will be mediocre vibe coders, and even worse programmers; at least that's the direction we're going.

[Chris2048]

> wanting to understand how computers work, which means knowledge of algorithms, data structures, etc.

It's possible to know in general terms, how computers work, and what assembly is without "knowing assembly" in the sense of being familiar with using/debugging it as a programming language.

[skydhash]

Knowing assembly doesn’t mean you would spend your time writing assembly (aka being familiar with opcodes and architecture optimizations). But in the process, you get familiar with the working of the computer hardware and the OS that sits on top of it. That is always useful knowledge especially when needing to deal with binary format and protocols or FFI.

[Chris2048]

> But in the process..

Then it's sufficient to know assembly, but not necessary.

This is compatible with "[developers] that still understand assembly to this day tend to be better developers", but not with "[on developers who] don’t know assembly, which speaks to [their] quality".

[gertop]

Your analogy falls apart because the "lazy bastards" still knew how to program and understood the code they were working on.

Vide-coders often don't read, let alone understand, the code they send for PRs.

[merlindru]

I don't think most JavaScript devs know how to read C code, let alone assembly, so I think the comparison is apt. Is it not?

[wtetzner]

The JavaScript developers are checking in JavaScript code that they ostensibly understand. That is not the same as prompting an LLM to generate Zig that they don't understand, and expecting someone to merge it.

[merlindru]

ah, i see what you're saying. fair point! though the argument was that LLMs essentially are a yet higher level programming language (or, rather, let you write in a higher level language).

[wtetzner]

They do let you write in a higher-level language, but it's not really analogous to a higher-level programming language. The ambiguity and lack of determinism makes prompting fundamentally different from using a high level programming language.

[gls2ro]

Generating AI code/PR is not the same as using compilers because of at least two things:

- the scale of how much and how fast you can generate code with AI vs how fast can you write code for compiler

- the mental model of what is being generated and how much the contributor understands and owns the generated code

[wtetzner]

Using an LLM isn't analogous to using a higher level language.

[brabel]

That’s funny because it’s exactly, literally the same. The difference is it’s not deterministic. That may be a problem but it’s still a higher level language, just a much higher level language than anything before.

[sandrello]

I assume you're some sort of programmer and I genuinely wonder how in the world can someone in good faith downplay non-determinism and ambiguity when talking about a programming language.

High-level languages can certainly yield inefficient code when compiled, or maybe different code among different compilers, but they're always meant to allow their users to know exactly what to expect from what they put together in their programs. I've always considered this a hard fact, I simply cannot wrap my head around working in a way that forces me to abandon this basic assumption.

[bigstrat2003]

> That’s funny because it’s exactly, literally the same. The difference is it’s not deterministic.

So it is not, by your own admission, "exactly, literally the same".

[amoss]

Take it gently, the poor thing doesn't understand the difference between code and talking about code.

[xigoi]

The main difference is that the input to an LLM is in an ambiguous language.

[brabel]

A programming language is allowed to be ambiguous, I don’t know of a definition that excludes that!

[xigoi]

All programming languages I know of provide at least some guarantees about the program’s behavior.

[skydhash]

The language specs may be, but an implementation is never ambiguous. When you encounter and undefined behavior in the specs, that’s when you look at your compiler/interpreter docs.

[a_shiine]

The kinda thoughts you form when you ever only vibe-coded

[newswasboring]

So is JavaScript haha.

[wiseowise]

So by your logic all the PMs, managers and customers are programmers, right? After all, there’s a human compiler that takes their input and produces a program?

[brabel]

They are programmers when they write a prompt and get runnable code as a result, yes… but no if asking a human to write the code because if you have an intermediate, manual step between the text and the running code, you don’t have an automated process and hence it’s no longer even an application, let alone a “compiler”.

[matt_kantor]

Why does it matter if a human or a machine is responsible for turning the prompt into code?

If there's a black box which I can send C code into one side of and get faithful machine code out the other, I'd call that box a "compiler". I wouldn't rename it if I later find out that there are little elves inside doing the translation.

[wiseowise]

There’s a big difference between (mostly) deterministic compiler and non-deterministic LLMs.