Rust’s compiler gives precise feedback, but a coding agent still needs the project context and the right check to make a useful change. A good AI coding CLI workflow starts with the workspace and its existing conventions, uses Cargo to narrow the failure, and treats a successful compile as one part of review rather than proof that the code is correct.
Ask the agent to map the workspace first
Rust repositories may contain a single crate, a workspace with several packages, generated code, feature flags, or platform specific modules. Ask the agent to identify the relevant crate, its tests, and any documented development commands before it edits. If a compiler message names a package or feature, include that detail rather than pasting unrelated output.
Keep the first request narrow. A borrow checker error may point to a place where ownership should change, but the first suggested fix is not always the design the project intends. Ask the agent to explain the data flow and suggest the smallest reasonable change before applying it.
Use Cargo checks in a sensible order
cargo check can catch many compile errors without producing a final executable. cargo test runs the project’s test suite. cargo fmt --check reports formatting differences, and cargo clippy can surface lint warnings. Use the checks the project already expects, and confirm the Rust toolchain and feature flags before interpreting a failure as a code regression.
For a focused fix, run the smallest relevant package or test first. Then run the broader workspace checks when they are practical. If a command fails because a dependency cannot be fetched or the platform is unsupported, report that separately from a test failure.
- Record the starting commit and the exact failing command.
- Find the owning crate and the smallest reproducing test.
- Make one focused change and add a regression test where practical.
- Run formatting, targeted tests, and the project’s broader checks.
- Inspect the final diff for unrelated edits and changed feature behavior.
Give compiler output without inviting a large rewrite
Share the first useful error and the surrounding type or function, then ask the agent to trace it back to the smallest cause. A large error log may contain useful clues, but it can also bury the first failure under follow on errors. Keep the original test result so you can see whether the agent fixed the problem or merely changed what the tests assert.
Do not ask the agent to silence warnings or add broad clones until it has explained the ownership boundary. Sometimes a clone is correct, but sometimes a borrow, lifetime, or data structure change is the better fit. Compare the patch against existing patterns in nearby code.
Review behavior as well as compilation
A compiling patch can still alter error handling, performance, feature behavior, or public API compatibility. Read the diff and check callers. If the change touches unsafe code, concurrency, serialization, or cryptographic behavior, require a stronger human review and tests that cover the relevant failure cases.
For other language workflows, see the Python and JavaScript guides. The same principle applies across languages: use the project’s own checks, keep the change small, and decide whether the result is correct yourself.