A coding assistant can explain unfamiliar syntax, but explanations alone do not teach you a language. A better first lap is a small working program that you build, break, test, and explain yourself. This walkthrough uses Rust and an expense-totaling command-line tool. You can apply the same routine to another language by replacing the project and its standard tooling.
1. Set a finish line for your first Rust program
Keep the assignment narrow: read a text file containing one expense per line, then print the total in cents. Each line contains a category, a comma, and a nonnegative whole-number amount. Blank lines are ignored. Malformed entries produce an error identifying the line. This is deliberately a simple format, not a complete CSV parser.
Tell your assistant: “I know Python and am learning Rust. Help me build this tool using only the standard library. Give me one task at a time, and do not write the complete solution unless I request it.”
2. Prepare the assistant and verify the local toolchain
Install Rust using the official installation instructions, then check that rustc --version and cargo --version work. Create the project with cargo new expense-lap, enter its directory, and run cargo run. Starting from a working default program separates environment problems from learning problems.
If you want a pay-as-you-go connection for your coding assistant, SwiftRelay works with tools including Claude Code, Codex, and Gemini CLI. Sign up for SwiftRelay, connect your preferred supported tool, and use a model such as Claude Sonnet 5.5 for guided explanations. Keep credentials outside project files and prompts.
3. Request a concept map tied to your project
Ask which Rust concepts this particular program requires. A useful answer should cover strings, borrowed string slices, iteration, integer parsing, error handling, and file input. Request a short explanation of each concept, followed by a tiny exercise that does not implement your project.
For example: “Explain why reading a file gives me a String but processing its lines gives me borrowed slices. Then ask me to predict what happens if I try to use a slice after its owning string is dropped.” Make a prediction before requesting the explanation.
4. Implement one vertical slice before adding features
Start with one hard-coded valid expense line. Extract its amount, parse it into an unsigned integer, and print the result. Next, process several hard-coded lines. Only then introduce file input and a command-line path argument.
Write each change yourself. Ask the assistant to review the smallest relevant function rather than regenerate the entire application. Require it to explain unfamiliar syntax and identify assumptions. If it introduces a dependency, an abstraction, or an advanced trait unnecessarily, ask for a standard-library alternative you can explain.
5. Turn compiler errors into prediction exercises
When compilation fails, read the first diagnostic before sending anything to the assistant. Write your own guess about the cause. Then share the relevant function, the exact diagnostic, and your hypothesis, removing sensitive paths or data.
Use this prompt: “Explain the rule I violated. Give me a hint first, not a patch. After I propose a change, check my reasoning.” Run the compiler again after your edit. If the proposed fix fails, report the new diagnostic rather than accepting another untested rewrite.
6. Test the boundaries of your expense format
Ask the assistant for test cases before asking it for test implementations. Include an empty file, blank lines, a missing comma, an empty category, a negative amount, invalid digits, and an amount outside the chosen integer range. Also test whether adding valid amounts can overflow the total.
Decide the expected behavior yourself, then write tests and run cargo test. Ask for a review of error messages and boundary coverage. An assistant's claim that tests pass is not evidence; your local test output is.
7. Finish with an assistant-free replay
Close the chat and rebuild the parsing function from memory. Explain ownership, parsing failures, and overflow handling in plain English. Then add one small feature independently, such as totals grouped by category.
Finally, ask the assistant to review your reasoning and suggest one next exercise without implementing it. Keep a short learning log of mistakes, language rules, and questions. Your finish line is not generated code: it is a program you can modify and defend without the conversation open.