Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

simonwillison.net

Post reply on HN
Print view View original

411–420 of 496 posts

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

#411

Post by ragall »

aerhardt wrote: post #403
hirako2000 wrote: post #207

Earlier quoted context omitted.

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…

Working long hours due to incompetence is not a good thing.

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

#412

Post by schmichael »

zeeveener wrote: post #387
jmcqk6 wrote: post #320

Earlier quoted context omitted.

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…

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.

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

#414

Post by umvi »

krupan wrote: post #384
umvi wrote: post #325

Earlier quoted context omitted.

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

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.

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

#415

Post by mexicocitinluez »

fibonacci_man wrote: post #255
mexicocitinluez wrote: post #200

Earlier quoted context omitted.

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

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?

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

#416

Post by pelasaco »

esafak wrote: post #286
pelasaco wrote: post #146

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.

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.

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

#417

Post by 10000truths »

jmcqk6 wrote: post #320
zeeveener wrote: post #313

Earlier quoted context omitted.

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

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.

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.

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

#418

Post by mexicocitinluez »

tovej wrote: post #250
mexicocitinluez wrote: post #200

Earlier quoted context omitted.

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

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.

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

#419

Post by pelasaco »

jbxntuehineoh wrote: post #342
secondcoming wrote: post #179

Earlier quoted context omitted.

"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

the multiple layers of vibe, makes the dozen of code bases even harder to maintain.

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

#420

Post by vatsachak »

switchbak wrote: post #405
vatsachak wrote: post #370

Earlier quoted context omitted.

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

Post reply on HN