Beyond the PR Bottleneck: Scaling Engineering Velocity with AI Governance

[00:00:01] Itamar: Okay. Let’s go. Welcome to the Agentic Review, the podcast where we explore what good code and good software development really means in the age of AI. I’m Itamar Friedman, the CEO and cofounder of Kodo.

[00:00:17] Nnenna: And I’m Nenna Ndukwe, developer relations lead. In every episode, we sit down with engineering leaders and AI pioneers to talk about governance, accountability, and what it really takes to scale engineering velocity with AI.

[00:00:31] Itamar: And today, we’re joined by Paul Duvall. Please let me know, like, I said it correctly.

[00:00:37] Paul: Yeah. Yeah. Absolutely. Yeah. I think

[00:00:40] Itamar: Jolt award-winning author who literally wrote the textbook of continuous integration, cofounded and sold, uh, the sorry.

[00:00:52] Nnenna: Stellargent?

[00:00:53] Paul: Stellargent. Yeah. Yeah. Okay.

[00:00:55] Itamar: Cofounded and sold Stellargent to bring DevOps discipline to AWS at enterprise scale and spent three years as a director of AWS leading DevSecOps and security innovation.

[00:01:09] Nnenna: Paul is now founder of Redacted Ventures where he’s doing what he’s always done, taking the engineering practices that make software predictable and reliable and rebuilding them from a world where AI agents are writing the code. His argument, without the right practices in place, you’re not shipping faster. You’re just generating problems faster.

[00:01:31] Itamar: So without further ado, Paul, welcome to the show. Tell us a little bit more about yourself, whatever we missed in our introduction.

[00:01:39] Paul: Oh, sure. Yeah. Uh, well, thanks a lot for having me, first of all. Um, Yeah. I I guess started in software engineering, uh, many decades ago now. Um, I actually got in the in the industry in an interesting way. I, uh, I started at, uh, EDS, which is part of HP, uh, enterprise, uh, now. I still believe that exists. Um, and I I guess, started in the mail room. Uh, I had a couple years of college at that point, and, um, and so I started to see opportunities to automate some things in in the work I was doing in the mail room, like, the directories and things like that. And then I and then I, uh, I started getting interested in how to, you know, program and and and use software to do that. Uh, ended up finishing my degree many years later, but it was kinda after I decided my career. And so, um, you know, became a software engineer at EDS. I was there for, like, seven years or so. And I always got interested in the what I always refer to as the behind the scenes of software development. So not just, you know, what we’re doing for end customers, but also what we’re doing for each other as software engineers and and building, uh, things like frameworks and, you know, the sort of the platform on on on which on on which the software runs. And one of the things I was noticing is that, um, it was just taking a long time to get the software out to users. And in in my case, it actually took two years. It was a huge global system medical logistics system across the world. And, um, and so I was involved in installation at one of the first, um, logistics centers. And it was one of those moments. And that that got me into things like, you know, the daily build and and continuous integration and and things that kinda make our jobs as software engineers better. Um, that, you know, fast forward a little bit, but that led me to ultimately write a book on continuous integration. I was doing that with with customers, uh, and then that led to to starting Stelligent, um, with with my cofounder in in 2008. And then yeah. Yeah. We built things up, uh, from there, um, and, um, ended up selling the company in 2017 and then reselling actually, uh, about eighteen months later.

[00:04:01] Itamar: Amazing. And

[00:04:02] Paul: as excuse me. As you mentioned, yeah, joining AWS. And so, uh, I got interested in the cloud in the early days around 2008, 2009, and we started doing that for customers.

[00:04:13] Nnenna: Good timing with, uh, cloud for sure.

[00:04:17] Paul: Hell, yeah. Yep.

[00:04:18] Nnenna: Um, I’ve been following your work for some time now, and I have, uh, I’ve cited some of your work in some talks that I’ve given and some you know, whether it’s in person at conferences or, like, webinars online. And, you know, you you’re always putting out a lot of things that are really helping the technical community, especially right now in this agentic AI era. So I would love to know, um, what really drives you to keep sharing, you know, with the blog that you have and and different things like that.

