## Transcript

**Snehith**: [00:00] ... taking the software engineering, data engineering, overall IT world by storm, which is essentially AI in SDLC. So I would like to introduce each of our panelists one by one. I would like to start with Anand. Anand is an LLM Psychologist at Straive, formerly co-founder of Gramener, acquired by Straive. He brings hands-on expertise in rapid prototyping and agile implementation. With a background spanning engineering at IBM and research at IIM Bangalore, he specializes in building practical LLM-based solutions using AI-driven workflows and Python content development. He focuses on how AI tools are actively changing the day-to-day workflow of developers. Welcome, Anand.

**Snehith**: [00:53] Next up, I would like to invite on stage Lakshman Peethani. Lakshman is the Director for Technology Solutions at EPAM Systems. He represents the enterprise scale of AI integration. He specializes in utilizing GenAI to revolutionize the software development life cycle across massive engineering teams. His expertise lies in AI-powered developer experience, using LLMs for coding assistance, automating regression testing, and safely institutionalizing RAG architectures in production environments. Welcome, Lakshman.

**Snehith**: [01:27] And lastly, I would like to invite Usha Rengaraju on stage. She is the Chief of Research at Exa Protocol and the world's first female triple Kaggle Grandmaster. She brings heavyweight AI research and rapid application-building credentials to the group. She specializes in deep learning, GenAI, and probabilistic graphical models. Having designed data science curriculums for major universities and prototyped extensively with RAG and LLMs, and beyond her technical acumen, she is also a prominent advocate for neurodiversity and organized India's first NeuroAI symposium. Please give a big round of applause to all of our panelists here today.

**Snehith**: [02:16] So, I would like to maybe ask each one of you, what is your day briefly in a minute on how AI is revolutionizing SDLC? Starting from Usha.

**Usha**: [02:32] For me as an AI consultant, working with large codebases is one part, and the other part is when you're prototyping, you're doing an initial prototyping for a client demo and things like that. So I predominantly work with pre-seed, early US clients who are yet to raise their seed funds and base their nature of funds. So there we don't really work with large codebases. We start from the scratch, mostly greenfield kind of systems where we start off from scratch and show a demo and things like that. For these kind of use cases, AI is brilliant and revolutionary. **A simple example from my personal experience: I deal with around four to five clients at any point in time. That's the volume of work which I take in. Until 2024, I used to have like six to seven interns, predominantly higher from IITs, the top ones like Bombay and Chennai. Because I want less people, six or seven, but the volume of work is very high. So I used to spend somewhere around 3 to 3.5 lakhs on intern salaries every month until 2024. From March and April 2024 till now, I am saving like 60, 70 lakhs on interns' salaries every year.** That is really working out brilliantly for me. At least for the use cases which I deal with, which are like small prototypes and demos for clients who are raising funds, it works out brilliantly. So this is my personal experience.

**Lakshman**: [04:16] As a technology consultant, say I talk to a lot of different large enterprise customers. My day mostly goes into talking to these clients in terms of how AI can actually accelerate their product development cycle and release faster. And at the same time, being a software services engineering company, we also face a lot of fierce competition from other competitors in terms of competing for the same project. **We are now leveraging AI to be more competitive and bid for those projects at a much lower price point.** And we are innovating in this space by building our own agentic solutions to actually develop these solutions faster for our clients and deliver at a much rapid pace than we were like two, three years back. My day-to-day life, I am also playing product manager for some of these modernization solutions. **Unlike what madam has spoken about, ours is mostly on the brownfield side and modernization.** And we are seeing significant strides in some, in terms of what kind of a productivity AI is bringing in those areas as well, but not maybe at the pace of greenfield kind of scenarios.

**Anand**: [05:43] **AI is my SDLC. I've stopped designing, I've stopped gathering requirements, I've stopped coding, I've stopped testing, I've stopped deploying. Here is roughly what it looks like right now**, and I prototype a lot like Usha. One of my colleagues, he calls, and I record the call. Then I send it to Gemini and say, "Tell me what he wants." Convert that into a prompt for Copilot or Codex or Claude. Give it to it, it generates the code. Then I have one of the other agents say, "Look, test it, find all the errors that you can," feed it back, and they keep talking to each other. Then I say, "Deploy it into the server," and it deploys it. And automatically send an email to these people with appropriate content saying this particular transcript has been deployed. And this is what I tell my team to do as well. **I'm very confident to take interns, put them in front of a senior intern. Say Varun, who is still studying at IIT Madras, whom we took on as an intern, I'm confident to let him interact with Ankor, who is Straive's CEO. And they've been having interactions and Ankor is like, "This guy is fantastic, how is he doing it?" The process is: he records the call, he feeds it to ChatGPT, and gets the result.** That's basically it. So unlike Usha, my process has been the reverse. I'm hiring more interns because they don't slow down the process like experienced people.

