Your Ops Team Pays the Price for AI Adoption

[00:00:01] Zichuan Xiong: I see a totally different way of doing software. After 20 years, I see that excitement again to really think, oh, I’m part of this. No one defined this. I’m creating a new way of doing software.

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

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

[00:00:26] Itamar Friedman: And I’m Itamar Friedman, the co-founder and CEO of Qodo.

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

[00:00:34] Nnenna Ndukwe: Every episode, we have candid engineering-first conversations about code quality and building a culture that enables trust and governance in the era of AI software development. Before we jump in, follow or subscribe to The Agentic Review wherever you’re listening – Spotify, podcasts or YouTube so that you don’t miss the next conversation.

[00:00:53] Itamar Friedman: Awesome. Today, we’re joined by Zichuan Xiong, Global Head of AIOps at ThoughtWorks. Zichuan leads AI-powered operations across managed services with a focus on agentic AIOps, SRE modernization, and control systems that enterprises need to run AI safety and production.

[00:01:13] Nnenna Ndukwe: His recent work examines why enterprise agents fail without the right context, why operations must adapt to probabilistic systems, and how AI-driven development is shifting cost and complexity downstream. Zichuan, welcome to the show.

[00:01:29] Zichuan Xiong: Thank you, guys.

[00:01:30] Itamar Friedman: I love the right context. Can you share more about how do you feel about your job? What did we miss, and how is that related to context?

[00:01:39] Zichuan Xiong: Oh right. So, at Thoughtworks, I’m leading the AI for operations solutions. So, I have a measures business at Thoughtworks, like, usually, our workers are building solutions and software. We run the business. We run the software deployed to our customers’ environments. So, the context is so important because for every operations decision, you have to think about the context. No matter if it is a change, or it is a PR to deploy or an incident resolution. Right? So, we have to think about where those incidents are located in the environment, the past, all the history you made in the past. Right? So, those are really the contexts we consume every time we make a decision. So, that’s why AIOps is not only like AI agents; people are talking about agents. But an agent includes multiple things. Right? Model harnesses. And also, the context is so important. So, that’s why I wrote a lot of things about context. Why context is so important for AI operations. So, that’s really my topic about context and all the other things. I love AI. I love building AI solutions, solving our customers’ real problems. It’s just like changing my work, changing our business in the last like 2, 3 years.

[00:03:06] Nnenna Ndukwe: Awesome.

[00:03:07] Itamar Friedman: Awesome. So, before we dive into context. Because I think I do agree with you that context is everything. Or maybe let’s say it’s the foundation, right? Like, we can have the best reasoning model there is, but if there is no access to the right context, and what is the right context is, like, a really important item to dive into. But before we do that, do you feel that AI has made your job better, worse or maybe related to that? Do you feel like AI is really moving the needle? I know maybe everyone says yes, but maybe you have a different opinion. Did it make, for example, co-generation or software development cheaper and better? Or in your case, did it make operations, SRE work, etc., better and easier? Or actually push, like, the build downstream, and everything becomes more complicated?

