Agentic DevOps: Transforming Software Delivery Beyond Traditional AI🎙️

The Code to Cloud podcast with host Kevin Evans. To continue the conversation, head over to codetocloud.io. Welcome to another episode of Code to Cloud.

I'm your host as always, Kevin Evans. And I am with my good friend today, Paul... Paul, I'm going to mess this up because I've just practiced it five times. DeVol?

DeVol, yeah. Yes. DeVol. DeVol, yeah.

Everyone's got their kryptonite and mine is people's last names. Paul, how's it going, man? Yeah, it's going great. Yeah, happy to be here.

Happy to talk about whatever we're going to talk about. Yeah, we're going to talk about stuff because that's pretty much the primary point of the show. But do you just want to quickly introduce yourself, tell folks what you do, how you got here a little bit, that kind of thing? Yeah.

So I started in software engineering, building pretty large systems. And I was, as a software engineer, I got kind of frustrated with the whole process of building, deploying, testing software. and it would take a long time for the software to get out to customers. And so this was one of those kind of aha moments that led to, well, could we shrink down the time between when you have an idea, when you get the software into production?

And so that led to things like daily build and things like continuous integration. And so I wrote a book probably, I think it's like almost 20 years ago now, called Continuous Integration. and then I started a company kind of to almost scratch my own itch, right? So it was called Stelligent and we focused on what became known as helping enterprises apply DevOps practices and ultimately on AWS specifically.

So we were doing kind of prior to using AWS only, We were in enterprises and basically embedding engineers along with them. And so built up that company and sold that in 2017. We helped a bunch of enterprise customers adopt these practices. I stayed on for a little bit with the acquirers.

And then I ultimately joined AWS in 2021. Stayed there for a little over three years. and then I had been using AI for coding like on the weekends and kind of side projects and things like that. It was another one of those things where I remember when I used EC2 back in I think 2008, 2009, it was like, you know, it was like just blew me away that you could, you know, provision a server, you know, that quickly.

And so it was the same kind of thing with AI. It's like, oh, this is going to change everything. And so I wanted to kind of focus on that and be an entrepreneur again. And so I started a company called Redacted Ventures, and we're helping customers adopt AI.

And so kind of mid-market to enterprise customers adopt AI. So I'm having a blast. I've been using - I have kind of gone through the whole thing, like ChatGPT and Cursor and Windsurf. And I've been using Cloud Code for the past 13 months, basically since it was GA, I think.

it was back in may of last year and so i i try to share uh you know while i'm learning that's just sort of my nature it's like as i'm learning something or you know working with customers or whatever um just you know sharing as much as i can in terms of what i'm learning so i'm kind of like i don't know building public sharing real time whatever uh and so yeah having a great time I recently started using Claude Code and it is literally the best thing since sliced bread. Like I've been using other agentic tools, right?

But it's simple, but very, very effective. Yeah, it is like that. We're at that next iteration, right? point of to your point when you first start using the cloud and you're like oh an ssh terminal right in my web browser or whatever right um it does feel like that now right like what do you want to build today so that's a really interesting path right so started up your own practice sold it off so like learning all the business stuff as well right around that and then going to work for a hyperscaler working there and now redacted again i i said to you last time i love that name redacted ventures right it's uh i mean it's one of the best best names i've heard on a long time for a company right um but yeah so published a book on ci continuous integration which was devops and this used to be a heated topic on the internet right like what is devops and people being called devops engineers right like personally i didn't care if they were called the devops engineer or not but people used to get a little bit you know tender about it right yes for sure so what is agentic devops paul in your mind what's your opinion on it yeah um i guess my overall take on this is that you really can't be as productive or effective using agentic coding tools without applying those kind of just good modern software engineering practices.

And so, you know, to me, like a lot of these DevOps, DevSecOps practices not only matter when it comes to agentic development, it's essentially crucial. You know, one of the things I'm seeing a lot about is people that are using these tools and they're talking about, oh, you know, I'm able to, you know, generate, you know, so many more PRs or, you know, PRs merge and things like that. Well, to me, what I'm seeing is that you're getting like more code being created. But then you have the reviews.