**Snehith**: [07:07] Madam, how are you there on the... You talked about how you are ensuring that your team is using AI as part of the overall process itself, right? But how do you ensure that AI reflects your preferences as a lead? Because sometimes you know your team better, you know who does what job better, you know based upon the code review check-ins, you know what is the cycle of your check-ins or changes that happen per repo itself, right? So how do you ensure that you are reflecting your preferences for your team when you use AI? And more importantly, what's actually working? Are custom instructions working, or shared prompts working, or PRDs working? What is it that works best for you as part of the SDLC?

**Anand**: [07:55] I'll start with something else that I'm doing, which is approaching this with a certain degree of humility and finding that **there are many areas that I don't know about that AI knows better than I do. Whether it's domain, or whether it's code, or whether it's style of even data visualization, which I consider myself very good at.** So when I see something that is different that it's produced, it becomes a learning opportunity for me to then have to start thinking, "Okay, is this better? Is this worse?" and so on. Put another way, how much of my preference is good and how much of it is actually hurting? Especially when the process of me applying my preference involves time and effort. So I have created one separate channel where I say, "This is the person whom you need to give stuff to. You are the person who is going to try and stay out of the way as much as possible, letting AI do that stuff. So you are that channel, let's see what happens without applying my preferences." And that is therefore increasing a different kind of channel without applying my preferences, and that is growing and I'm learning from that. Part A.

**Anand**: [09:04] But where I _have_ a preference, the process is review and more output review. Step one is, look, I've spent one and a half seconds looking at this, this is rubbish, this is too hard for me to review. Therefore, make it more reviewable. Specifically asking for output that is easier for me to review is one step. Second is, okay, now I've taken a look at it, make this broad change, make this broad change—not at a level of implementation, but a level of feeling. Because AI is good at execution. What I'm left with is therefore emotion, feeling, that sort of a thing which I'm trying to transfer both to the intern as well as to the model. Third, capturing all of these in transcripts and then having some agent look at all of this and say, "What are all the things that I've said more than thrice?" Take that and put it into a `skills.md`. So that you can use it, I can use it, and then periodically review the `skills.md`.

**Snehith**: [09:57] So Lakshman, actually you might be hiring a lot of freshers, people who are coming, graduating from an engineering background, because there are a lot of students out there as well, right? For a junior developer who is joining a team which are primarily starting to use AI as a part of every aspect of SDLC, right, what is their career path? Will they ever write raw code as how previous developers used to do a few years back? Or will they mostly lean into managing agents?

**Lakshman**: [10:37] I think it's an evolving space. Currently, in the current workday, they still write some code, but not at the same level as we used to write back in the day. But for them to produce the right kind of an output, they need to understand what AI has generated. They still need to be able to read through the code, understand it, and then maybe give feedback to the LLM in terms of, "Hey, this seems to be too complex," or "What was the solution I'm looking for? Maybe redefine it, simplify it," and so on. So for that, they need to understand. But what has changed significantly is, **now it's no longer like, 'Okay, I'm a Java developer, I will only write Java code,' or 'I'm a React developer, I will only write React code.' No, you have to be a polyglot developer and you have to do end-to-end. Not necessarily just a developer role, but you need to understand product management, you need to understand refinement of your requirements, development, and even QA as well.** And that's the level of AI maturity that we are inculcating in our organization. So we are trying to build that mindset because it's a mindset shift from what they got used to. And maybe it used to be like this back in the day, like maybe a couple of decades back, we used to do end-to-end. But that has changed significantly. Now we are kind of going back in that cycle and trying to build this cross-cutting layer. Like, there is no longer a QA role, developer role, and all that. And more polyglot in nature. Maybe you're not an expert of every technology or every framework, but you need to know, like, okay, if I'm doing an end-to-end task, I need to be able to understand my requirements, understand the output that AI has generated, review, give the feedback, and be able to test it and then deliver it. So that's the shift that we are seeing, and even my team, like, there is one guy sitting in the audience, he is doing that now. I'm forcing him to do everything end-to-end irrespective of what skillset he currently owns. I'm asking him and forcing him to do frontend development, testing, and so on.

**Snehith**: [12:45] Got you. Any other thoughts from the panelists around what students need to do? Junior developers need to do around making sure they are still relevant?