[00:04:00] Zichuan Xiong: So, I took this role about two years back. That was when agentic wasn’t really a new thing; it was a new thing two years back. But I still remember the first use case we did was using a large language model to answer a question about an SOP document. So, this is talking about when support engineers try to figure out how to reserve a ticket; they can just use AI to ask questions about a certain document. You can imagine that was really straightforward, a simple RAG-type application. So, we basically built out that application as our first use case. Now, fast forward like 2 years, our use cases covered about 25 to 35 different agents doing so many different other things. But at the work level, efficiency level, for sure, we definitely see the benefit in everything. But I think the most important thing AI changes in the industry is not the efficiency gain. I don’t think it’s really the efficiency gain. It changed the definition of the job entirely. Every time we try to sell an AI solution for an operation where I have to prepare a case for that change, right, and the clients were asking about the savings, the efficiency gain, everything to prove there is a case to deploy, I realized, like, after 2 years, when we were preparing those cases, I realized the cost, if you consider the entire cost, a job-per-job cost, yes, we’re saving like 80% of the time of preparing that document or resolving that ticket. But entirely, if you consider SDLC as a whole, I feel like it’s not supposed to be there yet. They’re, like, saving 80% of the cost is not; it’s shifting cost to the downstream. And this is exactly what I see across our enterprise clients. AI really empowers those non-developer background professionals to write code and also commit to whatever the environment is, right? It can be the production environment; it can be the pre-production environment, but it increases the cost of the operations to review those changes. So, I have a case, like, one customer has, in the last 8 months, had about 1.5 times AI adoption, but the cost is 10 times. So, that’s really what I see from the market because I don’t think the entire software development, the context – all the SDLC, the practices – they are not ready for this change. They don’t have a standard way of using AI or best practices for using AI. And then you have all the people that jump in and try to commit code, and they’re so excited about those new techniques, which is a good thing. But I don’t think, at the operations level, it creates a sustainable model to maintain or manage that cost. So, that will include all the model costs, you know, people are using those pre-built models to do simple stuff, all the way to the technical debt, context explosion, everything into the operation. So, that’s why I wouldn’t. When I worked with Qodo 2 years ago, and Qodo was doing the AI review, now I realized it’s not about review. Review is okay. Yes, we can do some, but if you think of this, before you review, all the costs have happened already, right? Like, you already made that cost. Reviews just last, like, gate, but before the gate, the cost is there. So, if you ask me, yes, it definitely changed everything. It changed my work. It changed our business. But if you say, does it change the cost, like, reduce the cost? No, it doesn’t reduce the cost. It increases the cost of the whole SDLC. Because SDLC is not only about building the code; it’s also about all the things. It just, like, shifts the cost to the downstream, which is operations. That’s what I see from the market.

[00:08:36] Itamar Friedman: But that’s super interesting. If I kind of recap what you’re saying, it’s that we need to look at the SDLC as a whole and maybe use Amdahl’s Law. You know, it’s a very simple one: if you want to check the change in a system, you need to multiply the change you made in a component with the overall impact or part of the component in the system, and then, basically, what I hear from you is that sometimes we increase, let’s say, 2x, maybe 10x the cost on some things like AI, and then expect a 10x or 100x on the entire system. But it doesn’t work like that because that 10x investment was doing 10x or even more, but only on a small component. One of the things that I might be taking from here is that in order to really see our investment pay off, maybe we need to reimagine the SDLC, and how to reimagine could be like many different things. It could be taking it as is and trying to automate everything possible. It could be the old vision that we have of shifting everything left. Like, you’re saying, when I’m reviewing, it’s already a lot of the cost is there. Maybe the review and the planning already need to be very coupled with AI and automation. So, when I’m coming to review, it’s basically already auto-approved or so. Or maybe we can reimagine everything. And I’d love to hear your thoughts about it. And maybe it’s even a good time to connect to context because I think everything here connects to the context that we started with. Right?

