Case study published by Cursor on 2 September 2026. Analysis by Alex Circei, CEO and Co-Founder of Waydev.
Nokia’s Core Networks division is rebuilding its software development lifecycle around AI agents, and it has published numbers rather than adjectives. Two engineers analyzed more than 50 million lines of code in two weeks. Root cause analysis moved from weeks to days. One engineer built a working project-management tool in under a week. Here is what happened, and what it means if you are the one who has to prove your own AI investment is working.
At a glance
Nokia, Core Networks division, Mobile Infrastructure Group. Cloud-native network functions powering 5G voice and data.
Highly regulated and standards-driven, with many use cases carrying five-nines reliability expectations. Hybrid codebase in C, C++, Go and other languages across numerous repositories.
Produce an evidence-based plan to decompose a monolithic architecture into a distributed, service-based one. Original scope: custom tooling, a dozen or more experts, several months.
Cursor as a multi-agent platform across four workflows: architecture analysis, internal tooling, defect root cause analysis, and upstream requirements and design.
Cursor customer story, September 2026. Figures are Nokia’s own.
Lines of code analyzed, without building custom tooling
Engineers on the job, against the dozen or more originally planned
Elapsed time, against a multi-month estimate
Core Networks needed to break up a monolith. That is a common enough goal, but the hard part is never the refactor, it is the evidence. Which components carry the most risk, where do historical defects cluster, and which cut lines would actually improve reliability rather than redistributing the problem. Getting that wrong in a system with five-nines expectations is expensive in a way that most software is not.
The team’s own estimate was custom tooling, a dozen or more specialists, and several months of work before a single architectural decision could be made with confidence.
Architecture analysis
Two engineers ran the analysis across the hybrid codebase in a fortnight. The deliverable was not code. It was a decomposition plan grounded in where changes would most affect reliability and customer outcomes, and it freed more than a dozen specialists for other work.
Internal tooling
Deploying a new 5G mobile core function used to mean a multi-month project spanning dozens of people. One engineer went from problem statement to PRD to a working project-management tool in under a week, automating and visualizing roughly 80% of a workflow that previously needed six to ten project and program managers to coordinate.
Root cause analysis on customer-impacting defects
Systems engineers load environment logs, historical tickets, the codebase and debug traces, then run agents in parallel to flag hotspots and propose triage steps. Investigations that took weeks, with multiple cross-team meetings, now take days.
Upstream requirements and design
Requirements gathering, PRD generation, high-level design and architectural planning. Engineers pick models per task based on the accuracy and token efficiency each one needs. Next on the roadmap is automatically cataloguing network elements and how they are configured, connected and governed.
| Workflow | Before | After |
|---|---|---|
| Codebase analysis for decomposition | 12+ experts, several months, custom tooling required | 2 engineers, 2 weeks, no custom tooling |
| Deploying a new core function | Multi-month project, 6 to 10 PMs coordinating manually | Tool built in under a week, roughly 80% of the workflow automated |
| Defect root cause analysis | Weeks, semi-manual, multiple cross-team meetings | Days, parallel agents, engineers act without waiting |
| Requirements and design | Little automation, the least tooled part of the lifecycle | Agent-assisted PRDs, high-level designs and architecture plans |
Notice what those four have in common. Only one is writing code. The rest are analysis, coordination, diagnosis and design. Kal De, SVP of Product and Engineering for Core Networks, describes the shift plainly: the role of the engineer becomes the supervision of agents.
That sentence is the actual story, not the 50 million lines. When the unit of engineering work changes from writing to supervising, every metric built on the old unit quietly stops meaning what it used to mean.
Run the Nokia scenario through a standard engineering dashboard and watch what survives.
| Metric | What it measured before | What it does in an agent-supervised SDLC |
|---|---|---|
| Commits and lines changed | A rough proxy for individual effort | Measures agent output, not human contribution. Two engineers supervising a fleet look either heroic or idle depending on the week. |
| Cycle time | First commit to production | Still valid, and more revealing. Coding time compresses, review and verification expand. The bottleneck moves and cycle time is where you see it move. |
| Change failure rate | Deployment quality | Becomes the most important number you have. It is the counterweight that stops throughput gains being reported as pure profit. |
| Time to restore | Incident response capability | Directly measures the Nokia root-cause result. Weeks to days is a time-to-restore improvement, and it is auditable. |
| Seats and token spend | Tool cost | Tells you what you paid, nothing about whether the work landed. The most reported AI number and the least informative. |
This is why we keep adoption, impact and ROI as three separate measurements rather than one composite score. Nokia’s story contains all three, and they are three different claims. Adoption is that teams across Core Networks are using the tool. Impact is weeks to days on root cause and a monolith analysis finishing in a fortnight. ROI is a decomposition plan the business believes will pay back. Collapse those into one index and you lose the ability to tell which part is actually working.
De’s comment on the architecture work is that the analysis gave them confidence the plan would return something, in a way that would not have been achievable otherwise. Read that as a measurement statement rather than a product endorsement. Nokia did not run this and then assert a benefit. They produced evidence first, then committed.
That is the opposite of how most AI rollouts have gone. Buy the seats, watch the acceptance rate climb, tell the board productivity is up, and hope nobody asks what changed downstream. The organizations still defending their AI budget in twelve months will be the ones that did what Nokia did: establish the baseline, then measure against it.
Which raises the closing window. Baselines are only possible before behavior fully shifts. If your engineers are already supervising agents across analysis, design and diagnosis, the pre-AI comparison data for those workflows is being overwritten right now, and no vendor can reconstruct it later. We covered the mechanics in measuring AI impact on delivery and the right unit of account in cost per accepted change.
This is a vendor-published customer story and the figures are Nokia’s own estimates rather than an independent audit. The counterfactual, a dozen experts over several months, is by definition an estimate of work that never happened. That does not make it wrong. Every number in this industry starts as somebody’s estimate. But if you are taking this into a budget conversation, take the shape of the result rather than the multiplier, then generate your own multiplier from your own systems.
The shape is what matters anyway. AI has moved out of the editor and into analysis, planning, diagnosis and coordination. That is a lifecycle change, not a tooling change, and this is the first enterprise account I have seen that documents all four stages at once.
We measure what happens after the tool goes in. Waydev reads Cursor usage alongside your Git, ticketing and CI data, then connects it to delivery outcomes: cycle time by stage, review load, rework, DORA metrics, and the cost side of the equation. If your engineers are becoming agent supervisors, the useful question is not how many suggestions they accepted. It is whether the work moved faster, held its quality, and cost less per unit delivered.
That is what the WAY Framework is built for. Work-first, Agnostic, Yours. It measures the work itself from system data, it combines DORA, SPACE, Core 4 and the AI measurement research instead of replacing them with a proprietary index, and it stays portable. We do not ask you to adopt our vocabulary to use our product, and we do not ask you to take a vendor’s word for a productivity claim, including ours.
The takeaway
Nokia did not just adopt an AI tool. It changed what an engineer does all day. If the unit of work has changed at your company too, the measurement system built around the old unit is now telling you a story about something that no longer exists.
Generate your own numbers
Our playbook for measuring AI adoption, impact and ROI covers the metrics, the operating model, and a 90-day plan to a board-ready ROI story. Written for the leaders who own the AI budget, and it does not assume a data team.
Keep reading: The WAY Framework · DORA metrics · Measuring AI adoption at scale · DORA metrics in the AI era · AI ROI calculator
All figures and statements about Nokia are drawn from the Cursor customer story published on 2 September 2026. This article is Waydev’s analysis of that case study; Waydev was not involved in the engagement. Waydev integrates with Cursor for AI adoption, impact and ROI measurement.
Alex Circei is CEO and Co-Founder of Waydev, the AI engineering intelligence platform trusted by Fortune 500 companies including American Express, Dropbox and PwC. Waydev has been building Git-first engineering analytics since 2017 and holds a USPTO patent in Git analytics.
Ready to unlock your SDLC productivity?