**Usha**: [12:59] I think to look at the positive side of things, irrespective of whether they are studying in university or even schools these days, AI is accelerating the learning process. So this could be relevant for both junior developers and things like that. For example, if you are a junior developer who's working with AI/ML pipelines and things like that, if you give a third-year engineering student good access to Claude, ChatGPT Pro version, and everything, and give him a deadline of two to three days, you have to learn kernel fusion. You are building LLM pipelines, you should know how advanced PyTorch works, how torch.compile works, how do you internally analyze graph breaks, how do you do this? These are advanced stuff. **But you give a third-year engineering student good access to all cutting-edge tools, three days' time, he will still be able to do it. That's the amount of acceleration which AI brings in.** And in my personal journey, if you see, I have been predominantly for the last ten years working only in the AI space. But last year I had a requirement where I had to build a full-stack desktop application. Not even web application—see, web application itself is difficult, but to build a desktop application... So I have zero in the desktop side. But I had been like three to four months into the development, I had been able to put together a demo for a client which can be shown as a proper demo using Electron and all that. So the learning acceleration is phenomenal when it comes from AI. Of course, it has its lot of flaws and other challenges and all that, but I really appreciate the acceleration which AI brings to the table. You take either the AI space cutting-edge advanced PyTorch, or the side of an AI developer being able to do desktop development. **Three years back in 2024 [meaning 2021], if you asked desktop development, I would have run three kilometers away. But now I'm confident of breaking anything in the SDLC lifecycle. That's the acceleration which AI brings into learning.**

**Anand**: [15:05] My advice would be: **use AI like crazy to find out what it does well. If it's doing something well, stop learning that. Nobody is going to hire you for that. Where it breaks, use AI to learn that. That way you'll be building a skill.** And keep doing this regularly because it keeps changing.

**Snehith**: [15:25] And that actually leads me to the next topic around coming to the release cycle, which is typically part of the SDLC process or essentially process. So say, for example, we are ingesting AI into the process. Say a Copilot writes or it fixes a bug, right, from a Jira ticket reference point of view. Who owns the commit? Does the AI own the commit? Will the developer own the commit?

**Lakshman**: [15:52] So it's the developer who is delegating to the agent owns the commit, because it's his responsibility to ensure it is functionally accurate and he needs to take the accountability of ensuring it is what the requirement says and it is not introducing any regressions or whatever, right. So from that point of view, it is still the developer's responsibility. He's instructing the agents or delegating to the agents. And then he—like, though AI agents are still doing the code review, maybe at the final review state it needs to be done by the developer. At least in the current state of the AI maturity. But that could change over a period of time.

**Anand**: [16:36] **It's largely about how do we assign responsibility and control. Humans, we know how to do that. Four centuries ago, we learned how to do that for companies. We also do that for gods, rivers, ships. These are all legal precedents where you can actually hold them accountable by law. We haven't yet learned how to do it for agents.** But it would be a fun exercise to figure that out. Say, what if, personally, I create an agency—and I am in fact doing that for exploring it with Times of India—where I'm saying, look, I'll give you five journalist agents. They will write your articles for you, and these five agents have names. So Matsya, who is the first one, has written an article, will get feedback. That feedback will improve blah, blah, blah. But I'm still at the end of the day accountable. But what if I could figure out some kind of an incentive system so that out of a fixed pool of money and token size or compute power, I penalize and restrict access or give money? Based on that feedback, they will want to improve. Already they are very eager to please, so steering them is not a problem. Can we assign some kind of a control mechanism telling them, "Look, if you do well and you are able to head in these directions, then I will let you survive. The rest of you die"? Not that they mind dying, they are just agents. But it almost creates an ecology rather than an accountability. I may still end up needing to be accountable, just like the board of directors probably still have to be accountable for a company. But **we may be able to create something like a limited liability corporation with a pool of agents and still give them a significant chunk of accountability while being able to trust them because they are going to be so bloody cheap.**

**Snehith**: [18:15] So, you talked about accountability, and typically RACI matrixes are something that are part of the project management itself, right? So would we argue that we would never have agents responsible? We would only have them either accountable or consulted or informed, but never developers responsible?

**Anand**: [18:34] "Never" is a long time, and I would say... at some point of time yes, but today, as of now, not responsible. Not legally.

**Snehith**: [18:48] Yeah. And if there are code reviews, for example, or if there are PR accounts or release dates changing, how are they changing for your teams by introducing AI into the process? Are you doing PR commits faster? Or do you see that they don't even have to do it, they're just monitoring it and they are no more the authors, they are just someone who are monitoring PR commitments?