[00:10:14] Zichuan Xiong: Fireworks is always seen as the leader, the thought leader in changing SDLCs all the way back to continuous delivery, CSD, that kind of stuff, but if you really think about SDLC, to me, I think in the market there are two versions of the SDLC. One is step by step. There is, at last, like you plan something, you build something, you design something, you test, and you ship, and you operate, and you just circle back. This is when people think about SDLC. That’s version one. The second version is really a CSCD type of continuous delivery. You have dab, you have all spinning, right? But I feel like either you have the linear bigger loop, or you have 2 loops that are spinning. I realized the one thing: if the cost is shifting to the right, the value is shifting to the right because the right side is more expensive and valuable. So, in either of these two versions, the operation is on the right because, visually, people would think, “Oh, let’s build stuff. Let’s talk about it and push to the operations team.” Or, in the DevOps context, you have Dev, you have Ops. Ops is still on the right-hand side. Then that changed the people and the mentality because I think human beings, like, when you think about one thing, the second thing is the second thing. So, that visual, I think, I keep saying this to my folks at Thoughtworks. I said, “If operation is so important, then why’d you visually put the operation on the last, the second side, the far end of the diagram you’re drawing, right? So, that’s why I think how you change the SDLC at the theory level, we have to really think about how we communicate that SDLC. Because changing how people think about this is really… I think operations should have better, like, branding because we’re talking about more risk and cost and shift to the right to the operations side. Then, from a branding perspective, we should put operations first. Let me give you some examples. Every time I try to pitch my customers about operations, the AI operation, I say everything you design is in the document, in the code, everything, but there is a source of truth that shouldn’t really be in the document; it should be in your operation, your runtime environment. You learn something from the runtime because, think about the enterprise software delivery. In a lot of cases, I think 80% of the time, you have to consider what’s going on today because we’re not a startup company if you’re enterprise users, right, stakeholders; you are not like starting from something like fresh and new. You have to take whatever you have built in the last 20, 25 years to start from there, and that is the operational context. So, when we design something, you’re not really designing for something zero; like, you design something from the operational context. Start from there. So, that’s where the ‘how’ I try to shift people’s mindset about: oh, you’re not really starting from the new design. You start from understanding the context. But that context’s only source of truth is in the system, in the runtime. But operational context gives you that really great source of truth and gives you a good decision to make good decision. That’s why you should do some service discovery first in your existing operational context. So, that’s why I think I really shift, of course, open it up. There are a lot of practice changes. How do you design software, how you build, how you test, of course, at the technology level, techniques or skill set level, there’s a new way of thinking. But fundamentally, if you want to shift the mentality, you always want to start from the operations, which is understanding the operational context. And that’s how you change the game. I’m not saying, like, I don’t like your story in the market, and people say, “Oh, SDLC is dead.” No, SDLC is not dead. The SDLC is like a life cycle of a group of people like us trying to solve some problem in some context through technology. It can be AI; it can be software. But SDLC is there. We are shaping our SDLC so that every single one of us believes there is something there and that we should change the behavior. We’re not saying SDLC is dead. SDLC is still there, but we have our obligation, our right, to redefine it, reshape it or change it how people think. So, this is really my point. Operations right now is so important. So, we shouldn’t take operations as the last step or far-right practice. We do. We always think about operations first. Then think about the other stuff. That’s how I redefine SDLC. I’m not saying SDLC is dead; it’s still there, but we need to reshape it.

[00:15:42] Nnenna Ndukwe: I’m very curious to see a visual of what you are describing here because I wanted to process, you know, a new mental model, a new approach, and I’m like very open to these different ideas or perspectives and your focus on how the most powerful – it sounds like you’re saying the most powerful or valuable context is in ops. I’m wondering, do organizations have that, or do they have the data?

[00:16:06] Zichuan Xiong: No.

[00:16:07] Nnenna Ndukwe: Okay.

[00:16:08] Zichuan Xiong: Yeah. So, that’s a really interesting topic because my past is really, oh, I do AI. I want to apply. If you think of my journey, I thought it was like leading AI, right? So, I started from, like, building AI solutions for business cases, like solving business problems. I realized AI is shifting that cost model. That’s really the reason why I joined the Meta services business: I want to learn how, really, the operations have changed because of AI. So, I joined the managed services business and building solutions for IT operations, and then I realized, oh, context is so important. But what’s the problem with context? Because you keep finding your next problem to solve. Then I realized, oh, context is a problem. Why? Context is a problem. Then I realized that there are a few things, right? So, because if you look at the enterprise data or landscape – all the things we built in the past 30 years – you were trying enterprise data infrastructure or data analytics infrastructure and trying to solve only one thing. It’s about how you make humans, together with deterministic systems, make a decision through analytics, through data. No matter how we did it right in the past, like, starting from the EDW all the way to distributing data mesh, data lakes, whatever things we’re building, the goal hasn’t really changed, which is to help humans and also those, like, deterministic systems to access data to make a decision. But starting from 2 years, that foundation should serve a new goal, which is allowing the AI, the non-deterministic system, to access data. Then, if you look at the gap there, how AI is consuming data is totally different to how humans are consuming data or how any deterministic system consumes data. So, that’s what I see in the market. The fundamental context and also the foundation of the data access layer is not ready for AI consumption. So, that context cannot be generated because, in a lot of cases, the systems are processing, like, structured data. Because AI is not only consuming structured data, but also unstructured data. If you go to unstructured data, there is a lot of tacit knowledge, tribal knowledge that’s in people’s minds, because when I look at the document, I get it because I have 20 years of experience to interpret that thing. I never write it down for other people. I know what that means to me, the terminology. So, in the recent blogs, I wrote a lot of things about semantic drift. So, semantic drift is really talking about when you have two domains, when AI is consuming the two concepts in two domains, because AI is really about rewarding fluency. To reward fluency, they have to find a common pattern between two things and try to compress. So, for example, when you say the customer in a sales context, it’s very different to when I say customer in the support context. But in the eyes of AI, it would just compress the two meanings; it’s just customer. But actually, in one domain context, it means different things. When you’re making decisions, even, like, the deeper decisions. If you confuse the two things together, you will make a mistake. And that mistake cannot be caught by any of the LLM tracing. If you look at tracing, it will look fine. Like, it green-lights everything. But at the semantic level, you already made that mistake. So, that’s when I see this market: I see there is a big gap: we have to change or transform the data foundation to make data ready for AI consumption. So, that’s really what I see here: the problems. Because you change the problem together, operations is so important. Context is so important. But why can or cannot we have good context? Because all the data infrastructure, everything, is not sufficient to provide the context. Then the next big question is there, focusing on transforming the data context data access layer to be AI-ready. So, that’s how you see the market – the shifting. So, that’s why I believe it’s a big, huge change out there.