The reviews are going up as well. And so to me, what that means is like your lead time is not changing. All you're doing is just creating more inventory. And so from my perspective, like you have to incorporate like these, you know, these good modern software engineering practices.

So things like, you know, that you're running, tests with all your changes, that you're running static analysis and that you're automating your deployments. And then you have sort of the good practices themselves versus just the automation of this and the tooling. But you're committing code often. You're committing small batches.

If anything fails, you're finding out about that early on. One of the really I think one of the big opportunities that we have is with some of these, you know, people are calling this kind of harness engineering and things like that, where the actual harness, so for example, cloud code itself and all the tooling that you can incorporate into that, whether it's like hooks where you can run deterministic checks. And so there's just a lot more opportunity to find some of these changes maybe earlier on.

And to me, that's always been the goal of continuous integration, continuous delivery, and so on is always about getting really effective feedback earlier on. Like if we can shrink that, the time between when we either, you know, create a defect and when we actually find out about it, and more importantly, when we actually fix it. Like that's always been the goal. So tightening up those feedback loops and kind of creating a closed loop out of the whole process is, I think, essential.

And so to me, like these practices matter even more as we use the Gentic tool. I just don't see how we're going to get any of the massive productivity changes that are being talked about without applying these kind of practices into your development process. So, I mean, that's a really good point. I've never heard it being called harness engineering.

Is that what you said? Harness engineering? Yeah, I'm just talking specifically about the, like, you know, with codex or cloud code or whatever, like there's these ways that you can use the tool itself to then, you know, run deterministic checks. I mean, hooks are the most obvious example.

But, yeah, that there's a skill and practice around doing that now. And you're starting to, you know, it's almost like people talked about prompt engineering, context engineering. And so it's like, well, there's another layer on top of this because people talk about the models so much, the LLM, right? But what, you know, we talked about sort of the power of a tool like Cloud Code is actually all the tooling that they build around it.

Such that, you know, in my mind, you can find out about these problems even earlier, which is to me has always been the goal of all this. Yeah, I do that a lot. I get it. Before I even push it to the repo, I'm like, what can I automate locally?

So it saves on the PR review, right? And everything else. Because I think to your point, I think you've raised a really good point there. You 5x the developer or the engineer, right?

Doing, like you said, raising the PR requests or generating more code. but then your whole deployment process needs to be five times as like um five times the capacity in order to not slow down the production line right essentially um and are you seeing that are people thinking about that or are they just still relying on same old processes right people are thinking about it there's definitely people talking about it um but i i still see it as a problem because like I've seen when I've gone into a customer environment, you see kind of what they're measuring and they're measuring like, you know, just the amount they're able to produce.

It's like, I remember back in the day when we were helping certain organizations where like we'd go into, you know, some big enterprise and we would tend to, you know, maybe focus on one part of the organization, you know. So, you know, maybe we're talking to the infrastructure team. And so they're like, okay, we're going to containerize this. We're going to automate the whole process.

And everyone's happy, right? At least everyone you talking to at that point But what you not doing necessarily is looking at the whole value stream right Because what you might done is you just locally optimized You're like, oh, I can crank out containers all day long. But then if you look downstream a little bit, you find out it takes four days to update the DNS because it goes through whatever process it goes through. And you have to go through that maybe every single time or however it might work.

And so in some ways, like you're measuring the wrong problem. You're just optimizing what you can control, which I understand is sort of the idea behind that. But to me, I don't think that's changed that much, but it's going to have to. And that is people have to look at the entire value stream.

They have to look at every part of it from defining the specifications to building the software to testing, deploying, and getting into production. And what's more, one of the actually really cool things that you're able to do with AI now is like, well, you could definitely do some of this before, but in production, right? So you can do telemetry and things like that. But what's kind of interesting is you can start to collect that data and then bring it back.

To me, that's always been the point of it is to bring it right back into the development lifecycle, right? You could fix it in production, but unless you bring it back into the code, then you're only going to be so effective. You're essentially going to most likely repeat the same problems as before. And with AI, you can actually have it, you'll look at, you know, like a long history and have it provide recommendations and create tooling around bringing that back into the development process.

