How Rovo Dev CLI became my BFF

[#1]

For the past few months, I've been using Rovo Dev CLI as my primary development tool. What started as curiosity about yet another AI coding assistant became a complete transformation in how I approach development work.

This blog post isn't here to give you a collection of prompts to copy and paste. Instead, I want to help you develop an effective mental model for working with Rovo Dev CLI; teaching you how to think about the tool, approach problems systematically, and build the kind of collaborative workflow that actually delivers results.

From Assistant to Orchestrator

The mental shift took time. Initially, I treated Rovo Dev like a one-shot request instead of a conversation: describe what I wanted, hit enter, hope for the best. The results were inconsistent at best. This approach worked fine for quick scripts or simple prototypes, but completely fell apart when working in large, established codebases with existing patterns, team conventions, and complex interdependencies.

The breakthrough came when I started approaching it like any complex engineering problem - systematic decomposition and validation. You wouldn't tackle "build a user authentication system" as one monolithic task. You'd break it down into manageable chunks, define the requirements clearly, validate the technical approach upfront, identify dependencies, and establish clear checkpoints throughout.

Furthermore, you need to effectively transfer the context you know about the problem and its complex interdependencies to Rovo Dev. The tool isn't going to figure out your codebase's quirks, legacy constraints, or team conventions for you. Context is key here.

Now every session starts with strategy, not code.

What Actually Works

My daily Rovo Dev usage has crystallized into several reliable patterns:

Test-Driven Everything: My standard instruction is now: "After every code change, run the test suite to ensure existing tests pass. For every piece of code you write, write relevant tests using our existing testing conventions." This single change transformed my experience from frustrating to productive.

Incremental Development Cycles: In larger projects with extensive test suites, I've learned to enforce incremental cycles: write small amounts of code → write tests for that code → ensure everything passes → repeat. Rovo Dev tends to struggle when it writes large chunks of code first then attempts testing, especially in projects with extensive test suites where failed test output can overwhelm the context window and cause confusion.

Git Worktree Parallelization: I run multiple sessions across different git worktrees in the same repository. One session handles bug fixes while another builds features. It's like having multiple developers working in parallel - I just check in periodically to course-correct.

Commit Organization: After features are working, I ask Rovo Dev to chunk changes into logical commits with proper messages. It's surprisingly good at this and saves significant cleanup time.

Strategy Sessions: Instead of jumping into code, I explain the problem and ask for a plan. We iterate on that plan together. We work on defining the problem statement and exploring various solutions before converging on one that makes sense.

Key Lessons Learned

Ctrl+C ASAP: If you see the agent heading down the wrong path, kill the session immediately. Don't try to course-correct, don't let it dig deeper. Just restart. I used to think I was "wasting" work, but letting it continue bad paths wastes exponentially more time.

Fresh Sessions Beat Long Ones: Extended conversations become unpredictable as context windows get pruned. The agent becomes less reliable over time. I now embrace starting fresh, using session journals to maintain continuity without accumulated confusion.

Clear Communication: Selecting and copying from terminal output can be frustrating. I learned to tell the agent upfront: "write this output to a file I can access easily." This saves enormous headache.

Journaling Everything: I ask the agent to maintain a work journal - what it accomplished, what needs doing next. When sessions go sideways (and they do), I have clear records. More importantly, new sessions can read the journal and continue seamlessly.

Platform Performance Varies: Rovo Dev performs noticeably better on some technology stacks compared to others. The pattern is consistent, likely due to training data differences.

Tight Development Loop Flow

Here's my current process for any significant development task:

1. Problem Definition: Explain what I'm solving and why

2. Strategy Session: Ask for multiple solution approaches, discuss tradeoffs

3. Test-First Development: Establish the write code → run tests → fix issues → repeat cycle

4. Checkpoint Maintenance: Document what's been accomplished and what remains

5. Course Correction: Kill and restart at first sign of wrong direction, starting from the last checkpoint

This approach works especially well in repositories with solid existing test coverage. By ensuring Rovo Dev doesn't break existing tests while writing new code, then immediately testing new functionality, you create a tight feedback loop that catches issues early.

Conclusion

Rovo Dev CLI has genuinely changed how I approach development work. The key insight wasn't learning better prompts; it was realizing this isn't a one-shot code generator, it's a development partner that needs clear context and systematic thinking.

The productivity gains are real when you stop expecting magic and start providing structure. The tool works best when you treat it as a collaborative partner rather than a simple code completion engine.

Start with strategy, maintain tight feedback loops, and don't hesitate to restart when things go off track. With the right mental model, Rovo Dev CLI becomes an incredibly powerful addition to your development workflow.

[Ash McConnell]

This is pretty similar to my experience - I love Rovo!  Can you talk about Journaling a bit more?  Do you just ask it to maintain a markdown file?  

Are there ways to include system prompts for getting it to run the tests after each new bit of code?  Is that what agent.md is for

Thanks for the post!