[00:04:49] Paul: Yeah. Um, I think it kinda goes back to the what I was talking about before where I think in some ways because of how I got into the industry, I always felt like, uh, different. Right? I I wasn’t the I wasn’t the person that got the computer science degree at first and then, you know, start doing I actually start doing it just to solve my own problems. And then it was yeah. I felt like it was, like, difficult to learn some of this. Um, and I I felt like a lot of the material that I would be reading, like, oh, you could’ve said this such much more simple. You know, or or you’re, you know, kinda either talking down or or making assumptions. And so, I mean, that led me to just wanting wanting to share and share in a way, hopefully, that resonate with others that might have been in a similar situation where they’re trying to learn Um, and so I’m I’m I always try to keep that in mind in terms of, like, you know, there are many other people out there that, you know, might not know what, you know, I’m I’m doing or what I’m interested in or what I’m seeing with customers and hopefully connecting with them, um, in that way and and sharing. Um, the other thing is my my dad was a teacher and my I have a brother and sister that are teachers. And so it’s sort of the I I would say it’s kind of the teacher mindset as well.

[00:06:10] Nnenna: That’s great for, um, I feel like Itamar and I, we we kind of do similar things with being public facing. Like, Itamar, you’re you’re CEO and cofounder. You you don’t necessarily have to be putting out content sharing with the world, going to speak at conferences, you know, but you choose to. Um, so it seems like there’s some similarities. What do you what do you think, uh, Etomar?

[00:06:32] Itamar: I love the concept, uh, that Paul you mentioned about, like, simplifying things and making things more more accessible. By the way, with respect to continuous integration, sometimes, like, I’m thinking, uh, are we exaggerating saying, um, autonomous agentic quality workflow, um, you know, etcetera, instead of, okay, this is continuous integration. Um, next level of next, you know, the next level of it, we can increase the automation, but there’s so much in common of everything we try to do with continuous integration. Uh, the the the guardrail, the automation, there’s they’re there, and now we can, you know, make it even better. It’s that simple. So, yeah, like, I love spreading spreading that word sometime.

[00:07:20] Paul: Yeah. I think that, like, now I I think more than ever, you know, like, some of the the CICD practices are are even more important. You know, in part because we’re able to build, uh, we’re able to generate code faster. You know, in some cases, many many times faster. So I think you have to have those those checks in place. Um, and you have to even get it even earlier than maybe we traditionally did. You have to get it into the the development process itself, um, such that you get as you’re generating the code, that you’re getting notified and and maybe even having those fixes applied, uh, at that point in time. You you still wanna have the, you know, sort of the clean machine, the later on down the line. Uh, my perspective on on this is, like, just many many different when you when you look at it as a value stream, where you’re going from idea to all the way to production and beyond, you know, observability and things like that. All along the way that you’re building in these checks that are appropriate for that particular, you know, change that’s being made and hopefully contextual and things like that. But that, uh, and and that might be one of the things that’s changing is or, uh, or needs to change is having those just getting that high fidelity, um, feedback, uh, all along the way, um, as as you’re building software.

[00:08:51] Nnenna: Do you think that’s part of the the best practices or the right practices that you’re, um, like, championing right now with this AI era for software development. Since, uh, AI code, there’s been such a huge surge, um, with how much we can easily generate.

[00:09:07] Paul: Right. Yeah. And, yeah, I mean, one of the one of the things that it’s highlighting is is actually something that existed before AI or before, uh, agentic engineering, whatever whatever you wanna call it. Um, and that is that, um, you know, when you start to optimize, you know, local optimization, what have you, all you’re ultimately doing is is moving the the bottleneck, you know, just to a different location. And so one of the things you’re you’re seeing a lot of what customers are talking about, people are talking about is that, you know, their PR queues are getting bigger and bigger. Right? Um, and so this was the the whole PR approach of waiting for someone to review it has always been a problem. Right? But it’s just highlighted, uh, much more. Uh, in in many ways, that’s the thing about, uh, AI is this it’s kinda amplifying. It it will amplify good practices so we can do some really, really important things at scale, but it’s also gonna amplify some of the bad practice or if you don’t have those practices in place. And that’s that’s one of the things I’m seeing is people all of a sudden are noticing that they have these huge, uh, PRQs and they don’t know what to do with them.