**Lakshman**: [19:13] So, we've been doing this adoption in many of our client implementations and every project has a different level of maturity. But the most mature ones are like, the AI, the delegated agents are executing everything in silos to the specific feature implementation, and then once the feature is implemented, the PR is created. And in the process, if there are any clarifications required, the agent triggers for that and then someone who is accountable is actually providing the clarifications. That's the first step. And then once the PR is created, the person is going and reviewing it. Though the first line of review is again done by another agent, the final review still needs to be done by the individual human developer. And he is also ensuring the functional accuracy of that. Like, though you have these different AI agents, one is ensuring the functional accuracy and the second is ensuring the technical accuracy, but there is still a developer who is actually validating it from a business requirement standpoint. So that's the process that we are seeing and it's still evolving. Like I said, every client and every project has a different stage of maturity. The most mature ones are actually currently doing this: AI agents are executing everything in silos and then getting a PR, and then the developer is actually taking the ownership and then reviewing it and then approving it and going forward into the release cycle.

**Snehith**: [20:46] So if there is a company or a team out there, would you recommend them to start off using AI in SDLC as a greenfield or start learning from a brownfield and get better using it? Or vice versa?

**Lakshman**: [21:03] I think greenfield is the easier target. Like, we have seen it works well in greenfield implementations, but brownfield you need to actually do a lot of groundwork and establish the workflows so that it actually produces a better outcome. Because in brownfield scenarios, what we have seen is like, the early adoptions actually failed and they were not really producing the right kind of a result. So then we have to go back and review our whole workflows and refine or redefine that process. And it also requires some mindset shift from the developers as well. You can't do it the same way that you're doing it in the past the way they are delivering. So that's also another point.

**Anand**: [21:47] New stuff has less competition, less preconceptions.

**Snehith**: [21:52] Right. So we are moving from AI as a copilot, right, to AI as an autonomous agent. So AI agents being autonomous software engineers. How ready do you think teams are to make that paradigm shift? I know some advanced teams are already making that paradigm shift as we speak, but how ready do you think we are, would you be comfortable handing over agents and making them responsible or accountable for your SDLC process, if you are handling a team?

**Usha**: [22:24] With brownfield systems, although I don't have expertise building like Lakshman and Anand in the brownfield system side of things, even in greenfield which I operate, the models which I operate, I wouldn't hand over the complete control. Because from my personal experience, there are a lot of challenges in certain use cases. For example, you are working with Nvidia CUDA libraries like [Nemo?] or Nvidia agentic AI libraries. These are not used by common developers, these are used by very elite developers, production level systems scaling like Netflix and all these things. So the amount of knowledge which is available externally for the LLM to be trained on is very limited. This is one example. Or you take a banking system like Temenos, they use a programming language like T24. So the amount of external knowledge which is available for this programming language is very limited. So of course, in very sensitive domains, whether it is greenfield or brownfield, handling over complete control is very difficult. And even in my personal experience of working with certain Nvidia things like that, I find hallucination rates, in spite of using the best code tools available and agentic tools available out there, I find the hallucination rate is so high that if I have to do it from scratch, it would have taken me half the time. Fixing and debugging the code takes... for certain areas where there are, you know, hallucination rate is literally very high and it's still not very good. But there are certain areas of development where it's extremely good. So handing over complete control, I wouldn't say. I would say, if I were to hire engineers and stuff, I would still have them go through this system design interviews, coding rounds, and all of this is still relevant because I might use it as an assistant kind of thing here and there. But at this point of time in 2026 [meaning present/near future], I would still use it as an assistant for very critical applications and stuff and not hand it over completely. So this is my thought process.

**Anand**: [24:39] I would strongly underline "in 2026."

**Snehith**: [24:46] And so one last question. What is the biggest blocker to have AI as part of SDLC? Is it the people?

**Anand**: [24:53] Yeah, yeah. It's the people. It's their... it's our unwillingness to include that as a part of... I am a coder. If AI is going to do my code, what am I?

**Snehith**: [25:06] Any final thoughts from all of you on what should we do or what should we not do for AI in SDLC?