I don't see a ton of people doing that yet, but I do think there are opportunities there. I mean, I haven't done it to that level, but I was explaining to some folks a few weeks back and they were like, I was building pipelines, I was doing deployments, right? And I said, but I had an agent that was referencing my cloud platform, getting metrics out of there, picking up if there was any failures on the pipeline itself from the logs of the Git platform and then remediating it based on performance.

Right. And I said, it's, they were like, so what does that mean? I said, well, it means that my deployments get faster and quicker because I'm not waiting for the pipeline to fail or I'm not waiting. You know, it's all good in theory.

you know even if everything is done as code the utopia of it being in the cicd is great but when it lands to your point when it lands into the environment there's always something that's a little different right be that performance or feedback or whatever it is and it's like how do you capture that data point to then feed back into the stream to make it improve whatever it is you're deploying right and yeah that's something i've been working on lately as well it's like more like a reality agent i like to call it a reality check or we thought it was going to act like this but actually it responded like x y and z instead right so yeah um that's a really good point too it's like and you're treating it just like you would uh you know what do you do when you know the good organizations what they do when there's a pipeline failure they stop the line right they swarm on or whatever they do to to ensure that it gets fixed right at that at the point that they discovered it well in production it really should be looking at the same it's not quote in the pipeline but i think notionally you should probably think of it that way right that you you have a problem and it not only needs to be fixed in production it needs to be now codified right needs to be in code go to go through version control and then go back through the pipeline again totally sometimes there's artifacts that get deployed that you you you didn't um implicitly explain right like it could be anything right or it could be like like you said go manual process the dns one's a good one right because that was you know i had to go through the networking team and then they'd make a change and they had their own own ecosystem going on there right and that could respond in a different way um and i'm thinking well yeah how do i if i've got these production lines how do i have agents monitoring the production lines right what kind of tools am i going to be using there and collecting data points and if it's in production we've got all these different deployment processes where it's like well we're only going to roll out out to 25% of the nodes or we're going to have green, green, blue deployments or AB deployments, right?

You know, there's obviously better ways of doing things. But how do you grab that data and feed it back so that by the time you've got the error or the email or the notification, it's like, no, I found a fix. We're good to go, right? I suppose that's more like SRE though at that point.

Yeah. I mean, in many ways, what you're describing is definitely on the deployment side and into production is progressive delivery, right? And ways in which that, you know, the difference between a deploy and a release is that, you know, you might constantly be deploying your software into production, but you're not necessarily releasing your software into production. So meaning you're hiding behind feature flags or whatever, such that you can actually test, you know, you were noting this before.

It's like there's a difference between what you thought it was going to, how it was going to behave and actually how it behaves in production and whatever those potential either data differences or whatever it might be. And so, you know, so that's a great technique, like you said, either blue-green deployments or, you know, canaries. You know, there's lots of different approaches. There's actually a really great book on progressive delivery that describes all this.

But yeah, having agents then, you know, I mean, feed into like open telemetry or something like that, that you can then feed back into the process. It's, I mean, in some ways it's the Holy Grail. Like you don't, it's great to hear your story. I don't hear a ton of stories in terms of people closing that loop.

They're kind of focused on the earlier parts of the process and ensuring, you know, I always think about, I was referencing this the other day where, have you heard the, I think Jez Humble calls it the CI certification or something like that. Oh, no, no. Tell me more. I mean, he calls it certification sort of in jest.

But basically, like, he talks about how he, when he was giving talks, this was probably like 10 years ago, but it still holds up today. Where he's giving talks and he would ask them, you know, how many people are doing CI? and, you know, so pretty much like most of the hands in an audience like that might raise, yeah, yeah, I'm doing CI. And then he said, well, how many of you are, you know, running builds and tests and that, you know, all the tests, 100% of the tests pass and, you know, some hands start to lower.

And then he talks about, well, once then you commit that code, and if any error is discovered, how many of you are fixing that error and putting it back into version control within 10 minutes or so. And so the whole idea is like that the difference between, or I think one of the other things he mentions is how many are running on the trunk or at least with short-lived branches, right? In my mind, trunk-based development is analogous to at least a predicate for continuous integration.

