GCC steering committee announces AI policy • Hacker News Board

Re: GCC steering committee announces AI policy

#151

Post by tavavex » Thu, Jul 30, 2026, 2:00 PM UTC

rurban wrote: post #44

javier_e06 wrote: post #17

The 3 big ones, Linux, GCC and Git require a human to vouch/explain the work in question. Once the 3 big ones start using LLM to review/accept the work for speed reliability sake, who knows what is going to happen.

Already happened. My AI coded C compiler already bypassed gcc in less failures, compiles 10x faster, and with their new policy they'll fall far behind.

Does your compiler replicate 100% of gcc's functionality? I've heard of similar compiler projects skimping on the lesser used functions and taking shortcuts. gcc is BIG.

But the real point is even if we get an ability to AI generate an accurate and fully-featured C compiler from scratch, everyone will keep using gcc. C compilers are solved, gcc is already here and it's pretty amazing. It's not flawed or in need of replacement, there's nothing for it to fall far behind on. We don't need another C compiler, the reason why AI users are attracted to the topic is just to "look ma, no hands!". And using gcc also ensures that I'm using something that has been looked at by thousands of qualified eyes in the past and will be looked at by thousands more for the foreseeable future. Will an AI compiler be comprehensible in ten years? Will every update be guaranteed to be better than the previous?

Re: GCC steering committee announces AI policy

#152

Post by htltzp » Thu, Jul 30, 2026, 2:02 PM UTC

Finally we have a large project where the developers have a spine. This is good for gcc and will attract intelligent people instead of the open source marketing drones (which unfortunately have taken over Linux).

Re: GCC steering committee announces AI policy

#153

Post by olalonde » Thu, Jul 30, 2026, 2:04 PM UTC

dijksterhuis wrote: post #135

olalonde wrote: post #122

Earlier quoted context omitted.

It's enough to tell you that, if it does happen, it must be quite rare and not a widespread systemic issue. It's also worth noting that Anthropic and co are so confident that it's a non-issue that they offer full copyright indemnification to their commercial users.

> It's enough to tell you that, if it does happen, it must be quite rare and not a systematic issue. alternative perspective: it's just taking time for the lawyers to figure out what they can sue them for.

Not sure I understand. If some company or open source project is violating your copyright, you sue them for copyright infringement, no?

Re: GCC steering committee announces AI policy

#154

Post by dgellow » Thu, Jul 30, 2026, 2:06 PM UTC

Given it is a GNU project, ie the free software ideology is an essential part of it, the guideline being focused on the legal ownership makes a lot of sense to me. Adding to the list of policies to follow over the next few years, it will be very interesting to see how they each evolve

Re: GCC steering committee announces AI policy

#155

Post by tossandthrow » Thu, Jul 30, 2026, 2:08 PM UTC

EvanAnderson wrote: post #134

tossandthrow wrote: post #104

Earlier quoted context omitted.

> Until very recently the norm has been that the vast majority of code had human eyes and hands on it. What quality does it have that humans had eyes on code? Elite teams likely still produce code of better quality with a higher qa bar than agentic code. But that category is dimishing everyday. The core point is that so much trust is reduced to "Joe in cubicle". Also a lot more than what he can carry. Most of the cod…

> What quality does it have that humans had eyes on code? The human who had their eyes and hands on the code has accountability. I think how accountability is going to work, in the case of LLM-generated code, is still an open question. (I dropped-on an edit to the parent comment to this effect, too.)

> The human who had their eyes and hands on the code has accountability.

They are not.

You can not go go back to a laid off person / one who quit and keep them accountable.

So this is absolutely not the case.

Devs are not accountable for their code.

Re: GCC steering committee announces AI policy

#156

Post by rurban » Thu, Jul 30, 2026, 2:09 PM UTC

ethin wrote: post #133

rurban wrote: post #44

Earlier quoted context omitted.

Already happened. My AI coded C compiler already bypassed gcc in less failures, compiles 10x faster, and with their new policy they'll fall far behind.

Prove it and that your compiler is fully C compliant and can handle all possible inputs GCC can accept (and optimize as well as GCC), then we'll talk. Only then will your compiler risk leaving GCC behind.

The proof is gcc's torture test suite. Have a look

Re: GCC steering committee announces AI policy

#157

Post by tossandthrow » Thu, Jul 30, 2026, 2:10 PM UTC

flohofwoe wrote: post #112

tossandthrow wrote: post #55

Earlier quoted context omitted.

You literally spend 99.999% og your time blindly trusting code - and that is only because I assume ymthat you write code yourself. For 99.999% of people, it is literally kthxbye on all code they execute on all their devices.

You sound like a webdev, e.g. the "let's just install 1000s of unvetted external dependencies" is nowhere else nearly as extreme as in web development land.

[flagged]

Re: GCC steering committee announces AI policy

#158

Post by rurban » Thu, Jul 30, 2026, 2:12 PM UTC

tavavex wrote: post #151

rurban wrote: post #44

Earlier quoted context omitted.

Already happened. My AI coded C compiler already bypassed gcc in less failures, compiles 10x faster, and with their new policy they'll fall far behind.

Does your compiler replicate 100% of gcc's functionality? I've heard of similar compiler projects skimping on the lesser used functions and taking shortcuts. gcc is BIG. But the real point is even if we get an ability to AI generate an accurate and fully-featured C compiler from scratch, everyone will keep using gcc. C compilers are solved, gcc is already here and it's pretty amazing. It's not flawed or in need of re…

Of course not. I don't care for gcc's broken optimizer to remove dead code without any warning.

gcc has too many bugs for my taste, sorry. And I don't want to wait 20m on gcc compilation, when tcc can do it in 1m.

Re: GCC steering committee announces AI policy

#159

Post by tossandthrow » Thu, Jul 30, 2026, 2:14 PM UTC

flohofwoe wrote: post #117

tossandthrow wrote: post #104

Earlier quoted context omitted.

> Until very recently the norm has been that the vast majority of code had human eyes and hands on it. What quality does it have that humans had eyes on code? Elite teams likely still produce code of better quality with a higher qa bar than agentic code. But that category is dimishing everyday. The core point is that so much trust is reduced to "Joe in cubicle". Also a lot more than what he can carry. Most of the cod…

It has nothing to do with 'elite teams', it has to do with decades long and very careful maintenance. It's too early to say whether LLM generated projects will ever reach that sort of maturity, most examples I've seen so far are basically "fire and forget". But lets talk again in one or two decades, maybe there will be counterexamples of successful open source projects which will be just as well llm-maintained as hum…

It really is not.

There are some areas that are critical and where software developers carefully will detail stear the work.

But the vast amount of software written, react components and rest endpoints, are very ripe to be entirely written by agents.

Re: GCC steering committee announces AI policy

#160

Post by [deleted] » Thu, Jul 30, 2026, 2:19 PM UTC

broodbucket wrote: post #3

This is a pretty good middle ground, I think. You can't prevent LLM usage and there's significant downsides to doing so universally, so restricting contributions to things that a human needs to demonstrably understand circumvents a lot of problems.

[deleted]