Deterministic Governance for Enterprise AI Systems

[00:00:00] Nirmal: Start thinking about your organizational knowledge. We still have so much knowledge in people’s heads. It’s not written anywhere. We still require so much context for AI, which is not in documentation and not in your codebase, and that’s a huge gap when we talk about context.

[00:00:20] Itamar: Welcome to The Agentic Review, the podcast where we explore what good code really means in the age of AI software development.

[00:00:29] Nnenna: I’m Nnenna Ndukwe, Developer Relations Lead.

[00:00:32] Itamar: And I’m Itamar Friedman, the cofounder and CEO of Qodo.

[00:00:35] Nnenna: So, let’s get into it.

[00:00:40] Itamar: Today, we’re joined by Nirmal Jingar. Nice to meet you, and great to have you here.

[00:00:45] Nirmal: Thank you for having me. Nice to meet you, Itamar and Nnenna.

[00:00:48] Itamar: Nirmal directs enterprise AI and supply chain engineering. He spent a decade fixing fragile systems before turning that hard-won reliability instinct into a philosophy of governed AI. And he’s now here to share it with us and also as part of the Forbes Technology Council. He’s a writer there and also a TEDx speaker.

[00:01:11] Nnenna: And in his work, he’s run GenAI coding pilots with tools like Cursor and Copilot across the software development life cycle. And he’s built a framework, deterministic governance, for wrapping AI in guardrails so we can act safely in production. His mantra: start with the decision, not the technology. He also sits on a dozen boards and advisory councils, from Ethical AI to Resilient Coders, a Boston nonprofit training the next generation of engineers.

[00:01:38] Itamar: So, without further ado, Nirmal, did we miss something? Do you like to add?

[00:01:44] Nirmal: I think we covered pretty much everything. Most of my time nowadays, I spend less thinking about the AI model and thinking more about the business context and the decisions, and really trying to understand, like, at the large enterprise level, specifically in supply chain, how do we make decisions, how many touchpoints we have, and how I can effectively use AI for the tier one systems. Right? So, this is far away from just creating a POC and MVP, and it requires a lot of changes, a lot of engineering and software development, even before we just talk about AI, right? So, yeah, I’m happy to dig into more detail and see where we take this podcast here.

[00:02:29] Nnenna: Yeah. Speaking of what you said about this is not just POCs. When we think about, like, AI coding tools in enterprise, in your experience, where has AI coding assistance proven to be very successful?

[00:02:43] Nirmal: Yeah. There are several areas where I have seen drastic change when I started using the AI tooling. Right? Number one is coding execution, which everyone already knows. This is not something new. Right? So, the execution speed has increased drastically. Right? The teams are able to finish projects which used to take months and months. They can finish in days and weeks now. So, that’s number one. That’s a huge benefit specifically for engineers who are writing code, right? The other area where I’m seeing the huge benefit is, like, triaging and root cause analysis. Right? So, triaging an incident, an issue, a software issue, and finding out the root cause for that particular incident used to take a lot of time. Right? Because when you think about the enterprise level, we have, like, so many systems involved in it. There are, like, so many teams involved in it, and you have multiple dashboards, and looking into multiple things until you get to the proper root cause analysis. And, plus, you have to talk to the human, right? So, all of that time that engineers used to spend on the incident has reduced drastically, right? Now we use this AI tool and run the root cause analysis through this, and that gives you the that comes with the response with reasoning, like, with evidence, right, and then gives you the next step. So, I think this is the next, second thing after coding when I’m seeing the huge, huge improvement.

[00:04:16] Itamar: Yeah. Would you say that you would use the same tools, the same UX/UI, in order to code and do, like, feature development, to do word code analysis? And I’ll challenge this question or spice this question and say, like, if coding agents are so good at generating code, like, why do we need root classes anymore? Like, can’t they, like, already, like, create that new change, or the existing software doesn’t require, like, they can do the root classes in advance to some extent. Right?

