Live data from Hacker News

We tasked Opus 4.6 using agent teams to build a C Compiler

anthropic.com

601–610 of 787 posts

Re: We tasked Opus 4.6 using agent teams to build a C Compiler

#601

This is more an example of code distribution rather than intelligence. If Claude had NOT been trained on compiler code, it would NOT have been able to build a compiler. Definitely signals the end of software IP or at least in its present form.

In a weird sense Open Source won

Yep - its an interesting angle to look at it.

Or rather OpenSource might have just saved the world!

Re: We tasked Opus 4.6 using agent teams to build a C Compiler

#602

Earlier quoted context omitted.

Claude did not wrote it. you wrote it with PREVIOUS EXPERIENCE with 20.000 long commandshyellihg him exactly what to do. Real usable AI would create it with simple: 'make c compilers c99 faster than GCC'. AI usage should be banned in general. It takes jobs faster than creating new ones ..

That's actually pretty funny. They're patting it on the back for using, in all likelihood, some significant portions of code that they actually wrote, which was stolen from them without attribution so that it could be used as part of a very expensive parlour trick.

Did you do diffs to confirm the code as stolen or are you just speculating.

Re: We tasked Opus 4.6 using agent teams to build a C Compiler

#603
post #598

Earlier quoted context omitted.

This is already hyperbolic; in most countries where software engineers or similar knowledge workers are widely employed there are welfare programmes. To add to that, if there is such mass unemployment in this scenario it will be because fewer people are needed to produce and therefore everything will become cheaper... This is the best kind of unemployment. So at best: none of us have to work again and will get everyt…

If you were to rank all of the C compilers in the world and then rank all of the welfare systems in the world, this vibe-coded mess would be at approximately the same rank as the American welfare system. Especially if you extrapolate this narcissistic, hateful kleptocracy out a few more years.

[flagged]

Re: We tasked Opus 4.6 using agent teams to build a C Compiler

#605
post #547

Earlier quoted context omitted.

> It's still really, really impressive though. Do we know how many attempts were done to create such compiler before during previous tests? Would Anthropic report on the failed attempt? Can this "really, really impressive" thing be a result of a luck? Much like quoting Quake code almost verbatim not so long ago.

> Do we know how many attempts were done to create such compiler before during previous tests? Would Anthropic report on the failed attempt? Can this "really, really impressive" thing be a result of a luck? No we don't and yeah we would expect them to only report positive results (this is both marketing and investigation). That being said, they provide all the code et al for people to review. I do agree that an out o…

  > No we don't and yeah we would expect them to only report positive results (this is both marketing and investigation).
This is matter of methodology. If they train models on that task or somewhat score/select models on their progress on that task, then we have test set leakage [1].

[1] https://en.wikipedia.org/wiki/Leakage_(machine_learning)

This question is extremely important because test set leakage leads to impressively looking results that do not generalize to anything at all.

Re: We tasked Opus 4.6 using agent teams to build a C Compiler

#606
post #311

Earlier quoted context omitted.

> $20,000 set on fire To be fair, that's two weeks of the employer cost of a FAANG engineer's labor. And no human hacks a working compiler in two weeks. It's a lot of AI compute for a demo, sure. But $20k stunts are hardly unique. Clearly there's value being demonstrated here.

Yes a human can hack together a compiler in two weeks. If you can't, you should turn off the AI and learn for yourself for a while. Writing a compiler is not a flex; it's a couple very well understood problems, most of which can be solved using existing libraries. Parsing is solved with yacc, bison, or sitting down and writing a recursive descent parser (works for most well designed languages you can think of). Then…

> Parsing is solved with yacc, bison, or sitting down and writing a recursive descent parser (works for most well designed languages you can think of).

No human being writes a recursive descent parser for "Linux Kernel C" in two weeks, though. And AFAIK there's no downloadable BNF for that you can hand to an automatic generator either, you have to write it and test it and refine it. And you can't do it in two weeks.

Yes yes, we all know how to write a compiler because we took a class on it. That's like "Elite CS Nerd Basic Admission". We still can't actually do it at the cost being demonstrated, and you know it.

Re: We tasked Opus 4.6 using agent teams to build a C Compiler

#607

Earlier quoted context omitted.

Interesting, why impossible? We studied compiler construction at uni. I might have to dig out a few books, but I’m confident I could write one. I can’t imagine anyone on my course of 120 nerds being unable to do this.

You are underestimating the complexity of the task so do other people on the thread. It's not trivial to implement a working C compiler very much so to implement the one that proves its worth by successfully compiling one of the largest open-source code repositories ever, which btw is not even a plain ISO C dialect.

I didn’t say it was trivial. Just that I thought my course mates would be able to do it.

Re: We tasked Opus 4.6 using agent teams to build a C Compiler

#608
post #479
post #412

Earlier quoted context omitted.

This is dead wrong: essentially the entirety of the huge gains in coding performance in the past year have come from RL, not from new sources of training data. I echo the other commenters that proprietary code isn’t any better, plus it doesn’t matter because when you use LLMs to work on proprietary code, it has the code right there.

> the huge gains in coding performance in the past year have come from RL, not from new sources of training data. This one was on HN recently: https://spectrum.ieee.org/ai-coding-degrades Author attributes past year's degradation of code generation by LLMs to excessive use of new source of training data, namely, users' code generation conversations.

Yeah, this is a bullshit article. There is no such degradation, and it’s absurd to say so on the basis of a single problem which the author describes as technically impossible. It is a very contrived under-specified prompt.

And their “explanation” blaming the training data is just a guess on their part, one that I suspect is wrong. There is no argument given that that’s the actual cause of the observed phenomenon. It’s a just-so story: something that sounds like it could explain it but there’s no evidence it actually does.

My evidence is that RL is more relevant is that that’s what every single researcher and frontier lab employee I’ve heard speak about LLMs in the past year has said. I have never once heard any of them mention new sources of pretraining data, except maybe synthetic data they generate and verify themselves, which contradicts the author’s story because it’s not shitty code grabbed off the internet.

Re: We tasked Opus 4.6 using agent teams to build a C Compiler

#609

I spent a good part of my career (nearly a decade) at Google working on getting Clang to build the linux kernel. https://clangbuiltlinux.github.io/ This LLM did it in (checks notes): > Over nearly 2,000 Claude Code sessions and $20,000 in API costs It may build, but does it boot (was also a significant and distinct next milestone)? (Also, will it blend?). Looks like yes! > The 100,000-line compiler can build a bootab…

This is getting close to a Ken Thompson "Trusting Trust" era -- AI could soon embed itself into the compilers themselves.

Reminds me of https://www.teamten.com/lawrence/writings/coding-machines/

Re: We tasked Opus 4.6 using agent teams to build a C Compiler

#610
post #435
post #412

Earlier quoted context omitted.

This is dead wrong: essentially the entirety of the huge gains in coding performance in the past year have come from RL, not from new sources of training data. I echo the other commenters that proprietary code isn’t any better, plus it doesn’t matter because when you use LLMs to work on proprietary code, it has the code right there.

Progress with RL is very interesting, but it's still too inefficient. Current models do OK on simple boring linear code. But they output complete nonsense when presented with some compact but mildly complex code, e.g. a NumPyro model with some nesting and einsums. For this reason, to be truly useful, model outputs need to be verifiable. Formal verification with languages like Dafny , F*, or Isabelle might offer some…

Human-written compilers have bugs too! It takes decades of use to iron them out, and we’re introducing new ones all the time.
Post reply on HN