And so anyway, the whole point was you get to see the hands start to go down when you find out, like, are we actually doing? And there's a reason for it. It's not just like, you know, do you check the definition of CI? The reason for it is because that's where you get all the benefits.

That's where you actually get real feedback. Because if you're running on a branch or something like that, you only get a portion of that feedback. Or if, you know, some of your tests fail, again, you're getting a portion of that. You're essentially delaying the real feedback that you need.

Or if you're not fixing it, then you start to pile up those errors. And so the more I do this, the more it comes back to basics like that to me. Yeah, I think there's the same analogy with CD as well. i i think someone did something similar and they were like so once it's all approved do you just let it automatically roll out and they were like no we still have someone clicking the button to say release the production right because there's still that fear um i think people do need to go back to the basics um and get those foundations right but i also feel like ai is gonna help accelerate that especially with these with these agents it's i think it's been easier than ever around you know if you think about the initial the initial problems that people used to run up against like you know there was folks that had never written a piece of line of code in their lives like the click ops to then how does git work how do i commit something to a repo what does a repo structure look like how should i break up my branches how do i do features and releases right and i feel like you can get a good grip of that now um but it's still around tooling and best practices is there anything like if you have to give advice out to the audience listening in where has been a good you mentioned a couple of books before i'm going to check them out um but there's only like sources of truth except from your acquired experience of working with different customers like here are some of the pillars i would start with right or here are the first five steps right to to get a good platform and play a good process and play um so let's see i'll try to answer both of those questions one is so i can start with you know i'll i'll name a bunch of resources i'll i'm sure i'll forget a few important ones um i mean i was talking about continuous integration like really the canonical source on that um was uh martin fowler's um blog on that.

I think he pushed it in 2000 or 2000, somewhere around that timeframe. It was based on work that he had done. He and Kent Beck, I think, had done at the time. And so that's, that's definitely a great source.

You know, the, the continuous delivery book, Jess, I mentioned Jez Humble and Dave Farley wrote that. I would say, so that was 2010, And like modern day, I mentioned progressive delivery. I think that came out a couple of years ago. And Dave Farley has a book on, I think it's called Modern Software Engineering, something along those lines.

There's Accelerate. That's great in terms of like measuring this. You know so the people often talk about the four DevOps metrics you know lead time for changes deployment frequency you know change failure rate And then I think meantime to fix something like the resolution. A lot of the Gene Kim related books, Gene Kim kind of, he was associated with Accelerate as well.

um so he's got the what is it the uh the phoenix project is probably the big one the devops handbook things like that so there's a lot out there and even then i'm sure i missed a few so those those are great resources um gene's been on the show he was incredible yeah he's got a new book not to plug his book but vibe coding yeah yeah yeah he uh he's go and check out gene's resources that's That's all I'm going to say. He's a great guy. 100%. Yeah, yeah.

And he's followed the same evolution, right, that we were talking about before. But so your question, Kevin, is about like the practices, like when it comes to agendic engineering and DevOps and things like that, right? Totally. Yeah.

So, you know, I would go back to the CI part that I mentioned, you know, that you're building your testing, you're running it on trunk that or very, very short lived, meaning like, you know, less than a day or so branches as you're stopping the lines, you know, kind of those sort of behavioral practices have that in place for sure. and then you know specifically when it comes to you know agentica engineering it's like well how do you how do you codify that that's you know you were talking about the all the opportunities that we have because of it makes things much easier and i agree you you have to have that foundation such that you know kind of what to look for and but like what's really what's really uh great is that now you can codify these things.

Like all this stuff that's been in your head as a software engineer, you can actually write in markdown files and then have the agent look at them. So, you know, ClaudeMD or AgentsMD is an example of that. It's, you know, probabilistic. It's, you know, it's not deterministic, but it's, you know, you kind of look at those as a guide or the agent will look at it as a guide.

But you can put, you know, some of your practices around that You can have your personal practices, put that in a CloudMD, and then you can have your repo practices. There's a different, basically it's a different directory structure that you put that in, but that you can actually commit that to version control. And then you can, you know, run things like those hooks I talked about such that, you know, it's, there's a lot that you can do locally. I'm trying to push that even more.