[00:04:56] Nirmal: Yeah. That’s definitely true, but I think most of the enterprise companies are not there. When we talk about the system architecture, software domains, right, it’s so fragmented. If you take an example of any enterprise system, it’s like there are so many multiple systems involved in it, there are so many monolith legacy involved in it, and something might be on cloud, something might not be on cloud, so that’s a perfect segue into the next thing that I wanna talk about, like modernization, right? I think a lot of people are making mistakes and trying to just add AI on top of the existing system without modernizing the base. Right? So, why is it important? If you don’t modernize, if you don’t have your event stream, if you don’t modernize your data, if you don’t categorize your data properly, if you don’t create proper domain context, and if your monolith legacy system is not in a proper state where it can integrate easily with the new AI models, new systems, or new third-party systems, you name it. Right? If you don’t do any of those modernization and just focus on, like, oh, I need to prioritize AI, and let’s say they add AI on this existing system, it is not gonna be successful, or you are not gonna gain a huge business outcome or impact, right? The AI learns from the context, but if you are not modernizing, you are shooting yourself in the foot because you are teaching the AI the wrong stuff. Right? And if the system is not properly architected, not modernized, it is gonna be extremely slow, and you will be facing issues with latency, right? And AI is gonna make mistakes. Right? It’s already probabilistic. And that’s the future of LLMs. Like, we wanted this to be probabilistic. And in order to make it deterministic and low latency, you need a strong foundation. If you don’t have that strong foundation, your latency will be high for any AI tooling response. You are not gonna get a 99% or more than 90% accurate answer. Right? There will be so many mistakes. So, if you do that after a year, people will realize, no, I made a mistake. I didn’t do modernization. My system is not working properly. I have other competitors in the market, and they are much ahead of me.

[00:07:25] Itamar: By the way, like, would you do modernization differently pre and post-AI? Like, is there something in the process or outcome, the end results, that you would like to be different? Like, you know, basically, I’m asking: are you talking about AI-native, or, like, basically, like, optimizing for AI to be able to understand the codebase? Like, that could be a different modernization, right? Are you thinking about that?

[00:07:57] Nirmal: Yeah. I think it’s somewhat both. One thing is like optimizing for the AI. Definitely, you have to do that. Right? Even before you optimize for AI, you need to look into it, like, is your system stable? Is your system scalable? Are you in a position where you are ready for the optimization? Right? If you are dealing with a system which is, like, built, like, 20, 15 years ago, And if you just start with just optimizing with the AI, we still need to figure it out. Like, what are the other challenges that you should be solving first? Are those challenges related to data? Are those challenges related to integration? Are those challenges related to the event stream? It can be anything. Again, we need to take a very specific example and problem, and then we can talk about it. But, yes, we have to make a decision even before you start changing the system for AI, as the system is stable or scalable or not.

[00:08:58] Nnenna: I feel like, oh, you mentioned determinism or deterministic tooling, but then you also mentioned how, like, probabilistic is the future. So, I wanna hear more about, I guess, your framework that you developed. What was it meant to solve as it relates to deterministic governance?

