Need help about AI

help
2

I do not use LLMs, i do not ask LLMs for help, I do all the planning without LLMs.

3

I will answer your questions based on the project AI did for me:

Learning Rust is painful for me, so I decided to delegate most/all Rust coding to AI. I do not use expensive token hungry systems, I use just the copilot Microsoft supply with Windows.

I already split complex projects by simple tasks, so I ask AI to code every task like a function and then I dd stitching it in the project manually.

I do a commit as only feel that a particular feature started working. Since the app supposes to work on all existing platforms, I do a commit also when I need to test/continue development on other platform. I do a commit also after any bug fixing or completing a refactoring task.

The project is obviously open source and contributor is AI in addition to myself.

I didn't need any help in architecture of this project because, I already knew what the project should do, I also wanted to use particular technology as websocket for its implementation. I prefer to do architecture myself, but sure I can delegate some tasks to AI in future if I will be confident it will do architecture right.

I didn't accept any AI solution without clear understanding what it does. So learning is a part of my development process.

10-80-10

I hope it helps.

4

I am probably not the best example here, since I use Rust for a small part of one of my projects (my "default" language isn't Rust), but still, I use AI to:

  1. ...review my code and look for errors right before I commit. Ironically, Rust is so "strict" language, so lots of errors are caught by the compiler, and most AI comments are usually small performance improvements. This is unlike some other "mainstream" languages which do a lot checks in runtime (only to silently skip bugs, putting the whole system into an inconsistent state, you now), so AI sometimes finds interesting problems in old, hairy code.
  2. ...write tests. Good test frameworks usually do not require much boilerplate, so tests could be written manually, but even writing down 20 possible cases worth delegating.
  3. ...fix broken English in my commit messages.
  4. ...help me to investigate time-consuming problems: what could be the reason of this rare race-condition user have seen once? Here is 20 megabyte trace. I do it, and I feel like I am slowly losing my cognitive skills. Maybe I should stop doing it.
5

Context: I'm only answering in relation to personal coding, which I do for fun.

"It depends" :wink: on:

  • if I'm about to spend a few hours trawling docs & src to try to work out how something fits together (usually I've just spent 15-20 minutes realising this will take longer)[1]. Then I'll send it off to research and provide a detailed explanation, maybe a few options for how to proceed. I usually need a few back-and-forth "yes, but what about ...", "wouldn't ... be better / also work", "why doesn't ...", "what alternatives are there to ..., I don't like ..."
  • if I've only got a vague idea of the skeleton of what I might want and want to avoid spending half a day mashing it together only to realise I need to go back to the start and rethink fundamentally[2]. Then I'll send it off in a dedicated git worktree, with a rough sketch of that I want to achieve and what I think the code shape should look like. Sometimes I'll even get 2 alternatives running in parallel worktrees. Afterwards I expect to pretty much start from scratch recoding the basics by hand before ...
  • if I've got past the "bit I'm excited about" and it's time to boilerplate[3]. Then I'll leverage it as a very powerful autocomplete.
  • if I'm deeply invested in a different crate / module / use case right now but need something to support that[4]. I'll send it off in a worktree or other repo to work on what I need.
  • By default I have an LLM service review all PRs on my repos. It's great to have a 4-eyes check on my own code. It's not perfect by a long way but catches subtle things quite often.

I love to code, so I'll often re-write the code by hand. Or go off on a tangent for a few days developing skills & tooling to get the AI output closer to good, then probably re-write the code a bit anyway :wink:

