The borrow checker really isn't that bad. It isn't like they were porting from something with GC. They were already having to think about these things anyway. Even then opus seems to have no difficulty going between c# and rust while respecting the idioms of both. No unsafe needed. Zig should be even easier except the lack of a training corpus for whatever frankenversion of zig that bun was using.

All that unsafe does in these cases is enable the "unsafe super-powers" which the compiler can't check, thus shifting the responsibility onto the author. But for example if you've got some code which doesn't borrow check, and you just sprinkle unsafe keywords on it, now you've got code which still doesn't borrow check and diagnostics telling that this unsafe keyword was futile and you should remove that.

I haven't reviewed this code, but the percentages described don't sound like they'd need a huge architectural overhaul to use much less unsafe, it might take more actual human effort than they want though.

Even if you “rely on countless unsafe blocks”, unsafe is additive, it gives access to additional APIs which are not checked. It does not disable affine types, the borrow checker, or send/sync traits. Unless the entire codebase is unsafe (e.g. fresh out of c2rust) it’s very hard to not have more guarantees.

And because unsafe is generally highly local or localizable reasoning (conventionally backed by safety justifications) it really is quite reasonable to go plugging at it, or task an AI within that.

If you are writing in C-like codebase and aren't tracking lifetimes and ownership at least as well as a borrow checker you're opening yourself to CVEs.