[00:09:15] Nirmal: Yeah. So, probabilistic is a feature of LLMs. LLM models are not gonna be 100% accurate. Right? That’s how they’re built. Right? And that’s a feature of LLMs. In order to make it deterministic, we need to make sure we are validating every response that comes out of the LLM, right? So, every response has to be validated, and you need to have your own policies, rules, right, and also the threshold. When I say the threshold, if you are making an, like, end-to-end automated system and you don’t want to involve a human, which is not possible, like, for highly regulated industries and the tier-one systems where companies make millions of dollars, right? So, you have to make sure you are validating every output. You have the policies, rules, right, and when I said threshold, threshold means once you are validating everything, the response, you need to have the defined threshold. The threshold will be based on your problem, what kind of problem it is, and what is the governance level, right? Is it like you want 100% governance, or you are like, okay, this system is not that critical; I’m not dealing with healthcare or patients, so it’s not a tier-one system? So, the governance level will be medium, and you can be a little bit flexible over there, right? So, for that, the threshold might be, like, 80%. Right? If you meet the 80% requirements, the rules, and you are happy with that system and the response from the LLM, then you say, “Yes, go ahead and continue working on it and continue automating. I don’t require a human for it.” Right? And based on the threshold, you can decide, okay, this is very risky. I don’t want you to automate. I don’t want this agent to continue working on it. So, we need to flag that, right, and make sure somehow the human gets the notification, and the human jumps in and helps break it. Right? And again, this is an iterative process. Right? Based on how many times you are involving a human, you keep a record of it, and that becomes a feedback loop to your system. Right? So, your system can run continuously and keep on improving continuously. And then when the human comes into the picture, what the human is doing for that flag – are they making decisions differently? You capture all of that data and feed that data again to your system, so your authentic workflow is learning on the spot, and it’s always improving. So, gradually, we wanted to take this to the level where you have, like, 99% automation running end-to-end and you don’t require a human in the loop, and the human can work on something more meaningful and more something more critical rather than just focusing on that one system, if that answers your question. Yeah.

[00:12:11] Itamar: You kind of reminded me a little bit of the DARPA definition of artificial superintelligence or automation of machine learning. It’s actually quite an old one. I think it’s called D3, if I remember correctly: data-driven; that’s why D3. Like, basically, the M is models. Basically, what they’re saying, what you said, is that a highly intelligent creature can get a set of instructions and a goal and then, as part of the process, go and acquire additional data and context, whatever, in order to reach the decision or the actions. And if it’s missing, and it’s not capable of making the right decision or getting the right context to make a decision, and that’s two different things. It needs to know that it doesn’t have enough context to make the right decision; then it goes and asks its master, like a human, for more information. And the more it’s capable to acquire the context and the data and make the right decision with minimal questions, the more intelligent and the more capable to know when to stop and go ask questions also defines its intelligence. So, it’s like, and it’s interesting. Like, DARPA sometimes, like, they’re really thinking ahead. I guess you’re familiar with that, like, they made an autonomous driving challenge, like, 20, 30 years ago, or maybe I’m exaggerating. So, 20 years before it actually went automated. So, I think the AutoML D3M at DARPA was, like, 10, 15 years ago. Kind of gives a hint that we’re 5 years ahead of just my bet, according to just, like, a few samples from that AI factory that you’re describing. And kind of, like, leads me to a question: so you mentioned the coding agents, I think, are in charge of, you know, developing the features, etc, and then the part of the automation and the governance, like, you also want to automate that. How does it look? What does good look like for that part of the verification?

[00:14:30] Nirmal: Yeah. I think that’s a really good question, and it’s a good problem to solve. Right? So, now we have AI agents who can write your code end-to-end. Right? Let’s talk about, like, governance and security and policies. We also want to automate it. But we need to be very, very careful in terms of, like, how you’re automating. Right? And before you automate, you need to decide what problem you are automating. So, in other words, as I was saying earlier regarding the governance threshold, every business, every domain, every problem doesn’t require the same level of governance. Right? The problem that you are solving – the governance level can be completely different for that. So, let’s take an example. If you are using an agentic chatbot – just question and answer – and the human, making some judgment and decision based on that, the governance level can be lower for that, right? So, even if the bot is making some mistakes, that’s fine. Nobody’s life is at stake, and we are not losing any money. Right? Let’s talk about the healthcare systems, right, or the supply chain systems, which make, like, millions of dollars every day. You need to make sure the governance level is, like, very strict and very high for that, right? So, we need to define the definition of governance first. And how do we define the definition of governance? It’s based on, like, what problem we are solving. And that goes back to: once we have that governance defined, then we go into the automation, right? How do you want to automate? And based on the governance and the thresholds and the type of the problem, you might be able to automate, like, non-critical tasks, fully automated end-to-end. And even though that automation is making some mistakes, we can come back, we can see the reporting, and we can adjust and change. Right? Let’s talk about, like, highly critical tier one systems where we are starting from scratch. So, I wanna take it very slow before I go into fully agentic mode, right? And what you’re asking is, like, automating everything – like governance and security and all of those things. And then, you are having the self-healing systems and all of that stuff. So, if you wanna build it, I would start with start it slow. Start with the POC, MVP. Figure out one use case, just one use case. We don’t need to build the governance for the whole enterprise at once. Right? It doesn’t work, and nobody’s gonna be successful if they try to do it all at once. Right? So, pick up a few use cases, one use case, and then figure out the governance for that. Figure out the automation for that. Try to make it fully automated. Right? Once you have that one use case fully automated, you will learn there are so many things similar in the other use cases. Why? Because the way you are implementing the AI, the way you are interacting with the AI agent, even though the problem is different, the infrastructure, the software architecture, is pretty much similar. You will easily find more than 60% similarity in these, like the back-end software, how they work, and how these authentic workflows work. Right? So, once you are successful with one use case, you are in a really good state already. Then just pick up the second use case and keep on building use case by use case, and eventually, you will learn. Try to go to fully end-to-end agentic workflows. And then, as we were discussing earlier, it’s like, make sure you have the threshold for all the automation based on your problem, what threshold you wanna define, make sure you have the feedback loop for your systems and continuously improving. So, it’s a gradual process until we achieve full autonomy and, like, fully agentic systems end-to-end. Yeah.

