Dropbox/continuous-integration

3 posts

dropbox

Beyond code generation: rethinking engineering productivity in the age of AI agents (opens in new tab)

AI coding agents have increased Dropbox’s code production, but they have also exposed bottlenecks in review, testing, release coordination, and operations. The central argument is that engineering productivity must be measured by end-to-end product velocity and customer impact—not code or pull-request volume alone. Dropbox is responding with agent platforms, stronger workflow infrastructure, broader quality metrics, and training that helps engineers adapt to new responsibilities. ## From Copilots to Agents - Copilots assist with explanations, snippets, and questions within existing workflows. - Agents can take scoped tasks, inspect repositories, edit files, run tests, fix failures, and return changes for human review. - Engineers remain responsible for intent, architecture, quality, and release decisions. - Increased parallel work and code output create new pressure on: - Code review systems - CI and testing infrastructure - Validation workflows - Release processes - Production operations - More code and pull requests do not necessarily create more customer value. ## Nova as Dropbox’s Agent Platform - Nova runs AI coding agents in controlled environments with relevant codebase context and internal engineering practices. - Its value comes from the surrounding platform—safe execution, workflow integration, guardrails, and human review—not only from the underlying model. - Nova generates approximately one in twelve Dropbox pull requests. - It supports both feature work and maintenance tasks, including: - Migrations - Flaky-test remediation - Bug investigation - Dependency updates - Other high-effort engineering work - The intended workflow is structured: define the task, let the agent work within constraints, validate the result, and require human approval before production. ## Measuring Product Velocity and Impact - Pull-request throughput was useful when implementation speed was the main constraint, but it is insufficient as AI increases output. - Dropbox evaluates whether the broader engineering system can absorb additional work efficiently. - Its four-stage measurement model tracks: - **Fuel:** Whether engineers use AI tools - **Adoption:** How teams change their workflows - **Output:** Whether AI contributes to production work - **Impact:** Whether products reach customers faster and create greater value - Quality and trust metrics include review turnaround time, first-run test pass rate, defect ratio, and rework rate. - Productivity improvements must not come at the expense of reliability or customer trust. ## Evolving Engineering Workflows - Engineers increasingly focus on defining intent, framing problems, reviewing changes, and making architectural and quality decisions. - Adoption requires more than tools; Dropbox uses hands-on learning, hackathons, bootcamps, workflow examples, and peer-led training. - Teams should adopt agents at different speeds based on risk, context, and readiness. - The goal is not to automate every workflow, but to make agentic development safe, useful, measurable, and repeatable. ## Broader Lessons - AI does not remove bottlenecks; it shifts them downstream. - Organizations must invest in validation, orchestration, governance, workflow integration, and measurement alongside code generation. - Competitive advantage will come less from access to common foundation models and more from the systems built around them: internal context, safeguards, quality controls, and integrated engineering workflows. Dropbox’s experience suggests that companies should treat AI agents as a change to the entire software delivery system, not merely as faster coding tools. The strongest results will come from improving the full path from idea to validated production impact.

dropbox

Introducing Nova, our internal platform for coding agents (opens in new tab)

