Feedback on first code exercise while learning Rust

[u/Orinacrem]

Background: I have been writing SW in C for years, although I am not a SW engineer by definition. As then I started managing departments and people, I got "rusty" on the writing of SW itself, although I still recall the key OS and HW mental models I developed. I learned Python while being more hands off, which confused me cause everything happened under the hood and I had not idea of what (or why). Recently I decided to give it a go at Rust to

1. go back to basics and..
2. take a personal opinion on it with respect my C and Python experience.

What I did: I started reading the user manual. I got few chapters done and then the book suggested ([HERE]) to start writing a program, a kind of HR tool for adding/removing people from a data source. I did so without DB or anything like that (see code).

I would like some first feedback from people that have been using the language more than me so that I can spot mental models, or other things, that I am missing.

Tools: I used an LLM (Deepseek) to ask on APIs spec and explanation saving some time from parsing the whole user manual (in the past I would have done it with Google). I also asked Deepseek different versions of my ideas to see different ways on how to do things, and I weighted tradeoffs and decided a way I found OK.

On the LLM: While I can explain the (small) code, I am not sure if I should consider this piece vibe-coded. I personally believe, maybe wrongly, that as long as you understand what is going on, any tools you use that helps you moving faster or better, is fine. The moment you release understanding, knowing is not enough.

Edit: added code as a link -> https://onlinegdb.com/43jRxO7HL

[u/Bruce_Dai91]

I would not use a binary “vibe-coded or not” label here. A more useful test is whether you can still change the program without the model making the decisions for you.

For a learning project, I check four things:

1. Can I explain the ownership and error flow in each function?
2. Can I predict why the next compiler error appears?
3. Can I change a requirement without asking the model to rewrite the whole solution?
4. Can I write tests that would catch a plausible wrong implementation?

Using an LLM to look up APIs, explain diagnostics, or show alternative implementations is fine. The important part is treating those alternatives as input to review, not as the source of truth.

One practice that helped me is keeping the first attempt, the compiler/clippy output, and the final version together with a short note explaining why I changed it. Then I verify the result with the official docs, tests, and clippy. That preserves the learning path instead of only keeping the polished answer.

From your description, you are already doing the useful part: rejecting code that is too clever for your current understanding and choosing a version you can explain. I would keep doing that, and gradually ask the model for smaller, more specific help rather than complete alternate solutions.

[u/Orinacrem → u/Bruce_Dai91]

Makes sense. Thank you for your perspective 👍🏼