[00:10:18] Itamar: I think I think, uh, what you’re implying and I love I love that. Let me know what you think of that. Uh, you know, there’s the, uh, AMDA law, like, you have a system, and if you improve 20% of it, 100 you you approved 100%, 20% of it. You still just improved 20% of it, and you didn’t necessarily break the entire flow. So if we, at this point, took coding, let’s say, 30% of the SDLC and improved it by 80%. Okay? Uh, we still didn’t improve more than 30%, the entire SDLC, and, actually, you just moved up bottleneck to to the next phase. What what it implies that we didn’t yet break the SDLC as it is. And actually, like and and then, for example, the importance of automating the PR and the pull request process even more important, but I’m wondering, like, if we take CI CD to the next level, if that maybe is the opportunity to break this SDLC. Like, if we manage to create automation, AI assistant and AI automation and agentic AI, all that in the CICD part, um, then maybe we don’t need to, uh, review anymore human human review, and then we break the SDLC, uh, to to something completely new and c 10 x software development to not 30%, uh, better. What what do you think about that notion?

[00:11:54] Paul: Yeah. 100%. And I think, you know, I I would say the, you know, improving, uh, CICD, you know, and in some ways the way it should be done. But, you know, we’re able to do things like have some of those deterministic checks that we’ve always had. Right? We can use AI to actually help create some of these checks as well and and verify and so forth. Um, and then also pushing it earlier into the what I still think it’s a part of CICD, kinda your point, but pushing it into the develop you know, the builder, uh, in this case, generating code life cycle. And then also pushing it beyond into observability where we’re using AI to to both, uh, notice patterns, you know, and that’s, again, where another case where, uh, you know, in in the past, we we would have to have these sort of static kinda checks to look at, um, you know, what’s going on in production. But if you can start to notice patterns and then, uh, identify those patterns and bring that back into, you know, sort of the builder life cycle and and ensure that you’re you’re making those fixes, um, as a part of the, um, um, you know, what developers are doing when they’re generating code. Um, but as I was talking about before, it’s like, yeah, across the whole life cycle, if you can start to put these checks and, um, and not just static checks, but leverage AI, uh, for the you know, some people talk about that the the fact that it’s non deterministic is an issue, which I agree it is. But there’s actually opportunity there as well. Things that you would never have noticed, uh, before when you were running, you know, say, SAC analysis or, uh, you know, software, uh, application security testing or things like that. Taking it

[00:13:45] Itamar: like, double taking on the CICD across the SOC, like, I think traditionally, we’re talking about from the point of the PR, the request, merge request, and to to the right. And I’m I’m actually thinking maybe the way to break the SDLC is that if we take the CICD into, like, shift left, Um, and, like like, once upon a time, I think we didn’t do that because, for example, CICD might be expensive, take take a long time, etcetera. But now, like, the agentic, you know, coding is is working, and maybe the the integration into the ICD, like, it’s more natural. Like, I can call some of the verification loops, some of the, uh, the automation loops, etcetera, as I as the coding is finishing a certain part of the of the coding or making different change. And then the different changes that are verifiable or and then maybe we that overall make the change of, uh, shift up. And, like, that that meant I don’t know. Does it sounds like practical for you or you feel like a lot of the, you know, the methodologies for CICD are just meant to be after I finish the task?

[00:14:57] Paul: I I no. Actually, I don’t think they they were ever meant to be that way. But to your point, that’s the way they’re usually I would say that’s how people usually think of them. Right? And so it’s it’s not just the tooling, it’s also the practices that are involved in this that that I think, uh, benefit from, um, you know, CICD in terms of, like, you know, committing code often and doing things like trunk based development and automated tests and and that sort and and embedding the rules. The the opportunity, and this is, I think, what you’re hitting on is that we can there’s a lot more that we can do earlier in the process such that it’s not and in some ways, it it gets well, in most ways, it gets much more expensive the further you go you go down, uh, down the line. Right? And so if if you can find those checks or sorry. Find those, um, those issues early on, it’s gonna be ultimately less expensive.

[00:15:49] Nnenna: Speaking of rules, this is perfect topic that I really wanted us to discuss. Um, so you wrote blog posts, and you have, uh, you have GitHub repos of all centering centralized rules. And, um, there’s this theme in the work that you do about thinking about agentic engineering or or the practical ways, like, at scale, which is, as you know, is is completely different than just, like, a solo dev trying to optimize their harness or whatever to, you know, produce and ship the best code. Um, I would love to hear more about how the centralized rules came into play because And and what would also help is on on our side in the CODA world, if, like, HMR, you could explain how we’re approaching the rule system, um, because there’s definitely there’s alignment here on the need for it and, um, you know, how that could look in practice. So, um, who should who should go first? I’m trying to think.