[00:20:44] Itamar Friedman: It might be a simplifying recap of what you said, and let me know if it makes sense and that we can continue from there. Basically, you’re saying that to really make a big difference in our SDLC, we need to think operational first. And that mostly means bringing the context of operations across the SDLC. When you’re doing planning, when you’re implementing, when you’re reviewing, hopefully the review is already lean because you did it correctly to begin with. And then basically the challenge is: how do you codify? How do you create that context? And that context is basically two parts. One, the things that are happening in the operation that are already collecting data. And we need to transform it in a way that’s fit for agents. That’s human agent interaction. And the other parts exist in our minds already. But we need to codify them. And if my summary is 90% correct, I’d love to hear, like, how do you think we should codify the human knowledge, the tribal knowledge, into something agents can use.

[00:21:47] Zichuan Xiong: So, you see my logic chain is shifting between AI is so important that it will create operational problems. So, operation is important; the operation is important. So, the dependency is the context. Context is important; context is important. Then data readiness is not there. Right? We have to codify a lot of things about reading the human brain. Then all the way to harness engineering, context engineering. Because harness engineering is really about agent equals to model plus harnesses. Everything beyond the model is the harness. Right? Then when I think about this, when I define the harnesses and also harness engineers. Two parts: one is the feedforward and not the feedback, right, controllers. Feedforwards are really the preview, like, knowledge. Feedbacks are really the controllers; they’re really, like, rule-based. You already know this has happened, this happened, and when this happens, do this. It’s more of a very logical, machine-driven type of decision-making. But the hardest part is the feedforward portal is building an AI review tool. AI review tool is like when something happens, you review it. That’s really the feedback system. You provide feedback to something. But the hardest part is, like, feedforward, which is translating those tribal knowledge into predefined guardrails, like the guidelines, everything and really embed that into how people are doing things. I think, to me, to focus on the feedforward control or harness, when you ask me how to codify the process, right? I think codifying is one thing. You always have a dedicated team to do that. Because AI has no intention to do that. This is really that humans should do things and try to go to the SDLC, go to how people do things, try to see the user backend. From the user backend, there should be something there, and try to extract the human knowledge into something. Explain this to the ambassador, like, between the human and the AI and translate that into AI language. So, that’s really what I think about this at the enterprise level. You have to create a new role. Imagine the past, before Agile, everything you had. I still remember we had a DBA role. Think about the DBA role. We created a role to facilitate a technology, and that technology was the DB, right? Database. You need somebody to talk about something to help do all the administration stuff for the DB. But nobody is talking about the DBA role today, right? It’s been 15 years. I rarely see people or hear people talk about their role. So, humans are creating roles to adapt to technology; then why not? We’re not, like, creating a new role for the new AI, which is coding, feeding the human knowledge into the human AI. So, we should create that. I don’t know how you’d call that role; like, we should create a term.

[00:25:00] Itamar Friedman: Software Factory Engineer. SFE. What about that?