It's like, how do you find out about these problems even prior to committing, prior to getting into a deployment pipeline? Because sometimes, going back to the whole idea that the feedback is crucial, that if I can run that locally. So one of the things I do, for example, is I have it such that the hook will have a set of rules and will look for things like high psychomatic complexity and look for things like long methods. You know, you look at the canonical code smells, for example, finds those.

And not only will it discover those in your code essentially as you're writing it right after you, you know, have written or right after the agent has written it. But then it will go and then fix it, you know, using the LLM. So, you know, so you can, again, codify those rules, put those, and then run it deterministically through the hooks. Another thing I've done is centralizing those rules such that, you know, the team can use that as well.

So, you know, where it can look at the programming language you're using, you know, your cloud environment, the various developer frameworks, things like that. And then it can gather the rules that for those, what you've written or, you know, sort of general industry best practices around that. So I've documented a lot of this stuff in an open source repo called AI development patterns. So I think right now I have 25 or so of these patterns, but codified rules and centralized rules, progressive disclosure, autonomous remediation is kind of what I was talking about before where it checks, you know, finds the problem and then fixes it for you.

um event automation with with hooks um things like that and so um yeah definitely you can that's i think a pretty good resource in terms of like what what are people in the industry you know what am i doing what are people in the industry doing in terms of uh when it comes to agentic development i mean you mentioned a few things there and it was like really going back to basics because I kind of liked it. It was like, oh, we're structuring this the right way. We're overengineering it.

What about efficiencies, right? All that good stuff. Would you say it was like real time or is it just more like the agent's just constantly observing or are you sort of initiating that, we call it review, but like an assessment, right, of what you're currently working on? How does it work?

Yeah, so it's doing it. I mean, essentially when it saves it to disk, so what is it? The post-tool use, there's like six different event hooks you can use in Cloud Code. And so in this case, you can either do like a pre-tool use.

So a good example of doing pre-tool use would be secrets, right? You never want to save secrets unless you're saving them to encrypted data store or whatever. And so pre-tool use would be an example of that. But in the case on most of the examples I was talking about use post tool use, meaning, you know, it's generated the code, it's saved it on disk, but it's not committed it.

It's not part of your virtual control yet. And so in that case, it's, you know, it's looking at the code. We're talking like in order for something like that to work, it has to be like almost like milliseconds, you know, like 100 milliseconds or something like that. You need to have that kind of you don't want it to disrupt your flow too much.

At the same time, you know, if you're injecting, if you're generating code that's going to become a problem later, you obviously want to know about it. So it's just sort of that balance. It's always, to me, that's always been a balance of continuous delivery. It's like, which, you know, it's how long is something going to take versus, you know, do I find that problem right?

If I can give a recommendation or a fix right now, then you want to do that. if you can do it in a reasonable amount of time. So, and so, yeah, it's just looking at the code and determining based on your rules that you've established whether or not it violates that and then starts fixing. It tells you what it's doing and you can review the code if you want.

But one of the things I wanted to talk about too, because you were mentioning that PR, PR queues. And that's what, what I'm seeing is, you know, we, we talked, I talked about at the very beginning, like we were seeing like so much more code being generated, but then you also, the, the PR queue is also increasing. We don't have like, you can't necessarily like throw more people at the problem and it's probably not the wrong rate way of thinking about it anyway. But that I, in, in my view, that, that whole queuing process was broken to begin with.

Right. And so I think people are just maybe finding out about it more because, you know, we were, when humans were the ones writing all the code, there was, you could, you could theoretically have, I mean, you were still building up a queue, but you could theoretically balance that. You have one person review that code. And so in my mind, it's like it was already a broken system.

And now we're just seeing how much of an impact that has when it comes to AI generated code. So I think the less that we can have humans review the code, or the less that they actually need to review the code, the better. So do we think that's depending on how many lines of code that was written, the type of PR that was raised, or do you just mean in general, right? Yeah, I think it is based on the type.

