Artificial intelligence investment has jumped 28 times for most companies, especially those with more than 99 engineers, yet speed metrics remain stagnant and have even declined, according to the State of AI Impact in Engineering report from DX. The study measures engineering organizations across speed, effectiveness, quality, and impact. AI tools are accelerating individual work, but the systems around them are dragging everything back down, the report finds. This disconnect grows worse with company size and pull request size.

The innovation ratio—how much engineering effort goes toward new features versus maintenance, toil, and operational overhead—remains flat even as AI spending soars, meaning AI isn't freeing up engineers' time for interesting business problems. The Developer Experience Index (DXI) benchmark dropped two points industrywide last quarter, marking the first decline DX has ever recorded. Code maintainability and change confidence, two drivers that usually move together, have split apart: engineers report they can understand and modify code more easily, but their confidence in releasing that code to production has turned negative. Pull request size has ballooned from a median of 42 lines of code in July 2024 to 72 lines a year later. Smaller organizations spend more on AI and see better results, while legacy software companies struggle to capture any return on investment. Separate research from LinearB ranks 253 organizations by AI usage and finds that "elite" groups in the top 10 percent maintain average pull requests under 100 lines of code, while those labeled "Needs focus" at the bottom exceed 228 lines.

Justin Reock, deputy CTO of DX, tells The New Stack that the tension between code maintainability and change confidence worries him. "AI is making it easier to understand what's in front of you, and even to make changes to it. But change confidence is now in the negatives," he says. "We can understand the code, maintain the code, look at the code, and make changes to it more easily. But we trust less what we're releasing." The report notes that for every point of improvement in DXI, an organization returns ten hours per year to each engineer. According to research from LeadDev's AI Impact Report 2026, set to publish later this August, only 31 percent of teams measure AI's impact at all. Among organizations that have adopted AI-powered developer tools, 70 percent now describe their adoption as "widely or completely," yet only 26 percent report that AI has boosted engineering productivity by more than 25 percent—and most of those respondents are going on instinct rather than confirmed data.

Medium-to-large organizations are trying to retrofit AI into existing systems built when writing code was expensive, but code-writing is now essentially free while old structures remain costly, the report explains. This is the renovation problem: processes and hierarchies designed for a different era no longer fit the purpose. Small organizations don't pay the coordination and communication taxes that grow with headcount—a team of 10 has 45 channels of overhead, meaning three people effectively exist just for alignment, while one or two people eliminate that cost entirely. Martin Davidson, CTO of micro-consultancy a2bic.ai, tells The New Stack that he and his co-founder, with combined experience of about 80 years, can manage teams of AI agents to do the work of 100 junior to mid-level engineers. Many teams are ignoring universally accepted success patterns at AI speed, including how smaller batch sizes lead to more stable releases, the report finds. Incremental delivery—engineers reporting they work on small, incremental changes—took the biggest hit of all DXI indicators measured last quarter, carrying consequences for revert ease, review time, documentation clarity, and unit test quality. The report warns that the productivity optimism and the measurement gap are separate problems: most people reporting gains can't prove them, and even those measuring results are seeing worrying trends. Companies that succeed may not be the ones that transform successfully, but rather those that start fresh without legacy constraints.