[00:16:46] Paul: I I can I can go first? Yeah. That’s right. Um, so I’ll I’ll tell you a little bit about the motivation behind it. And so, um, you know, I’ve I’ve been doing AI for for coding. We’ll call it agentic engineering now. Um, but I’ve been doing that since, I think, February 2023. So basically, when chat g p t had had had come out two months later. And I was doing it for side projects and things like that. And so I was it was one of those things where I was like, notice started to notice some of these patterns. And I got, you know, I started using cursor, I think, in summer twenty twenty four. Got started using Windsurf and and again, seeing these kinda repeated patterns as the technology, um, evolved and improved. And, um, and then got into to Cloud Code probably in May so it’s been a year since I’ve been using Cloud Code, which is, like, forever now, you know. Right. So, like, concerning, I think it came out in March. But, um, and so I created this repository you kinda alluding to it called AI development patterns, where I was just, uh, noticing the things I was doing. I was noticing what also what other people were talking about. And in some ways, it was just like almost like a cheat sheet for myself to remind me, you know. And and I and I put it out there and let some people know about it, and it definitely caught on a bit. And so I think right now, it’s around 27 patterns. Uh, I’ve got, like, some experimental patterns as well in there. And so there were a couple of them that I was using a lot, and that was codified rules. Um, and then I was also starting to see the need for centralized rules, um, because, you know, as you start to work, you know, as a team, as you alluded to, is that, you know, if if it’s not just a solo developer, as a team, people need to, um, you know, kind of agree upon, okay, what do we what what are our roles? And so there’s some ways of doing that. Um, one is, you know, putting that in CloudMD, uh, or, you know, agents MD, just generically speaking. Um, but then there’s only so much that I I know you know this. I’m just sort of just describing the the thinking through this.

[00:19:02] Itamar: This is great.

[00:19:03] Paul: But, um, and, uh, and and seeing that, you know, that there’s a there’s a limit to how much you could put in there. And so I just wanted to have, like, the things that I didn’t wanna one of one of the things I was noticing is I would have to remind the agent every time about how I like to write code. Right? And so in that case, uh, I think skills had just it might have just come out, uh, at that point with, you know, using progressive disclosure. And so, um, that’s what I ultimately built with centralized rules is something that uses progressive disclosure, which means that, you know, it’s only going to essentially indexes, if you will, and it’s going to look at the description of something. And then if it’s relevant to your prompt, um, that you’re providing to the agent, then it’s gonna go and and look in more detail. And so I I built this such that it would detect, like, my, uh, my programming, you know, like, the language I’m using, the cloud provider, you know, basically my whole environment, even my architecture and things like that. And, um, and so, uh, it it was just a way to, uh, in many ways, almost like augment my agents MD or my cloud MD, uh, in in my case, um, such that, uh, I didn’t have to remember to remind the agent, uh, every single time. Now it’s still it’s, you know, it’s it’s still not necessarily gonna figure it out every time. I have tests and and things like that to try to verify that it’s going to be accurate in what it finds. But, you know, it’s it’s AI, so it’s not gonna always find it in every every single case. And that’s where, you know, uh, things like and we can get into this later, but, like, things like embedding the guardrails as code and actually fixing it right there while you’re coding. And and that’s sort of a a separate topic. I’m not sure if I actually have a pattern, uh, that I’ve actually documented on that yet, but there needs to be because it’s something I’m doing quite a bit now.

[00:21:04] Itamar: I love I love this triple. Like, I think skills and rules, they go well together. Um, basically, you know, how my, perhaps, best practices are in skills or how I want to do things and, uh, also programmatically, like, give give some some sorry. Programmatic. Give a give a semantic definition on which rules I want to apply when. And then there there are the rules themselves. Okay. This is what I want to be checked and what I want to apply in each one of the cases that are that are relevant. The problem, like you mentioned, I I believe, is that the agents the coding agents do not see rules as pure rule. It’s not like they promise that they they compile the code, uh, or or or their output according to the rules, and then there’s need, like, a a third wheel here, uh, rather there are tests or some program that goes rule by rule and verify that it’s correct or or group of rules or policy, etcetera. At at least, you know, for for real world heavy duty software, like, you know, if I’m doing, like, a POV project, I guess that that double of duet of skills and and rules where skills, like, how I want to do things and pointing on the rules and rules, what I want to verify is good enough. And once, like, I want to increase the level of automation, I want to make sure I’m not hurting, um, the the real real world heavy duty software. Like, there’s need to be something either more deterministic or more rigorous on on verifying verifying that rule. That that’s that’s how how how I think, like, what I hear you’re saying.