A lot depends on how "boilerplate-y" the job is and/or how tangential it is to my current focus (I'll likely revamp tangential work at some time in the near future and use it for now)

I commit a lot and try really hard to force my agents to do the same. I have never ended up thinking "I wish I'd comitted less often" and still regularly think "damn, why didn't I commit that interim result - I really want to take another look at the idea and maybe use a bit of it here".

I like to have agents commit after each turn, so I can take a look at the interim results and think about how to improve the setup (skills, prompts, agent definitions, tools etc) or identify where it found a "better way" but then dropped it because of an "out-of-scope" change that it would have required.[5]

I squash my PRs to main, so the long list of commits on a working branch are only temporary. I also set my github repos to only accept linear history on main, require a PR, only allow squash merging PRs and auto-delete branches for merged PRs[6].

On third-party codebases I would NEVER use an LLM to generate any contribution. That's not fair on the maintainers. The only possible exception is if the maintainers have made a clear "LLM accepted" statement and provided an AGENTS.md etc. for contributors to follow.

  1. If there is something you would like to see in a crate you want to use, but it's missing what you need. Or you find a bug / documentation issue / ... when you're using a crate. That's the best place to start, you can also develop your project against your fork for a bit, so you get real feedback on the value of your idea to the other crate.
  2. Many projects have a "help wanted" or "good first issue" tag plus some guidance on the sort of general help they want (extending tests, documentation are common cases).

It depends :wink:

  • Historically, I would start a project because I was interested in it enough to want to code it. I do the driving and enjoy the coding.
  • Occasionally now, I start a project because I really just want the result. I'll share the workload a lot more on these projects but often leave them unpublished, until they switch to the above case. I don't want the maintenance responsibility for "2000 random things I got AI to do and now other people are using them"

That's all down to your own mindset. If you actively want to learn, then you'll do that. If you "want to have learnt" then you're in for a struggle no matter what.

  • Be very clear yourself whether you are asking it to implement something, help you learn, act as a sparring partner/researcher, or a mix of them.
  • Ask "how would you ... go about?", "I'm thinking about implementing a ... but I don't know how ... would work. Can you explain it to me?", come back with "hmmm ... but why/what about ...?" and "I don't understand ... why can't I ... / why do I need to ...?"
  • Only once you have enough of an understanding say "OK - can you implement that for me", or even better "I'm going to try to implement that, how should I start?" / "I've started to implement ... can you help me with understanding ..."
  • Ask it to explain its code and the reasons it chose to do it this way

It's all mine. I don't feel comfortable having any code "out there" in my name that I don't feel ownership of. How I get to that point varies but always involves line-by-line engagement with the code. If I ever feel "I don't actually know how this works", I either stop and dig into it, usually improving as I go, or throw it away and start again. The approach in my answer to the first question helps a lot with avoiding code I don't own.

That's exactly the same as I would with a PR raised by someone else on one of my repos BUT without the concern for the human who did the work. I'll take time to discuss with a human, to understand their ideas, kindly suggest edits, try to fill in the gaps rather than just go "back-to-sender".

  1. "how the hell does tracing_core::DefaultCallsite work? It seems to have circular internal references. I need to construct one for <specific use case & reference to point in current code base>. I'd suggest you take a look at and " ↩︎

  2. erm ... can't think of the last specific case right now ↩︎

  3. I've defined and implemented trait Trace with or_warn() & and_warn() now I want to add or_error, and_error, or_info, ... which are all just variations on a theme. ↩︎

  4. I'm busy working on getting the right span hierarchy through my app & supporting library and really want an alternative to .map_err(|error| { tracing::warn!("uncooperative yak", %error); error })? ↩︎

  5. If this struct field had a set_foo(&mut self, value) method that validated invariants then ... would be possible. Something is missing Default or Display, an enum needs an additional variant to make life easier elsewhere, ... ↩︎

  6. That's for my own projects. If I'm contributing elsewhere I check the guidelines and rebase my work into the preffered commit style, if there is one ↩︎

6

You have a lot of questions there. I don't want to go through them all. But here is my current approach.

For example my current project is a web server/service thing. I know it can be done in Rust. Likely using Axum or some such we framework. I know I want some kind of graph database behind it, a topic I know nothing about. And a couple of other features that I am not familiar with.

So the first step is to have a discussion with my LLM where I say what I want and it comes up with suggestions about how to implement it. That LLM may well just be the AI mode in Google search. So at this point the use of LLM is as a turbo charged search engine and Stackoverflow replacement. No code is being written.

From that we home in on what seems like a reasonable plan. In this example it is decided to use Axum and some helpful Axum related crates that I have found that look like they can help. And to use Surrealdb for the graph database. And so on.

At this point I have a lot to learn. So I spend some days looking at Axum docs, tutorials and building actual Axum code myself. Similarly for the Surrealdb. That at least makes me understand how these things should be used and all the parts should hang together even if I'm not super familiar with the details.

With that done it's time to refine the plan. Pining down what will be used and how. I think helps to ask the LLM what it thinks the project is all about, get to ask you questions if it has any undecided or ambiguous notions.

I also think it helps that the plan splits the project into smaller meaningful chunks that can be implemneted and tested independently. Could be Rust modules. Could be separate libray crates in the Rust workspace. Then you can let the LMM get to work one stage at a time.

My use of git is such that when one of those chunks of work is completed and tested it gets committed. I don't like to have untested code committed. I do want working code committed before moving on to the next step incase the LLM decides to mess it up! It can happen of course that when I review the code I see that the LLM has taken off in the wrong direction or otherwise making a mess. In which case it all gets reverted to the last commit and done over again, after some refinemnt if the plan to ensure the same does not happen again.

7

(Probably very unrelated to your post so feel free to ignore)

I'm undergoing a vibe-code therapy by revisiting the Rust Book and relearning things I might/might not already know. It brings a lot of benefits not just in your Rust coding skills but how you make your approach in general. A good brain exercise too.

This might be farfetched or very contradicting to what you've asked but I highly suggest doing it like the forefathers of programming intended. Not everybody is a Linus Torvalds, so I would suggest you take your time actually learning it, you have the compiler as your often-incomprehensible senior dev, unless its actual work...

8

wouldn't call myself a "rust developer" but i have co-authored with claude on a media encoder and it seems to understand rust quite well.. sometimes. for what it's worth:

  1. ai + rust: i mainly use it for testing more than 10 interactions of ideas i have or writing test cases
  2. vibe coding to me is someone who cant read the code and generating endlessly until they have a result they desire or are okay with accepting
  3. github activity: i cannot make 5000 commits a year i try to be happy committing a few times a week and make those count (quality over quantity any day)
  4. contribution: i have exactly one live rust repo: LoMux
    as far as contributing i would say start with small issues and things that the developer could absolutely fix themselves but does not have the time to do
  5. projects: i design the architecture from the ground up honestly, i mostly know exactly what i want to build i just lack time. yes and no on core logic for certain projects (hobby projects for example) but honestly reading the code it writes is probably your biggest factor here in 2026
  6. learning v ai: im going to sound like a broken record but read the code. don't continue until you understand what the hell it's doing if you want to push that even further.
9

The same! :grin::+1: Truly not a lamer, as I can see it immediately :face_savoring_food::handshake:

10

I'm not using AI :robot: at all :slightly_smiling_face:

But... Yeap! Obviously, doing pretty much humble, and small projects :thinking:, but with using only my hands :grin::open_hands: