𝗕𝘂𝗻 𝗦𝗵𝗶𝗽𝗽𝗲𝗱 𝗨𝗻𝘀𝗮𝗳𝗲 𝗔𝗜 𝗖𝗼𝗱𝗲
Bun recently rewrote its core in Rust. They also added experimental multithreading. These are big moves. However, the method used to reach these goals is concerning.
The Bun team admitted that Claude AI wrote much of the Rust rewrite. This change added over 13,000 unsafe blocks to the codebase. It also shipped without a concurrent garbage collector.
In systems programming, unsafe code bypasses memory safety. One unsafe block is a risk. Thirteen thousand blocks from an AI is a liability.
I understand the need for speed. Small teams must move fast to compete with Node.js and Deno. But speed without care is dangerous.
Every unsafe block is a promise of valid memory access. When an AI writes the code, who signs that promise?
The risks are clear:
- AI code lacks human reasoning for memory management.
- High-velocity generation requires high-velocity review.
- Missing a concurrent garbage collector makes multithreaded workloads unstable.
A runtime is not a simple library. It is the foundation of your entire application. You choose a runtime based on trust. When infrastructure feels experimental, developers move back to stable tools like Node.js.
I use AI tools every day. I treat AI code the same way I treat code from a junior engineer. It needs a review that matches its impact.
The impact of multithreading inside a runtime is massive. Thirteen thousand unsafe blocks need thirteen thousand good reasons. They do not need thirteen thousand rubber stamps.
Being ambitious is good. Being careless with systems code is a liability.
Would you run 13,000 AI-generated unsafe blocks in your production app? What is your limit for trusting AI with infrastructure?
Optional learning community: https://t.me/GyaanSetuAi