[00:25:04] Zichuan Xiong: So, that’s really the first role I’m thinking of, translating the input and output, right? Input will be all the human patterns because humans are really good at identifying patterns. Right? Talk to people. Socialize it. It can be a social engineering type of practice. You always need to identify the pattern. That’s exactly what I do. I theorize. Like, I see how people do things, how people see the logs. But while a senior engineer can see logs in about 30 minutes, compared to junior folks, they will just see logs for 8 hours. They have no clue what’s going on. Why is that? You have to be super, like, passionate about that problem, about why there is a human distance, right; there’s entry-level versus senior-level, why there is a distance. Your goal is try, to, you know, close the gap by using AI to reach some level of this similar, like, level. So, whatever that role is doing, we need to create that kind of role. So, that’s number one. Number two role, I’m thinking because of DevOps, all the tooling, SDLC tooling, whatever, you have a new concept of developer experience. Remember, like, DX, that was super popular, I think 5 years back – Backstage, Spotify’s new best practices. Everything is about the API platform, the catalog, everything. But what does DX mean today? If AI is taking over development, then to me, DX is really about facilitating humans with AI. Facilitate that experience. I don’t know how to call it. But that’s a new way of thinking, because the feedback controller is machine-driven. That’s okay. You don’t need to care too much about that. So, like, for example, I really love the one that Qodo, something like a feature, like, a very small thing: you have the emojis they put there. But to me, that’s a massaging kind of, like, experience. Oh, you’re okay, I’m here. That kind of experience is so interesting in those smaller things. Even like, in Slack, you have some AI taking care of something. You have the eyeball, like, the looking eyebrow emoji that says, “Oh, I love that.” So, that should be part of the new generation of the DX we’re talking about. So, when you ask me how to do this, I think we need to create new roles because our existing roles are shifting a lot in the past, like, one year. We should create some new roles to give a place for humans to play something, focus on DX, focus on extracting those human knowledge and prepare that knowledge for the AI. Try to close the gap. So, that’s really how I see it: we shouldn’t have the previous because humans always create a role for a new type of technology. You’re calling one role, but you’re also creating a new role.

[00:28:06] Itamar Friedman: Completely. I think, like, by the way, what you’re describing is that we’re moving from a multiplayer game of humans alone and being empowered by AI tools into a multiplayer game of humans and AI. In that case, like, it does meaningfully change that user interface, the developer experience and then the small things on how we communicate, how do we interact, how do we give acknowledgement to each other, how do we share context and so on. For example, about that, one of the things that we believe in Qodo is that the context for agents and the context for humans needs to be coupled. For example, if you have, like, a software graph with a lot of information that can be useful for agents, you need, on top of it, let’s say, documentation that is coupled – that is, more human representation that, for agents, maybe not to optimize. Agents want more; they can digest more. It needs to be structured in a way that agents can have really high accuracy. But humans still need to have some level of documentation to some extent that needs to be, let’s say, coupled. So, I think the multiplayer game, all across the board of the SDLC, from how do we respect each other, acknowledge each other, review each other, share knowledge, share context, approve tasks and so on, and that’s, like, a really exciting world to reimagine in this new multiplayer game.

[00:29:33] Zichuan Xiong: So, I’ll give you some interesting stories because I’ve been staying with ours a long time, so I know those early-stage stories. So, you know, ours is really into Agile, like, leading Agile and also DevOps; about at least like 15 years back, we had a new tool. We had a tool, I think, between 2009 and 2012; it’s called Mingo. So, Mingo is about – it’s like before Jira. So, we use Mingo software to do things; it’s outside of this.

[00:30:10] Itamar Friedman: Not Bugzilla?

[00:30:11] Zichuan Xiong: No, you’re right. So, that wasn’t like super successful in the commercial way, but in the software way, really, I loved it.

[00:30:18] Itamar Friedman: Right.