[00:18:32] Itamar: By the way, who do you think is you? Like, is it the developer, the tech lead, the director, the VP, the CTO? Like, I guess, like, would we expect each one of them to expect something different?

[00:18:46] Nirmal: Yes. I think everyone has their own roles and responsibilities. So, it’s the whole organization. It’s not just one person, right? We need to define the company-level governance and the policies, right? And if you are in a bigger company, you might already have, like, a specific team for the governance, and you might already have a security team who will take care of the security and everything, right, so you don’t need to worry about that. If you are in a smaller organization, you might need to think about everything, right? You might have, like, 10 engineers, and all of those 10 engineers directly report to the CTO. Then that’s a group of, like, engineers, including the CTO, business; they all have to work together to make sure we are moving in the right direction. So, I don’t think this is just a software problem, right? This is not just a coding problem. Right? This is a problem for the whole organization, and everyone has their own role in it. And when everyone comes together and works together, then we make the real business impact. If just an engineer or just the engineering department is working on it and nobody is, like, talking to them, like, okay, what is the business use case? Which one do we wanna prioritize? What is the most impactful thing? How does the security work? How does the company-level governance work? All of that stuff. They will build something. They will have a cool MVP POC. The demo will be really cool. Everyone will clap, but I don’t think they are gonna take the business to the next level.

[00:20:23] Nnenna: I think that segues perfectly into this discussion around culture, really. Like, in an organization, you have said that culture is the real control layer. So, what does building that culture from top to bottom really look like to do exactly what you just explained?

[00:20:41] Nirmal: Yeah. I think what I explained just now, it’s really important to build that from top to bottom, right? Culture is a huge topic. We can have a different podcast, maybe. We can talk for an hour. But just to quickly summarize it, I have seen, in many places, where we have few engineers; they are, like, very excited, coming up with their own ideas and building some authentic tools and solutions and demoing them and trying to figure out what do we do? And I have seen the organization where leadership and even the board of director missing the AI literacy, right? Again, AI literacy is really, really important when we talk about the culture for AI in this era, right? I think it’s really important for board members to understand, at least at a high level, and have a proper AI education so they are not just talking about business; they are not just talking about dollars. Those things are important, right, but they need to have AI literacy. They need to have at least one technical person in the board seat, right? Most of the boards that we have nowadays are lacking that technical capability, right? So, as we are moving really, really fast in this AI era, your leadership team, your C-suite, your engineering leaders are making decisions every day. Things are changing so fast. In those situations, if your board is lacking AI literacy, that’s a problem to fix. Right? So, that’s at the board level.

