Gemini CLI is a terminal coding agent you start with gemini in the project folder. For Rust work it is most useful when you give it a GEMINI.md that captures cargo, test, lint, and formatting rules, then keep every change small and verify with cargo test and clippy. The agent overview at Gemini CLI covers the basics if you are just getting started.
How Gemini CLI helps with Rust’s toolchain and borrow checker
Rust development is command-line native: cargo build, cargo test, clippy, and rustfmt all produce structured, textual feedback. Gemini CLI can consume that feedback directly, propose fixes, and rerun the same command. It is especially useful for compiler-driven refactors where a borrow checker error points to a specific span and the agent can try a minimal ownership or lifetime change. In a cargo workspace, it can stay scoped to one crate by using -p <package> flags, so changes do not ripple across unrelated code. Because cargo output includes file:line spans, the agent can navigate directly to the relevant code without guessing.
Configuring GEMINI.md for a Rust project
Place a GEMINI.md at the workspace root or the crate root you usually open. The file should be short and concrete: build, test, lint, format check, crate layout, and Rust-specific rules the agent should honor.
# GEMINI.md
## Commands
- Build everything: `cargo build --workspace`
- Run all tests: `cargo test --workspace`
- Lint: `cargo clippy --workspace --all-targets -- -D warnings`
- Format check: `cargo fmt --all -- --check`
- Run the server: `cargo run --bin server`
## Workspace layout
- `crates/core` — domain types, errors, and pure business logic; no I/O.
- `crates/api` — HTTP handlers, request parsing, and response mapping.
- `crates/storage` — database access behind repository traits.
## Rust-specific rules
- Prefer `&str` for function parameters unless you need to store or modify the string.
- Do not add new crates to `Cargo.toml` without asking first.
- Run `cargo fmt` after editing, not `rustfmt` on individual files.
- Avoid `unsafe` in new code; if it appears necessary, explain why and show the safety invariant.
- When fixing a borrow checker error, prefer a minimal lifetime or ownership change over `.clone()` on large values.
- Keep `cargo clippy --workspace --all-targets -- -D warnings` clean before marking work done.Do not put secrets or machine-specific paths in GEMINI.md. The agent reads it as instructions, not as a source file. If your project uses feature flags, include the exact cargo test --workspace --all-features command; otherwise the agent may only test default features. Also mention which binary to use for cargo run if there are multiple binaries.
A daily loop with small diffs and cargo test
For most Rust work, keep the loop tight: plan the change, ask the agent to make the smallest edit, run the relevant test command yourself or ask the agent to run it, then review git diff before accepting. Agentic coding on Rust can go wrong when a large prompt asks for a multi-module refactor at once, because the borrow checker often rejects it after many moved parts. The guide at How to use Gemini CLI: a step-by-step guide shows a similar step-by-step loop.
Example prompts:
- Read GEMINI.md first. Run
cargo test --workspaceand report the first failing test without changing code. - In
crates/core, implementFromStrforConfig. Add unit tests for valid and invalid input, then runcargo test -p core. - Fix the
needless_cloneclippy warning incrates/api. Explain the ownership change, then runcargo clippy --workspace --all-targets. - Refactor
crates/storageto use a repository trait so callers can mock it in tests. Keep the public API stable and runcargo test --workspace. - Review the current
git diffand point out every new.clone()orArcthat is not needed for the change.
After each prompt, check that the agent ran the commands it claims and that the output ended with the expected pass or failure. Then look at the diff in a real diff viewer. If the agent suggests a change, ask it to show the exact git diff --stat first; this keeps large refactors visible.
What Gemini CLI handles well in Rust, and where to review closely
| Task | Good prompt | What to watch |
|---|---|---|
| Add a parser or constructor | Implement … and add tests | It may use unwrap() in library code; ask for Result or Option instead. |
| Fix clippy warnings | Fix the clippy warnings in crate X and rerun clippy | It can silence lints with #[allow(...)] instead of fixing the underlying issue. |
| Resolve borrow checker errors | Find a minimal fix without cloning large values | It may overuse .clone() or Arc and hide performance problems. |
| Add a new crate in a workspace | Add crate Y and wire it into the workspace; run cargo test | It can edit Cargo.toml and Cargo.lock in unexpected ways; review those diffs carefully. |
Beyond the table, be careful with unsafe, feature flags, and target-specific code. The agent can be helpful with cargo errors around trait bounds and lifetimes, but always have it show the before and after of any unsafe block. A common failure mode is an agent that keeps proposing Rc<RefCell<T>> or Arc<Mutex<T>> to silence the borrow checker when a simpler structural change would work. Review those suggestions as design decisions, not mechanical edits.
Verifying Rust changes with the agent
Make verification non-negotiable. The canonical commands are:
cargo test --workspacefor unit and integration tests.cargo test --workspace --docfor doctests.cargo clippy --workspace --all-targets -- -D warningsfor lint.cargo fmt --all -- --checkfor formatting.
Ask the agent to run these after every meaningful change. When a test fails, ask it to quote the exact failure and the line, not a summary. For a workspace, run the relevant package first (cargo test -p core) to shorten the loop, then run the whole workspace before considering the task done. If the agent touches Cargo.toml, also run cargo build --workspace and inspect Cargo.lock; dependency changes deserve manual review. For libraries, ask the agent to run cargo test --workspace --doc because doctests also serve as usage examples. For binaries, run the integration tests that exercise the main entry point.
Running parallel agents on a Rust project with AgentVera
On a Rust project with multiple agents, AgentVera lets you run real Gemini CLI terminals side by side. The practical pieces for Rust are git worktrees for parallel work without conflicting Cargo.toml or Cargo.lock edits, automatic code review that links findings to file:line, and checkpoint undo when an agent makes an unsuccessful ownership or lifetime refactor. Token budgets also matter a lot because repeated cargo test and clippy loops can consume a large amount of context, especially in a workspace. See AI agent orchestration for coding: 5 patterns and tools for orchestration patterns.
Final thoughts
Gemini CLI becomes a reliable Rust helper when you treat it as a pair programmer who needs explicit context and a fast verification loop. Keep GEMINI.md current, keep prompts small, and make cargo test and clippy the final word. For parallel work, use isolated worktrees. The AI pair programming: how to work with a coding agent guide has more on working with an agent as a pair.