**Anand**: [25:17] The world is moving forward so fast that I think one of the biggest gaps we face is not being able to plan extrapolating into the future. We are making all of our plans knowing the current state, and that is hard enough to find out where we are today, what is the state of the world. And therefore, the plan that we make, which we lay out for a year, is outdated in a quarter and we are having trouble. So **what I would do is extrapolate things for a year and put it in a safe pocket somewhere, where once things get to that stage, we will be able to take from that process and learn from it. Which means that we need safe ways of giving autonomy to agents.** Not guardrails. Guardrails is about making them safe and that is hard. If I could put guardrails and get it to work, I would put it in production. I would say get it to a state... try them out in spaces where when it fails, it's okay. I have a continuous publication of comics from news. When it hallucinates, it is a feature. Exactly! So in that case, I can discover 10 things, 20 things that it can do which will be useful tomorrow, and then I can then say, "Oh, now it has to align with this particular style, or this has to be the format, it cannot do weird sensitive comics," and all of that. At that point, I will put it into production, but I know what it can and cannot do. So **having a safe space where hallucinations are not a problem and running with it, I think, is one way of being able to anticipate the future.** And there are many more, but the core thing, I think, is to plan for where we will be a year from now than where we are now.

**Lakshman**: [27:04] Yeah, I echo with Anand's comment. I think experimenting in the safe areas is the best way to start this adoption. And that will give you at least a feedback of, okay, where it will work, where it is likely to fail, and then you can identify those failure points and then try to mitigate them or at least come up with an alternative solution for those environments. And whether we like it or not, this is going to be the norm, and it is already becoming kind of a norm with a lot of clients. Like, I spoke to some customers who question our numbers like, let's say if I say, okay, realistically it is 30%, they are questioning like, "Is it 30%? Is it 50% or is it 80%?" and all that. So whether we like it or not, it's a norm. So I think we as engineering people need to evolve and then start adopting it and then see what are the safe areas that I can adopt it and where I get more value out of that and then start with those and then figure out how you can improve it from there.

**Snehith**: [28:07] And before Usha, I think one thing that I would like to share also is, I think there was a recent report, basically a news report where one of the consulting companies were asked to pay back the money that they had saved by using AI by their clients saying that, hey, you used AI and you achieved 20% efficiency, give me that money back. So I think the costing model for companies who are working with clients also is probably, you know, not far off, as we speak.

**Lakshman**: [28:39] It's happening.

**Snehith**: [28:40] It's happening. Yeah. Usha, your final thoughts?

**Usha**: [28:44] Yeah, so I am safely unattached. Currently I am charging the same rates what I was charging in 2023, 2024. But the time is running out, I am quite aware of it and anticipating next time in the next month, what would be my financials. So, and my final thoughts would be like, use the current system of development, AI where it is for code, look at the positive side of things. There are a lot of things which it can accelerate, your learning and even unchartered areas. Personal experience: there are certain areas which two years back I would never touch it. I would have the fear of even having discussions around it. But now my mind has opened up. **You give me any topic, even something like HPCs, HPC and all that, configuring Slurm and all these things, I was just doing a small mini demo. These are areas which I couldn't even imagine two years back. Now you give me, I am very confident with AI's help I can pull it off.** So there's a lot of positive side of things, definitely you can use it for accelerating development, initial POCs, and there's a lot of research areas in the intersection of AI and SDLC coming up, like the core context engineering, up the challenges with looking at that retrieval thing. I was exploring these research areas for the cybersecurity right at a point where I had to build an AI agentic system for resolving code vulnerabilities kind of things. So there are very interesting research areas. **So as students, as professionals, if you are looking for research areas, these are like good research topics to pick up and solve these existing challenges.**

**Usha**: [30:27] And before I wind up, I would take a minute. I am so happy to be here. I am associated with Python, PyLadies for a really long time, and PyCon India as well. I would like to take a moment to appreciate the organizers. Srikar, Kalyan, Snehanth is part of the organizing team, Sanchit, Bhushan, and all of this, and many more in the organizing team as well. **I really appreciate the amount of effort—and I am a community organizer, I lead communities for like [inaudible], so I know the effort it takes to organize conferences.** And doing it consistently for several years, keeping the community alive. **And PyCon Hyderabad, the Python community in Hyderabad, is one of the most active Python developers communities in the world actually.** I travel across the globe to give keynotes at PyCons. So I can say hats off to all the organizing committee and give them a round of applause for doing this consistently.

**Audience**: [31:24] [Applause]

**Snehith**: [31:26] Yeah, thank you, thank you, [inaudible]. So yeah, I would probably like to start off with one thing. So when we were discussing yesterday, Anand had given one idea, **we should probably also have AI as one of the panelists.** We'll try to do that, but **I was afraid that probably AI would take over my job as a moderator.** So we'll try to do that, but we said okay, we'll probably put human heads.

**Anand**: [31:50] **That's why I stopped inviting it as a co-host, it was stealing the show.**

**Snehith**: [31:53] Exactly. So thank you so much all panelists, and please give a big round of applause for all of our panelists for all of the panelists for joining us today. Thank you so much.