What Is Nova

Nova is Dropbox's internal platform for running AI coding agents. It acts as both a coding agent—like a Claude Code or Codex—and as a platform that other internal services call out to for their coding jobs.

With Nova, what we wanted was a platform where people could use agents in a way that didn't necessarily disrupt their local development flow. We've got a large monorepo, over twenty gigabytes. That takes a while to set up a new environment. One of the earliest wins has been helping people who are making simpler type changes very quickly spin up a development environment — it's kind of a hybrid of production and CI environment — and be able to talk back and forth with an agent and create a pull request after that.

Each Nova session runs in an isolated environment containing a codebase snapshot from a specific commit, with validation commands executed against Dropbox's real build and test systems. The platform follows a consistent loop: propose changes, validate, iterate if needed.

Why Build It In-House

There was a lot of fragmentation among the AI tools developers were using locally. That diversification is great—we keep getting the best of what all the different labs are putting out, and we love that competition. But that also means it's a little harder to get things set up. Integrations, MCP servers, and getting that local environment perfect across all the different platforms is tricky.

Nova provides a place where everything is automatically set up. And with developers wanting to work more in parallel—three, four, five things at a time—having that extra environment away from the local one helps.

But the deeper reason is integration. Off-the-shelf tools can't plug into internal Dropbox infrastructure the way Nova can.

The security angle is especially important given Dropbox's brand. The team has been exploring how Nova can handle their most sensitive tier of data—a conversation that would look very different with an external tool.

Platform, Not Point Solution

What makes Nova a platform rather than a point solution is that other teams can build on top of it. It's the canonical and fastest way to spin up a development environment in Dropbox's cloud and have agents ready to do whatever. More than 20 internal use cases have been built on top of Nova so far.

Nova connects with Dropbox-specific infrastructure, including their Bazel build system, CI/CD pipelines, and on-premise validation systems. It supports interactive sessions through a web interface, a command-line interface, and an API for launching parallel jobs. It also integrates skills, plugins, and MCP-based context sources.

Starting with Toil

The team deliberately chose to start with work that reduces toil, areas where they had confidence that what the AI would produce was something developers would accept with high quality.

A prime example is flaky test remediation. Dropbox has a platform called Flakes that detects when you've introduced a flaky test, creates a Jira ticket, and assigns it to a team. Plenty of times this ends up on the plate of a very busy on-call engineer, or very busy teams who don't have time to prioritize it.

Other use cases include migrations and dependency upgrades (replacing a previous AI migrator with Nova's capabilities), production incident response where agents recreate crash states with tests and generate candidate fixes, and emerging experiments like automated PR review and scheduled workflows to reduce on-call burden.

Owning the Harness

The team runs both AWS Bedrock access and open-source models hosted on their own GPUs, giving them flexibility to swap models as costs and capabilities shift.

Kevin: I think a harness is a pretty low-level piece of software, all things considered. It's probably the kind of thing that will be very standardized as we move forward. There are features and ways to manage context that are not going to vary between harnesses. 

Still, owning the harness today gives Dropbox control over cost, model selection, and the total experience.

Lessons Learned

Kevin previously worked on a different project that eventually merged with Nova, one that launched agentic jobs to fix locations in the codebase based on a description, with no interactivity.

Kevin: The key thing I realized, after doing user research — and this was about two years ago, right at the birth of agentic engineering— was that because agentic stuff makes coding so much faster and easier, everything is moving up a tier of thinking.

Rather than launching tiny jobs across many little locations, like I thought would have been useful, people actually want to manage this themselves. The tools are so powerful that they want to work with it and manage all the code changes in one session.

What's Next

Chris: One thing is just having reliability built in. We're at the stage now where we need to build out SLOs and get more serious about alerting so that the user experience is good. The other thing is how to build better planning and integrations so you can take a feature across the full lifecycle of development — from design and research all the way to rolling the change out, following a feature flag out to production.

Kevin: It's enabling the agent to do things over long periods of time and giving it the ability to manage its logic across long periods combined with the ability to take action on things like deployment, PRs, watching metrics, looking at logs.

You want to tell the agent: go migrate this endpoint from this version of the API to that one. Make a PR, I want to comment on the PR, I want the agent to address my comments, I want to merge the PR, and I want the agent to be smart enough to know that it needs to wait for the deployment, watch the logs, watch the metrics, ensure that it's all good. And during all of this, it raises concerns to me, messages me and says, hey, this is wrong, that's wrong.

Chris: One thing I'm passionate about is evals as a way to help validate repeatable workflows. We're looking at making it easier for folks outside our team to build their own evals and perhaps eval a skill they're adding or a common workflow, so we can learn and experiment with data we've already got in our repo and history to produce the best outcomes.