[00:22:31] Nnenna: I’d like to know, with that problem, what would end up happening without the educational layer at that level?

[00:22:39] Nirmal: So, if you don’t have the education layer, how is the board gonna approve the budget for AI? For them, it’s just a number. Like, your C-suite will say, like, “Okay. I need $20 million in the next year.” If the board doesn’t have AI literacy, okay, you need $20 million, but how are you gonna use that $20 million? Right? And what is the ROI? Right? ROI is a big topic, right, and it’s different for AI. I think if the board doesn’t, the traditional ROI is different, and getting the outcome from AI and making the business impact and getting the real ROI is different. Sometimes, for enterprise level, the ROI you don’t see in a couple of months that required multiple years. Right?

[00:23:25] Nnenna: Right.

[00:23:26] Nirmal: Yeah. So it’s really important to know what decisions the board need to make and why they are making those decisions and why they are approving those budgets; they need to do their homework. Right? So, I will give you an analysis example. If you don’t have manufacturing experience and you are sitting in a board seat, will you approve a $10 million budget if you’ve never worked in manufacturing? You won’t. Right? So, how can we expect someone to approve a $10 million who doesn’t know anything about AI at the technical level?

[00:24:03] Nnenna: Right.

[00:24:04] Itamar: So, would you say that board members and executives in general, they should go do hands-on developing, using AI, or whatever, all the jobs that they used to do once upon a time, like, do a little bit of maybe one year hands-on, because it’s the new world out there?

[00:24:25] Nirmal: I don’t think the hands-on is required for every tool and every technology. Right? But I do think they need to understand what is an LLM, what is large language model, what is small language model, what is happening in the frontier LLM industry, what is happening in the open source, right? Why should we choose open source? Like, why do we choose Anthropic versus OpenAI? Right? And what are the different kinds of tools out there? Right? They should try those tools at least once in a while for their own use, right? So, at least they need to have a basic understanding of all the tooling, what is happening recently, and also, going a little bit into the technology, but I don’t expect them to, like, be hands-on every day because at their level, it’s their job as the governance. Their level is not for executing it.

[00:25:19] Nnenna: Yeah. This reminds me of a CTO I know of, like, an analytics firm, and he wanted to introduce AI to the engineering organization. But, culturally, you know, they weren’t as receptive to it as he wanted them to be in order to, like, move fast on, like, the cutting edge. And when you’re thinking about competition, something that you’ve brought up. So, he decided to lead more by example by diving really deep into, like, agentic engineering, tinkering just like, you know, who he really is at heart, which is a developer at the end of the day. But he was able to do that, integrate different tools, upskill as much as possible, and then show those results to his team, which then laid a bit of a cultural foundation, leading by example to begin introducing these tools into the system, and yeah.

[00:26:16] Nirmal: Yeah. Yeah. So, I do expect, like, decipher examples from, like, CTO, director, or VP level, but not from the board level. So, what you just said is, like, really good. Like, you need to become that example instead of just telling them, go ahead and do it.

[00:26:32] Nnenna: Which reminds me, Itamar?

[00:26:34] Itamar: Yeah. So, yeah, I have to admit here, like, confession. As a CEO, I think I do, like, average at least one PR. I’m probably, like, more on two PRs a day, but yeah, like, I think, first of all, my background is completely, like, software development. But also, at Qodo, we do AI code review and code governance tools. Like, we are selling to developers and empowering developers. So, it feels like I have to, and I enjoy it. I have to, and enjoy it, at the same time, do dogfooding. Of course, I don’t take, like, core features. I think it’ll be a mistake, but it’s really, really awesome to have the opportunity to be hands-on, being part of this revolution, not only with the leading product, but also, like, with your own hands. And my experience is what we just talked about. Like, it’s one thing to go and read, like, Anthropic and OpenAI literature or so, or use it yourself. It does bring some, like, wisdom. When I say wisdom, I mean, like, what’s the difference between intelligence and wisdom? In my opinion, it’s the experience. And sometimes a hard question in that area. So, like, when do I trust AI or not? It’s hard to read, although it’s useful to read, but experience really helps with that.