[00:30:19] Zichuan Xiong: There was a very interesting feature. It’s called Murmur. M-u-r-m-u-r. Murmur. Because we believe that software is a social engineering practice. It’s a social game because you socialize a group of people all sitting in one room, do something, iterations, sprint by sprint. You achieve something like a sports game. Then we use the terminology: Murmur. You can add people. And I was like, really, before Twitter, yes, I guess. Or learn something from a computer. You add somebody on a card, like, a story card; you talk about it. So, that was our innovation: if we don’t think the software is a production line, like step by step, we think, oh, it’s multiplayer games, it’s an RPG game for building software; then we build those small tools to enhance that experience. Fast forward 20 years to now, we need a new way of thinking. When people think about SDLC, people always think of SD as a pipeline. It’s a production line, right? Linear approach. Of course, you had some feedback, go back, loop, or you draw some loops there, but that’s okay. But back to your point, I think now we’re talking about people because the role is redefined. Are you a product manager, or are you a product owner, or are you a developer? Are you a tester? With AI, everyone can contribute. It’s a multiplayer game. But we need to find a new way of creating the feature, like Murmur or any emoji you’re using in your code or platform. On those smaller things that give us a golden state, a golden age of recreating something at the fundamental level, at the human level, how we design something between AI and humans, right? That makes me excited because we’re entering a new phase. That’s the excitement. When I joined Thoughtworks, that was at the peak time of the agile movement and everything. I see a totally different way of doing software. After 20 years, I see that excitement again to really think, oh, I’m part of this. No one defined this. I’m not following those people’s rules. I’m creating a new way of doing software, right? That, of course, we make mistakes. We humans, make mistakes. But that is the sense of exploring a new thing. Because think of the PR, even the pull request, right? But who defined that pull request? That was those people. Because in the DevOps context, continuous delivery context, you have a pull, you have a push. But who designed the pull and push? But right now we should change; we should jump outside of the predefined terminology and the term PR. Because I keep saying to you, like, my folks in Qodo, I say, “Don’t limit yourself to PR because PR is a predefined practice. But what if the whole concept has changed?” The PR concept has changed. Then you have to think outside the box. So, that’s really how I see things happening.

[00:33:31] Itamar Friedman: Completely. By the way, we released, not too long ago, Qodo 3.0. We’re opening it to more and more people, where we believe Qodo is serving the work package instead of serving the PR. The PR is still there, and it will take us a little bit of time to get beyond it. But now it’s becoming not the right unit to work on. I think, like, what we’re trying to achieve is work. We’re trying to get features done, get infrastructure upgrades; we’re trying to push new capability features. These are usually work packages, and today at Qodo, we believe that review needs to be in work packages. Yes, it could be that the work package might be broken into small PRs, but when I’m coming to review the work package, I want to review it as a whole. I want the AI to look at every diff; I want the AI to work on every PR. I want the AI to look at the entire work package and give me all that in a digestible way, and I’ll decide how to then dive deeper. So, we’re totally with you. That’s one notion. And the second thing is what you said in the beginning is that the pull request needs to become clean already. It needs to be clean. Like, all the work needs to be done up front. So, the other thing that we – sorry for the shameless plug – and Qodo really believe is connecting Qodo already to the coding agent and working in tandem along the way. And when you open a PR you already have, or you open a work package pull request, and then you already have a report of everything that was reviewed and verified, and you can just continue on.

[00:35:04] Nnenna Ndukwe: I was going to ask you about hot takes, and I think you’ve already started to talk about that with the PR and having to reimagine things and probably rename, redefine what it is that we’re doing.

[00:35:16] Zichuan Xiong: So, that’s exactly why I have multiple different backgrounds. I was the first, one of the first designers at Thoughtworks, bringing wireframing as a technique into software development. When I joined Thoughtworks, I didn’t think the UI was important. UX is important. It’s really because, in the past, our context was like building those hardcore technology for large enterprises. But you see how the Internet, the mobile Internet, is changing things, and you bring those products, digital products, to consumers, right? So, the context shifted. Then I quickly shift my role, like all the way from the designer to a front-end developer, like, shift because you keep shifting your roles, right? I’m shaping, reshaping my role in my context. I always jump outside the box because if my context is different, I need to do something else. People are really shaped by the tools and processes, right? Because if you are, when I was building the design, I was helping people change the solution, change the tooling from those web page-focused design tools to more mobile design tools, shifting. For example, Figma. Figma was the one thing, right? But now Figma is not the thing. It’s just hard; it’s a struggle. So, don’t let the tool. Because tools define; a tool is a byproduct of a process. You have the process, you have a role, you have a tool. Those are really the byproducts. But the process is a byproduct of a context. If the industry context is changing, the whole process will be changed. All the processes and all the tooling are changed. All the terminology. Terminology is also not a byproduct of communicating the tool and process better with human beings. You always need to think outside of existing. What’s the predefined concept that we have right now? Because PR is related to DevOps, and DevOps is related to the enterprise or a distributed system, like all the microservices, everything has to run continuously. There is the enterprise context: when software is needed for what? But now, it’s different if AI is changing the enterprise context; if AI is shifting the cost to the operations, all the practices. I’m not saying I would kill all the practices and also tooling and concept one time. No. It’s about the questioning. You always need to question what’s the context. We create that process and tooling and also concept. And are we still using that tooling, concept and process by assuming that context hasn’t changed or pretending the context hasn’t changed? So, that’s how you evolve things. As a person, as the practitioner, you always need to challenge your assumptions because the whole context changes so fast.

