How AI is redefining developer velocity: A guide for engineering leaders

Organizations want to maximize developer velocity for obvious reasons, but developer velocity is more than simply shipping software as fast as possible. After all, what good is shipping software quickly if you’re shipping the wrong thing, introducing defects or creating technical debt that slows things down later on? Teams that deploy 100 times a day aren’t necessarily more productive than those who deploy 10 times daily.

Developer velocity can’t be fully expressed by customer satisfaction in the final product or the number of Jira tickets closed each day, either. It has to include all of these things and more to be a useful measure.

Organizations also factor in things like code quality—is code readable, maintainable, efficient and reliable? Developer velocity also involves the question of flow—how smoothly does work progress without blockers and unnecessary organizational or technological bottlenecks interrupting developers’ concentration?

However an organization chooses to measure developer velocity, its measurements must take into account how the resulting software impacts business performance, and ultimately business value. In other words, velocity must be pointed in the right direction.

Developer productivity typically focuses on how effectively individual developers or teams perform their work. Developer velocity is a broader concept that encompasses the systems, processes and organizational conditions that allow developers to turn their work into valuable software. Productivity can be considered a major component of velocity.

Different DevOps frameworks use different tools for improving developer velocity, and emphasize different elements. Agile and Scrum methodologies support team performance through rapid iteration; speed and smooth handoffs are paramount.

Generally speaking, improving developer velocity involves looking at the entire end-to-end software development lifecycle (SDLC), beginning with the experience of developers themselves.

Developer experience (DevEx) is a catch-all term for how an organization’s systems, workflows, developer tools, culture and work environment affect developer productivity. It involves minimizing tasks that don’t add value, automating workflows, centralizing resources, streamlining integration, and implementing tight feedback loops that give developers opportunities to catch errors early and often.

Reducing cognitive load—the amount of mental effort developers need to finish a given task—and encouraging flow states of uninterrupted focus are core dimensions of DevEx. One way to achieve these goals is to implement self-service infrastructure-as-code and internal development platforms. These development environments make it easier for developers to build, deploy and operate software without needing to manage all the underlying infrastructure themselves.

Improvements to collaborative processes can have a big impact on developer velocity. Developers rarely spend all their time writing code. They wait for builds, look for documentation, configure environments, request permissions, investigate unfamiliar code, wait for reviews, troubleshoot deployments, attend meetings and switch between tools. These phases are often marked by downtime, and while individual delays may seem trivial, they can become enormous organizational costs when multiplied across hundreds or thousands of developers. This friction is one of the primary enemies of developer velocity. And even so-called “10x” engineers are only as efficient as the systems built around them.

Efficient code reviews, clear communication protocols, shared ownership of code documentation, breaking large epics into smaller manageable pull requests (PRs)—such efforts pay dividends in long-term improvements to developer velocity.

Minimizing time spent on repetitive tasks, especially ones developers tend to find tedious, can be accomplished through several means. Smart CI/CD pipelines automatically build, test and merge code changes to catch bugs early. Automated testing helps ensure code quality while eliminating the manual overhead previously required to achieve it.

AI coding assistants such as IBM Bob are probably the single biggest developer velocity improvement that an organization can make. These tools can handle much of the SDLC, from generating boilerplate code to automating testing. For example, one organization reported around 90% faster delivery using Bob, preserving over 160 engineering hours for higher‑value work during an uplift to Java 25.

AI coding assistants do much more than just generate code. Coding tools with agentic capabilities can autonomously perform many development tasks, such as:

• explaining unfamiliar code

• creating tests

• debugging

• refactoring

• documenting software

• migrating legacy applications

• reviewing pull requests

• translating requirements into implementation

• orchestrating development tools

The AI-SDLC is an augmentation of the SDLC: a software development methodology completely built around AI, treating a large language model (LLM) or group of models as an active collaborator throughout every step of software development. AI is not just part of the SDLC but central to it, with continuous collaboration between AI and humans. This methodology has boundless potential for improving developer velocity because agentic workloads can scale to a degree that human productivity cannot.

Well-structured, maintainable code is easier to work with, but developers often must work within systems that are difficult to understand and update. Legacy systems are commonly rife with spaghetti code and technical debt, making them difficult to extend.

Updating legacy code is often a major undertaking, but it can be a powerful way to improve developer velocity. When developers don’t have to sift through dependencies, understand undocumented behaviors or fix things that unexpectedly break, new code can be written more quickly. Here too, AI-powered coding tools can provide massive efficiencies.

Developer velocity is difficult to measure because software development is abstract knowledge work. One can’t simply count the output. More commits don’t necessarily mean better software. More lines of code don’t necessarily translate to better engineering. Faster pull requests aren’t better if they increase defects.

Still, it can be helpful to consider a multidimensional approach. Since 2015, the DevOps Research and Assessment program has sought to understand the capabilities that drive software delivery and operations performance. DORA deliberately focuses on outcomes rather than individual productivity. The organization has defined four DORA Metrics that measure software delivery performance:

• Deployment frequency: how often code reaches production

• Lead time for changes: time from code commit to production

• Change failure rate: percentage of deployments that cause incidents or require fixes

• Mean time to recovery (MTTR): how quickly the team restores service after an issue

Other common metrics include:

• Story points completed: the estimated relative effort, complexity and uncertainty involved in completing a piece of work

• Pull request cycle time: the time from opening a pull request to merging it into the codebase

• Build and test duration: how long it takes for code to compile and build, and for automated tests to complete

• Code review turnaround time: the time a developer waits for their code review to be completed

• Time spent waiting vs. actively coding: the proportion of a developer’s time spent on productive development versus waiting for other dependent software development processes

• Developer satisfaction: how satisfied developers are with their overall development experience, typically measured through surveys

Different DevOps frameworks use different tools for measuring developer velocity.

A developer velocity index (DVI) is a composite score designed to communicate the level of developer velocity that organizations have achieved. Unlike DORA, this isn’t a universally standardized metric. The term is associated with research and benchmarking frameworks from McKinsey & Company. It looks at tools, culture, talent management and additional factors already discussed to determine how effectively organizations enable developers to produce valuable software.