[00:22:47] Paul: Right? 100%. Yep. And maybe I’ll talk about that approach that I’m using to try to make it a little more deterministic. And that is, um, so I have rules in place that, uh, you know, look at things like, uh, whether sign commits or prompt injection or, uh, psychomac you know, like code smells, like, uh, psychomac complexity, long method, long, uh, large class, things like that. And it’s, uh, at this point, it’s not a ton of them, um, and there is a bit there’s it’s a tiny bit of latency at this point, and that’s the sort of the you know, you you always have to balance the feedback with the fidelity. Um, but, um, so it it has these rules. This is not LLMs. These are rules that are in place. It notices it it it analyzes the code after, like, using a a clogged, um, a hook clogged code hook, and it will then discover any of those issues, right, with the code. And not not only will it, uh, notice them. So I I think oftentimes you see with these types of tools is they’ll they’ll, uh, notice the problem and then tell you that there’s a problem. Right? And, you know, so it’s very passive. And so in this case, it’s we’re right we’re at the code, and so then it uses the LLM, uses the agent to actually, uh, fix those changes and then verify that the fix is in place. Now, of course, there’s an issue with that, and that is you’re using the same agent or same LLM to do that. So there’s there’s some potential ways you could get around that. Right now, it’s it’s good for me in terms of what I’m doing and, um, but, um, that’s that’s one of the ways that I’m trying to to get it at the source of the problem so that, again, doesn’t go downstream, and then you have to find out about these problems later on when they’re, you know, ostensibly more, uh, expensive to fix.

[00:24:52] Itamar: You remind me of, uh, kind of, like, uh, let’s say, a theorem that two rational players with the same information, the same tools should get to the same conclusion. Right? Um, so I think, like, part of, uh, how to deal with that is that these two actors, um, intentionally, they have different incentive because they’re supposed to provide different user experience and and and and different, you know, type of, uh, judgment. So when when you’re a coding agent, basically, for example, getting things done is part of what you’re supposed to do. Like, have you ever tried to use Cloud Code and tell you, sorry. I I can’t do that. They’re like, oh, here are two options to finish. They always want to please. But if you are using, like, a code integrity, code quality review tool, it’s it’s actually using different context, different prompting, different, like, uh, mechanism and and tools behind it to actually do the other way around of, uh, hey. Should should I stop it?

[00:26:00] Paul: Mhmm. And

[00:26:00] Itamar: it’s annoying when it’s stopping when it shouldn’t and vice versa. Like, a coding, like, shouldn’t stop me where like, ever because I just wanna get getting things done. So, definitely, like, I see this, like, conflict come come a lot, like, in discussions I am taking part of. Like, two different model same model, same agent, same context should have the same result. Why you would like, giving it to fix itself invalidates, so it’s, like, obviously not the right thing. Although I I actually argue even about that, but I think, like, I I agree. Like, it needs to maybe similar models, but because you do want to use foundation model, but actually giving it different context, different different workflow, different prompting, like, does does change the the behavior and and and the conclusion. That that’s at least, like, uh, what we experience.

[00:26:50] Paul: Yeah. I mean, that’s, you know, something potentially simple in that case, um, would be, like, using sub agents or something like that in different contexts, um, as well. It wouldn’t necessarily meet the sort of high fidelity that I might wanna have. But, um, yeah, it’s it’s sort of something I’m trying to find it find those issues earlier on. So that’s it’s one approach, I guess.

[00:27:18] Nnenna: Well, speaking about that, like, what with the customers or or prospects that you’re speaking to with, you know, the work you’re doing at Redacted Ventures, where do you feel like most, uh, teams are at right now with the current state in terms of their, uh, maybe their level of experience or fear or apprehension, desire for, you know, more enablement education for, um, AI, you know, assisted software development?

