Rovo Dev CLI
From a two-person experiment to an organization-wide coding-agent product.
Recognizing the CLI as the Missing Interface for Coding Agents
When we started Rovo Dev CLI, Cursor was already becoming very popular. But we noticed a limitation in the IDE-centric workflow: much of real software development still happened outside the editor.
Engineers ran tests, invoked build systems, inspected repositories, used local development tools, and interacted with infrastructure primarily through the command line. An IDE assistant was naturally centered on reading and modifying code. But as natural language began to emerge as a higher-level interface for specifying intent, the code editor was no longer necessarily the center of the development workflow. The agent needed to connect to the tools and actions required to build, test, and operate software.
Our thesis was that integrating the coding agent directly into the CLI would unlock substantially more of its potential. The command line was composable, scriptable, close to the repository, and naturally connected to the tools engineers already used.
We believed the CLI was a neglected battleground for coding agents—before Claude Code made that direction obvious.
Building the Product Through the Community
Rovo Dev CLI began as a two-person project. From the outset, we believed that engineers should not only use the product but actively shape it.
Our initial proposal to release it as an external open-source project faced resistance from an SVP. Instead, we created an internal open-source community inside Atlassian.
The response was immediate. Within the first month, the community grew to roughly 300 engineers. I personally recruited more than ten community-channel maintainers and cultivated an “everyone helps everyone” culture in which users answered questions, diagnosed failures, proposed features, and contributed improvements.
I also recruited the first feature contributor from outside the core organization, demonstrating that the project could grow beyond the team that created it. Many important capabilities were proposed or shaped directly by the community.
This development model became part of the product strategy. Rather than deciding the roadmap entirely through a centralized process, we used real engineering workflows to reveal what the agent needed to become useful.
From Bottom-Up Adoption to Product Strategy
Within six months, Rovo Dev CLI reached approximately 3,000 Atlassian employees, including more than half of the company’s engineers. Its internal adoption was on par with Cursor.
The composition of the user base was particularly revealing. Product managers, engineering managers, and designers were represented at disproportionately high rates. This suggested that the CLI was becoming more than a coding assistant: it was emerging as a general interface for understanding software systems, organizational knowledge, and technical work.
Technically, we focused on differentiating Rovo Dev through deep integration with the Atlassian ecosystem, particularly Jira and Confluence. The agent could combine repository context with the plans, requirements, decisions, and operational knowledge surrounding the code.
The project also reached the top position on SWE-bench Full, providing external evidence that the underlying technical system was competitive with leading coding agents.
As adoption and technical results accumulated, the organizational conversation changed. The question was no longer whether a command-line coding agent was worth pursuing, but how Atlassian should bring it to customers.
The project ultimately received SVP approval and became an external-facing product.
My Role
I co-founded Rovo Dev CLI as a two-person project and helped define its CLI-first product and technical thesis. I built key parts of the initial system, created and cultivated the internal open-source community, and used adoption and technical results to help build support for external productization.
What This Work Demonstrated
Rovo Dev CLI reinforced three principles that continue to shape how I lead technical work.
First, important product categories often emerge at interfaces that incumbents overlook. The CLI appeared less visible than the IDE, but it was more deeply connected to the complete development workflow.
Second, early communities can do more than accelerate adoption. They can become part of the product-development system, revealing use cases and shaping capabilities that a small central team would not discover alone.
Finally, organizational conviction is often built through evidence rather than argument. A working product, sustained adoption, community contribution, and measurable technical performance turned an initially resisted direction into a company-backed external product.