[00:27:56] Nirmal: Yeah. Yeah. And, also, for example, like, even at my level, for the last couple of weeks, I’m, like, using fully agentic code writing and reviews and everything, right? And per week, I’m opening around 90-plus PRs.

[00:28:16] Itamar: Amazing. Amazing.

[00:28:19] Nirmal: The other thing I wanna say, as we are talking about the culture, organization don’t become trustworthy because of policies, right? What I think is, like, they become trustworthy because uncertainty is rewarded instead of being hidden, right? That’s very important because we want to reward the people who are experimenting, who are solving an ambiguous problem using AI LLMs, right, instead of just keeping on looking at the result. Because in the industry, all the engines are already under pressure. Like, okay, you just do it and show me. But that’s not how it works. Like, you have to reward people even though they did something, they learned something, but they failed. That’s how they learn and grow.

[00:29:04] Itamar: Yeah. By the way, we talked about 90 PRs a week. We have a lot of statistics. This is really good. And do you think, like, PR is a good unit now? So, in the past, today, and in the future, for developer productivity? Or I’ll even say something naughty for how good as an engineer or how good as an organization, right? Yeah. I hope it’s an okay question to ask.

[00:29:34] Nirmal: It’s a good question. Yeah. I think, first of all, I don’t think it’s a good metric. In my opinion, even before AI in 2020, I don’t think it was a good metric. I don’t think it’s a good metric now. Just one metric. Right? But it’s a good metric to increase the adoption, right? If you are facing a problem where you have an AI adoption problem within your engineering organization, it’s a good metric to start with. Right? So, you can track PRs, see how many people are, like, how many, whether your PR count goes up or not, because you have all of these tools and technologies. That’s good to start, so you can have some kind of enforcement, and the people who are not very excited and shying away still get involved in it, right? But once that happens, you should stop that immediately and immediately move to the impact and outcome. Right? No matter whether you are opening 3 PRs versus 100 PRs in a week, show me the impact. What is the impact? Right? What impact did you make? Like, is this moving any critical KPIs or OKRs within the company? Are we saving some cost? Are we making more money? So, that’s the main measure. And also, if I talk about the engineering metrics, I don’t believe any one metric can give you the right answer, right? The way I think is, like, you have to combine multiple metrics. So, you can get, like, PR count, the PR quality, how many times the engineer is reverting the change, or how does the road roadmap initiatives looks like. Are we finishing on time, or not finishing? So, all of those bunch of things, when I look at everything, should paint the right picture for one engineer.

[00:31:29] Itamar: Yeah. That’s really great. I agree with you. And speaking of which, like, code quality: so 90 PRs, assuming that you have half the amount of issues per line of code versus manually writing. I’m doing, like, a favor here. Correct me if I’m wrong. So, if you were in 3 PRs in the past and now 90, but the code is double better. Like, you might have still, like, introduced 10x more issues or technical debt, etc. I’m taking you as an example, and also the numbers are an example. Love to hear, like, how do you think about that? How do you measure that? How do you protect from that? How do we govern that, etc?

[00:32:11] Nirmal: Yeah. So, the 90-plus PR, the example which I gave, is not for the tier one system. Right? So, it’s for the tier three system, which is not affecting it if something breaks on production; if it is down for 5 minutes, we are good with that, right? So, that’s not a problem. And that’s why I was saying earlier, like, we have to define the governance for every problem at every level. And based on that, you can decide how fast you can move. Right? So, maybe tier three, tier four, I can be fully agentic. Maybe tier two, 50%. Let’s say 60%, 50% if you are very early. For a tier one system, you need to be super careful and should be, like, less than 50% automation, and then you keep iterating, and with the feedback loop, you are improving. Right? So, my example for the 90% is, like, for a tier-three system. And what I do is I’m using over the weekend or after work, I just sit for half an hour, one hour. I’m doing a brainstorming session with the tool. Right? I define all the design, have some back-and-forth like, hey, what does the latency look like? Is it gonna affect any latency? Is this a good solution? Review this design as a principal engineer, things like that, right? So, after a back-and-forth and my own, like, domain experience and subject matter expertise and what I know about the supply chain and all of that, I’m feeding all of that information. So, it’s not just like I don’t know anything about the system, and I’m just talking to AI. It doesn’t work that way. You need to have the knowledge of the system, and you need to know about the business. Right?

