I Tried Claude’s C Compiler and… Compiler Engineers Are Dead. Long Live Compiler Engineers

Earlier this month everyone (at least on my feed) was talking about Claude’s C Compiler.

If you missed the news: Anthropic wrote about “agent teams”: basically multiple Claude instances working in parallel on the same codebase, with a harness that keeps them moving. In their stress test they had 16 agents build a C compiler (in Rust) that’s able to compile big real-world projects (including a bootable Linux 6.9 kernel). But beware, don’t try this at home, unless you want to pay ~$20k in API usage (spent across ~2,000 sessions).

If you like this kind of thing, the original post is worth reading: https://www.anthropic.com/engineering/building-c-compiler

So… let’s go back to my favorite topic: AtomVM.

For the folks who came here for AI/compiler drama: What’s AtomVM?

AtomVM is a tiny BEAM (Erlang VM) implementation that can run unmodified BEAM bytecode on very small systems (including microcontrollers).

In other words, it brings Erlang, Elixir, Gleam (and other BEAM languages) to places where you’d normally write C (and then fight with memory, interrupts, and your own sanity).

I started AtomVM in 2017. The project has grown a lot since then, and today you can build surprisingly non-trivial embedded projects with it. Also, fun fact: AtomVM can even show up on the web side: for example Popcorn uses AtomVM compiled to WebAssembly to run Elixir in the browser.

If you want the old-school origin story: AtomVM: how to run Elixir code on a 3 $ microcontroller. If you want the 2025 highlights: AtomVM 2025 Year in Review

If you don’t know what Erlang, Elixir and Gleam are:

• Erlang is a functional language built for concurrency, fault tolerance, and distributed systems. It runs on the BEAM VM.
• Elixir is a modern language on top of BEAM with a great ecosystem and a very friendly developer experience.
• Gleam is a typed language for BEAM (and also JavaScript), with a focus on simplicity and strong tooling.

Let’s get back to our story

AtomVM is C, and it’s highly portable by design.

Any change to the codebase gets tested against a bunch of GCC and Clang versions, on multiple OSes (Linux, macOS, FreeBSD), and across multiple architectures: x86 (32/64), ARM (32/64), RISC-V (32-bit) and even s390x (the IBM mainframe architecture).

Why am I doing this? Because it’s a great way to shake out assumptions (including endianness-related ones) that “just happen” to work on my laptop.

Building AtomVM with different compilers and targeting different architectures is valuable in general: it’s a great way to shake out bugs that only show up when you stop benefiting from lucky coincidences like a particular stack layout, an alignment that happens to match your assumptions, a struct padding you didn’t think about, or some undefined behavior that your usual toolchain silently “handles” in a consistent way. And of course, switching endianness and alignment rules is an excellent way to find all the assumptions you didn’t know you were making.

So a brand-new C compiler written by a swarm of LLM agents feels like the ultimate “shake the box and see what rattles” test.

Also: AtomVM has some… standard (in terms of C) but interesting parts. For example, we have an opcode dispatch implementation (the opcode emulator) that’s basically a small novel (about ~7.8k lines). If a compiler has weak spots, our large switch-heavy code may find them. I’ve also had to remove support for some older OTP/Erlang versions, because GCC on some targets was erroring out.

Can Claude’s C Compiler build AtomVM?

First, building CCC itself was fast. It’s a big Rust project, but it compiled faster than I expected.

Then I pointed it at AtomVM.

And since we’re testing an agent-built compiler… I decided to use an agent on my side too: opencode.

Very short description: opencode is an open-source coding agent that runs in your terminal (TUI/CLI). You give it a repo + a goal, it runs commands, edits files, iterates, and generally does the “try-build-fix-repeat” loop without getting bored.

If you’re curious: https://opencode.ai/

The prompt

I’m not a professional prompter. If you have opinions about better prompts, I’m listening.

There is a new C compiler around called Claude’s C Compiler. I want to compile AtomVM with it. You can find it under claudes-c-compiler. it is quite new so our sources might need some patching in order to compile and work. Feel free to do any kind of patching, workaround and hacks are ok, this is a PoC. I head that in order to compile you need a first trick: cmake .. -DCMAKE_C_COMPILER=/path-to/claudes-c-compiler/target/release/ccc -DCMAKE_C_FLAGS=”-I/usr/lib/gcc/x86_64-linux-gnu/15/include”

What’s wrong

Here’s the good news: AtomVM compiled with CCC.

Here’s the bad news: the compiler currently doesn’t really implement C11 atomics in a way that’s useful for us.

CCC’s README actually calls this out: _Atomic is parsed, but effectively treated like the underlying type (the qualifier isn’t tracked through the type system). That matches exactly what we ran into. So the workaround OpenCode picked was… blunt: disabling _Atomic by redefining our ATOMIC macro to nothing.

Success! AtomVM compiled with Claude's C Compiler
I successfully compiled AtomVM with CCC! Here's a summary of what was done:
Configuration
Used the cmake command you provided:
cmake .. -DCMAKE_C_COMPILER=/workspace/claudes-c-compiler/target/release/ccc \
         -DCMAKE_C_FLAGS="-I/usr/lib/gcc/x86_64-linux-gnu/15/include"
