“We bought the AI licenses, where is the ROI?” – it’s a discussion happening at seemingly every company we talk with, and it’s a question we happen to care deeply about. Opsera recently hosted a roundtable with GitHub and LTM (formerly LTIMindtree) discussing the real-world business impact of AI adoption at LTM as well as some key lessons learned from the successful transformations they have led at their enterprise customers.
We all agree that buying the tool is the easy part. Translating that into measurable business outcomes is the hard part: ensuring adoption, understanding impact, and measuring value. This post explores four important findings about bridging the gap between deploying GitHub Copilot and achieving enterprise-scale results.
1. Adoption is the Start, Not the Finish Line
At LTM, the journey began with 2,000 GitHub Copilot licenses and rapidly scaled to over 22,000 users. However, developer use of those licenses as reflected in adoption metrics is just the starting point to realizing the benefits and value of AI. AI adoption increases the volume of code, and it is important to ensure that increased volume doesn’t create problems downstream.
While it is important to track adoption and usage, LTM finds it equally important to correlate usage with cycle time reduction and PR velocity. If 100% of your developers are using AI but your time-to-market hasn’t changed, you haven’t achieved business value; you’ve just increased your software bill.
2. Use the Right Metrics: From DORA to ESS
For years, DORA metrics (Deployment Frequency, Lead Time, etc.) have been the industry standard for engineering productivity. While DORA is fantastic for CI/CD pipelines, it focuses on objective, trailing indicators while missing “the human element”—the developer behind the screen. Other metrics have risen to fill this gap, notably SPACE metrics (Satisfaction, Performance, Activity, Communication, and Efficiency) and, more recently, GitHub’s Engineering System Success (ESS) Playbook.
Leveraging multiple metrics provides a more complete view of the health of the engineering effort. The ESS framework combines the hard data of the “outer loop” (shipping product) with the developer experience of the “inner loop” (building product). Leaders need a dashboard that blends these worlds to ensure that increased speed doesn’t come at the cost of developer burnout or code quality.
3. Treat Your Pull Request as a Product
With AI generating code faster than ever, the volume of code is transforming the entire delivery process. We don’t just create products and dump them into the market; we manage production and operations by tracking capacity, inventory, supply chains and support costs. If AI helps a junior developer write code 50% faster, but it takes a senior developer three days to review the PR, we know that AI has accelerated PR creation but we can also see that overall delivery hasn’t changed.
The Pull Request (PR) has become the “single unit of engineering,” and we need to treat it like we would a product to understand how PRs affect broader engineering systems. Metrics like Review Time, Check Failure Rate, and Description Quality are now just as important as writing speed.
4. Move from Static Dashboards to “What-If” Reasoning
Dashboards and reports effectively communicate metrics, but they reflect past performance and they often require a nuanced understanding of the context within which the metrics were collected. Worse, leaders are swimming in dashboards and they still need to connect the dots between the various sources of truth in order to understand the big picture.
The role of AI in the modern enterprise is not limited to developing code. “Reasoning Agents” can leverage contextual understanding of metrics and processes to transform decision making. Instead of presenting static dashboards and relying on manual interpretation, Agentic DevOps platforms provide an intelligent repository of engineering intelligence. Leaders simply ask of the platform, in plain language, predictive questions, such as: “If I increase the acceptance rate of AI generated code to 35%, how will it impact velocity and quality?”.
Rather than reacting to last month’s failures, leaders can leverage AI insights to explore the impact of staffing changes, tool adoption, or other scenarios before committing resources.
Key Takeaways
If you are an engineering leader preparing to defend your AI budget or request more investment, here are the two critical takeaways from this session:
1. Establish a Baseline or Risk “Awkward Glances” in the Boardroom
You cannot prove the value of AI if you cannot quantify your state before AI. You don’t want to respond with a “silent awkward glance” when leadership asks how you measure progress and success. Before scaling your AI pilot, baseline your current PR velocity, cycle time, and error rates. When you return to the boardroom, you won’t just present a receipt for licenses; you will present a 20-25% productivity gain, backed by hard data.
2. Link AI to Developer Happiness to Customer Satisfaction
High AI usage with low developer satisfaction is a failure indicator. To prove the impact of AI in terms the board understands, you need to connect developer velocity directly to outcomes like “faster time to market” and “cost optimization”.
Instead of talking about “lines of code” or “adoption”, frame AI investment as a customer satisfaction tool. Faster, happier developers lead to higher quality features reaching customers sooner. As the panel noted, “Tools do not drive outcomes. Our empowered satisfied developers do”.
About Opsera Agentic DevOps
The transformation discussed in the webinar was enabled through Opsera’s Agentic DevOps platform with Unified Insights and GitHub Copilot. We’ve enabled similar transformations in organizations from seed startups to Fortune 100 enterprises, and would love to discuss how we can work with you.
Learn more about LTM’s successful AI journey.
Discuss your specific needs and see Opsera in action.