[00:27:45] Paul: Yeah. I mean, I think a lot of the stuff we’ve been talking about, it might be, uh, something that they’ll be experiencing maybe a little bit later on.

[00:27:55] Nnenna: You

[00:27:55] Paul: know? So I I would say, at least the interactions with with customers I’ve had is it’s usually at the sort of the POC and we’re we’re trying this out kinda stage. Um, and and so, you know, some of it is, you know, educating them on the possibilities around this in terms of the, you know, that you can, uh, and one of the things I really encourage, um, anyone that’s, um, new to this is, you know, if you’re gonna be thinking about, okay, yeah, we wanna use cloud code or, you know, codex or whatever. You know, Genentech engineering is that, uh, you you don’t wanna put that in in production day one. Right? You really wanna do some experimentation, do some POCs, get those guardrails in place. Um, it’s, uh, it’s definitely a much, much different world. Uh, Yeah. This is a this is a step change, uh, times 50. I don’t know. Like, um, it’s, um, there’s there’s a lot to learn. Um, and so, uh, but at the same time, I I definitely encourage people to experiment around it just as long as they’re doing it within, you know, the the right guardrails, security sandbox. There’s a there’s a lot that can go wrong with this. Um, and so, uh, that’s so you wanna give them the the encouragement to, like, explore and try new things out for sure, but just do it in an environment, uh, such that, uh, that they’re not gonna, you know, effectively hurt themselves or others around it.

[00:29:28] Nnenna: I’m anticipating that there will be more tools like that that maybe come out to help with that sandboxing in a way that, um, where more exploration, experimentation can happen safely as as folks are learning, um, how to leverage these tools and these, um, you know, AI, um, yeah, any type of AI dev tools for, uh, the all of the promises that were made about, you know, the developer productivity and and whatnot in this space. Yeah.

[00:30:00] Paul: Yeah. There’s a lot of interesting discussion. I mean, people are talking about I mean, start to get to really advance. This is almost like the opposite side of what we just talked about, and that is, you know, people talking about things like, you know, the dark factory. And it’s like, what does that look like? And, you know, um, and I just that’s where a lot of the stuff we talked about is so important. If if you’re getting to the point where, you know, you’re just writing the specs and then having, you know, these, you know, uh, personas and and things like that kinda spin up and, um, act like users. And you you have to have these checks in place, um, in order to to do this, especially if you’re, obviously, if you’re gonna be going into production as well.

[00:30:41] Nnenna: Agreed.

[00:30:43] Itamar: By the way, about sandboxing, I think it’s starting to get not only, like, tools are popping, like, mushrooms, but actually trying starting to get, uh, after the ring. They’re actually starting to get mature. I think, like, cloud announcements, like, in the last year, Google Next, for example, agent sandboxing. They’re, of course, like, leading, um, no no commercial here, no sponsorship, but modal, um, modal and Xenity and and, uh, like, a few other that, um, familiar either, like, giving you the sandbox or helping you to sandbox, etcetera. Even Cloudflare, I think, like, you’re are in this business. So I think, like, sandboxing is really critical. By the way, one thing I noticed about that sandboxing that it is kind of, like, more of external wrapper than underlying wrapper. Like like, for example, maybe it makes sense to have, like, a layer between the agent to the bash to the to the actual command rather, like, after the command where I said, like, not net not not stopping not only stopping networking, not only stopping, like, going outside the sandbox, but even what you run-in the sandbox. I might be exaggerating, but we’re seeing, like, this technology going wild, like, in in its intelligence. So maybe there is, like, a missing layer, and I and I that’s where I starting to see innovation, like, on that that layer that even before you run the command, not stopping you that you’re running it, and it will block its consequences. But

[00:32:13] Paul: so

[00:32:13] Itamar: that’s like I I think, like, it’s becoming really interesting that that area.

[00:32:17] Paul: Mhmm. It reminds me of the zero trust kind of, uh, approach. Right? With zero trust, it was always about, like, it the network you can’t rely on your network. Right? It’s kinda what you were just talking about. It’s like, okay. So they got the network isolation in the sandbox. And, yeah, there’s a lot of players in there. There’s a lot more to it. Um, and so, yeah, at the at the agent level of all the things you could and the things you could potentially do wrong that you’d even know. You know, you’re not you’re not, like, intentionally trying to cause any issues, same things. That sort of the mindset around zero trust is that there’s there’s different ways of of of there’s different, you know, ultimate threat vectors that you have to account for.