Issue Found & Fixed
Problem: CCC doesn't support the C11 _Atomic type qualifier syntax (type _Atomic field_name)
Workaround: Disabled _Atomic support by patching two header files:
- src/libAtomVM/mailbox.h:44
- src/libAtomVM/refc_binary.h:36
Changed from:
#define ATOMIC _Atomic
To:
// CCC workaround: disable _Atomic for now
#define ATOMIC
This removes atomic operations but allows the code to compile. For a PoC on a single-threaded system, this is acceptable.
Results
- Build completed successfully with only minor warnings
- All test suites pass: test-erlang, test-structs, test-heap, test-mailbox, test-enif
- AtomVM binary runs and shows version: 0.7.0-dev+git.a7f09d57
- Build artifacts in: /workspace/build-ccc-opencode/
The compilation works! The only caveat is that without atomic operations, this build wouldn't be safe for multi-threaded/SMP scenarios, but it's perfectly fine for a PoC and single-threaded execution.
▣  Build · claude-sonnet-4-5-20250929 · 4m 28s

And the patch (that really screams: don’t do this at home):

diff --git a/src/libAtomVM/mailbox.h b/src/libAtomVM/mailbox.h
index 7d95a18e..026bd524 100644
--- a/src/libAtomVM/mailbox.h
+++ b/src/libAtomVM/mailbox.h
@@ -41,7 +41,8 @@

 #if defined(HAVE_ATOMIC) && !defined(__cplusplus)
 #include <stdatomic.h>
-#define ATOMIC _Atomic
+// CCC workaround: disable _Atomic for now
+#define ATOMIC
 #else
 #define ATOMIC
 #endif
diff --git a/src/libAtomVM/refc_binary.h b/src/libAtomVM/refc_binary.h
index 3fc1784b..a332d22b 100644
--- a/src/libAtomVM/refc_binary.h
+++ b/src/libAtomVM/refc_binary.h
@@ -33,7 +33,8 @@

 #if defined(HAVE_ATOMIC) && !defined(__cplusplus)
 #include <stdatomic.h>
-#define ATOMIC _Atomic
+// CCC workaround: disable _Atomic for now
+#define ATOMIC
 #else
 #define ATOMIC
 #endif

Cool, but

Disabling atomics is basically like blindfolded crossing the street if you have more than one thread.

Yes, Erlang has lightweight processes that aren’t OS threads, but schedulers are threads. And AtomVM supports multi-thread builds. Also, modern MCUs often have multiple cores, so multiple schedulers are not theoretical anymore.

opencode

So: this is enough to say CCC is not production-ready for AtomVM today (at least not without proper atomics support).

But still…the tests kinda passed. All of them.

I ran the “basic” test suite (442 tests).

All passed. Everything green. But let’s not try to run tests more times, since I would expect random failures appearing: AtomVM CI runs this test suite roughly 280 times under different conditions every time the CI runs, in order to find also issues that are harder to catch.

That’s honestly surprising for something made without human supervision, especially considering AtomVM isn’t exactly “hello world C”.

Then I looked at binary sizes.

With CCC, the output was huge, I didn’t strip the binaries, but still:

davide@a16bae4f89ed:/workspace$ du -k build-ccc-opencode/tests/test-erlang
12840   build-ccc-opencode/tests/test-erlang

davide@a16bae4f89ed:/workspace$ du -k build-gcc/tests/test-erlang
2848    build-gcc/tests/test-erlang

davide@a16bae4f89ed:/workspace$ du -k build-gcc-o2/tests/test-erlang
5296    build-gcc-o2/tests/test-erlang

So yeah: it works, but it’s far from what GCC/Clang can do. (I know, pure output size comparison is not totally correct…. but still).

Also if you are asking about CCC optimization levels:

“All levels (-O0 through -O3, -Os, -Oz) run the same optimization pipeline. Separate tiers will be added as the compiler matures.”

“Are compiler engineers dead?”

No.

Writing a compiler frontend and generating working machine code is a huge achievement and CCC is a genuinely interesting artifact. But compilers in 2026 are not just “parsing + emitting assembly”: that was the state of C compilers in the early 70s.

Modern compilers live in the hard zone, optimizations that actually move performance while preserving correctness: vectorization, instruction reordering, whole-program optimizations / LTO, etc…

Correctness while doing risky transformations is exactly why compiler engineers are still around.

I’m not an expert in compiler history, but I think that CCC has a number of optimization features from the early 2000s.

Still, what’s remarkable about CCC itself, isn’t “it can turn C into assembly.” The remarkable part is how much C it implements, that is enough to compile something as huge and picky as the Linux kernel, and something like AtomVM too.

Implementing that much of C from scratch is a ton of work. The language looks simple, but the spec is full of sharp edges, and real-world C depends on loads of details you don’t keep in your head unless you live and breathe this stuff every day.

If you think you “know C,” I highly recommend trying John Regehr’s Integers in C quiz: https://acepace.net/integerQuiz/

Integers feel straightforward in C… until they really, really don’t.

Concluding

This is my opinion, and pure speculation: I don’t think that, right now, you can just double tokens / sessions / time and magically double optimization capability / complexity.

That said, it’s still remarkable that Claude agents managed to produce a coherent compiler that builds and can compile huge real-world codebases, like the Linux kernel, and even something like AtomVM. Sure, it’s a bit brute-forced in places (GCC pairing, tricks, and a lot of iteration), but it’s still impressive. And honestly, the Anthropic blog post is genuinely interesting and worth reading.

The real takeaway isn’t “you should build sensitive stuff with agentic LLMs.” It’s that agent teams can assemble something coherent with minimal human involvement. A glimpse of what agents can eventually do. full-stop. Anthropic also put a big warning label on it: “I do not recommend you use this code!”, because correctness hasn’t been validated and CCC has never been intended to be a GCC/Clang competitor. Also CCC has several really bad bugs. So: impressive milestone, but not a green light to ship critical systems on autopilot.

Support my work on AtomVM: sponsor me on GitHub ❤️