OXC Wants Your Build Pipeline. The Compiler Earns It, the LLM Features Don't.

I've been waiting for a Rust-based JavaScript toolchain to actually threaten the incumbents. SWC got close. esbuild got close. Rome tried and pivoted to Biome. And now there's OXC — the Oxidation Compiler — which is the first one I've seen that's not just chasing benchmarks but rebuilding the whole pipeline (parser, linter, formatter, transformer, minifier, resolver) in one coherent Rust stack.

The compiler is genuinely good. The "AI" features bolted on top are not. Let me explain both.

What's actually new

OXC ships five components that previously required five different tools: a parser (oxc_parser), a typed AST (oxc_ast), a transformer and minifier (oxc_minifier), a linter (oxc_linter), and a module resolver (oxc_resolver). All written in Rust. All in one repo. All consuming the same AST.

That last point matters more than the headline benchmarks. Most JS toolchains convert between representations three or four times: source to CST, CST to AST, AST to IR, IR to bytecode. Every conversion is a place to lose semantic information. OXC keeps one typed AST and operates on it. That's why their linter can be 50x faster than ESLint — not because of a clever algorithm, but because the AST is already there, typed, and shared with the parser.

Numbers I trust from their benchmark suite: oxc_parser handles roughly 3x the throughput of SWC on the same hardware. The minifier beats esbuild on gzip'd output size for most codebases I've tested it against. The resolver is competitive with enhanced-resolve, the de facto Node standard.

These are not "we benchmarked on a synthetic test" claims. They hold up on real monorepos.

The LLM integrations: where I get grumpy

OXC's recent release added two AI-flavored features: an "intent-aware" formatter that uses a local model to guess how you wanted your code formatted, and a refactoring assistant that suggests structural changes.

Here's the problem. The formatter is a deterministic problem. Prettier proved that ten years ago. When a formatter becomes "intent-aware" with an LLM in the loop, you've taken something fast and predictable and made it slow and stochastic. Every developer's machine now needs to download a model, every save has a chance of producing different output, and you've reintroduced the exact class of bikeshedding bugs that "no format wars" was supposed to kill.

The refactoring assistant is more defensible, but it's also not new. GitHub Copilot already does this. Your editor already does this. Why is it in the compiler?

My read: OXC is chasing the "AI-native" branding wave. A Rust compiler alone doesn't get you funding headlines in 2026. But slapping a small model onto a formatter and calling it AI-powered does. I understand the business logic. I don't respect it.

The catch

OXC is fast. OXC is correct on most modern code. But there are gaps that matter:

• **TypeScript type checking is still delegated to tsc.** The transformer strips types, but doesn't verify them. If you're coming from an SWC workflow, this is the same, but it's the dirty secret of every "fast TS" toolchain. The compiler is fast precisely because it's not doing the work tsc does.
• The plugin ecosystem is small. Babel's killer feature was always its plugin API. OXC has one, but most community plugins haven't been ported. For most apps that's fine. For anyone depending on a niche loader, it isn't.
• The linter's rule coverage is maybe 60% of ESLint. For greenfield projects, fine. For mature codebases with hundreds of custom rules, you'll be writing your own.

If you're starting a new project in 2026 and you care about build speed, OXC is a legitimate choice over SWC. If you're maintaining an existing app, the migration cost is real and you should weigh it honestly.

Who is it for

• Teams running large monorepos where CI time is measured in dollars, not minutes.
• Library authors who care about minified output size as a competitive feature.
• Anyone who has watched SWC stagnate on roadmap and wanted an alternative.

Who it's not for: anyone whose build works fine, anyone who depends on a Babel plugin that doesn't exist yet, and definitely not anyone who thinks a "smart formatter" is a feature.

What this means for builders

The Rust wave in JavaScript tooling is no longer a curiosity — it's the new baseline. OXC is the most ambitious entry yet, and on the compiler side, it deserves the attention. The shared typed AST is the actual technical contribution; everything else flows from that decision.

But the AI features are a distraction. They're marketing, not engineering. A formatter with a model in the loop is a slower, less predictable formatter. A compiler is supposed to be the opposite of that.

If you're evaluating a toolchain in 2026, ask one question: does this make my build faster, my output smaller, and my code more correct? OXC's compiler answers yes to two of three. The LLM features answer no to all three.

Skip the AI. Use the compiler. That's the take.