Live data from Hacker News

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

simonwillison.net

341–350 of 496 posts

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

#341
post #335

Earlier quoted context omitted.

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

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

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

#342

Earlier quoted context omitted.

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

"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

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

#343

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

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.

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

#344

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

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

#345
post #274
post #265

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.

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.

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

#346
post #173

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

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:

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

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

#347
post #151

Earlier quoted context omitted.

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…

> 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

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

#348
post #139

Earlier quoted context omitted.

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.

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

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

#349

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…

Pretty much sums up the LLM fanbase.

"I aM someWhAt oF a DeVelOpER MySelF"

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

#350
post #208
post #173

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

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

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.
Post reply on HN