By ByteBot
On January 11, 2026, Nikita Popov (nikic), lead maintainer of LLVM, published “LLVM: The bad parts“—documenting seventeen categories of fundamental problems in the compiler infrastructure powering Swift, Rust, Clang, and millions of developers’ toolchains. This isn’t external criticism. It’s the person responsible for fixing LLVM admitting it’s broken. When foundational infrastructure maintainers catalog systemic failures, that’s not documentation—it’s a warning.
The Scale of the Problem
LLVM isn’t niche tooling. Apple uses it for Swift and macOS/iOS development. Google uses it for Android. Intel, IBM, Microsoft, and NVIDIA all depend on LLVM. Rust, Clang, Kotlin Native, and Julia rely on it. When nikic lists build time crises, CI instability, API churn, and review capacity bottlenecks, he’s describing problems affecting every developer downstream.
LLVM has 2.5 million lines of C++, 200+ buildbots that are “never fully green,” and 150+ commits daily. Moreover, it has “known correctness bugs” that remain unfixed because fixes are too complex.
Seventeen Categories of Failure
nikic, who was appointed lead maintainer in October 2024, identifies seventeen distinct problems. Specifically, the worst:
Build time crisis. Clang-15 regressed from 30 seconds to 40+ minutes for some code. Furthermore, LLVM 10 made Rust compilation 10% slower. Building LLVM itself causes out-of-memory errors and hundreds of gigabytes of disk usage on low-spec hardware.
CI instability. With 200+ buildbots and 150+ daily commits, the system is “never fully green.” False positives dilute the signal. Consequently, real failures get buried.
API churn. The C++ API and IR undergo frequent breaking changes. Philosophy: “upstream or GTFO.” Therefore, external tool maintainers must constantly adapt or break.
IR design flaws. Undef values are “very hard to reason about.” Known correctness bugs remain unfixed. Notably, a formal specification working group was formed in 2025—two decades after LLVM’s creation.
Review capacity bottleneck. Thousands of contributors, yet insufficient expert reviewers. PRs languish, forcing unqualified rubber-stamping. nikic writes: “Code review requires more expertise than writing code.”
The Industry Exodus
Multiple compiler projects are abandoning LLVM. Specifically, Zig is building a custom backend (citing LLVM as “too slow”). Similarly, Jai, C3, and Odin are ditching it. Meanwhile, Go and OCaml never adopted LLVM, choosing custom compilers despite the convenience.
The trade-off: accept LLVM’s complexity and build times, or build your own backend. Increasingly, more projects choose the latter—a vote of no confidence.
Infrastructure Rot, Not Technical Debt
This isn’t technical debt. Technical debt implies eventual paydown. However, LLVM’s “new” pass manager was introduced over ten years ago—the backend still uses the legacy version. Likewise, GlobalISel was meant to replace SelectionDAG a decade ago—no targets have fully migrated. Meanwhile, new features keep getting added to old systems, making parity impossible.
nikic admits LLVM is “optimized for optimization,” leaving “substantial costs even at -O0.” That’s a design philosophy problem. When architecture makes fixes impossible without breaking everything, that’s not debt—that’s infrastructure rot.
If LLVM—widely used, well-funded, technically sophisticated—admits to systemic failures, how much other foundational infrastructure is similar? How many projects have “known correctness bugs” maintainers can’t fix? How many rely on shrinking numbers of overworked reviewers?
Maintainer Honesty Is Rare
Most maintainers don’t publicly catalog how their projects are broken. They patch, work around, hope no one notices. In contrast, nikic did the opposite—documenting every major flaw, from process to IR semantics.
But that honesty exposes precarity. LLVM isn’t going away. Rust, Swift, and Clang are locked in. Yet the problems nikic describes aren’t improving. API churn and incomplete migrations are structural—they can’t be fixed without breaking everything.
The Broader Warning
Can LLVM fix these problems? Unclear. Build times and CI flakiness are addressable. However, IR design flaws and “upstream or GTFO” are embedded in culture. Alternatives like Cranelift and QBE offer faster compilation but less optimization. For most projects, switching is infeasible.
The real question: how do we maintain critical infrastructure when complexity exceeds our ability to review, test, and reason about it? As highlighted in community discussions about LLVM’s slow compilation, nikic’s post shows what happens when foundational tools accumulate problems faster than they’re addressed. The answer so far: we don’t. We build, patch, and hope cracks don’t widen.
LLVM’s problems aren’t unique. They’re symptomatic of an industry prioritizing feature velocity over sustainability. Ultimately, nikic’s warning isn’t just about LLVM—it’s about every piece of infrastructure we depend on but can’t fully audit or trust. The Hacker News discussion with 279 points and 55 comments reflects how deeply developers recognize these patterns.