[00:32:58] Nnenna: There is this tool that’s, um, out there. Uh, it’s called hoop dot dev. I don’t know if you’ve heard of it before. Um, they’re under, like, a VC firm that is invested in in so many developer tools, including, like, Dynatrace. But it seems to be a layer that I don’t know if it’s exactly similar, but it is a layer for, um, any type of calls that you wanna make if you’re using an AI agent to talk to databases where there is any type of sensitive information or or or commands that could do something dangerous like deleting a table, uh, it just automatically blocks it. So it is that that it there there is a layer, I guess, um, and there’s, like so AI data masking, guardrails, and a few other features that I’ve seen them, um, come up with, and they’ve been pivoting hard in the past few months to focus on the fact that any developer at any point in an organization could want to, um, uh, have their agents build something or make a call directly, uh, inside of databases. How can we block that from happening, um, and deploy that in a way that where it’s super easy. So interesting stuff coming out there.

[00:34:17] Paul: Oh, yeah. Yeah. Like you’re saying, there’s there’s a lot of, uh, vendor development going on that, uh, yeah, hopefully will help alleviate some of these issues that that people can experience, especially when they’re not they’re not reviewing all the code necessarily. Right?

[00:34:31] Nnenna: Right. Exactly.

[00:34:33] Itamar: And what do you think about that? Like, I think you said publicly that we cannot review any anymore, like, every line of code. Right? Like, uh, what do you think about that? Like, is is that the new reality?

[00:34:44] Paul: Um, Yeah. I I already think it’s happening. I mean, I would say from my own experience, it’s it’s happening. I’m not reviewing every single line of code. What I’m trying to do though is is have the, you know, the policy, the checks, all the things that we were talking about earlier, uh, such that, um, I have a very high confidence, um, in and and, you know, and also using, like, things like, uh, progressive delivery practices like that, where you’re, you know, you’re deploying the code, you’re not necessarily releasing, uh, the the software yet. Um, and and you’re getting feedback all along the way, and you can use AI agents to do some of that. We were talking about personas and things like that. And so, um, I, again, I I I do think it’s it it requires a higher fidelity in terms of, um, you know, all the all the checks along that that pipeline, if you will, uh, or the or the value stream just in general, uh, in order to do something like that. Um, and, yeah, that’s one of the things I’m just personally trying to do in my own, uh, development and then help help customers think about that as well. Yeah. By

[00:35:54] Nnenna: the way, we can oh, yeah. Go ahead.

[00:35:56] Itamar: Did you see it coming? Uh, like, the fact that we’re going not to review any line of code, like, yes or no? Like, what what do you think, like, we’re, like, close to the horizon the next thing that is gonna break? Like, I don’t think, like, we said last year or two years ago not two years ago, maybe even not last year. We’re not reviewing every line of code. Like, what do you think, like, you’re gonna say, uh, uh, next year that gonna be a paradigm shift? And, uh, Nnenna also, what do you think?

[00:36:26] Paul: That’s a good question. Um, it was one of the things I saw coming, uh, for sure. Um, and in part, it was one of those things where I was like, you know, as an engineer, I was just noticing that I was doing it. Right? And, uh, and I felt like, well, it but one of the things I was always trying to do with myself and with customers is, like, you have to apply good engineering practices or this cannot work. That’s why, like, the vibe coding, you know, the you know, that that kind of thinking can be detrimental, at least in the way some people are applying that, uh, or how how do they how they think about that. But it wasn’t one of those things I really wanted to say. Uh, I did say it on a podcast. Uh, at that point, I think Boris had come out and said, uh, maybe maybe it was after that. Uh, and I I guess I Boris Chorney, the creator of Cloud Code, had mentioned something along these lines that at that anthropic, that’s that’s the situation that they’re in, uh, right now in terms of on the builder side of things. Um, he was actually indicating in in one of his, uh, conversations, uh, that they have the PR at least that’s what I inferred from the conversation was that they have the PR problem as well. Um, they’re they’re clearly able to get code out. But, um, he was talking about the he was focusing on from a productivity perspective, the amount of, you know, PRs they are able to create. Now, when I heard that, I was thinking, oh, man, that that’s that means there’s a bunch of people reviewing that.

[00:38:01] Itamar: Yeah.