Hacker News Reader

Comment by Tiberium | Hacker News Reader

Plus some of the issues are clearly written with LLMs, and apparently there's an active contributor who has been using LLMs to translate comments and help with code - https://github.com/ZigEmbeddedGroup/microzig/pull/1087:

> Yeah we know you're working with an LLM. That is fine (imo), as long as you're not doing drive-by slop PRs. These have been rather good quality, and you've been testing on hardware (which is important)

So it feels odd for them to suddenly change from this (clearly working) setup.

View on HN

Keep in mind the project HAS just adopted the policy

My point is that it seems extremely strange to do that when they have developers who use LLMs already contribute to the project. I feel like they'll either alienate people who are interested, or just not care to enforce their no-LLM policy.

Said developers will decide: either fork or retire their LLMs. As simple as that. Nothing strange at all.

The productive ones will just fork and accelerate faster. I understand the need for the mental muscle, this framing just sounds terrible at this point. Something something human scrutiny is not even an option the people want to consider.

Let's see when they deliver real features alone which are widely adopted and battle-tested in production.

https://www.ign.com/articles/we-vibe-coded-a-new-epic-games-...

It's not hypothetical to say that an LLM can write widely adopted, battle-tested, production code.

Claude Code would be another example.

Linux is still mostly human, but even Linus Torvalds has warmed up to the idea that LLMs are tools a skilled user can use to contribute there.

There's a lot of quieter, private examples where some company rewrote their entire back-end or internal tooling with an LLM. You just tend not to hear about it because "we used AI" is currently negative marketing/PR, so why say it out loud?

Remember when the Claude Code devs compared their TUI to a game engine while trying to explain why it was so buggy and slow?

https://x.com/trq212/status/2014051501786931427

Remember, game engines can render millions of triangles per frame, and Claude Code struggles to render a few hundred characters on a monospace grid. I wouldn't hold it up as a shining beacon of quality.

> widely adopted

What a poor example. Epic Games’ launcher is popular despite its software, not because of it, and in large part because they give away free games every week.

> battle-tested

You’re just throwing words around. You can’t in good faith call something that is barely out “battle-tested”.

> Claude Code would be another example.

Claude Code is widely regarded as a mess and bad software, and for good reason (see sibling comment).

> The productive ones will just fork and accelerate faster.

Zig has had a similar policy for a while. Where are these myriad forks which accelerate faster, and the communities behind them?

Yeah, where are they?

Maybe people don't have a reason to write Zig code when rust or even C might do, and this could be that reason.

I've been very productive getting some Zig code to work with 0.17.0 and I really don't find a reason to contribute anything back given this policy.

Reply on news.ycombinator.com