AI adoption isn’t about how many engineers use AI. It’s about how the engineering workflow changes because of it.
Rohit KhanduriEngineering Manager, Mobile Engineering, RoadzenMost engineering organizations are measuring AI adoption the way it's easiest to measure: seats enabled, lines of code generated, developer usage. Those numbers prove activity, not software. A team can clear every one of them and still ship a system that's harder to debug, less reliable, and more expensive to run. The shift that actually matters is harder to count, when AI changes how a team investigates problems, anticipates failures, makes decisions, and validates changes, not just how fast it produces code. That's the difference between adopting AI tools and evolving the engineering operating model.
Rohit Khanduri is an Engineering Manager in Mobile Engineering at Roadzen, an ML-driven InsurTech company, where he works on Android and Flutter architecture for mobile inspection products that feed insurance claims and assessments. Khanduri has spent his career close to the runtime realities of mobile pipelines, camera capture, compression and upload, the places where things actually break, which is the vantage point behind his skepticism of usage-based adoption metrics.
“AI adoption isn’t about how many engineers use AI. It’s about how the engineering workflow changes because of it,” Khanduri says.
Faster code isn't faster delivery
The assumption baked into most adoption dashboards is that generating code faster moves software out the door faster. Khanduri has watched that assumption break on contact with production. “Across multiple teams I’ve managed, including one of our mobile inspection products, I’ve seen that faster code generation doesn’t always translate into faster delivery,” he says.
AI accelerated the implementation, but the team still hit edge cases like interrupted image uploads, network failures, and camera lifecycle handling that the fast path had skipped. The time saved writing code came back as time spent debugging, fixing regressions, and shoring up reliability. His conclusion is that the metric is pointed at the wrong target. “AI adoption should be measured by delivery speed, defect rates, and production reliability, not lines of code generated.”
The coding fix versus the engineering fix
Khanduri’s sharpest illustration is a real failure from one of Roadzen’s mobile inspection products: the inspection images upload successfully, but the video upload fails. The two ways a team can respond are where his whole argument lives. “A coding-focused fix might simply retry the failed upload or modify the API call,” he says. The engineering-focused response starts further back, with the entire flow: video processing, compression, file handling, network interruptions, retry behavior, and backend responses, and asks what must stay true across all of it.
A failure in video processing can't be allowed to break the overall inspection, and retries can't create duplicate uploads. “A coding-focused fix addresses the immediate failure, while an engineering-focused fix addresses the underlying cause and makes the system resilient to similar failures,” he explains. As AI makes the fix itself cheaper to generate, the scarce skill moves elsewhere. “The real engineering judgment lies in validating the solution against failure scenarios and ensuring it works reliably in production.”
Where AI traces failures and where it guesses
Mobile failures rarely sit in one place, and Khanduri has found AI genuinely useful at moving fast across the chain, up to a point. It accelerates root-cause analysis from capture through compression, watermarking, and upload, helps the team navigate unfamiliar code, and generates hypotheses quickly. Then it hits a wall that matters. “Where it falls short is understanding the full runtime context,” he says.
In the video-upload failure, the symptom points at the upload service while the real fault sits earlier, in compression or file handling, and AI tends to chase the symptom. “AI may focus on the upload API while the actual issue lies in compression, file handling, or an earlier processing stage,” he says. Closing the gap still takes logs, reproducible test cases, and end-to-end validation. AI compresses the investigation, but it doesn't certify the conclusion. “Engineering judgment determines whether we’ve actually found the root cause.”
In insurance, half the data is its own failure
The stakes behind that reliability are specific to the industry. A partial inspection reaching the server isn't a smaller success, but a distinct failure mode that can surface later as a delayed claim or a disputed assessment. “An inspection isn’t truly successful just because some images have reached the server. The required images, video, and metadata must all be accounted for,” says Khanduri.
The team anticipates the failure modes directly, testing network interruptions, app termination mid-upload, insufficient storage, and video-processing failures, and designs recovery so a user can resume a failed upload rather than redo the entire inspection. AI has widened the net for finding those cases, suggesting failure scenarios and expanding test coverage faster than the team would alone. What it produces still has to be checked against real devices and real business rules. “In insurance, success isn’t just uploading data, it’s ensuring the inspection is complete, consistent, and recoverable when something fails.”
Tying AI to outcomes without fooling yourself
If usage is the wrong metric, Khanduri is specific about the right ones, and about the discipline required not to claim more than the data supports. He measures at three levels: reliability, including end-to-end upload success, video failure rates, retry recovery, and incomplete inspections reaching the backend; engineering efficiency, meaning time to diagnose and fix, review time, and post-release rework; and production quality, tracked as escaped defects and incidents before and after a change.
The harder part is attribution. A better number after an AI-assisted change is not proof the change caused it. “I wouldn’t claim AI caused an improvement based on a simple before-and-after comparison alone,” he says, noting that honest measurement means normalizing for upload volume and network conditions and ruling out other changes, and verifying that incomplete inspections are never marked successful. The bar he sets is deliberately higher than the usage dashboards clear. “The goal is to prove that AI-assisted development improves delivery speed without compromising production reliability, not just that developers are writing code faster.”
What stays with the team
Running through all of this is a line Khanduri won't move: AI reduces friction and widens investigation, but the accountability doesn't transfer. The decisions about what should happen when compression or watermarking fails, whether to retry, recover, or fall back, are engineering trade-offs, not calls to hand to a model. “Architectural ownership, production accountability, and final engineering judgment must remain with the team,” he says.
The aim was never to maximize how much AI gets used. It's to build an engineering system that ships reliable software with less wasted effort, and to introduce AI only where it measurably earns its place.
