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

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

anthropic.com

Post reply on HN
Print view View original

431–440 of 787 posts

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

#431

Post by kortilla »

typ wrote: post #364
nomel wrote: post #298

Earlier quoted context omitted.

I would claim that LLMs desperately need proprietary code in their training, before we see any big gains in quality. There's some incredible source available code out there. Statistically, I think there's a LOT more not so great source available code out there, because the majority of output of seasoned/high skill developers is proprietary. To me, a surprising portion of Claude 4.5 output definitely looks like studen…

I'd bet, on average, the quality of proprietary code is worse than open-source code. There have been decades of accumulated slop generated by human agents with wildly varied skill levels, all vibe-coded by ruthless, incompetent corporate bosses.

It doesn’t matter what the average is though. If 1% of software is open source, there is significantly more closed source software out there and given normal skills distributions, that means there is at least as much high quality closed source software out there, if not significantly more. The trick is skipping the 95% of crap.

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

#432

Post by bdangubic »

svieira wrote: post #418
bdangubic wrote: post #379

Earlier quoted context omitted.

name one with comparable number of users and revenue? not saying you are wrong but I would bet against the outcome

Enron

I should have guessed someone would answer this question in this thread with Enron :)

I did not ask for random company that went under for any reason but specific question related to users and revenue.

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

#433

Post by kaibee »

FeepingCreature wrote: post #186
kgeist wrote: post #174

Earlier quoted context omitted.

A lot of the internet is duplicate data, low quality content, SEO spam etc. I wouldn't be surprised if 1 TB is a significant portion of the high-quality, information-dense part of the internet.

I would be extremely surprised if it was that small.

Well, a terabyte of text is... quite a lot of text.

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

#434

Post by casey2 »

Interesting that they are still going with a testing strategy despite the wasted time. I think in the long run model checking and proofs are more scale-able.

I guess it makes as agents can generate tests, since you are taking this route I'd like to see agents that act as a users, that can only access docs, textbooks, user forums and builds.

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

#435

Post by nextos »

dcre wrote: post #412
nomel wrote: post #298

Earlier quoted context omitted.

I would claim that LLMs desperately need proprietary code in their training, before we see any big gains in quality. There's some incredible source available code out there. Statistically, I think there's a LOT more not so great source available code out there, because the majority of output of seasoned/high skill developers is proprietary. To me, a surprising portion of Claude 4.5 output definitely looks like studen…

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 solutions [1]. Otherwise, a gigantic software artifact such as a compiler is going to have a critical correctness bugs with far-fetched consequences if deployed in production.

Right now, I think treating a LLM like something different than a very useful information retrieval system with excellent semantic capabilities is not something I am comfortable with.

[1] https://risemsr.github.io/blog/2026-02-04-nik-agentic-pop

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

#436

Post by shakna »

signatoremo wrote: post #304
shakna wrote: post #212

Earlier quoted context omitted.

Well, "Reimplement the c4 compiler - C in four functions" is absolutely something older models can do. Because most are trained, on that quite small product - its 20kb. But reimplementing that isn't impressive, because its not a clean room implementation if you trained on that data, to make the model that regurgitates the effort.

> Well, "Reimplement the c4 compiler - C in four functions" is absolutely something older models can do. Are you sure about that? Do you have some examples? The older Claude models can’t do it according to TFA.

Not ones I recorded. But something I threw at DeepSeek, early Claude, etc.

And the prompt was just that. Nothing detailed.

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

#437

Post by vbezhenar »

icedchai wrote: post #394
qarl wrote: post #383

Earlier quoted context omitted.

A compiler that can build linux. That level of quality should be sufficient. Do you know any low quality programmers that write C compilers in rust THAT CAN BUILD LINUX? No you don't. They do not exist.

Yep. Building a working C compiler that compiles Linux is an impossible task for all but the top 1% of developers. And the ones that could do it have better things to do, plus they’d want a lot more than 20K for the trouble.

What's so hard about it? Compiler construction is well researched topic and taught in the universities. I made toy language compiler as a student. May be I'm underestimating this task, but I think that I can build some simple C compiler which will output trivial assembly. Given my salary of $2500, that would probably take me around a year, so that's pretty close LoL.

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

#438

Post by qarl »

ThrowawayR2 wrote: post #429
bdangubic wrote: post #348

Earlier quoted context omitted.

> On top of that, Anthropic is losing money on it This has got to be my favorite one of them all that keeps coming up in too many comments… You know who also was losing money in the beginning?! every successful company that ever existed! some like Uber were losing billions for a decade. and when was the last time you rode in a taxi? (I still do, my kid never will). not sure how old you are and if you remember “facebo…

Anyone remember the dotcom bust?

Oh yeah, I do. That whole internet thing was a total HOAX. I can't believe people bought into that.

Can you imagine if Amazon, EBay, PayPal, or Saleforce existed today?

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

#439

Post by shakna »

TheCondor wrote: post #422
shakna wrote: post #200

Earlier quoted context omitted.

> Opus was unable to implement a 16-bit x86 code generator needed to boot into 16-bit real mode. While the compiler can output correct 16-bit x86 via the 66/67 opcode prefixes, the resulting compiled output is over 60kb, far exceeding the 32k code limit enforced by Linux. Instead, Claude simply cheats here and calls out to GCC for this phase Does it really boot...?

The assembler seems like nearly the easiest part. Slurp arch manuals and knock it out, it’s fixed and complete.

Huh. A second person mentioning the assembler. Don't think I ever referred to one...?

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

#440

Post by MaskRay »

silver_sun wrote: post #427
MaskRay wrote: post #366

Earlier quoted context omitted.

I want to verify the claim that it builds the Linux kernel. It quickly runs into errors, but yeah, still pretty cool! make O=/tmp/linux/x86 ARCH=x86_64 CC=/tmp/p/claudes-c-compiler/target/release/ccc -j30 defconfig all ``` /home/ray/Dev/linux/arch/x86/include/asm/preempt.h:44:184: error: expected ';' after expression before 'pto_tmp__' do { u32 pto_val__ = ((u32)(((unsigned long) ~0x80000000) & 0xffffffff)); if (0) {…

They said it builds Linux 6.9, maybe you are trying to compile a newer version there?

git switch v6.9

The riscv build succeeded. For the x86-64 build I ran into

    % make O=/tmp/linux/x86 ARCH=x86_64 CC=/tmp/p/claudes-c-compiler/target/release/ccc-x86 HOSTCC=/tmp/p/claudes-c-compiler/target/release/ccc-x86 LDFLAGS=-fuse-ld=bfd LD=ld.bfd -j30 vmlinux -k
    make[1]: Entering directory '/tmp/linux/x86'
    ...
      CC      arch/x86/platform/intel/iosf_mbi.o
    ccc: error: lgdtl requires memory operand
      AR      arch/x86/platform/intel-mid/built-in.a
    make[6]: *** [/home/ray/Dev/linux/scripts/Makefile.build:362: arch/x86/realmode/rm/wakeup_asm.o] Error 1
    ld.bfd: arch/x86/entry/vdso/vdso32/sigreturn.o: warning: relocation in read-only section `.eh_frame'
    ld.bfd: error in arch/x86/entry/vdso/vdso32/sigreturn.o(.eh_frame); no .eh_frame_hdr table will be created
    ld.bfd: warning: creating DT_TEXTREL in a shared object
    ccc: error: unsupported pushw operand
There are many other errors.

tinyconfig and allnoconfig have fewer errors.

    RELOCS  arch/x86/realmode/rm/realmode.relocs
    Invalid absolute R_386_32 relocation: real_mode_seg
Still very impressive.
Post reply on HN