And I think the PR itself is the, yeah, that whole queuing process is a broken process altogether. right yeah i i mean i was recently with a customer and i'm i'm generating the code and i had them on like i am right i was like i'm submitting it and they would go and then they would launch an agent to review it it was really ironic and then they would say right i've made a comment and then they would ping me back on the im and i'd be like right let me remediate it and then until it was right it was like ping pong right but it was really i thought it was fast but it was like then he went on lunch and i had to wait yeah to your point right and but ironically he was using an agent at the other end yeah right to assess it all right it was it was yeah it's that kind of uh that kind of analogy right i was just like this is wild i something that would have taken me months or weeks to remediate previously maybe right depending on the problem is now taking me like 10 minutes next pr but i had to wait for someone at the other end who was using an agent to approve it yeah and i think that i think that's what it is is like the less that that humans actually even need to approve it like if you can trust other parts of your system such that for example maybe you have a rule i just wrote about this on linkedin but like if you have a rule that says, okay, if this is a high-risk change, whatever you define high-risk change to be, you know, security, PII, you know, some big architectural change or something like that, and you can route it based on that versus just everything goes through a PR queue and it always has to get reviewed in that way.

Like, if you have trust that it's already finding all these problems, and then the problems or the issues that you want to raise with humans are based on, you know, some heuristics, some rule, such that it then gets routed to them And then you using things like progressive delivery such that you ensuring that the behavior is what you want before it actually gets released or rolled out to all the users You know, to me, that's sort of the happy place, if you will, that you want to be.

And this won't scale if humans have to review every single change like that, regardless of whatever the change is. Would your recommendations around that? because like i speak to a lot of organizations right and they're like is this thing going to go and delete everything right is it going to become self-aware right and yeah i'm like i'm like okay james cameron's not in the room yeah take a few steps before that yeah yeah yeah yeah so it's like we'll just start off with dev then you know implement these practices in dev and you remember when the cloud came out and it scared you just instill confidence right by promoting it through the environments until you feel comfortable right or you could you could even ring fence it to certain parts of your platform or system right you don't have to have it at the crown jewels so to say but you can then you know promote it if you know as the confidence builds i think it comes back to again, it's that circle, right?

That figure of eight that we used to just live off when it came to DevOps. It's like, well, the more data you've got, right? The better it's going to be. Yeah.

It's almost like, I mean, trust is the word that really comes to mind, you know? And, you know, perhaps, you know, you could create like a trust score or something like that based on various factors. But yeah, I think that the more that you trust that the deterministic checks in particular, right, are that you always know that it's never going to get to that point in the point of, you know, forget AI, agentic engineering for a moment. It's like you know it's never going to get to that point unless it's run through these tests, unless it's run through the static analysis, unless it's run through, you know, all these various checks such that, you know, you're only seeing the changes that really matter and that might have an impact, might be of high risk.

But yeah, it could take a while to get there for sure. But to me, that's the one way to solve that problem. And I want that to be, I want the focus to be on shipping versus, you know, that i you know i cringe the more i hear people say like you know i i can i merged like 10 times you know the number of prs than i did you know five months ago i'm like okay but it doesn't matter unless you're shipping unless you're shipping that to to the end users so i i think we talked about this last time on our intro call right people forget why they're doing it in the first place is that the end users right how is that in the palm of their hands right regardless of how they're using it is what's the feedback from them as well so uh shipping features right and adding value essentially right for both sides yeah one one is use the organization and then the other one to the customer right so exactly and it's all that stuff to me that's is all the stuff in the middle Right.

The between the idea of, OK, this is something that we think the customers are going to like because they told us so or that we've looked at the data or, you know, we've made some educated guess around this. Right. So you come up with that idea. All that other stuff in the middle between the idea and getting to customers, you want to shrink that time as much as you possibly can.

So anything that sits in queues or anything that requires human input is just going to increase that wait time such that to the point when it gets to the end users. Because only when it gets to the end users do you know it worked or not. Either they're going to give you direct feedback, you'll be able to look at the customer data. You know, again, that's where things like progressive delivery can be helpful before you, you know, roll it out to all the end users.

But, like, the more we can shrink that time, the more we can get actually that useful feedback. And to me, all this stuff has always been about is getting good feedback, useful feedback from users such that you can then build, you know, more of what they want. Totally. Totally.

