Home
/
Blog
/
AI will reduce developer productivity before it unlocks faster delivery

AI will reduce developer productivity before it unlocks faster delivery

Photo of Ben Lloyd Pearson
|
Blog_Dev_prod_will_decline_2400x1256_928f03efec

During a recent episode of the Dev Interrupted podcast featuring LinearB CEO Ori Keren, one thing became abundantly clear. As engineering leaders map their 2025 roadmaps, AI stands as the defining trend, but not in the way many expect. The maturation of AI will unfold along two distinct tracks, each with its own timeline and implications for how teams operate. Preparing for this shift requires an understanding of how new tools will alter daily workflows, impact developer experience, and ultimately reshape the definition of productivity itself.

AI coding tools will mature before autonomous delivery agents

The first track involves AI-assisted coding tools embedded directly into IDEs. These technologies, think Copilot, Cursor, and similar platforms, are poised to move from early adoption into mainstream maturity. For junior developers especially, proficiency with these tools will create a measurable productivity gap. Those who learn to leverage AI assistance effectively will accelerate their output dramatically, while those who do not risk falling behind.

"I think the senior developers are very interesting because these folks, if they are able to leverage the entire potential that AI has to offer here, they could become small teams."

Senior engineers represent a different opportunity entirely. With the right orchestration, experienced developers could deploy multiple specialized agents across their workflow. One agent might handle basic code reviews, another could monitor pipeline health, and a third might identify and fix flaky tests. This multi-agent approach could transform individual contributors into what effectively functions as a small team, amplifying their scope across review, debugging, and delivery optimization.

The second track, fully agentic workflows that autonomously move from ticket to pull request, remains in an earlier experimentation phase. While the promise is compelling, the practical challenges of embedding these systems into production environments are substantial. The central hurdle is not replacing engineers but determining orchestration. Teams will need time to figure out exactly how to embed these technologies, when to rely on human intervention, and when it is safe to let autonomous agents run their course. As these capabilities mature, governance becomes critical, especially when agentic behavior intersects with compliance requirements, security protocols, and standardized CI/CD pipeline practices. Organizations that establish clear frameworks now will be better positioned to scale these technologies when they stabilize.

Real-time developer signals expose friction teams can fix

Developer experience measurement stands at a crossroads. The traditional survey-heavy approach, often semi-academic in tone and detached from daily work, is proving insufficient for organizations that need to move quickly on experience improvements. The evolution requires a fundamental shift: moving from infrequent, abstract questionnaires toward a hybrid model that combines qualitative and quantitative signals captured in the flow of work.

Context-aware feedback mechanisms that prompt developers immediately after completing a task yield richer, more actionable data than periodic surveys asking them to recall experiences from weeks prior. Capturing insights literally seconds after a task is completed provides incredible visibility into the exact problems a developer is facing. This shift from passive to active measurement creates opportunities to identify friction points with absolute precision.

But measurement alone is not enough. The real innovation in developer experience will come from platforms that not only surface problems but also provide tools to solve them. Build times, test determinism, environment availability, and CI stability materially shape daily experience, and they are measurable. More importantly, they are fixable.

Organizations that treat developer experience measurement as a continuous practice rather than a periodic diagnostic exercise gain the foundation needed to justify investment. When leaders can connect specific friction points like excessive wait times for environments, unstable test suites, and inefficient handoffs to delivery outcomes, the business case for platform improvements becomes clear. Measurement creates the evidence base that transforms developer experience from a nice-to-have into a strategic priority.

AI adoption will lower productivity before teams see gains

The term "developer productivity" carries baggage. Unlike "sales efficiency," which focuses on optimizing a process, developer productivity centers on individuals, and worse, on individual developers rather than teams. This framing invites misinterpretation, suggesting surveillance and stack-ranking when the actual objective is improving the efficiency of the software delivery process.

"I predict that productivity will go down next year. It will decrease."

This prediction, bold and counterintuitive, reflects the reality that every significant technology adoption follows a learning curve. Organizations absorbing new AI tools, navigating resistance, and adapting workflows will experience an initial dip before realizing gains. The path to 10x productivity runs through a valley of experimentation, adjustment, and cultural change.

