A request budget for my first week learning Rust

When I use AI to learn a programming language, I want two things: working knowledge and a bill that does not surprise me. The easiest way to lose both is to ask for a complete application and spend the evening requesting fixes. A better approach is to build something small, make predictions, and ask for help only when it moves your understanding forward.

This walkthrough uses Rust as the new language and assumes some experience with JavaScript. You can follow the same process with another language by changing the project and the concepts you practice.

Choose one small program you can finish this week

Start with a command-line reading list that stores titles in memory. It should let you add a title, list the titles, and mark one as finished. Leave storage, networking, and a graphical interface for later. The point is to encounter a few language fundamentals without creating a large debugging surface.

Before opening a chat, write down what you already know and what feels unfamiliar. For a JavaScript developer learning Rust, that might include ownership, borrowing, explicit types, and error handling. This gives the assistant a useful starting point without requiring your entire programming history.

Ask for three exercises instead of a finished application

Tell the assistant your background, describe the reading-list project, and request three exercises that build toward it. Ask it to explain the first exercise without providing a solution. For example, your opening request could ask for a sequence covering a single book, a collection of books, and an operation that updates one book.

Set a response limit in ordinary language: one concept, one exercise, and one question to check understanding. Short, focused replies are easier to study and help keep usage predictable. Save broader architectural discussions until you have something working.

Make a prediction before you ask for help

Attempt the first exercise yourself using the language documentation. Before running it, write a sentence describing what you expect to happen. If you are experimenting with ownership, predict whether a value will still be available after an operation.

Then run the program or compiler. When your prediction is wrong, send the assistant the smallest relevant excerpt, the exact diagnostic, and your explanation of what you expected. Ask it to identify the mistaken assumption before suggesting a correction. This turns an error into a lesson rather than another piece of generated code.

Use the compiler to check the explanation

AI explanations can sound convincing while missing an important rule. Treat each answer as something to test. After applying a suggested change, make one small variation and predict the result again. If the assistant says borrowing preserves access to a value, explore when that access is allowed and when it is restricted.

Check disputed claims against official documentation. Ask the assistant which concept to look up, rather than trusting a remembered quotation or an invented reference. Your compiler, tests, and documentation should remain the final checks on technical claims.

Review request costs at a fixed stopping point

Choose a small session budget you can comfortably afford, then review spending after each exercise. MyRelay gives one person one key and one budget across supported providers, with token counts and costs visible for every request. That makes it easier to notice whether long conversations or repeated explanations are consuming your budget.

Create a MyRelay account if you want to track those requests together. You could try Gemini 2.5 Flash for a short explanation, then judge whether its answer helps you complete the exercise correctly. Check current pricing rather than assuming a model name guarantees a particular cost. Keep each request limited to the context needed for that question.

Finish by rebuilding one feature without assistance

At the end of the session, close the chat and rebuild one feature from memory. Explain your choices aloud, then test ordinary and unexpected inputs. If you get stuck, ask for a hint before requesting a solution.

Keep a brief learning log containing the concept you misunderstood, the experiment that clarified it, and your session cost. Tomorrow, begin with that concept rather than a fresh tutorial. The useful measure is not how much code AI produced, but how much you can now write, explain, and check on your own.