it's the reason why we build stuff in the first place even though we like to mess with code right and all that it's it's only useful if someone's using it right at the other end so yeah that's what got that's what got me into into this i was talking about how i was doing a lot of you know kind of these big business applications at the very beginning of my career and i remember it took a long time for it to get out to the users and i was actually part of it was like a bunch of medical logistics centers across the world.

And I went to the kind of our, the local site to do an install. And it all sounds funny because it was forever ago. But when I met with them, they, you know, one, they were like super excited. Two, they gave me like five new ideas, right?

But it had taken, you know, two years, honestly, to get to that point. And so I was so excited by that. But then also like, oh man, we got to fix all this, the other stuff in between here. Because that's what's slowing everything down from getting that feedback.

Like, I want to get that kind of feedback. It was like, I want to get that feedback all the time. And now, you know, there's definitely, there's many organizations that are able to do that. and even more so with AI when done well.

No, when we were talking about it, it brought back memories for me as well. It was like when we used to wait for a service pack for an operating system, because it would be like three or four years of feedback, right? And then the operating system would have been falling over all the time, right? Or have gaps or whatever.

And then the service pack would come out, fix it. and then a new operating system would come out right like the year after and it was like starting the process all again because you had to wait it was like a roll-up of ideas features but then if there was uh you know you know problems with the code in the first place or functionality and yeah it was uh and it used to come on a cd but it's it's true right now it's more like right okay we got feedback how do we ship it out as quickly as possible right how do we push that out do you just keep on trying to push the envelope in terms of how how quickly we're able to do that which is you know really exciting okay um i'm conscious of time so i know you're a busy guy um any words of wisdom or feedback i mean there was some great nuggets there, right?

And I'm going to include some of the links in the show notes today, but any words of wisdom for the audience out there? I mean, I think like if we look forward, I mean, if we look back, you know, 12 months, well, 12 months ago, Claude Code had just become GA, right? So it's like a, it's a whole nother world that's going on. So, you know, I think one of the things that we're going to be doing in the future is figuring out how to reduce the cues and kind of the buildups downstream that we've created as a part of AI-generated code and agentic engineering in general.

So to me, that's where we should be focusing a lot of time is on that part of it, right? But I would really encourage people to look at the full value stream, right? And that everything matters. And the more that you can shrink that process, as I talked about, the better.

And you can just, you know, if you don't know where to start, start back with those fundamentals that I talked about. Awesome. Awesome. So if people want to know more, Paul, about what you do and what Redacted Ventures does, where's the best place to find you?

You can. Sorry. It's okay. Yeah, you can find me at paulmduvall.

com. you can find redactedventures.com and I think Paul Amdovall gets you there as well those are probably the best places check me out, I'm on LinkedIn as well you can follow me there but yeah Any conferences you're going to later this year that people might bump into you? Yeah, actually I don't know when this is coming out but the end of June I think they call it the AI Engineer World's Fair which is in San Francisco um so uh yeah uh that that's good that's an exciting event that's i think they said 6 000 people are going to be there and so it's all focused on on all this stuff and so i think it's the third year doing it um this is my first year going though um but and then um i've been to some of the ai native i went to the ai native devcon in new york city uh that's done through tessle uh so those are the ones that so far that uh i've um i found beneficial awesome so if you're one of those 6 000 people going to that you might bump into paul right that sounds absolutely wild it sounds like it's gonna be a great turnout right yeah um but yeah thanks for coming on paul thanks for making time um it's been really insightful i've learned a lot um it was it was quite a technical episode it was really good i quite liked it it was good um but yeah if you've liked what you've been hearing don't forget to like subscribe and share with your friends remember we've got the discord channel as well if you want to join that it's at connect.

co.co.io all the amazing resources that we've talked about today will be included in show notes we will catch you on the next one so it's goodbye for now You've been listening to the Code to Cloud podcast, where ideas meet innovation and the future of tech takes flight. If you enjoyed today's episode, don't forget to subscribe, leave us a review and share it with your network.

Let's keep building the tech community together. For more insights, resources and updates, follow us on social media or visit us at CodeToCloud.io. Until next time, stay curious, keep learning, and remember, every line of code has the potential to shape the future.

See you in the cloud.