Nova is Dropbox’s internal cloud platform for running coding agents across the software development lifecycle. Rather than building separate tools for coding, CI debugging, migrations, and operational tasks, Dropbox created a shared platform that supports interactive sessions and autonomous workflows within its monorepo and infrastructure. The platform grounds agent changes in real builds and tests, making AI assistance more reliable and easier to integrate into engineering workflows. ## The Case for a Shared Platform - Engineering work includes repetitive but important tasks such as: - Debugging CI failures - Updating dependencies - Improving test coverage - Fixing flaky tests - Managing migrations and operational work - Different tasks require different interaction models: - Interactive chat for developer-driven work - Asynchronous workflows for long-running remediation and automation - Dropbox’s environment has specialized requirements: - A large monorepo - Bazel for builds and tests - Caching and remote execution - On-premises infrastructure - Dropbox-specific validation workflows - Off-the-shelf coding agents were designed primarily for local development and did not naturally fit this environment. ## How Nova Runs Coding Sessions - Each session runs in an isolated environment using a specific snapshot of the codebase. - Callers provide: - The repository commit - A task description - Optional validation commands - Iteration limits and branch settings - Nova can run builds and tests after an agent proposes a change. - If validation fails, the results are sent back to the agent so it can continue troubleshooting. - This creates a feedback loop of: - Propose a change - Validate it in the real environment - Correct failures - Repeat as needed - Nova supports multiple coding agents behind a common interface. - Engineers can access it through: - A web interface - A command-line client - An API - Internal scripts and services - The platform also provides prompt evaluation, observability, feedback collection, skills, plugins, and MCP integrations for accessing systems such as logs and monitoring tools. ## Deterministic Code Publication - Nova keeps code publication outside the agent. - Each session is limited to a single branch. - This makes active work and publication status predictable. - It avoids the complexity of agents creating and managing multiple branches. - The deterministic model simplifies automation such as: - Running tests - Rebasing onto the main branch - Tracking which changes belong to each session ## Engineering Workflows Using Nova ### Developer-Driven Sessions - Engineers use Nova’s web interface for quick fixes and prototypes without disrupting local work. - Validation commands can use Bazel selectivity tools to target the relevant compile and test dependencies. - Slack discussions can be carried into Nova sessions, preserving context and reducing manual setup. ### Flaky Test Remediation - Dropbox built Deflaker, a durable workflow connected to Athena, its flaky-test detection system. - Deflaker gathers examples of a test passing and failing. - It sends the associated logs to Nova. - The agent analyzes the evidence, identifies a likely cause, and proposes a fix. - This demonstrates how Nova can combine investigation, context gathering, and code changes in a longer-running automated process. ## Practical Takeaway Dropbox’s experience suggests that coding agents are most useful when embedded in existing engineering systems rather than treated as isolated code-generation tools. A shared platform like Nova can support many workflows while preserving consistent execution, validation, context, and observability.

dropbox

Reducing our monorepo size to improve developer velocity (opens in new tab)

Dropbox’s server monorepo grew to 87GB, making full clones take over an hour and threatening GitHub’s 100GB limit. The root cause was inefficient Git delta compression of internationalization files, not unusually large source files. By changing how the repository was repacked, Dropbox reduced it to about 20GB and cut clone times to under 15 minutes. ## Repository Size and Developer Velocity - The monorepo contains backend services and libraries used across Dropbox. - AI feature development often requires coordinated changes across ranking, retrieval, evaluation, and UI systems. - A full clone exceeded one hour at 87GB, slowing onboarding and affecting CI jobs that start from fresh clones. - Internal synchronization systems also processed more data, increasing timeout and reliability risks. - The repository grew by roughly 20–60MB per day, with occasional increases above 150MB. - At that rate, Dropbox expected to hit GitHub Enterprise Cloud’s 100GB hard limit within months. ## How Git Compression Caused the Growth - Git normally reduces storage by representing similar file versions as deltas rather than complete copies. - Its default file-matching heuristic considers only the final 16 characters of a path. - Dropbox’s i18n files used paths such as: - `i18n/metaserver/[language]/LC_MESSAGES/[filename].po` - Because the language component appears early in the path, Git often compared files from different languages instead of related versions of the same language. - Translation updates consequently produced oversized deltas and disproportionately large pack files. ## Testing `--path-walk` - Dropbox tested Git’s experimental `--path-walk` option during a local repack. - The option considers the full directory structure when selecting delta candidates. - A local repack reduced the repository from the low-80GB range to the low-20GB range, confirming that packing—not data volume—was the main issue. - GitHub could not use this approach because it conflicted with server-side optimizations such as bitmaps and delta islands. ## Why Server-Side Repacking Was Necessary - Local optimization cannot permanently change the packs GitHub generates for clones and fetches. - GitHub dynamically constructs transfer packs based on what each client needs. - Dropbox’s mirror experiment showed that an aggressive repack could reduce the repository from 84GB to 20GB: - `git repack -adf --depth=250 --window=250` - The repack took approximately nine hours. - Dropbox worked with GitHub Support to apply a compatible server-side solution. - Larger `window` and `depth` values make Git search more thoroughly for compression opportunities, trading increased repack time for smaller storage and transfer sizes. ## Results - Repository size fell from 87GB to approximately 20GB—a 77% reduction. - Clone time dropped from more than an hour to under 15 minutes. - The work reduced pressure on GitHub’s repository size limit and improved the performance of developer and CI workflows. Dropbox’s experience shows that monorepo growth can result from repository layout interacting poorly with Git’s compression heuristics. When large repositories exhibit abnormal growth, teams should inspect pack-file behavior and consider server-side repacking rather than focusing only on removing large files.