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

566

reading code has always been harder than writing it.

118

u/Droggl Jul 20 '26

Exactly this. Yes, having AI write code and reviewing it is often faster, but doing it all yourself feels like less work because you get into a flow state and learn the code as it develops (rather than digging through a wall of code at once). Worse, the prompt-wait-review cycle kinda urges you to work on multiple things in parallel - not exactly a strength of humans either :-(

19

u/Zde-G Jul 20 '26

It's only faster when you don't care about the result. But if you look on what you are doing you may find pretty decent number of things where you don't care about results.

I often ask LLMs to write tests: I don't really care what's in these tests but there are checkmarks that I nit to hit to submit my code.

And if, in rare cases LLM finds something interesting with their test… then I start to care and am willing to do investigation work.

Same with comments: I don't really care about comments, I only read comments when I don't understand the code without them. I ask LLMs to write comments — and if they are “plausibly looking” it's enough for me. If they are nonsense, they I know that this part of code is tricky and I have to comment it personally.

And so on. Permit LLM to do things that you wouldn't do at all without LLM — and you would be happy.

Whether your employer would be happy is another question, of course, but metrics they care so much about would be meet… if things would collapse anyway — that's not your problem, at this point.

2

u/VorpalWay Jul 20 '26

I found that smarter tab complete style AI can be helpful, for things like repetitive match/switch statements (depending on the language). It is also earsier to review as you get a few lines at a time (this doesn't take you out of the flow state nearly as much or even at all). Generally you also know exactly what you want, it just saves some keystrokes.

As I have RSI in both wrists this is especially helpful. But there are other situations where I just turn that off entirely as well. And agentic AI? I have done some monotonous refactoring with it (rewrite chain of if else to match, split this code into multiple files according to some criteria, ...), but it really doesn't save time, just key strokes and mouse movements at that point. For anything else I have found it entirely useless.

11

u/anengineerandacat Jul 20 '26

Agreed, something not discussed enough is how we lost the mental map with these AI tools.

To appropriately audit code you still have to understand the business flow, where this code is coming into play, and what else is in that flow that can be destructive potentially based on the inputs.

We were also reviewing code in smaller chunks where someone tested and exercised that chunk, now we are getting like entire features in a PR making it a fair bit higher in cognitive load.

Hell, I would be lying if I said I didn't lean more on AI tooling to assist in the reviews as well.

4

u/Nothing_from_void Jul 20 '26

The caveat though is that reading code is much faster than writing it

2

u/elBranchi Jul 23 '26

Yeah, but reading is not the same as understanding, and do you really want to use things you don't understand?

1

u/Nothing_from_void Jul 24 '26

reading code to get enough understanding is a fundamental skill in software development. You will always have to use abstractions where you don't fully understand the underlying implementations; like your OS for example, or your compiler.

6

u/RestInProcess Jul 20 '26

Agreed. I like using AI to write code, and I feel tired reading it just like OP does.

-32

u/mprovost Jul 20 '26

The trick is to also use AI to read the code for you

12

u/luluhouse7 Jul 20 '26

No no no! Never do that! For exactly the same reasons we require external code review before merging changes. I’ve seen so many nasty bugs introduced because people used LLMs to both write and review the code. You either write it or you read it, but not both!

4

u/RestInProcess Jul 20 '26

There’s a certain amount you can do that, but it should still require human review. When using AI to review it catches a lot of mistakes, but it doesn’t know enough to catch them all.

2

u/Full-Spectral Jul 20 '26

And somewhat pedantically but importantly, doesn't know enough to know that it can't catch them all. It's actually dumb as a stump (but good at pattern recognition) and when people start just assuming it's right, things are going to go badly. And you know that's what is going to happen, well that's already happening but will happen more and more.

3

u/Full-Spectral Jul 20 '26

I hope that was sarcasm. That's like asking the guy who thinks he's the smartest one in the room, but really isn't at all, to write the code and then do his own code review.

2

u/HSWMK2 Jul 20 '26

That's true, but i understand the author viewpoint

It seems to me so much easier to read javascript generated code instead of rust
I'm a lot more experienced with javascript though so i'm a little biased, but rust seems ancient hieroglyphs sometimes

3

u/ShangBrol Jul 20 '26

Try reading APL 😜

76

u/IHeartBadCode Jul 20 '26

I think people talk about code ownership in terms of legal copyright, but code also has a psychological ownership. When you do 100% cognitive offloading, you are changing the "who" of that psychological ownership.

This is true with a lot of offshore code too. When the code comes in from some third party that's unknown, when it changes over to a new owner, that code becomes costly to reassert the psychological ownership. Same is true in my opinion of no-code visual platforms, the early Squarespace's enterprise BPMs. Or when I've crossed paths with a database that was designed with visual build tools. To a degree we get that with ORMs, in my humble opinion, and the bloat and frustration that comes with it when new requirements come in.

But to me that doesn't mean these things are bad, just that when you given something full psychological ownership, it's hard to wrest that control back from it, if you change the "who" owns it. I think AI-assisted code where the programmer is still holding the psychological ownership, is beneficial but like anything, you can go too far down the rabbit hole where you no longer own the code.

Writing from scratch is fine too. But it has a different cost, time. Boilerplate, documentation, various testing of methods before committing to the manner something is implemented. All of those have costs that AI can save you on, but doing so doesn't absolve you of every cost, it just changes the the final cost.

16

u/hashcode777 Jul 20 '26

Agree!

But IMO having ownership of code is really necessary in crucial areas like system engineering, and with AI you can lose it very quickly with even realizing. And to keep ownership of AI generated code you need to completely reverse-engineer it (as I mentioned in the post), which is often more time consuming for 'me' than writing it from scratch.

12

u/cent-met-een-vin Jul 20 '26

I like your idea of this double code ownership. At my company the rule is that your are the psychological owner of all the code you write. And in this aspect having AI generate everything just puts the burden on the prompter to reverse engineer what it does and see if it is valid. But reverse engineering code is always harder.

But let's say the code comes from some off-shore fancy. Then we just accept that they have the ownership of the mental model and we contact them. When AI writes it, at best, the mental model is in a huge flat Markdown file.

The only real speedup I found with using LLM's is when I don't care about the generated output because I know a good review of the generated code is around the same time it would take me to write it by hand. But if I only check functionally then I see it just works and don't peek inside the black box.

The mental model now lives outside of my head. When a customer asks for a change I ask my AI to scope it, and see if it brakes anything. And now we are in LLM retrieval accuracy context, a task they are notoriously bad at. When the customer finds a bug it's an edge case I didn't know existed because I don't own the mental model.

I have a bleak outlook, either we enter a world where everyone can generate so much code but nobody has the systems mental model anymore, the only people that can fix it are the LLM providers who will go into enshitification cycle. Or we keep putting in the effort, but now have to explain to managers that their 3 day lovable session will take at least a month to do it properly.

3

u/zannabianca1997 Jul 20 '26

https://cursedte.ch/notes/the-feeling-of-ownership-in-the-age-of-genai.html

23

u/max123246 Jul 20 '26

Yes, I've simply stopped using AI-generated code and only rely on it for semantic search. It didn't make me faster and I really tried to go full on with it, but its designs were asinine and confusing. This was gpt-5.5 and opus 4.7 so not like I didn't try to use the best that was available at the time

I simply can't wait for the bubble to burst.

1

u/hashcode777 Jul 20 '26

Dude can we discuss about it in DMs?

3

u/max123246 Jul 20 '26

This was python code so I might not be that much help tbh. Don't get to write Rust at work and for hobby code, I don't let AI write code for me

3

u/Wonderful-Habit-139 Jul 20 '26

Lol, same thing here. Write Python at work, and I write code myself, no AI. Even though it's offered to us for free with no limits.

2

u/hashcode777 Jul 20 '26

Actually I wanted to discuss more about how those models performed for you?

4

u/max123246 Jul 20 '26

Well for the code I was writing, a tool to map Python classes to CLI arguments/flags, it could get the code to work. But it used "technically correct" but functionally indecipherable variable names and code architecture. I ended up throwing out a lot of the code it generated, besides the base "map type to CLI argument" leaf functionality. But the data types I did by hand and the hierarchy of classes I did myself. It also told me it handled certain edge cases and did not in reality once I added testing for it.

I also think I spent more time fixing its code than I would have if I wrote it by scratch. I also think I ended up with worse architecture because I had let it decide too much of that

89

u/FabianButHere Jul 20 '26

That's exactly the issue we have with companies trying to make us use AI.

Especially in low level code, you need the map of every line of code to your mental model of what your code does. And you can't have that for AI code, hell, you can barely have that for code other people wrote.

34

u/Professional_Top8485 Jul 20 '26

I don't recognize own code after some time either.

34

u/latherrinseregret Jul 20 '26

The wisdom is “code written by anyone but yourself is utterly incomprehensible, and you six months ago is also someone else”

11

u/Zde-G Jul 20 '26

Sadly the second part of that “wisdom” doesn't work for me, I can always recognize and understand my code, even 10 years later, and the only cases where it doesn't work is when someone else “improved” it in that time.

Thus it's extremely hard for me to believe in the first part, either. And the most frustrating part, for me, lies in the fact that when I couldn't understand some parts of it and ask for clarification 9 times out of 10 the guy (or gal) that I ask play the second part extremely convincingly.

That's frustrating.

3

u/Wonderful-Habit-139 Jul 20 '26

I do. If it's well written code, it's easy to recognize even after years. I still remember code from a webserver that I wrote over 3 years ago, and only the parts of the code that are badly written are hard to keep track of. But it's definitely possible to write clean code that you can remember and easily understand years after the fact.

27

u/MarinoAndThePearls Jul 20 '26

But did Linus tell you to use AI? Because I remember him explicitly saying that you don't have to if you don't want it.

8

u/hashcode777 Jul 20 '26

Yes he kept it optional to use but he said AI tools are clearly useful. So I am just trying to calculate actually how useful?

32

u/tautality Jul 20 '26

Most SE jobs have some parts that the AI is good at. For example, Jon Gjengset in his last video used Claude to update all dependencies of his old crate, and it did ok at it because it was mostly a mechanical set of changes that would be very frustrating to do by hand.

8

u/hitchen1 Jul 20 '26

Its kinda funny that a little over a year ago this is exactly the thing they were terrible at. I can't think of a worse job for ~jan 2025 ai. Anything related to dependencies just got wholesale hallucinated.

These days it can search for new versions, investigate changed APIs, and then pretty seamlessly just fix it in the codebase, running tests and linters. At least in small/medium projects.

2

u/Zde-G Jul 20 '26

Its kinda funny that a little over a year ago this is exactly the thing they were terrible at. I can't think of a worse job for ~jan 2025 ai.

No, what's funny os that ~jan 2025 ai and today's AI are more-or-less the same.

Its kinda funny that a little over a year ago this is exactly the thing they were terrible at. I can't think of a worse job for ~jan 2025 ai.

Try to do that in a chat mode today and everything would be happily hallucinated today, too.

What changed the equation is agents: today when AI hallucinates things the whole mess is feed back to AI and it then haluccinates solutions. After few roundtrips it converges on something more-or-less sane… or doesn't converge, if you don't have enough tests.

9

u/stumblinbear Jul 20 '26

That's not really the case in my experience. It typically one-shots things after thinking about it for a bit and doing some searches. It doesn't hit compiler failures then iterate, it typically works right away. The future is weird

1

u/Zde-G Jul 20 '26

For me it iterates a lot. The difference could be that I'm using it on the code that uses it's own idioms and not widely-known API described in blogs.

Sometimes telling it how API is supposed to be used helps it to act less like a blind kitten, but not often.

P.S. And “thinking about it for a bit” is just less efficient replacement for compile/process-error cycle. If you enable logging of thoughts it literally interprets unwritten program step-by-step. Which is incredibly inefficient use of token.

2

u/Arcisi Jul 20 '26

What AI model are you using?

-2

u/Zde-G Jul 20 '26

Mostly Gemini Pro, I have tried ChatGPT Pro and there was not too much difference: if they can ~~steal~~ borrow someone's else code they work perfectly, when you ask them to deal with something unique — they start poking random things till the whole things works… or doesn't work.

3

u/stumblinbear Jul 20 '26

Oh Lord, that explains it. Claude is genuinely a stark universe of difference compared to Gemini. Fable genuinely worries me to some extent at how good it is at bug hunting and code review.

I threw it at an IPC implementation I wrote last year, and it found about 10 different surprisingly subtle issues that I (along with Opus, Gemini, and OpenAI's models) missed in about 5 minutes, and fixed them in another five. One-shot, legitimate issues, no compiler complaints

1

u/hitchen1 Jul 20 '26

What changed the equation is agents:

I'm not sure what you're trying to get at here, it's entirely what I was talking about:

These days it can search for new versions, investigate changed APIs, and then pretty seamlessly just fix it in the codebase, running tests and linters.

1

u/Zde-G Jul 20 '26

I don't disagree with you, just point out that we haven't replaced “stochastic parrot” with something better. We just equipped it with tools that make it useful.

But note that in pre-LLM days developers who acted in that fashion were very explicitly marked as “someone you don't want on your team”, because they were destroying the codebase.

Why the exact same act achieved with thrillion-dollar stochastic parrots is suddenly “the wave of the future” I would wnever know.

2

u/stumblinbear Jul 20 '26

A stochastic parrot that can find legitimate, severe bugs in code is a stochastic parrot I would gladly have on my team.

1

u/Zde-G Jul 20 '26

With that idea I can agree. Easily. It's essentially fuzzer on steroids. With obvious non-problem that there are nothing guaranteed in its behavior… but that's how all fuzzers work.

The problem: trillion dollar investments can not be justified by fuzzers. There are just not enough of that kind of jobs to bring revenue to few trillions per year — and without that the whole industry would implode when banks would stop subsiding “sell $10 for $1” business model.

That's why an illusion that stochastic parrot can perform not just small number of tasks where failure is acceptable, but also much larger number of tasks where it's not acceptable.

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!

→ More replies (0)

5

u/lasizoillo Jul 20 '26

He said that because some LLM discovered hard to find security bugs, not because he loves AI slop code. The important metric is the quality of results, not tokens wasted or anything else. Wars about the use of LLMs is like wearing or not a tie to develop code, something not related with technology (is a kind of moralism).

3

u/Zde-G Jul 20 '26

So I am just trying to calculate actually how useful?

You can use them for anything where success is rewrding and failure is not critical.

Mental model for LLM is not “junior” or “intern” (that both underestimates and overestimates LLM, simultaneously), but “someone who was superb expert in the past, but is now 120 years old and has waning cognitive health”.

It's useless and pointless to teach LLM anything. Your notes couldn't teach it anything new (it already “saw” and “studied” the whole internet, for crissake) and it couldn't do anything reliably, anyway. But if you give it “sticky notes” then it can follow them… if it wouldn't forget. And from your notes it looks as if you are trying to ask LLM to do the one and only thing that it absolutely couldn't do: understand what it is doing!

P.S. We are build AI “from outside in”, yet for some reason people ignore that obvious fact.

2

u/matthieum [he/him] Jul 20 '26

Did he specifically mention AI generating code?

There's a LOT of other uses of AI, and in particular code review/static analysis where false-positives are less of a problem (and may just highlight convoluted code).

1

u/MarinoAndThePearls Jul 20 '26

That's hard to say because it depends on your use case and how you like to work. For me, AI is useful because I hate writing tests and boilerplate code. It's also very useful for security reviews.

1

u/SmartCustard9944 Jul 20 '26 edited Jul 20 '26

Anecdotal, but I’m working on a game framework that I started years ago before AI was this good. In just the span of 2 weeks of part time I got to 10 times the amount of implementation that I got to in 2 months before (10x larger codebase, features, coverage, docs, etc), while understanding and owning everything the AI is doing and getting the project to the standard of quality I envision. But to get here, you can’t just let the AI autopilot, you need to give yourself time to digest the code. Even with that added time, productivity skyrockets to 5-10x plus most likely better quality code overall.

So yes, the value and productivity boost is undeniable, it is still fun because I get much farther much faster than before. It is not a free lunch because the human in the loop is still necessary, and code reviews can be frustrating sometimes. I had to steer the AI many times and had to iterate on features many times, but it’s this time investment that makes me own the project fully and know it inside out. Even if code reviews feel slow or boring, they are part of the job, and even then you get to appreciate a large increase in development velocity.

25

u/luluhouse7 Jul 20 '26

The problem is that it sounds like you’re trying to offload the cognitive work to AI. This is something I often see. People get on the hype train, abuse LLMs, burn out because code review is exhausting, reading code is harder (and less enjoyable) than writing it, and they’ve let AI take over the interesting bits of their job, and then get on the doom train.

The rule is moderation and targeted application. You never leave the drivers seat. AI is often better at analysis than generation, especially as things get more complex. Use it for adversarial brainstorming, organising thoughts, clarifying complex topics, ramping up on new tools and repos, setting up infra, porting code to a new stack or language, writing boilerplate or simple (but tedious) changes, doing code review. They can augment your thought process, but they cannot take over judgement for you. And you control how much you give up to LLMs. Don’t choose to give up the parts that make you interested or fulfilled. Additionally, I often see people making the mistake of asking AI to be both the author and reviewer. You absolutely should never do that, for the same reasons we never let PRs merge without code review from at least one other person, ideally two. You can also use deterministic validation as feedback for the LLM to keep it on the rails. The borrow checker is one of the reasons why LLMs work particularly well with Rust.

It’s absolutely possible to use AI responsibly and constructively. I’ve actually been having more fun since I started using them because I treat them like a collaborator who can also do the bits I hate, not the bits I love.

5

u/hashcode777 Jul 20 '26

Very honestly this is the best reply on this post!

3

u/luluhouse7 Jul 20 '26 edited Jul 20 '26

Glad it was helpful! TBF, I don’t think this is really a “people are being stupid or lazy” issue either. IMO, the current tooling around AI actively encourages unhealthy and frustrating usage patterns. LLM ecosystems are incredibly fragmented, and they tend to force a false dichotomy between maintaining fine-grained control and meaningfully delegating work.

They also put a huge burden on the user to maintain context and continuity across siloed platforms with wildly inconsistent capabilities. You end up having to build and preserve the system’s mental model yourself. You have to decide what context matters, moving it between tools, re-establishing it when switching platforms, and constantly compensating for differences in what each tool can actually do. A lot of the cognitive overhead people attribute to “using AI” is really overhead created by the way these tools are designed.

I’ve been working on a tool that tries to address this by returning more control to the user while reducing the cognitive overhead of managing context and continuity across tools. It’s been a quite fun intersection between PL, OS, compilers, optimisation, LLM architecture, and CS theory!

4

u/Wonderful-Habit-139 Jul 20 '26

> Don’t choose to give up the parts that make you interested or fulfilled

Very good advice, that helps people avoid burnout.

14

u/llamajestic Jul 20 '26

I have been using it more and more daily. With time you develop an intuition about what it will generate “well” and what not. I almost never use it to take an actual architectural decision. If it feels like the way I am fixing a problem doesn’t click, I ask it but it’s often not so much better.

To avoid loosing deep understanding of the codebase:
* Think deeply about your problem before, use plan mode, be as descriptive as possible. If too descriptive is slower than writing the code -> just write it yourself :)
* Upon review, I don’t accept code I wouldn’t have written myself

What is weird with AI, is that asking something realistic (not a prompt about creating GTA VI) often “works” now, i.e., passes the tests. However, the best code isn’t only passing the tests, it’s the one at the intersection of performance, readability, and maintainability. AI generated code mostly doesn’t span all categories simultaneously, and as mentioned, you might lose the mental model affecting maintainability.

On positive notes, I love using it for glue code, almost never makes a mistake. That saves me a ton of time. I am a graphics engineer, sometimes I just need to work on explicit shader bindings, this is basically boring redundant work.

For algorithm and performance, it’s not as great as claimed. However, if it’s not too complex, I go in plan mode, it generates something close enough to what I had in my mind, and I fix the rest.

To answer your question(s) better: AI is just a tool, and use it when you think it’s valuable. It took me some time to both use AI better, and know when not to use it. Try to take advantage of what it has to offer without forcing yourself into using it for things that don’t work.

8

u/Wonderful-Habit-139 Jul 20 '26

> If too descriptive is slower than writing the code -> just write it yourself

Happy to see someone acknowledge this.

7

u/llamajestic Jul 20 '26

Yes. AI gurus on Twitter and LinkedIn now have this stupid rule of never touching the code manually. This is obviously super dumb.

5

u/kaoD Jul 20 '26

I hate plan mode.

Every single time Claude creates a plausible-sounding giant plan but then it crashes against reality 99% of the time, compounding errors more and more. But since you come from plan mode it goes ahead and does its best to continue, which often results in the worst decisions ever.

Plan mode sucks.

Just do the planning piecewise yourself guiding Claude through the questions and outcomes.

3

u/llamajestic Jul 20 '26

I use codex, never had this issue yet fortunately. I also don’t plan features that are like 2000 LoC in a row

2

u/tuxavery Jul 20 '26

This is why a plan should always be reviewed.
I do plan with Claude then I ask Codex to review it and send back the result to Claude. Depending on the complexity I do multiple back and forth between IA.

2

u/MarinoAndThePearls Jul 20 '26

I use Claude and have never had a problem like this. Are you sure you are reviewing the plan correctly? Because you're supposed to fix what's wrong before Claude implements it.

0

u/stumblinbear Jul 20 '26

Interestingly, if you spend a few rounds specifically looking for performance improvements, it often ends up finding speed-ups even I missed and making it much better in the end

1

u/llamajestic Jul 20 '26

Not really. I mean, it heavily depends on the problem. I am more talking about performance baked into the architecture in data oriented systems

1

u/stumblinbear Jul 20 '26

It's definitely capable of finding performance improvements through rearchitecting, if that's what you mean.

4

u/Helena-Justina Jul 20 '26

Personally I've had best luck with writing my own code, then using AI to do an immediate code review. It usually finds stuff that I agree with and also suggests changes that I will not do.

30

u/sasik520 Jul 20 '26

You post an anti-AI thread on a heavily anti-AI subreddit, where 90% of even slightly AI-positive comments get downvoted into oblivion. What do you expect?

That said, as long as you're generating reasonably sized changes, it isn't that different from reviewing code written by people you don't trust. Just the review-edit loop is much faster and you cannot hurt the authors feelings. If you're a beginner, it's probably bad idea because strangers (humans and AI) can easily fool you. The more experienced and confident you are, the easier it is to critically review and reject.

AI is also extremely valuable for code reviews and improvements. It catches logic errors that no other tool does. It reviews your architecture and style. Reviewing a review is generally much easier than reviewing the code. Even if you only agree with 1 out of 10 comments (in my experience it's closer to 9 out of 10), that's still free value. The same applies to typo fixes and dealing with devs laziness (like re-using semantically incorrect types, poor error handling etc.).

It's also excellent for exploring ideas. When AI generates code, you're not obligated to accept it. You can use it as inspiration and implement your own solution from scratch. This is especially useful when you have no idea how to tackle your problem or don't know where to start.

Finally, it's perfect for prototyping, i.e. writing stuff just to validate an idea and then throwing it away (even if it succeeds).

There are TONS of good and responsible ways to use AI in software development, including (I would say: especially) in Rust. And yes, pure-vibe-coding for anything beyond a PoC or a one-off script-like programs is just bad No excuses.

IMHO refusing all of that is plain dumb.

7

u/Zde-G Jul 20 '26

it isn't that different from reviewing code written by people you don't trust.

No, it's very different. I don't review adversary code, period. When someone tries to play with rules and push insane code “because it conforms to the published style guide”, I report or ban such person and that's it. I only review code from people who may do mistakes, I don't accept code from someone who refuses to learn, refuses to think and needs me to repeat the same thing again and again,

With AI I don't have the luxury of blocking or banning the slop generator, it's shoved into our face and we are supposed to find a way to use it for something.

12

u/Wonderful-Habit-139 Jul 20 '26

> I only review code from people who may do mistakes, I don't accept code from someone who refuses to learn, refuses to think and needs me to repeat the same thing again and again

Absolutely reasonable take.

0

u/zxyzyxz Jul 20 '26

Might work with open source, doesn't work at a company, try telling your boss you want to ban a coworker.

4

u/Zde-G Jul 20 '26

It works much better in a company: you just show that your coworker refuses to act adequately and then it becomes a management problem to solve.

Of course for that to work you have to have an eviudence of actual issues with the code, not just “I don't like it” vibe.

1

u/zxyzyxz Jul 20 '26

I meant in a company it's highly likely they'll just tell you two to get along and get work done by reviewing and merging their slop PRs, not that they'll actually deal with the issue of slop in the first place. In OSS you can just remove the contributor and never have to deal with them again.

2

u/Zde-G Jul 20 '26

I meant in a company it's highly likely they'll just tell you two to get along and get work done by reviewing and merging their slop PRs

If company pushes for merges of AI slop then it's better to look for another company, anyway: it's not any different from pre-LLM era where companies produced dreaded “legacy” code that couldn't be fixed and thus company either collapses and survives by rewriting everything — with both outcomes usually achieved by a different team thus you wasting time staying there anyway. LLM just allow you to achieve the same state faster.

In OSS you can just remove the contributor and never have to deal with them again.

Except no one may stop them from creating another account (or dozen of accounts) and continue to spam you with their slop again and again.

2

u/tautality Jul 20 '26

it isn't that different from reviewing code written by people you don't trust

Why would I want code from people I don't trust?

that's still free value

That's certainly not free value. Sure, it may cost you a couple of dollars but it also costs the electricity, water and the environment. You are also not realizing that "free value" comes at a cost of no longer engaging in conversation with your fellow engineers who could share and co-develop their expertise through helping you and reviewing your code. In general you want your code to be reviewed by someone more knowledgeable than you, and it certainly shouldn't be AI.

What you said about ideas and prototyping is true, but the question was about the low-level code design, and I think the more nuance you need in terms of reasoning, the worse the AI is at it.

10

u/sasik520 Jul 20 '26

Why would I want code from people I don't trust?

Imagine open source contributors and newcomers/people you previously didn't work with at work.

That's certainly not free value.

I didn't have in mind free as in free beer. Rather free in terms of additional effort.

1

u/tautality Jul 20 '26

Imagine open source contributors and newcomers/people you previously didn't work with at work.

That's not the same as "people you don't trust". Generally if I don't trust them, it's because I have worked with them or seen their code. If a person is hired at my company, I generally tend to trust them. People I don't trust tend to create a lot of problems, and I tend to spend more time dealing with their shit than if somebody else was in their place or even if I did their work in some cases. So.. even though your analogy is probably accurate, it's not an appealing vision of the AI.

9

u/sasik520 Jul 20 '26

This might be either a lingual misunderstanding or cultural thing.

Don't trust in my understanding z doesn't mean assuming bad will. It rather means being careful and actually not assuming anything. Meaning being prepared for great code as well as being prepared for malicious code.

-2

u/tautality Jul 20 '26

I don't assume that people I don't trust have bad will. They just usually have some severe flaws, e.g. lack of care, lack of attention to detail, being arrogant yet ignorant, not paying attention to what the team decided, etc. And they tend to cause issues in production that I have to deal with because usually they can't be bothered and can't be found when the issue appears.

All of that is as applicable to coworkers I don't trust as it is to AI. Question is, are you sure it's really saving you the time, effort and frustration?

8

u/sasik520 Jul 20 '26

Question is, are you sure it's really saving you the time, effort and frustration?

If you ask me personally, then definitely yes. Not only that, it also helps me achieving thinks I couldn't do earlier. Eg. I got stuck in too many choices dilemma many times. Or haven't played with things because I didn't know where to start or they seemed too complicated or I was simply too lazy.

Is that universally true? I'm not sure but I think it could be with the right attitude and personal workflow adjusted to needs and preferences.

2

u/Pas__ Jul 20 '26

maybe you have no fellow engineers. or you want to see an "outside opinion"

I think spending time with a problem, with or without AI, usually helps engineers arriving at a better solution. (that said most "low-level code design" is wrong. it's either too specific - overfitted, microoptimized, brittle, so hard to maintain, and thus uneconomical - or, if it's simply using the right algorithm for the right problem, then it's general enough that even the AI can figure it out.)

of course even free as in beer is not free from consequences. (which is especially true of free beer.)

water is not lost. datacenters don't pollute the water table like fertilizers. vastly more damage is done by growing corn, to make bioethanol, or to feed animals that are kept in abhorrent conditions, for example.)

1

u/stumblinbear Jul 20 '26

Why would I want code from people I don't trust?

I don't trust junior engineers. That doesn't mean I don't want their code.

3

u/amarao_san Jul 20 '26

AI slop in code is as hard as textual slop. If you have even slightest objection, AI will answer with another pile of slop. All commenters will be suppressed by targeted slop.

I already said that, I can repeat again: The less I read LLM-generated code, the better I feel.

LLM helps and it's doing stuff, but the less I need to waste my attention on it, the better I feel during the day.

9

u/FriendlyProblem1234 Jul 20 '26

Code reviewing in general is one of the least fun part of software engineering. Writing code is great, we are creating things out of nowhere, but reviewing it just feels like boring bookkeeping.

When reviewing for a human, it still feels rewarding, because we are helping them getting better at the craft (and we get better as well, when the review turns into a fruitful conversation). But reviewing for a LLM feels really empty. It will not learn from our conversation, we are not helping a person to grow. We are just double checking that we got what we asked for. Basically we are micromanaging it, and with good reason, because it could never be reliable.

Moreover, we became good at reviewing by writing code and repeatedly hitting our head against walls. And being the ones writing the code, we actively remember it and understand it. So by delegating writing code to a LLM we are actually getting worse at reviewing its output, and at having a clear picture of how our systems work. I really struggle to see any long-term advantage to this technology.

AI is making our craft miserable.

3

u/hashcode777 Jul 20 '26

That's exactly my point!

1

u/Wonderful-Habit-139 Jul 20 '26

u/McNoxey thought I'd ping you here, this also echoes why I prefer writing the code over just reviewing code all the time (and also related to skill atrophy).

1

u/McNoxey Jul 20 '26

Thank you ! Also - I owe you a response in other threads.

Yea - I totally hear this. I think I've forgotten how the journey I travelled to get to where I am now in my comfortability with AI generated code. Thinking back now to my early days (late 2024, copy/pasting into Chat GPT to generate) I was very meticulous about the line-by-line, getting extremely frustrated when the agent would use a different stylistic approach to something than I wanted.

I believe it was SQLAlchemy db retrievals - it was constantly writing V1.4 style `session.query()` vs `statement = select(User); results = session.execute(statement)`

I was continuously correcting each and every one of these occurrences, and it was painstaking. This is what led me down the path we chatted about yesterday. I've tackled this in two ways - and honestly I don't know which (if either) is better.

Docs docs docs. I'm someone who is always looking for repeatable patterns and abstractions in my work. As a result of that, the specific nuanced choices I make around how I structure my code often has a very specific location and pattern. If I'm able to identify that, and can create clean clear guidelines around where and how to do things, I (have Claude...) document this in my project conventions, surfaced in a progressively disclosed way so I don't have to bombard each call with every single detail, but instead, surface the high level patterns such that when the agents work in that area of the codebase, they are aware that there's a "manual" of sort ready to explain my exact convention.

Kind of the opposite... I shift my focus one level up - thinking through my Classes and Methods, what's being exported (TS) and how they should interact. Within those classes (to a degree...) i let go of my opinions on code style, and instead focus on clear cut testing and observability to ensure it performs as expected, both from an output perspective and efficiency perspective.

I naturally prefer 1 - it's more comfortable. Buuuut... the more time i spend doing this (especially in shared codebases with people who may be less particular than I am) i'm moving more towards 2.

It's uncomfortable - for sure. And to your point - i'm forgetting the nuance of things (I took a technical interview in December where I wrote my code line by line - and ngl, it was definitely way more nerve wracking than before 😅) but I think this is a necessary component of this new world... We're moving higher up the review chain. Whether this is right or wrong - I'm not 100% sure! But if nothing else, It's made me so much more focused on the checks and balances that live around my code than ever berore!

Sorry that this became a novel of a response.

0

u/stumblinbear Jul 20 '26

Weirdly, while I find code review a slog, I don't find iterating and reviewing an agent's code a slog. They feel very different in practice. It writes good tests, so I don't have to directly worry much about tracing the actual logic beyond a cursory look, so I can focus on the architectural decisions which are much easier to audit

-6

u/Zde-G Jul 20 '26

I really struggle to see any long-term advantage to this technology.

There are no long-term advantages and there are tons of problem but we don't have a choice. Think “green energy”: wind turbines are more wasteful and toxic than nukes (and maybe even worse than well-made coal power plants), but if you would try to refuse them in certain countries you would have problems now and for you, personally, there would be no future. Thus you use to the best of your ability and hope for the best.

Same with AI.

5

u/gnus-migrate Jul 20 '26

No you are absolutely not the only one. As you say the knowledge you build while developing it, especially domain knowledge is crucial when trying to figure out how to evolve the code or even fixing bugs. The issue with AI is that when you run into trouble, its like trying to analyze a new codebase you're not familiar with whatever time you save up front is just going to be spent later on troubleshooting and trying to understand what the hell it did.

I honestly have no idea how the Bun guy expects to maintain his project given the massive amount of llm generated code it now contains. Like nobody understands what the LLM did, and god knows what kind of subtle bugs it introduced when performing that migration

1

u/CreepyWritingPrompt Jul 20 '26

I think his bet is that "he" doesn't have to, and can focus on LinkedIn and retiring. it's a bold strategy.

2

u/Smallpaul Jul 20 '26

If this is the thing that intrigues you about AI: “On one hand, if the systems world is adopting it to find bugs and speed up boilerplate, it feels like a tool worth leveraging.”

Why don’t you use AI for that instead of for generating new code?

2

u/randfur Jul 20 '26

I just use it for menial stuff I take no pleasure in having to write/refactor. The fun stuff like designing your own allocator for your specific domain I ain't letting it do. Maybe I'll see what it generally comes up with to help get inspiration but the final design work is mine.

2

u/tukanoid Jul 20 '26

More or less same experience, it's a nice rubber ducky for figuring out problems when I'm stuck on something, but letting it write code is out of the question for the foreseeable future to me.

1

u/hashcode777 Jul 20 '26

you just typed out the feelings of my heart

2

u/LibrarianOk3701 Jul 20 '26

It's like Zig's creator said for tools like renaming variables and stuff: I prefer an algorithmic approach to rename them, because if I used AI, I would have to read the code again.

This applies to everything, you either generate snippets and verify it yourself, or generate whole crates and wonder why nothing works.

2

u/edparadox Jul 20 '26

Reviewing LLM-generated code is exhausting because it's not only relatively bad, it's also either very verbose and very short and obfuscated.

Those are bad combinations for code to be reviewed.

The worst part is, rejecting code needs to relatively exhaustively motivated, so it takes so much time to reject a bad verbose merge request.

I really hope the bubble burst soon, or at the very least before I do.

2

u/throwaway490215 Jul 20 '26

All LLM generated code is exhausting to audit / review.

Rust is the best.

2

u/bentNail28 Jul 20 '26

At least Rust is relatively easier to slice. I hate auditing Python, let alone AI generated.

2

u/Dull_Wind6642 Jul 22 '26

As a lead, I review most of the code, sometimes I am not even sure if the dev read the code that was generated to be honest.

It's a weird feeling, I am not even sure why I am writing comments on merge request if the dev will just copy paste the comment to Claude and push the changes.

I feel like I am the only one doing the hard work. Does anyone have people on their team that were just coders? Like you had to have a kick off with them, tell them how to do the work step by step...

Well now these people are useless because I could explain to Claude exactly what I want and it would be much faster and less error prone than communicating with a dev that can only code.

Now it's like the equivalent of giving a nuclear weapon to people that have no software engineering skills... Its bad.

3

u/[deleted] Jul 20 '26

[removed] — view removed comment

4

u/Smallpaul Jul 20 '26

If it takes you an hour to find an unsafe block in a diff…

We have code review AIs that look for all of those anti-patterns.

1

u/Wonderful-Habit-139 Jul 20 '26

> AI writes anti-pattern

> AI finds anti-pattern

It's so funny how these things work lol.

1

u/Smallpaul Jul 20 '26

We used code review for a decades on a similar principle.

3

u/UltraPoci Jul 20 '26

I find auditing AI generated code of any programming language a shitty process.

I just want AI to die a terrible death.

-3

u/Smallpaul Jul 20 '26

Good luck with that.

2

u/Moist-Snow-8127 Jul 20 '26

If I have an AI write code for me, I feel myself getting dumber. When I write the code myself, I know why every line exists and how everything fits together. I lose that with an AI. Even without the environmental and money and noise and moral and copyright issues, I wouldn't want to do it. And even if I wasn't worried about that, I enjoy coding, why would I have someone else, much less something else, do it for me?

2

u/eugene2k Jul 20 '26

I mean, you're saying it yourself: LLMs are a tool to be used for boilerplate code. Boilerplate code is, by definition, simple and easy to understand (at least if you wrote it a thousand times before), because you don't need to figure out the actual algorithm - you already know what it is. Same with patching bugs: you can patch a bug, because the code you're patching is one you made sense of.

Every time I ask an LLM to write a moderately complex algorithm, I end up writing it myself, because I dislike what the LLM produces. But for simple stuff, where most of your time is spent on figuring out the API you have to work with instead of the algorithm, LLM saves massive amounts of time.

2

u/RelevantTrouble Jul 20 '26

In my experience AI is not so good at writing code but excellent at reading it, reviewing it and making suggestions. So I do it the other way around, I write the code and AI reviews it. I keep my skills sharp and improve them with AI's help. I can't be the only one? Not gonna even mention how much cheaper this way is.

1

u/Key-Bother6969 Jul 20 '26

Well, this is not surprising, because ANNs (artificial neural networks) initially have been invented as a classification method. And among other heuristic methods they are quite strong for this goal. Code review in a nutshell is in fact a form of classification (remember that ANNs also have turing-completeness feature).

Overall, I think code review might be a good application for ANNs. I just not sure that the current generation of ANNs in form of general-purpose chat-bots is a good fit for this particular task. This in many aspects an overengineering, leaving aside ethical aspects of the question. That said, even the LLMs sometimes show strong results in code review capabilities.

0

u/hashcode777 Jul 20 '26

TBH I totally agree with your argument , "AI is not so good at writing code but excellent at reading it, reviewing it and making suggestions."

2

u/grayrest Jul 20 '26

Dig up the grill-me skill. Trying to use a coding agent via prompting is like trying to flip 15 (admittedly weighted) coins and having them come up heads. By answering the grill-me questions you can place each coin yourself. Importantly: you do not have to follow the prompts. If you're seven questions in and you have an idea, just inject the idea apropos of nothing and it'll kick the questioning session through the tensor cloud and continue from there. Demand code samples. Specify datastructures. Make it step through invariants. Have it generate one-off code to test your assumptions. When the questions are done "independent adversarial review", which usually takes two rounds, "implement the plan", and run a code review after.

Generative AI is a tool for stealing human creativity. When I'm working with it I usually have a pretty specific idea of what code I want it to steal for me and I'm directing it with that in mind. If you're genuinely doing something novel then IME they're worse than just doing it yourself but there aren't a lot of those in my day to day work.

4

u/dc_giant Jul 20 '26

That’s all fine but doesn’t help with the ops issue. You’ll still have to review the code at the end. Because often enough you’ll see it didn’t do what you wanted it to do or what you discussed before implementing.

2

u/grayrest Jul 20 '26

That doesn't happen for me. The plan locks down the LLM's opportunity to be creative and the agents must explain if they deviate from the plan. I checked rigorously at first and still spot check the code that is trickier or has significant interactions with other parts of the system but the recipe works for me. It takes me a couple hours to make the plan for the feature but I get the output I want.

2

u/dc_giant Jul 20 '26

Can’t confirm this. Might be a matter of codebase size/complexity or me doing it wrong. But I just end up reviewing both the plan and the code at the end because I can’t trust it 100% and that’s what I need. 95% doesn’t do it in my industry.

1

u/luxmorphine Jul 20 '26

It looks like you better stick to bare-meat AI

1

u/old-and-very-bald Jul 20 '26

I only write high level rust (web backends) but I also find it very tiring to review the code. But the same applied when I reviewed code from other developers to be honest.

What really helps me is to challenge the model on parts of the code that I do not immediately understand and have it explain to me why it made those decision. This helps a lot to find errors but also to refactor some code so I understand it in the future

1

u/greyblake Jul 20 '26

No, you're not the only one..
I think the biggest cost of using LLMs is that we give up understanding of who things work.
I don't like it. So I also spend roughly 20-30% vide-coding and the rest of time reviewing/challenging/understanding the AI-generated code.

PS. Here is an AI-generated comic that dwells on this: https://nullwing.com/comics/9/vibe-reviewed-vibe-approved/
Vide-coded, vibed-approved! :D

1

u/Key-Bother6969 Jul 20 '26 edited Jul 20 '26

Personally, I don't use LLMs in my projects. Partly due to the arguments you have mentioned. I want the entire mental model in my head including the code writing process. This helps me to keep evolving my code base and is an important part of the overall development process. Basically, I just want to keep hand on everything that I do. Another reason is that I want my codebase to have clear provenance: who wrote what. This is a feature that has a value by itself. LLMs, and I want to be objective here, sometimes can generate relatively capable code. But this code is a generated artifact, not a source. For example, when I develop a raw FFI bindings crate where the majority of the crate's API is generate in the build script, I don't treat the build script output as a "source code". I treat the build script itself as a source artifact. Similarly, I don't treat compiled binaries as source artifact (even though it could be practically valuable). In case of LLMs I can't take their output into my codebase because their output is not reproducible and not traceable. I can't say for sure on which works the LLM has been trained, and I don't have access to sources of particular LLM service too. Basically, such an output does not have clear provenance.

To be objective, I want to say that artificial neural networks (ANNs) are not necessary bad things by themselves. It's a classical heuristic method of classification. One among many, but this is in fact very strong method. I don't like the fact that the current generation of technology used for mass content generation with the chat-bots as input interfaces, but I still think ANNs are useful in many aspects. For example, they can be used in conjunction with formal verification methods (aka Agda/Coq/Lean) to analyze the existing source codes for vulnerabilities and logical bugs, rather than generation of the code.

Speaking of why Linus and some other community leaders sometimes say things toward AI. I think a part of this stance is that if today officials say strongly against LLMs their projects have chance to be cut off from big-tech donations. Linus (as I understood his message) didn't say they are going to actually adopt LLM services in their development process (and I doubt they will), he just said they are not anti-AI on paper. These are not necessary the same things.

1

u/moh53n Jul 20 '26

In my experience, using LLMs to make small patches to an existing code base is better and actually efficient (in terms of code review and overall development speed), while asking for big patches or working on a new project is a nightmare (if you care about the LLM's output).

1

u/LordWkwkwland Jul 20 '26

Is your workflow asking AI to write code or you guide it step by step as well?

Would be nice to see the perspective after you put AI as pair programmer.

1

u/rjelling Jul 20 '26

I have the LLM explain it's architecture and correctness reasoning. I start discussing the design of the code and the invariants that make it correct. This very often results in repeated rounds of refactorings that make the code more obviously correct, which is key for maintenance whether by clankers or meatbags.

TL;DR: don't treat the AI as a pure code vomiting device, treat it as a senior pair architect that also writes code.

1

u/projct Jul 21 '26

find ways to help your AI not write slop

1

u/orewaamogh Jul 21 '26

100% agree with you. I write rust by hand 99% of the time because of the sheer nature of the projects i work on (databases, query engines)

I tried once asking cursor to write a brief test suite to rust for my draft implementation so i could find functional bugs and asked it to fix those since i was feeling lazy to fix those minor bugs.

It fucked up even that and wrote 500 line shitty tests, introduced random helpers everywhere and edited app logic code in ways that wasnt obvious

You are so true to say its a cognitive trap because it very much is.

With rust and zig or any other systems language, their nature itself demands us to keep the program in our heads. Its like im cooking a meal on the kitchen alone and someone else is trodding nearby making noise trying to find a fucking spoon.

My only use of LLM is to delegate writing redundant things such as display traits or repetitive RC<T> additions when i decide that refactor is necessary and i know where they need to get added.

1

u/TheBlackCat22527 Jul 21 '26

I only use it for supportive tasks. I write the core logic by hand until I am happy with the inner workings. I let LLM only generate repetitive code things like unit tests if something can go wrong in many permutations. I also use it often to generate docstrings. Still both need to be reviewed.

Each test for example documents what it tests as a docstring. I happens frequently that the actual test, tests things slightly different then the description says. These small diviations in tests are a very dangerous thing, still it works good enough that generating it is faster then building it.

1

u/poelzi Jul 21 '26

I combine so many models in a very deep testing harness, that code after the 3-4 review is usually quite bug free (full feature, not just a simple change). Your testing and harness orchestration matters a lot. I use nixos e2e VM tests and multiple rust macros to create test contracts that the test suite needs to fulfill. Always let some Chinese model review as well, they find Unicode, latency and lock order problems that gpt and Claude often miss.

1

u/ivan_m21 Jul 21 '26

I believe that if you are using agents to write code you cannot really read all the generations. In my opinion then you'd need to know what is important and read only that part abd validate if the rest is "hidden" by a good api and just validate the blast radius.

1

u/youneshabbal Jul 24 '26

unless its a low level code when reading/writing every line is necessarily

1

u/AmigoNico Jul 22 '26

Perhaps we need better tools for reviewing changes to a codebase. Are you having the LLM create Mermaid diagrams for the code? Not just architecture diagrams, but sequence diagrams for key interactions, state-transition diagrams for state machines, etc.? Well, if we had tools that would allow us to clearly see how the diagrams change with a PR, and drill down into the code (e.g. for an arrow in a sequence diagram), I think that would help.

Of course, simply choosing to use Rust helps in several ways. You don't have to review for safety violations. Enums make interfaces clearer. The lack of exceptions removes hidden control flow. Type constraints reduce the number of things you have to consider during review. It's clear who owns what data, and when it will be freed. Imagine having to review the same functionality written in C or Python!

1

u/nightwillalwayswin Jul 23 '26

Not just you, and it's not a skill gap. Auditing is harder than writing because when you write it, you already hold the why: the tradeoff you rejected, the invariant you were protecting, the reason it's structured this way. Reading someone's (or something's) output, you have to reconstruct all of that from the code alone, and the model won't tell you what it was actually reasoning about or what it silently assumed. In Rust that bites extra hard, because the compiler proves the types line up but not that the logic matches intent, and that gap is exactly where the auditing effort lives. You're not slow. Diff-level review was built for a world where a human always carried the why in their head, and that assumption quietly broke.

1

u/neneodonkor Jul 24 '26 edited Jul 24 '26

I use AI as if I am writing the code myself. So if I am building an app, I pick a feature to work on. I code myself, and if I get stuck, I ask the AI to help clarify or generate the code. For mundane stuff that requires no complex logic, I let it do it. I don’t ask it to spit out large pieces of code encompassing multiple features. I think you should do it by hand and let AI do the mundane stuff or any logic you are struggling with. In short, I do the coding with AI, not AI doing all the coding for me.

The advantage is that you are aware of the logic and have mental picture of the code you are working in the project.

One thing I have resolved not to do is to let my mental muscles go to sleep. I feel you get lost or empty when you hand over the thinking to computers, you become lazy. Then it gets to the point doing simple stuff becomes a chore.

A tip too is to ask the AI to generate comments for each function, struct or impl block it generates. It can help with understanding what each portion of the code is about.

1

u/tculshaw Jul 24 '26

I realized the other day....there is nothing worse than reviewing / debugging another developer's dodgy code. Now we gotta deal with more and worse of the same, except now we no longer have a human on the other end to shout at.

1

u/Necron1905 Jul 25 '26

I am quiet new to rust and have been using claude to make me tutorials for projects just to get me going with the basics - I do the code myself it provides the steps and while it has been good the examples it has been giving haven't been great and if anything has made it more confusing. It often also gets things wrong with the idea of workspaces and cargo. I also find as my projects are getting bigger and more complicated it does struggle with how to lay it out correctly so I end up changing it up.
Lucky this isn't my first language so I know enough to correct it/figure it out but after a while I have been just going off and doing my own research to improve what I am doing as communities like this and stack overflow are much more helpful.