Live data from Hacker News

Learnings from 100K lines of Rust with AI (2025)

zfhuang99.github.io

101–110 of 225 posts

Re: Learnings from 100K lines of Rust with AI (2025)

#102
post #54

We're working on a large Rust codebase, heavily assisted development with Claude and Codex, and one critical workflow is after you have written a spec, have the other LLM critique it thoroughly. This back and forth will take quite a while, but the resulting implementation plan will be 10x better than the original. You can automate this by giving Codex a goal, and a skill to call Claude to review the implementation sp…

This is precisely how I used to use Beads before I made GuardRails (I wanted something slightly simpler, but similar with more 'guard rails'). I braindump everything I want to build, I ask Claude to do market level research. I then ask Claude to ask clarifying questions, when I ask Claude to be critical of its conclusions and provide the top options and to justify it. I also question Claude and say its okay to disagree with me, be critical, I just want to understand.

By the end you have piecemeal "tickets" for your coding agent, if you have multiple developers you can sync them all up into github, and someone could take some locally, or you can just have Claude work on all of them with subagents. The key feature there is because its all piecemeal the context stays per task.

Then I run a /loop 15m If you're currently working ignore this. Start on the next task in gur if you have not. If you finished all work and cannot pass one gate, work on the next available task.

(Note: gur is my shorthand for GuardRails)

I also added a concept called "gates" so a task cannot complete without an attached gate, gates are arbitrary, they can be reused but when assigned to a task those specific assignments are unique per task. A task is basically anything you want it to be: unit test, try building it, or even seek human confirmation. At least when I was using Beads it did not have "gates" but I'm not sure if it has added anything like it since I stopped using Beads.

Claude will ignore the loop if it's currently working, and when its "out of work" it will review all available tasks.

If anyone's curious its MIT Licensed and on GitHub:

https://github.com/Giancarlos/guardrails

Re: Learnings from 100K lines of Rust with AI (2025)

#103
post #54

We're working on a large Rust codebase, heavily assisted development with Claude and Codex, and one critical workflow is after you have written a spec, have the other LLM critique it thoroughly. This back and forth will take quite a while, but the resulting implementation plan will be 10x better than the original. You can automate this by giving Codex a goal, and a skill to call Claude to review the implementation sp…

This is astrology for devs.

Re: Learnings from 100K lines of Rust with AI (2025)

#104
post #9

I'm also shifting to an vibe coding workflow, but I have a genuine question: whenever I use AI for Rust, it makes an insane amount of lifetime errors. I have no idea how people are churning out so many lines of code so quickly. Honestly, despite all the hype around Rust in the community, the fact that AI can't handle lifetimes reliably makes me reluctant to use it. The AI constantly defaults to spamming .clone() or w…

> Honestly, despite all the hype around Rust in the community, the fact that AI can't handle lifetimes reliably makes me reluctant to use it. The AI constantly defaults to spamming .clone() or wrapping things in Rc, completely butchering idiomatic Rust and making the output a pain to work with.

This hasn't been true since around gpt-4.5 on the OpenAI side of things. The 5.x models have been pretty much solid on Rust for a while now.

Re: Learnings from 100K lines of Rust with AI (2025)

#106

Earlier quoted context omitted.

If you ask 10 different humans to produce the spec with the same information (prompt and context) they will also produce 10 unique answers that will contradict each other and (depending on who you asked) may be just as confident. There are real decisions to be made when going from a vague prompt to a spec. It's not surprising that an LLM would produce different specs for the same work on different runs. If the prompt…

LLMs aren't people. They don't reason. They're token generators, a black box. Your analogy falls on its face with any scrutiny.

They very obviously reason.

Re: Learnings from 100K lines of Rust with AI (2025)

#107
post #76

Earlier quoted context omitted.

it's an analogy, it didnt fall on its face at all. it's just a comparison to highlight the point being made was nonsensical. example: you're just a next action generator controlled by trillions of cells and subconscious dna-based behavior. a black box.

Reductio ad absurdum.

exactly my point lol

Re: Learnings from 100K lines of Rust with AI (2025)

#108
post #85
post #76

Earlier quoted context omitted.

it's an analogy, it didnt fall on its face at all. it's just a comparison to highlight the point being made was nonsensical. example: you're just a next action generator controlled by trillions of cells and subconscious dna-based behavior. a black box.

> you're just a next action generator controlled by trillions of cells and subconscious dna-based behavior. With moral agency and the ability to learn (even if we presume you are correct, which I don't think you are).

moral agency and the ability to learn are implicit in the description you quoted. this isn't some special superpower, all animals have the ability to learn, and many have moral agency. these aren't human specific traits

Re: Learnings from 100K lines of Rust with AI (2025)

#109
post #36
post #29

Earlier quoted context omitted.

Sorry, should clarify. .clone() itself isn't inherently unidiomatic when used . My issue is specifically with how the AI uses it. In AI code, .clone() is almost always used as a brute-force escape hatch

So .clone() significantly reduces the mental overhead of using rust with a small performance impact? I'm intrigued :) Maybe it's harder to reason about the lifetime semantics while also writing code, and works better as a second phase (the de-cloning).

    > So .clone() significantly reduces the mental overhead of using rust with a small performance impact? I'm intrigued :)
No, the performance impact will depend on `impl Clone` for the underlying type, the hotness of the code path, and how sensitive to those two variables your code's domain is. It may be extremely expensive.

    > Maybe it's harder to reason about the lifetime semantics while also writing code, and works better as a second phase (the de-cloning).
There are cases where assuming `clone` is possible allows for significant architectural and API simplifications at the expense of performance. In those cases, de-cloning will be involved and may produce significant changes.

Re: Learnings from 100K lines of Rust with AI (2025)

#110
post #99
post #30

Earlier quoted context omitted.

Honestly Rust is an UGLY language. For whatever powers it possesses in memory safety, its cryptic symbology is reminiscent of assembly. This is a problem when language designers are mathematicians and don’t understand typographical nuance and visual weights.

I really don't get the complain about Rust's syntax, it's almost identical to TypeScript's and nobody complains about TypeScript Synthax being ugly … (Yes, I know the 'a lifetimes are a bit weird, and that's not something that exist in typescript, but that's also not something you use everyday in Rust either.

[dead]
Post reply on HN