[00:38:19] Nnenna Ndukwe: I think what we’ve accomplished so far in the ecosystem is I’ve seen the progression of focusing on one slice or stage of the SDLC and throwing AI into it. And that is progress. And so now that we’re doing that, we’re expanding that across the SDLC. It’s like a perfect time to actually reimagine and go back to the fundamentals and look at the building blocks and begin to redefine things. But we definitely started off not doing that, but it’s coming to a point where I think we can introduce that conversation, invite that conversation more. And another thing to mention is that I love what both of you all said about this software factory engineer. Like, who’s going to be the person that’s going to spend that time actually closing the gap between what I say on stages a lot is: we really want agents to mirror, agents and tools around it to mirror the expertise, the tribal knowledge of a senior or principal engineer. And it’s like for an agent or agents to mirror a human, there’s so many more nuances there. And those nuances are what you’re talking about with that context of how does a junior have such a difference in understanding as a senior? All of that needs to be codified. Like, those are all the things we need to discover, define and be able to disseminate that information. Because all of us can get better at agentic engineering.

[00:39:46] Zichuan Xiong: You really make me think because I’m thinking about nuances. That term. If you look at it, in the past 20 years, like all the agile lean movement, everything started with Toyota lean manufacturing, the production, right? That’s our source of imagination; even Tomra, you’re using factory. To me, when I hear the factory, it keeps reminding me of the Toyota type of lean production system. But nuances are new things because I’m thinking about nuance. Lean production is all about killing waste. So, waste is something very important. We have to identify the waste and kill it. But nuances are different, and nuance is a new way of thinking. It’s not waste. It’s a really new, valuable thing. Because waste is about let’s repeat – because production is worried about all the deterministic processes, everything, and try to find the differences or any delays, misalignments; that’s a waste. Let’s kill it. Use Kanban to visualize those wastes of thinking about work-in-progress (WIP), that kind of stuff. But nuance is new magic. It’s a waste to monetize because that has a conical low. Like, you say something, I say something. That’s nuance. But that nuance of that difference is a waste. In the worldview of the Toyota lean manufacturing context, it’s a waste. But in the AI world, it’s different. The nuances are so important. You have to understand the nuances and deliver those nuances to the AI. Let the AI figure out the nuances. It’s not a bad thing; it’s a great thing. So, I love those nuances as a new way because I always have my knowledge map to connect dots, but that makes me think the nuances are a new way of thinking about the waste because in the past, nuances, yeah.

[00:41:40] Itamar Friedman: If I try to take a lot of what we talked about in this, like, amazing episode, that there’s a few major differences between a hardware factory and a software factory. It’s software. And hardware is maybe all about determinism, being deterministic, understanding how you can change a pipeline to make it more efficient. But in the software factory, it’s a lot about codifying the nuances, the tribal knowledge continuously, because that changes because the software is very connected to the world. It’s like, in the world, it’s changing, and the software is changing, so the nuances are learning and changing. So, it’s all about codifying the tribal knowledge, the nuances and making that accessible, feedforward and feedbackward to the agents and to the humans in one multiplayer game that considers those, like, new types of players.

[00:42:37] Zichuan Xiong: That’s great.

[00:42:38] Itamar Friedman: Maybe it’s a good note to finish. I think like we had so much fun that we are a little bit over time, and it was really amazing. Thank you so much.

[00:42:45] Nnenna Ndukwe: We would love to know where listeners can find your research, your writing? Where are you most active?

[00:42:52] Zichuan Xiong: No. LinkedIn and also thoughtworks.com. You can just search. Yeah. I wrote a lot of stuff about AI.

[00:42:58] Nnenna Ndukwe: Amazing. Thank you. Thank you for listening as well. So, if this conversation gave you something very useful to take back to your team, please follow or subscribe to The Agentic Review again on Spotify podcasts or YouTube and share the episode with someone who’s responsible for the quality and reliability of AI. Thank you so much, Zichuan and amazing conversation.

[00:43:21] Zichuan Xiong: No problem. Thank you for inviting me.

[00:43:24] 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.