Live data from Hacker News

The Zig project's rationale for their anti-AI contribution policy

simonwillison.net

81–90 of 496 posts

Re: The Zig project's rationale for their anti-AI contribution policy

#82
post #71

> 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…

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

Re: The Zig project's rationale for their anti-AI contribution policy

#83

Earlier quoted context omitted.

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 bug…

Yes, see e.g. a quarter-century-old (!!) https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Good read!

Re: The Zig project's rationale for their anti-AI contribution policy

#84
post #49

Earlier quoted context omitted.

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.

By using my brain.

Don't be ridiculous! We don't do that anymore.

Re: The Zig project's rationale for their anti-AI contribution policy

#85
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...

Re: The Zig project's rationale for their anti-AI contribution policy

#86
post #8

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 ha…

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.

Re: The Zig project's rationale for their anti-AI contribution policy

#87
post #49

Earlier quoted context omitted.

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.

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.

Post reply on HN