[00:33:49] Itamar: Yeah.

[00:33:50] Nirmal: Then it becomes magic with AI. So, I’m doing all of that. And within, like, half an hour, one hour, based on the problem, I say, like, “Okay, go ahead and start working on it.” And then there will be a parent session, and the parent session will spin up multiple chain sessions, and it will keep working in the back end in the cloud, right? And then I have the automated code reviews, right, which are taking care of, like, most of the things, most of the mistakes, edge cases. So, it runs automated code reviews. It watches the CICD pipeline automatically, and if there are any issues failure in the CICD, it fixes them automatically. I was facing issues. Now we have, I have, like, hundreds of PR. Like, I don’t have time to review and keep on pushing on production. And then once I push one change, the next change says, like, okay. You need to rebase this and run everything again. It’s like, no, I’m not gonna do it for every PR one by one. So, I created an automation for every PR session. It’s like, whenever you should automatically track if you need to rebase, rebase it automatically and do all the other stuffs CICD and what I just talked about so I don’t need to click manually in each and every PR, right?

[00:35:03] Nnenna: Wait, where do you apply that automation? Because I actually need to steal that. I’m running into the same roadblocks.

[00:35:10] Nirmal: Yeah. So, this is within the tooling that I’m using, right? The AI tooling provides that agentic workflow, and you can create an automation within it. So, I can just create my automation. Like, when this happens, do this, and it will automatically trigger and pick it up.

[00:35:29] Nnenna: So, I could probably set that up in Codex, I’m assuming. I’ve been using that for automation scheduling.

[00:35:34] Nirmal: Yeah. It’s based on what tool you are using. There are, like, a bunch of tools in the market. I’m sure you can set it up in Claude, Codex, and others, like Devin or Cursor. Yeah.

[00:35:44] Nnenna: So, we’ll probably have to wrap up soon, but I have a couple questions for you. This whole workflow, like, breakdown, you went into a lot of detail here. And I know that that’s how you approach work, but what do you think that means for, I guess, the future of software engineers, the type of mental model that they should have in this era of AI?

[00:36:07] Nirmal: I think the mental model is going back to basics. Right? Making sure engineer should have a strong fundamental computer science background. That is still needed. Right? I think the problem that I’m seeing nowadays is, like, people get very excited about the AI tooling. They are less focused on the design, architecture, and scaling part of it, and they just, like, type the problem in the chat, and you get an answer, and the code is ready, right? But who will think about scaling? Right? Have you thought about, like, your architecture? Is this the right architecture? Did you have a back-and-forth with the AI tooling, whatever you are using? Right? Did you ask questions like, “Hey, what about latency? Am I building the low-latency software?” If you need to integrate with any third-party software, are you building in a way where it should be plug-and-play? Right? And did you think about the number of requests? Right? Can you serve, like, 1 million requests in one minute? Is that possible with that solution that you built? So, like, so many things still require the computer engineering mindset, and that’s why I think the fundamentals that we have are still very important. Yes, the coding became easy, but we have seen that from last 20 years, like, we don’t write, like, what do you call it? I’m missing the term. We don’t write the assembly code now, right? Very few people write the assembly code. We used to use the assembly, then we moved to C++, and then Java, PHP, Python – all the latest technologies came up, and we started using so many different frameworks, and we had so many frameworks in the market, and that made our coding really easy. Yes, AI generates everything, but you still need to understand that when it breaks, who is gonna fix it. If your AI agent is not able to try its root cause analysis, we still need smart people, strong engineers who understand how it works, and they should be able to fix it, right? So, I will give you an example just to close with. I know we are on time, but I was solving a problem where something was breaking on production, working with multiple people, trying to figure out what happened. I used all the AI tools, couldn’t figure out what happened, and the AI tool couldn’t give me the answer. Then finally, I had to call a person who had that knowledge from Many ER. That person immediately joined the meeting, and he said, “Here’s the problem. Go ahead and fix it.” So, we spent two hours, even using AI and all the tools, and we couldn’t figure out the problem. The person who had the organizational knowledge and all the historical knowledge was able to fix it immediately.

