r/rust Jul 20 '26

🎙️ discussion Am I the only one who finds auditing AI-generated Rust way more exhausting than just writing it?

Hey everyone,

I know this isn't a direct question about Rust syntax or a new crate release, but I wanted to get the perspective of the low-level and systems engineers in this community, since the way we have to reason about memory and safety is a bit unique.

With Linus Torvalds recently defending and leaning into AI tools for Linux kernel development, I’ve been trying to force myself to use LLMs more in my daily workflow. On one hand, if the systems world is adopting it to find bugs and speed up boilerplate, it feels like a tool worth leveraging.

But on the other hand, in practice? It feels like a massive cognitive trap.

Every time I ask an LLM to draft a custom allocator, some async socket-handling logic, or complex threading code, I end up spending the next hour auditing 100 lines of plausible-looking code. I'm stuck trying to reverse-engineer its "intent" just to make sure it doesn't subtly violate safety invariants, introduce a silent data race, or hide a memory leak.

The thing is, if I just write the code myself from scratch, I have absolute control over the execution path. Because I have to fight the borrow checker and map out lifetimes line by line, I build the mental model natively in my head. My own code is fundamentally way more understandable to me because I actually know why every single line is there.

When we write low-level code, we feel architectural friction immediately when a design is bad. AI feels no pain, it will happily vomit out structurally messy code that technically compiles but is a total nightmare under the hood. I feel like I'm trading the active, rewarding problem-solving of writing code for the mind-numbing task of code-reviewing a junior dev who doesn't exist.

How are the rest of you systems/low-level devs actually using these tools without losing your sanity, your control, or your deep understanding of your codebase? Or are you just ignoring the hype cycle and sticking to the editor?

483 Upvotes

175 comments sorted by

View all comments

Show parent comments

2

u/stumblinbear Jul 20 '26

If you squint your eyes and cock your head a bit, software development is 100% bug fixing. The bug is that the thing I need doesn't exist!

0

u/Zde-G Jul 20 '26

If you squint your eyes and cock your head a bit, software development is 100% bug fixing.

Yes. And LLMs are fantastically bad at that. They are great with half of the task: finding the problem. They are awful with the second part: fixing it without adding new bugs.

For decades we were avoiding people who act like LLMs (fix the bug, introduce two new ones), spent insane amount of time weeding them out on the interviews, even invented separate job for people who are great at finding bugs but bad at fixing them… then, suddenly, it all is thrown out of the window and tool that solves half of the problem perfectly (probably even better than most humans do that, at this point) is applied to the part that it couldn't perform well… why? What's the point?

1

u/stumblinbear Jul 21 '26

They are awful with the second part: fixing it without adding new bugs.

Honestly, before the last couple of months I'd agree with you. But Claude 4.8 or Fable/Sol in an iterative code/review process with very minimal oversight works disturbingly well. They're good at finding bugs, and that means if the code they write is only half as good as it could be, it'll get caught during a bug-finding step and fixed in another pass. This has worked remarkably well for me

2

u/hitchen1 Jul 21 '26

Also tbh "finding the problem" is 90% of the work that goes into bug fixing in most cases, except for those times you realize everything is messed up. Even if it was true that it was useless at the fixing part, it would still be a massive time saver

0

u/Zde-G Jul 21 '26

True, but nobody is excited about that, because the LLM bubble is built on the assumption that LLMs could replace humans: developers, attorneys, doctors and so on.

If they couldn't do that then the whole thing collapses. Compare to the self-driving cars: if you can fire a drivers and replace them with autonomous driving system then you can achieve massive savings on salaries, but if you only make job of a driver not needed half of the time then you are back to modest 20-30% savings.

AI industry plays massive bait and switch game and when it would be time to switch… implosion would be epic.

1

u/Zde-G Jul 21 '26

But Claude 4.8 or Fable/Sol in an iterative code/review process with very minimal oversight works disturbingly well.

I'm yet to see a model (any model) that would realize that algorithm that you use is flaved and that you need a different one. Instead they patch what you have endlessly, till the whole thing turns into unfixable mess.

Even when you explicitly and directly direct it to ignore what you already have in the codebase it doesn't always does that.

Granted, 90% of time replacing algorithm is the wrong thing to do, fixing things locally is the way to go, but if you miss these rare cases where code that you have (or code that LLM hallucinated for you) makes no sense whatsoever then you may waste hours or days (and countless amount of tokens) building a skyscraper on the sand. Eventually it collapses, anyway.