I recently had the chance to speak with Narender Reddy, a Lead Software Engineer working in the insurance industry in the United States. With more than 17 years of experience across web development, mobile development, cloud hosting, DevOps, and software architecture, he has seen the industry evolve through many times. During our chat, Narender described AI as a tool that helps engineers work faster while still relying on human judgement, experience, and responsibility. Instead, he spoke about it as another tool that helps teams move faster while still requiring judgment, experience, and responsibility. We discussed how large organisations are introducing AI into their engineering teams. Rather than introducing AI everywhere at once, they are first preparing the engineering platform. That includes migrating repositories to GitHub, replacing Jenkins with GitHub Actions, strengthening governance, and improving security before expanding AI adoption across the company. We also talked about what it actually means to be a Lead Engineer. Many people imagine that a lead engineer spends most of the day in meetings. While management is certainly part of the role, Narender still enjoys being hands on. He likes working with the team, discussing solutions together, discussing solutions together, encouraging engineers to propose ideas, and helping the team decide on the best approach together. One part of the discussion that resonated with me was estimating work. Unknowns always appear during software development. His approach is to focus on today’s priorities, organise work clearly, and delegate whenever the right expertise already exists within the team. His approach is simple. Prioritise today’s work, organise tasks clearly, and delegate when the team has the right expertise. It sounds straightforward, but doing it consistently makes a real difference. Naturally, we spent a lot of time talking about AI. Today, he relies on AI for a significant part of his daily work. Writing user stories, analysing repositories, understanding unfamiliar codebases, and generating implementation plans have all become significantly faster. At the same time, enterprise security policies still limit where AI can be used, especially while large codebases continue migrating to newer platforms. We also explored a topic that every engineer is thinking about today: trust. How much information should we really give to AI systems? There is no simple answer. We both agreed that there are clear benefits, but also responsibilities. Sensitive information, credentials, customer data, and private documents all require careful thought. Local models have their place, cloud models are becoming incredibly capable, and every engineer has to balance convenience with privacy. The conversation also moved into software architecture. We also explored monorepos, microservices, enterprise migrations, and the complexity of maintaining systems built by hundreds of engineers over many years. One example was particularly interesting. Different insurance products had evolved separate login systems, each with its own users, databases, and authentication flow. Bringing those together into a single authentication platform became a multi year engineering effort involving databases, APIs, migrations, and collaboration across many teams. It is a reminder that software engineering is rarely just about writing code. Much of the work happens long before implementation begins. Towards the end of our conversation, Narender shared that he is also researching AI adoption in enterprise environments and publishing research papers and technical articles on the subject. Like many engineers, he has found that writing about what he learns helps him organise his thinking and deepen his understanding. And that’s something I strongly relate to! Whether it is an article, a video, or simply explaining an idea to someone else, teaching remains one of the best ways to learn. We also both agreed that modern software engineering is becoming increasingly product focused. As AI takes over more repetitive implementation work, engineers spend more time thinking about user experience, architecture, and solving the right problems. Lastly, we discussed internal hackathons, where teams prototype new ideas over a couple of days. One project involved AWS Bedrock to automate parts of the insurance underwriting process, reducing work that previously took days down to around an hour. Mentioned Resources & Links * AWS Bedrock * Zeera AI Tools (Narender uses it for his meetings) * GitHub Copilot * Google Scholar * Medium Publications This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.pierrehenry.dev
