developer-productivity

4 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.

microsoft

Enhancing Code Quality at Scale with AI-Powered Code Reviews (opens in new tab)

Microsoft developed an AI-powered pull request reviewer to reduce routine review work, catch defects earlier, and help developers merge code faster. What began as an internal experiment now supports more than 90% of Microsoft’s PRs—over 600,000 per month—and has influenced GitHub’s Copilot for Pull Request Reviews. The central lesson is that AI works best as a human-in-the-loop assistant embedded directly into existing workflows. ## Addressing PR Review Bottlenecks - Human reviewers often spend time on style issues and minor bugs while overlooking architectural or security concerns. - Large, multi-file PRs can lack sufficient context and may wait days or weeks for review. - The AI reviewer automatically joins new PRs and handles repetitive or easily missed checks, allowing humans to focus on higher-level decisions. ## AI-Powered Review Features - **Automated comments:** Flags issues such as missing null checks, error-handling problems, sensitive-data risks, inefficient algorithms, and style inconsistencies. - **Suggested fixes:** Provides corrected snippets or alternative implementations, but authors must explicitly review and apply changes. AI does not commit changes automatically. - **PR summaries:** Generates descriptions of the change and highlights key modifications across the diff. - **Interactive Q&A:** Reviewers can ask questions about parameters, code behavior, or the impact on other modules directly in the PR discussion. - **Workflow integration:** The assistant behaves like a normal reviewer, requiring no separate tools or interfaces and optionally engaging as soon as a PR is opened. ## Effects on Quality and Development Speed - AI-assisted reviews reduced median PR completion times by 10–20% in early studies across 5,000 repositories. - Early feedback reduces waiting time, back-and-forth cycles, and the chance that minor issues delay approval. - The system has identified bugs such as missing null checks and incorrectly ordered API calls before they reached production. - Developers, particularly new hires, can use the explanations as continuous guidance on coding standards and best practices. ## Team-Specific Customization - Teams can configure repository-specific review guidelines. - Custom prompts support specialized checks, including regression detection based on historical crash patterns and validation of deployment or change gates. - This extensibility allows the reviewer to address concerns beyond generic code quality rules. ## Feedback Between Internal and External Products - Microsoft’s internal deployment provided early feedback on review quality, usability, and developer trust. - Internal experiments helped shape features such as inline suggestions and human-controlled change application. - These lessons contributed to GitHub Copilot for Pull Request Reviews, which reached general availability in April 2025. - Microsoft also uses learnings from GitHub’s broader external adoption to improve its internal development practices, creating an ongoing feedback loop between first-party and third-party products. Overall, the post recommends treating AI review as an always-available first pass—not a replacement for human judgment. Its greatest value comes from seamless integration, strong customization, and keeping authors and reviewers accountable for final decisions.

figma

The VS Code Method: Tightening a developer’s inner loop | Figma Blog (opens in new tab)

The post argues that developers are most productive when they can sustain the “inner loop”: writing, compiling, debugging, and iterating without disruptive context switching. VS Code’s approach is to bring more outer-loop activities—collaboration, project management, design inspection, and AI assistance—into the editor. The result is not only faster development, but better code quality, greater energy, and improved developer satisfaction. ## The Inner Loop and Flow - The inner loop is the repeated cycle of writing code, compiling, debugging, and continuing in the code editor. - The outer loop includes activities outside the editor, such as: - Checking bug trackers - Updating tickets - Responding in Slack or Teams - Reviewing documentation - Switching between projects and terminals - Staying in the inner loop builds “inertia,” increasing speed and productivity over time. - Interruptions also cause developers to lose mentally loaded context, including edge cases and future plans for the code. ## Reducing Distractions in VS Code - VS Code uses features and extensions to help developers remain focused inside the editor. - Zen Mode hides interface elements and creates a distraction-free workspace. - Even small UI changes, such as collapsing a sidebar, can interrupt concentration as the brain recalibrates. - Developers can customize VS Code with extensions that match their preferred workflows. ## Bringing Outer-Loop Work into the Editor - The broader goal is to move as many tasks as possible into the developer’s existing workflow. - Integrations can reduce switching between: - VS Code and GitHub - Code and project-management tools - Development tools and design platforms - The Figma for VS Code extension lets developers access and inspect designs without leaving the editor. - AI tools such as GitHub Copilot provide proactive, non-intrusive code suggestions. - GitHub reports that Copilot increases coding speed by 55%, while 75% of AI-using developers report greater fulfillment. ## Collaboration Without Breaking Focus - Collaboration is essential but often disruptive when it requires meetings or prolonged chat exchanges. - VS Code integrates GitHub features so developers can manage issues, review code, and submit pull requests from the editor. - The ideal collaboration model lets multiple people remain in their own inner loops rather than requiring constant synchronous interaction. - Direct comments and embedded collaboration can preserve focus while keeping teams connected. ## A More Connected Developer Workflow The VS Code team envisions an inner loop that eventually includes all the tools developers need. Until then, teams should prioritize integrations that eliminate unnecessary switching and tedious manual work. Keeping developers in flow improves productivity, code quality, energy, and overall happiness.

figma

The Atlassian Method: The Power of Developer Joy | Figma Blog (opens in new tab)

Atlassian treats “developer joy” as more than a smoother developer experience: it is a company-wide philosophy centered on reducing friction and protecting the craft of development. After poor productivity and satisfaction in 2022, Atlassian standardized tools, improved processes, and empowered engineering teams to address frustrations directly. The effort produced major gains, including higher satisfaction, faster pull-request cycles, more frequent deployments, and improved roadmap delivery. ## Developer Joy as a Company Priority - Developer experience typically covers workflows, tools, and processes; developer joy focuses more deeply on the values, standards, and craft of development. - Atlassian found that developers lose more than eight hours per week—about 20% of their time—to inefficiencies. - Common sources of friction include: - Searching for information and solutions - Poor tooling and redundant systems - Cross-functional coordination with design and other teams - Planning and process overhead - In 2022, Atlassian frequently missed public roadmap commitments, while developer satisfaction fell below 50%. ## Operationalizing Joy - Atlassian created a cross-functional “champions” program to identify and eliminate organizational frustrations. - The initiative focused on: - **Systems:** Auditing tools and processes, standardizing where possible, and removing redundant tools—the company’s “Noah’s Ark of tooling.” - **Culture:** Establishing coding standards, shared values, and metrics that emphasized quality and craft, not just efficiency. - Every engineering team allocated 10% of its time to developer productivity improvements. - This gave developers an “ownership stake” in solving the problems affecting their work. - Developer joy became a company-wide OKR reported by teams every month. ## Measuring the Business Value - Atlassian accepted short-term tradeoffs, prioritizing engagement and productivity improvements over immediate revenue optimization. - The company measured both quantitative and qualitative outcomes. - Within a few months, it achieved: - A 50% increase in developer satisfaction - A 50% reduction in median pull-request cycle time - A threefold increase in deployment frequency - Delivery of all customer roadmap commitments instead of repeated delays - An increase in internal CSAT from below 50% to 80% - The results reinforced the idea that investments in tools, processes, and clear measurement compound over time. ## Toward Team Joy - The success of developer joy helped Atlassian build broader support for applying the same principles beyond individual developers. - The initiative began moving toward the larger concept of “team joy,” extending the focus to collaboration and the shared experience of delivering work. Organizations seeking similar results should treat developer productivity as an ongoing company responsibility: give teams dedicated time to improve their systems, reduce unnecessary complexity, and measure satisfaction alongside delivery performance.