Yeah I’d agree with that. LLMs absolutely democratize building proof of concepts and internal tools. But in my experience building really high quality software still requires very close supervision from experienced developers, even on frontier models at the highest thinking levels.

Yeah, you absolutely can produce very high quality software with LLMs. I don’t think you save that much time on new, interesting features, bc producing something great was never primarily blocked by typing speed. But a great eng/team can absolutely make something great.

It’s called code and a compiler ;-)

Wanted: a detailed specification format to ensure that AI doesn’t drift. Preferably with tooling that automatically checks if there are other areas of the codebase I need to consider as I work on the spec. Maybe realtime highlighting of any obvious mistakes I’m making in the spec document ;-)

Combine that w manually spot checking some code and automated review and we’re good.

The strategy is that this is reviewable and we’ll land it. We don’t need thorough human review of every line of code: instead we are focusing on verifying the test setup. If it’s tested properly (every single compiler pass produces identical intermediate state), that gives us a ton of confidence..

That first port was more of an exercise in “how much quality can I get for a nearly automated port” to which the answer was “nowhere near enough”. So I went back and spent a lot more time getting it right. Good experience learning the limits of agents atm.

Eagle eyed observers will notice the first commit on this branch was from *after* my post here. I threw everything out and started all over again! The original port was pretty good but had some fundamental issues. Things i had told the agent to avoid, but where it gradually drifted from the guidance

The React Compiler rust port is now up as an in-progress PR at github.com/facebook/rea... - more to come as we test and polish.

“These are advanced features that can be skipped for now”

Citation needed

We primarily expect to publish integrations but happy to discuss on a GitHub issue once the rust version is out there and you can try it.

I’m thinking we’ll switch to the Rust version only, as soon as it’s ready

No, I think AI changed the tradeoffs

General thought is that I wish I’d had the time to port by hand. You learn by writing. But alas.

Anyway yeah, will try to share more learnings somewhere

Once the port completes we have to iterate, test, look at perf, and then ship. Will try to get a ln experimental preview out asap.

There are a few design choices the agent made along the way that I want to change, but nothing major enough to stop the process. I got the key design choices locked in on the initial plan. We’ll just do some polish passes at the end.

One big unlock (h/t @ricky.fm) was to have the agent create custom agents for planning, implementation, review, and orchestration of the project. That’s now running for a few days with minimal intervention.

We’re pretty close to having an initial Rust port of React Compiler. My approach was to iterate on the plan document (write it manually, have the agent expand, edit, repeat). Then try to run it, see what goes wrong, revert back to the plan, tweak the plan, repeat.

Your post was totally fair! I appreciate you sharing your experience :-)

The parts of the post describing subtle nuances are about which specific ways of breaking immutability the compiler does/doesn’t catch. But developers don’t need to remember which way of crafting an error will be caught or not! They just need to remember the rule, which is straightforward.

Thanks for sharing your experience! We’ll take a look to see if there are any of the cases you flagged where we can detect an error automatically.

There are two aspects: the rule & how we enforce. The rule is simple: don’t mutate stuff that crosses JSX/hook boundaries. You almost certainly follow this ~all the time, else you would have crazy bugs. What feels and is more complex is that we can’t statically catch all violations of this rule.

What if we all got together and agreed to pay a bit of money to the government every year so that they could put together a group of trained people to protect us from masked thugs in the streets?

We’re exploring a different direction but I don’t have a link handy. Cc @capt.dev

Still something we have on our list to potentially optimize further in a future release

In this example each element will “re-render” but what that means has changed: since each item will largely no-op if its inputs haven’t changed. With React Compiler a component function executing doesn’t necessarily mean much work happens.

I hope we’ve earned enough trust that people don’t think we’re so naive as to _only_ rely on feedback that we hear about directly. We also look at things like adoption which accounts for people bouncing off for various reasons, as well as on our own judgment/experience.

Did you already have ESLint running and our plugin slowed it down, or was the slowdown from switching from a fast linter back to ESLint?

..and avoid rewriting the core logic. But more importantly: we are very actively expanding and building upon the compiler. We’ll hopefully be able to prioritize build performance sometime in 2026 but we’ll see how things go. The more we hear about it the easier it is to prioritize so send feedback.

We get that reintroducing Babel in an otherwise Rust-based toolchain slows down builds. It’s a compromise. Unfortunately the Rust-based JS tooling ecosystem is fragmented - SWC and OXC - with different parsers and AST formats. We’re still hoping to be able compile with Static Hermes