Anybody with the requisite domain knowledge using these tools can produce high-quality code with none of the obvious smells of vibe-coded slop.
That’s a rare exception, IME there are many more examples where people simply switch off their brains and don’t even review the generated code, not to mention thorough testing.
If I were the Zig team I would simply ban large feature contributions from ‘untrusted’ contributors, no matter if written by hand or code-generated via an LLM. Doing a thorough code review for large feature PRs from an ‘untrusted’ author is frankly a waste of everybody’s time. The more the author is trusted (via former contributions), the bigger PRs I would accept from that person.
I would also accept carefully reviewed and curated non-PR issues which point to bugs and performance improvement solutions which had been found by running an LLM-assisted bugscan over the code. Those bugs should have been confirmed and reproduced by a human before writing the ticket (e.g. filtered down to actual issues). E.g. in the case of the Bun project I would expect that they don’t dump a million-lines PR with all the LLM changes, but instead pick those changes apart, isolate the biggest performance contributors, figure out why the performance has improved in that specific place and turn that into one ticket per improvement which is easy to act on by the Zig team.
Running an LLM in “passive mode” (e.g. finding bugs, performance problems, and advicing on solutions) should be much less controversal than letting LLMs write actual code, also from a legal perspective.
I would always require disclosure whether LLM tools had been used though, and tbh outright banning LLM content might be the only option for a popular project like Zig to avoid getting overwhelmed with noise and not being able to pick out the actual signal anymore.
Can’t speak for the Zig team of course, but that’s how I would deal with it.