[00:38:55] Nnenna: I would love for Itamar to help close. That is the perfect segue. I’ll let you take it, Itamar.

[00:39:03] Itamar: Yeah. So, I definitely think that, you know, there is the framework of data becoming information, becoming knowledge, becoming intelligent. And then what’s the step to wisdom? I think, like, that intelligent creature, they experience over time, and they create tribal knowledge. In a development organization, right, we have those senior developers that are capable to learn from experience and create that tribal knowledge – the scars from the good points and also the wins that eventually, you know, like, they know they have that knowledge that they know to point to the right context and the right place. I have a feeling that there is a path. I’m not saying, like, this year that we kind of codify that in the same way to how a senior developer would do that. I’m not saying, like, taking, like, an AI factory or, you know, AI system and, like, in 5 minutes understanding the entire codebase or 5 hours. But maybe the AI system of the future is actually, like, learning that tribe of knowledge over time, maybe even two years. And eventually, that person we don’t wanna take that person’s job, and I think the AI system will not. But eventually, if that person leaves, that’s a big problem for a company.

[00:40:28] Nirmal: That’s a big problem. That’s a huge problem for the company. Yeah.

[00:40:32] Itamar: Yeah. And that’s why there’s an opportunity here. This, I think, will be a major point that gonna be discussed in 2027, 2028: how AI could help us with that tribal knowledge. So, it was a great…

[00:40:43] Nirmal: I 100% agree with that, and that’s the problem I am already seeing. It’s not only in 2027. I’m already seeing that problem. Right? It’s the start of history. We have started seeing the effects of AI and just relying on AI already, right? What you say is 100% agreed. I hope the LLMs, these models, will become smarter and smarter. Right? So, they start learning what you just explained now. And the main problem I want the leaders to start focusing on is, like, start thinking about your organizational knowledge. We still have so much knowledge in people’s heads. It’s not written anywhere. We still require so much context for AI, which is not in documentation and not in your codebase. And that’s a huge gap when we talk about context.

[00:41:40] Nnenna: I completely agree. And thank you so much for spending time with us and having these, like, super interesting discussions about, like, the work that you’ve done, the problems that you’re solving, and your contributions in your career as an engineering leader, TEDx speaker, and Forbes. Where can everyone find you if they want to look deeper into what you’ve done and what you’re currently working on?

[00:42:04] Nirmal: Yeah. I’m very active on LinkedIn, so you can find me easily on LinkedIn. My my LinkedIn user is Nirmal, last name, Jingar. So, it’s very easy to find me. And I regularly post about governance, agents, security, and different talks. So, please follow me on LinkedIn.

[00:42:25] Nnenna: Amazing. Will do. Thank you so much.

[00:42:27] Itamar: Will do. Thank you.

[00:42:29] Nirmal: Yeah. Thank you so much, Itamar and Nnenna. It was great talking to you.

[00:42:34] Outro: If today’s conversation challenged how you think about AI and code quality, that’s the point. At Qodo, we believe that independent, context-aware code review with rules as guardrails is how engineering teams maintain standards at scale. If you’re leading an enterprise team and want to see how intelligent AI code review can reinforce governance, visibility, and accountability in your workflow, visit qodo.ai to learn how we help teams turn AI productivity into production-ready quality. And if you enjoyed this episode, subscribe, share it with your engineering leadership circle, and leave us a review. Until next time, keep human in the loop. And keep shipping.