March 14, 2026 (3mo ago)
Written by David Viejo
Last updated March 14, 2026 (3mo ago)
I use AI to draft the Rust boilerplate, write the tests, and explain borrow checker errors I've seen before — then I handle the architecture, race conditions, and lifetime edge cases myself. That's the honest answer. I build Temps alone: 55 Rust crates, a Pingora proxy, a TimescaleDB backend, an embedded agent runtime. AI makes me roughly 30% faster overall, but the gains are concentrated in specific places.
I want to be specific about where it helps and where it doesn't, because the honest answer is more nuanced than "AI writes my code" or "I write everything myself."
TL;DR: AI makes me roughly 30% faster overall. The gains are concentrated in boilerplate, tests, and documentation. Architecture decisions, race conditions, and subtle lifetime issues are the same speed as before. The biggest workflow shift: I stopped writing first drafts of boilerplate myself, which freed my attention for the hard problems.
The short answer: treat AI as a fast first-draft machine for the mechanical work, and reserve your own attention for the decisions that actually require knowing the codebase.
Here's what that looks like in practice, across the parts of Rust development where it actually changes how I work:
| Approach | Why it works for Rust | Example |
|---|---|---|
| Let AI draft trait implementations | Trait impls are often structurally repetitive — same method signatures, same error type, same Ok(()) at the end. | "Implement ExternalService for PostgresService — here are the trait bounds and the existing impl for RedisService." |
| Use AI to write unit tests first | Test scaffolding is tedious and AI produces complete test modules faster than I can type them. I review for missed edge cases. | "Write unit tests for this BackupExecutor — cover the success path, a missing S3 source, and a timeout." |
| Paste borrow checker errors directly | For error classes you've seen before, AI explains the fix faster than re-deriving it from scratch. | cannot borrow \self.state` as mutable because it is also borrowed as immutable` with the surrounding code context. |
| Describe schema → ask for entity structs | Translation between a Postgres schema and Sea-ORM entity definitions is mechanical. AI handles it in seconds. | "Here's the service_members table schema — give me the Sea-ORM entities with the correct column types." |
| Use AI for doc comments on public APIs | rustdoc comments on public APIs need to be accurate and concise. AI drafts them well when you give it the function signature and intent. | "Write a doc comment for this function — it resolves an S3 source ID with fallback to the default source." |
| Feed it type signatures, not just intent | Rust's type system is specific. Prompts that include the actual types, trait bounds, and lifetimes get far better output than prose descriptions alone. | Include fn resolve<'a>(&'a self, id: Option<Uuid>) -> Result<S3Source, AppError> in your prompt. |
Boilerplate. Rust has a lot of it. Implementing a trait for a new type means writing the same three methods with the same signature patterns I've written fifty times. I describe what I need and let Claude draft the implementation. I read every line before it goes in, but the drafting is fast.
Tests. Writing unit tests is often more tedious than writing the code being tested. AI drafts test cases quickly. I review them for completeness, add the edge cases it missed (there are always edge cases it missed), and move on.
Documentation. Rust has rustdoc, and public APIs need doc comments. Describing what a function does in a comment is the kind of task where AI is faster than I am and the output is usually as good or better.
Debugging known error classes. If I have a borrow checker error I've seen before, I'll paste it in and let Claude explain what's happening. This is faster than re-deriving the explanation from first principles every time.
Translation between representations. I have a Postgres schema and I want the corresponding Sea-ORM entity structs. That's mechanical translation. AI handles it in seconds. I verify the output and check the types.
Architecture decisions. I've tried asking Claude to help me decide how to structure a new subsystem and the answers are plausible but shallow. They don't account for the specific constraints of the codebase's design — the things I know from having built it over two years that aren't captured in any single context window.
Debugging race conditions. When something is timing-dependent, when a test fails 1 in 20 runs, when a deployment works on the third retry but not the first, AI suggestions are often confident and wrong. These bugs require understanding the system's actual runtime behavior, not its code structure.
Knowing when to say no. AI will implement almost any feature I describe if I frame the request confidently. It rarely pushes back with "this is the wrong approach" or "this will create a problem in three months." That skepticism is something I have to supply myself.
Subtle Rust lifetime issues. Straightforward borrow checker errors are fine. But the ones that involve async lifetimes, shared mutable state across task boundaries, or complex interaction between multiple crates — those require careful human reasoning. AI gets them wrong often enough that I've learned to treat its suggestions as a starting point, not an answer.
The biggest shift is that I've stopped writing first drafts of boilerplate myself. I used to start every new module by typing from scratch. Now I describe what I want and let Claude draft the structure, then I revise from there.
This sounds minor, but it changed my relationship with tedious tasks. The parts of coding I used to procrastinate because they were boring are now the fastest parts. The cognitive overhead of starting a new file went to nearly zero.
What that means in practice: my attention is available for the hard parts. Designing the state machine for a new deployment feature. Thinking through the failure modes. Deciding what to leave out. That's where I spend my time now.
Three patterns I'd pass on to anyone building a Rust project with AI assistance:
Prompt engineering for Rust codebases is still somewhat rough. I've gotten better at providing context — I include relevant type signatures, trait bounds, and architectural constraints in my prompts — but there's still a lot of back-and-forth on anything non-trivial.
I'd like better integration with the actual codebase: asking questions about my specific code rather than generic Rust patterns. That's getting better. But it's not there yet.
AI made me probably 30% faster overall. Not 10x, not 2x. 30%. The gains are concentrated in the boring parts, which means the hard parts — the architecture, the edge cases, the debugging — are still slow. But they're the same speed they would have been without AI. The tedium tax came down.
For a solo developer building something this large, 30% faster is the difference between shipping and not shipping.
If you're curious about the technical decisions that shaped the codebase, see why we chose Rust for a deployment platform. For the practical result of all this work, here's how git-push deployments work under the hood.
