What Leading AI Transformation Across 300+ Engineers REALLY Looks Like

Rohit Deep, who leads claims transformation at GEICO, joined Enrich for a candid conversation moderated by Ravi Tata, Founder & Fractional VP of Engineering at Sryam,  about running AI adoption inside a large, regulated enterprise. Rather than talking in generalities, Rohit walked through real numbers, real failures, and the operating model he's built over the past year to move a 300-person organization from zero AI tooling to using AI tools as the default choice for building anything. 

Key Takeaways

  1. ROI shows up in two places: delivery speed and reduced cognitive load on people. Rohit has always optimized for shipping faster because speed lowers opportunity cost and gets business impact sooner. The second lever is using GEICO's decades of data to make claims easier and faster for both customers and the human adjusters supporting them.

  2. Legacy systems don't have to slow AI down, if you build the right bridge. The team applied AI-driven software engineering capabilities to modernize access to a legacy claims platform. Using a generated API specification, AI agents analyzed the existing codebase and produced the necessary integration layer for a specific business area. This accelerated delivery and reduced dependence on engineers with deep institutional knowledge of the legacy system.

  3. "300% or bust" is the wrong way to roll out AI tooling. Rohit's first attempt was to mandate a 300% productivity jump across 30+ teams. He got 10 to 15%. When his team dug into where time actually went, they found coding was only 15% of the total effort, the rest was requirements gathering and getting things to production. That data reshaped his entire strategy.

  4. Change has to be pulled from the ground up, not pushed from the top. Instead of mandates, Rohit's team ran hackathons, but the real shift came when one engineering manager applied the hackathon energy directly to her own backlog and saw it work. That example spread organically to peers, and change leaders, not top-down directives, drove adoption from there.

  5. "Prompt to prod" became the operating model. Once Rohit's team realized coding was a small slice of the timeline, they split the problem in two: business requirements to prompt (a people-driven process involving product, design, and engineering working together) and prompt to production (a tooling-driven pipeline connected to existing CI/CD). That split significantly improved velocity in six months and then doubled it within a year.

  6. AI is not a headcount reduction story, and pretending otherwise is a cop-out. Rohit's team is simply moving through a much larger backlog with the same number of people. He's also skeptical of headline claims from companies saying AI now writes 80 to 90% of their code.

  7. Lines of code and PR counts are the wrong way to measure AI's impact. Rohit doesn't track individual engineer productivity at all. Instead, his team measures the business value of shipping earlier, if a product that used to take three months now takes two, that extra month of business impact is the number that matters, and it's what justifies the team's funding.

  8. Let teams choose their own way of working, then hold them to outcomes. One manager dropped Scrum ceremonies entirely and moved to one-week cycles; it worked well for her team. Another tried the same thing and it fell apart, so he went back to structured planning. Rohit doesn't mandate a standard process across teams anymore, some are even skipping user stories and working directly at the epic/feature level since agents handle design, coding, and testing end to end.

  9. Guardrails scale with risk, not with hype. In a heavily regulated business like insurance, GEICO uses a scoring system to flag high-risk work for mandatory human review. Lower-risk gets far more AI autonomy. Every engineer's code, whether written by a human, a product manager, or a designer, still goes through peer review.

Next
Next

The Human Side of AI: Where Do You Stand?