Current productivity debates reflect deep polarization across multiple dimensions, weighing AI adoption against control, hybrid work against office mandates, and standardization against developer freedom. These contrasts create tension that engineering leaders must navigate without clear playbooks.

The connection between productivity and experience is direct. Poor experience does not just frustrate developers; it actively degrades productivity. Excessive waiting on environments, unstable test suites, and inefficient workflows transform normal workload into sustained overwork, creating the conditions for burnout.

Addressing productivity requires treating it as what it actually is: a team sport shaped by process quality, tooling, and organizational choices. Leaders must define a clear philosophy, decide what matters, measure it consistently, and use those metrics to drive improvement. Productivity cannot remain an abstract aspiration. It requires operational rigor, as it is impossible to optimize a process you are not actively measuring.

The recommendation is straightforward. Choose metrics intentionally based on strategy and philosophy, measure them continuously, and deploy frameworks that enable action, not just observation. Sales leaders would not dream of operating without funnel metrics and conversion data. Engineering leaders need equivalent discipline around their delivery pipeline.

Engineering intelligence turns pipeline visibility into faster delivery

Software engineering intelligence has emerged as one of the core frameworks for understanding developer experience, sitting alongside surveys and internal developer platforms as a foundational capability. At its essence, engineering intelligence makes the development pipeline observable. It surfaces where bottlenecks occur, where instability creeps in, and where inefficient handoffs slow delivery. This visibility creates the context needed to intervene effectively.

"We believe not just in showing you where the problems are, but in giving you tools to actually go and solve these problems."

The distinction between passive observation and active intervention defines the next generation of engineering intelligence platforms. Identifying that build times are excessive or tests are flaky is valuable, but only if teams can then shorten those builds, stabilize those tests, and improve operational flow.

This capability becomes especially critical as organizations deploy AI and automation. Engineering intelligence provides the context layer that helps teams identify where agents or automation can have measurable impact. Without pipeline-level insight, automation decisions rely on intuition, a risky foundation for significant investment.

The goal is to move beyond dashboards that report problems toward integrated platforms that help teams fix root causes. When engineering intelligence connects directly to remediation capabilities, it transforms from a diagnostic tool into a delivery accelerator.

Data-driven engineering leaders tie delivery health to business results

Engineering leadership may be the toughest role in technology organizations. The dual mandate, translating between technical and business contexts, balancing people and process, optimizing for both speed and quality, requires fluency in multiple languages and the judgment to know when to prioritize which concern.

Data-driven leadership provides a framework for navigating this complexity. Just as sales organizations map their funnel with precision, engineering leaders must map their delivery pipeline with equivalent rigor, identifying where handoffs slow down, where work queues up, and where quality issues emerge.

This is not about measuring everything. It is about choosing metrics intentionally, based on a clear philosophy and strategy, then measuring them continuously so optimization becomes possible. One-time diagnostics do not create lasting change; continuous measurement does.

The connection to business objectives is non-negotiable. Engineering leaders who can draw clear lines between technical metrics and business outcomes, showing how delivery health, speed, and quality connect to organizational goals, gain the credibility needed to secure investment in platform improvements and developer experience initiatives.

For leaders new to the role or stepping into new organizations, the advice is consistent: define your philosophy, choose what you will measure based on that philosophy, adopt systems that help you measure continuously, and use those insights to drive improvement. Do not assume you can optimize systems you are not observing.

The human element remains central. Even in an era of increasing automation and AI assistance, engineering leaders work with people who face resistance to change, concern about job security, and the daily friction of imperfect tools. Data provides the foundation for better decisions, but leadership remains fundamentally about people navigating change together.

As organizations enter 2025, the leaders who balance people, process, and product, using data to guide investment without losing sight of human concerns, will be best positioned to navigate the productivity paradox, harness AI effectively, and build the developer experience that attracts and retains exceptional talent.

Listen to Ori's full conversation on the Dev Interrupted podcast for a deeper dive into his predictions for the future of developer productivity and AI orchestration.

blp_headshot_1_ee25d527aa

Ben Lloyd Pearson

Ben hosts Dev Interrupted, a podcast and newsletter for engineering leaders, and is Director of DevEx Strategy at LinearB. Ben has spent the last decade working in platform engineering and developer advocacy to help teams improve workflows, foster internal and external communities, and deliver better developer experiences.

Connect with

Your next read