Screaming in the Cloud - The Rise of Autonomous Ops: Inside AWS’s DevOps Agent with David Yanacek

Episode Date: May 14, 2026

In this episode, Corey Quinn sits down with AWS Senior Principal Engineer David Yanacek to explore the next evolution of DevOps.After two decades of building systems to reduce operational pain, David shares how AWS’s new DevOps Agent is pushing automation to a whole new level, autonomously diagnosing incidents, suggesting fixes, and proactively improving systems before engineers even log in.From pager overload to autonomous remediation, this conversation is a glimpse into a world where software isn’t the bottleneck anymore, operations are evolving into something entirely new.If you care about DevOps, SRE, platform engineering, or just want fewer 3 a.m. alerts, this episode is for you.Show highlights: (00:00) DevOps Meets Agents(00:13) Welcome and Sponsor Break(01:29) David Yanacek Backstory(02:34) DevOps Roots at Amazon(04:22) DevOps Agent GA Overview(05:32) LLMs MCP and Any Cloud(08:32) Guardrails and Safe Changes(11:47) Beta Results and Consistency(14:13) Troubleshooting Theory and On Demand(17:29) Future of DevOps and ClosingAbout David: David Yanacek is a Senior Principal Engineer at AWS and a lead advisor on the Agentic AI team. His current work focuses on Kiro, Amazon Bedrock AgentCore, and AWS’s operational agents, where he helps shape the future of intelligent, autonomous systems.Over a 19+ year career at Amazon and AWS, David has been at the forefront of building services that simplify life for developers and operators. His experience spans serverless, DevOps, and CloudOps, including launching Amazon DynamoDB and AWS IoT Core, and contributing to the direction of cornerstone services like AWS Lambda, Amazon API Gateway, and Amazon CloudWatch.David also served as the lead publisher for the Amazon Builders’ Library, helping customers apply Amazon’s hard-earned architectural and operational lessons to their own systems.Outside of engineering, David plays the French horn in a local Seattle ensemble.Links:LinkedIn: https://www.linkedin.com/in/david-yanacek/Website: https://aws.amazon.com/builders-library/authors/david-yanacek/Sponsored by: duckbillhq.com

It's DevOps is time to shine. Because with the advent of agentic AI coding, everything, people are just getting a lot more done themselves. Welcome to Screaming in the Cloud. I'm Corey Quinn. And my guest today is David Yanichick, who's a senior principal engineer over at AWS. David, thank you for joining me. Oh, I'm so excited to be here. Thanks for having me on. Longtime fan. This episode is sponsored in part by my day job, Duck Bill. Do you have a of a horrifying AWS bill? That can mean a lot of things.

Predicting what it's going to be. Determining what it should be. Negotiating your next long-term contract with AWS. Or just figuring out why it increasingly resembles a phone number, but nobody seems to quite know why that is. To learn more, visit duckbillhq.com. Remember, you can't duck the duck bill bill, which my CEO reliably informs me is

absolutely not our slogan. Well, thank you. I appreciate that. Most people don't admit to that in recorded media. So I've taken that and putting it on the website. It'll be great. You are a lead advisor on the agentic AI team at AWS and, as recently reported by the New York Times, a trim man of 42 with a gray beard, which does not seem to be in evidence, and a jittery intensity. Well, that will be on evidence. I think I've had plenty of coffee this morning. So what do you do in these days? What are you up to? You've been at AWS a very long time, and agentic AI has, well, not been a thing for nearly that long. What's your backstory? Well, I've spent the last around 20 years at Amazon, and most of that at AWS, like there's kind of a gray area on exactly when I started in AWS, because so much of that was on team straddling both AWS and the rest of Amazon that made, like, the web service framework that all the AWS services and Amazon services use.

So I don't know. I'd say the whole time that I've been at Amazon out of college for 20 years has been with pretty much a singular purpose. And that's been to make developers lives easier. Everything I've done seems to be on the same theme of I build something. I see what was painful about that. And then I build a thing to make that thing less painful. When you say you're talking about making a developer's life easier, are you talking about developer experience? Are you talking about underlying capabilities? of the platform because making developers' lives easier can cover an awful lot of ground. When I look at the most pain that I have, at least the way that I look at developer pain, it's around the ongoing maintenance and operations of a thing. Like that's just, I shouldn't say, well, yeah, pain. It's just the most amount of work that I'd rather not be doing is around ongoing operations. And as a developer, as a software developer, I like to automate my way out of that.

That's actually why we do, and always, for my view, have always done at Amazon DevOps. To us, what that's meant has been developers do the operations. There is no separate thing. It's just one thing. Developers wear all the hats, just do everything. And so the nice property of that is that I've been building my way out of and automating away the annoying stuff the whole time. When I started, I was on this team that ran Amazon.com's web server fleets. Arguably not a DevOps team because we ran the web server.

fleet, but when you have hundreds of teams pushing code to the same web server environment. You can't be a DevOps team when you're working with that much Pearl. I'm pretty sure it's against the byline somewhere. Yeah, yeah. A lot of Pearl to do the, to script the automation, a lot of pearl rendering the web, the HTML. Yeah, a lot of that. So in order to make operating that Web Server Fleet easier, we had to build systems to help us automate it. So we built like alarm aggregation systems to turn, instead of our pager, like I have here, going off like a hundred times, one for every web server or a thousand times as we grew, to turn that into just one page.

So that takes, that takes... Well, now you're in Amazonian. I mean, I assume you carry six pagers. Just one, but I make sure that I... Well, I guess I... No, I shouldn't say that because it's my pager. It's my phone to make sure there's a backstop, does the text message, and of course, the app that we have.

So, okay, okay, good point. I have three pagers. There we go. You'll get up to a full six pagers before appendices app later. It'll be great. Your timing on this is impeccable. Because as we record this, about an hour ago. You folks came out with the general availability of AWS DevOps

agent. So now you can talk about it freely, but it wasn't enough time for me to actually kick the tires on it and ask the embarrassing, well, what about questions? So tell me, I assume it was. Basically, me talking to people dictates the entirety of AWS release schedules. What is DevOps agent? What's it do? I'm guessing it's going to make developers lives easier, just a hint based upon how you started this. It really is. I mean, it's a sign of the culmination of everything I've been trying to do over the last 20 years at AWS. I've been working hands-on, building DevOps agent now for some time. And what it does is it responds autonomously to operational incidents. Before you open your laptop, it has hopefully fully root

caused and suggests remediation steps for how to fix an alarm. It's also proactive in that it will just scan through everything, sift through everything to find operational improvements that will prevent future incidents, future issues, optimize things for you. So I know nothing about the service yet. So forgive me if this turns into a really awkward line of questioning, but there have been a number of bites at this Apple historically, mostly before the rise of Gen. I. And the biggest stumbling block to all of this was either you had to build your systems in a very prescriptive way, or spend a tremendous amount of time instrumenting and getting things aligned in such a way that these agents could then do anything with it. And that was work that very often just never got done.

Has that not been cracked? That is exactly why we're building DevOps agent now and why I think this is going to be the right swing at the Apple or whatever mixed metaphor as you want. We've always been improving developers' lives by making new services. I worked on DynamoDB because I didn't want to have to do database ops anymore. So now I don't have to like set up replication and deal with backups. We built Lambda because I don't want to have to patch operating. systems and deal with server failures. Those are great and they solve that real problem for customers, but of course they have to adopt. They have to do work in order to invest in using it in order to get and switch their application around in order to get that. Just migrate your

relational database to Dynamo is not really that straightforward of a lift. Yeah, the migration part. Yeah, using it from scratch, great, but yeah, no, it's unfortunate. It's like how do we make migration easier and we keep chasing this. The advent of LOMs are actually the magic here. Before there were, okay, everything has an API. You can make anything talk to anything. Like that's what the whole web service, API, service-oriented architecture thing was about. But you have to do work to integrate those, point integrations to make those work together. The advent of LLMs is now, as long as you have, actually arguably in the future you won't,

but as long as you have an MCP interface to a thing that isn't special purpose for a point integration. You just have an MCP server that's essentially just documentation plus API. Once you have that, anything can talk. to anything, and it works great. And so it's... I'm going to say what I've been saying about that. I feel like I've already had one for many years, and it's the AWS-C-L-I tool.

The CLI is great as an MCP server. In fact, the AWS-M-C-P server essentially is just pass a string that is the AWS-C-LI command. So, yeah, that is a nice interface with documentation in the help, just making it tailored so it's easier for an L-LM to use. So the key is, with DevOps agent,

is like that. Now it adapts, because of L-O-M-C-P, adapts to anything. But we've also built it from the beginning to be completely unopinionated about what you're using to do your operations, what infrastructure you're running on, what frameworks you're using, what instrumentation, what observability provider and tool, like everything. It plugs into everything, thanks to LLMs and MCP. It works. We call it AWS DevOps agent. That's because it's built by AWS, but it is unopinioned about whether or not you run on AWS. You could use this hypothetically to troubleshoot things in a completely different environment.

That's right. In fact, like part of GA support was like just built-in, baked-in integration for applications running on Azure. It works for any cloud you run on as long as you provide an MCP server that can describe your resources. Some people have hobbies, they grow an herb garden. I do something very similar. I have a test Kubernetes cluster running in the spare room, as one does. And I basically have been letting Claude code tend the garden for me, for lack of a better term. I'll let it go ahead and run and make changes to it. And periodically, I have to slap a chainsaw out of its hands because, oh, it looks like this thing isn't working.

I'm going to blow away the volume and recreate. Like, there's data on that. Maybe don't do that. It's the guardrail thing of things that might make sense in some contacts could be dangerous and others. But again, there's nothing critical on this. I'm not that irresponsible. But how do you wind up, I guess, avoiding the temptation to do things that could themselves be

destructive for the LLM, not you personally? I mean, we all want to burn the office down some days. I get it. AWS DevOps agent, we're very intentional about what it can do, what the data can look at. So just like any AWS service you configure, you give it permissions to say you can look at these things. We actually scope that down. So you can give us permissions. And if you try to give us too much permissions, we'll actually just take fewer permissions. So we are very intentional about it can do read-only operations, only certain read-only operations. just guardrails are basically where, like the main focus of the AWS DevOps agent. And when it suggests, it says, hey, you should, here's a fix.

Here's how to get yourself out of this operational situation. There is in the moment fixes. We produce what kind of what we do at AWS whenever we make a change or like any manual change. We write down a very deliberate set of steps in a very deliberate order. Okay, I'm going to run some commands to make sure that the world is what I think it is, this pre-validation. We're going to record the current. state of the world. I'm going to make the change, have my rollback steps ahead of time,

and post-validation steps to make sure that this had the effect that I want. We call these change management documents. That's how we present any suggested change, a very deliberate and methodical thing that you can use to execute that change safely. And then when we suggest a coding follow-up change, we give you an agent-ready specification to give the agent all the context about the what and the why so that it goes for the right approach. One thing that I've always been a fan of when it comes to letting these agents run loose in prescribed ways, let's be clear, has been that they sort of embody that spirit I always look for in SRE hires or DevOps folk of the never give up, never surrender approach. Whenever they get blocked in a particular

troubleshooting direction, they'll come up with some way to solve the problem. And some of them have been pretty freaking creative. TCP dumps after a Netcat experiment being fired off SSHing into the far side. Just weird in-depth stuff. S-tracing. to see what the thing's actually doing. It gets really deep, really quickly, and I love that aspect of it. So it's almost feels like it's a balancing act. How do you let it continue to drive for those solutions while not also letting it drive your company into the ground?

That's definitely why we, with DevOps agent, we said, okay, for production operations, let's give it a very specific subset of tools, not the shell, that type of thing. Until we have that proof that things like shell commands writing its own code are safe, then we're going to continue with these like very well, easy to understand perimeter and guardrails. So you've obviously been running this a fair bit yourself in your environment, which is always dangerous,

in that it works super well at companies shaped like Amazon is not as broadly applicable as one might think. So there's the, okay, now you start testing it on pre-launch customers. I believe it was in public beta for a while after reinvent. And what have you seen as this has unfolded? What areas is it excel in? and what areas is it still not doing as well of a job as you might hope? I'd say it's pretty good at figuring out these sifting through a ton of operational data and figuring out something that like a little needle in the haystack

that could explain an alarm incident that would have been taking a long time to figure out. There's a company Western Governors University. They ran it on a thing that had kind of re-ran it out. They adopted it and then took an incident that took them two hours to figure out to root cause. This is a while ago, an earlier version of DevOps agent or an earlier incantation of it. So in that two hours that they had done manually, and it figured it out in 28 minutes. The applications, I found myself making a lot of applications that have nothing to do with AWS, doing it not the Amazon way, like the internal Amazon way, because for this exact reason,

to make sure, like, it's actually teaching me a lot about the tools that exist in the real world, too. It's a lot of fun. Like, even then, like when we started, when I first set it up at Reinvent, and used it. It caused a certain operational issue in like 11 minutes. And now I re-ran that scenario just a week ago, and it took four minutes. So we've been making a lot of improvements. It's very good at that alarm. Is that consistent? Or if you run it a third time, would it then take 45 minutes? Like one of the things I found is it feels like Claude, which is what I use for a lot of this stuff on the Claude Cod's Incarnation. It has smart days and dumb days. And it's,

you never know what you're going to get. It's like roll for initiative every time you have it dive into something. It's relatively consistent, I think. A lot of what we are building behind the scenes around context around your application, learning about your application. I guess it's not the same every time because we're learning from past troubleshooting. That's obviously a trade-off of making it so that it doesn't like have target fixation on a specific past run. I know it's DNS.

I just have to prove it. Well, that is actually baked in, unfortunately. It's always DNS. There's no way for it not to be. The problem, of course, is when it's DNS, when it can't find these API endpoint, Well, suddenly we're not going to space today. But yeah, that's always the challenge. How prescriptive is it as far as this troubleshooting methodology?

Is that baked in? Does it follow whatever computer equivalent of gut instinct is? This episode is sponsored by my own company, Duck Bill. Having trouble with your AWS bill, perhaps it's time to renegotiate a contract with them. Maybe you're just wondering how to predict what's going on in the wide world of AWS. Well, that's where Duck Bill comes in to hell. Remember, you can't duck the Duck Bill Bill, which I am reliably informed by my business partner is absolutely not our motto. To learn more, visit duckbillhq.com.

We have baked in kind of how we go about troubleshooting into it that helps. We find forward these kind of specific alarm triage. Because the goal of alarm triage is actually not to understand the root cause. We call it root cause, but that's actually not ultimately, the goal. The goal is to figure out what mitigation step would make the problem stop, the customer impact stop. That's actually the goal. And so we baked that in. I talked about this in some past reinvent talks, a somewhat ridiculous name for it, but it would call the grand unified theory of incident management is that any production impact can be mitigated by in through the pursuit of

looking to see whether it was a deployment, like a change that broke it, a change in inputs, like a traffic spike or passing new parameters or stopping passing parameters, a failed component, like the application crashing on one server, one availability zone, a dependency, or running out of something. These are kind of all recursive. They kind of refer, they point to other parts of, oh, it's not, if there's a change in traffic, well, let's go investigate the caller to see if they changed, they did a code deployment.

So it's a recursive kind of exploration. We found that to be very useful. And so we've baked this kind of thing into the agent. But we've also known that we also know that that isn't always everybody's goal. Their goal isn't always to find mitigation. Sometimes they really just have some ad hoc operational tasks that they want to figure out what's going on. And so that's why 4GA has a little bit less of the customers using it every day. But we've launched on-demand tasks.

So you can ask any kind of question. It's a little bit less fixated on finding the root cause of an alarm and more just helping you in general. So that I think has a little bit less usage of it so far. But we know that operations is an endless set of very varied thing. It's not just responding to alarms. And that's where we're trying to help people. Where do you find that the differentiation comes into as opposed to my crappy backyard experiment of just go ahead and run Claude Code in dangerous skip permissions mode, let it tear into the thing and have fun

versus like the hyper lockdown approach that some shops take where everything it does has to be vetted by a change committee? One of those leads to faster outcomes, but less system stability. And the other feels like it's a lot safer, but doesn't get anything done. It feels like there's a continuum there. Yeah, I feel like striking that balance is the important part. And that's where we're going with the change safety. We're going, but still letting it have the creativity, if you will, of exploring down any avenue that any avenue that it might want to chase down.

You've done a lot of work in your career around the developer experience. is the DevOps world as it is. What do you think the future of DevOps lies? There have been a lot of flavors of companies organizing around operations and individuals around how they get things done, how they keep things running. There's SRE approaches where you have a kind of a frontline team who also is automating things, just kind of more fewer operations where there's like an incident response team. And what I think of is DevOps, which of course is a word that has taken a lot of

term and change over the years. It encompasses so many things. Like, you can't buy DevOps, but I sure would like to sell it to you. Yeah, it's become a panacea for a while of it just means your assistant admin, but if you call yourself DevOps, you'll make 40% more. Great, good for you. Get the bag. Then that became SRE, then it became platform engineering and who only knows what it is this

year. That's right. I think DevOps is obviously biased because this is how I've been operating and AWS generally operates for the last 20 years plus. is I think DevOps, it's DevOps is time to shine. Because with the advent of agentic AI coding everything, people are just getting a lot more done themselves. Like I love wearing all the hats, talking to customers,

thinking about the product, implementing it, running it. I like wearing the hats, securing it. I like that. And I think now these tools are making that even more vital to just be able to do more and more yourself as a little bit more generalist almost. And so I think DevOps is really the future of DevOps with my definition, of course. Oh, yeah.

But my version is always going to be the future. Let me define the term. I mean, that's just common sense. From where I sit, software is no longer the bottleneck. You can do a whole bunch of things in a suddenly I'm going to have it write code to solve my specific problem. I've been doing that. And it's great.

Is this robust code? Absolutely not. I mean, as I'm sure you've seen, building services and products, everything you thought you knew about this gets thrown out the window the first time you put it in a customer's hand and they try to use it like a bad hammer. There's other people's requirements, other people's usage patterns often cause software to no longer work the way that you wanted it to as soon as it violates one of those design constraints. Now I feel like that's okay. I just send Claude back to the minds to go ahead and build me another version that now does this. But back in the early days of the

newsletter, when one day I wanted to start sending out blog posts, that took me three weeks to get that system to support that. Now it's just yell at the robot and go get a cup of coffee. Yeah, I think the key is that it can, the agents are super successful when they can see their own output. That's really the key is that they can, instead of, okay, let me have it, build a thing and it'll tell me, give it to me, and then I'll try it and see that it failed and I'll paste the error back in. You know, that's the tedium. That's not, that's not the future. Future is where it can do more and more of that in that loop where that it runs until it works. And so that means going further into, well, okay, it'll produce a pull request for you because it's run all the unit tests.

Well, what if we could do the integration tests? What if it could actually, we also did this AWS security agent that can do penetration testing for you? Like, what if you could have that be part of the CICD pipeline? What if you could have DevOps agent kind of calling it back that, okay, this thing that you did didn't work? So extending that loop out beyond just your local machine, I think, is very very. very important in terms of avoiding a bottleneck where things will just pile up in your kind of deployment pipeline with so much change. It's making sure the agent has the agency to see its own result even further all the way through to production. One of the challenges I found with

folks taking this approach has very often been their organization's own guardrails and boundaries, where even for a human sitting down and solving the problem, they're spending most of their time trying to get access into the right account to look at the law. put out by something, which is sort of a necessary first step, unless you want a blackbox troubleshoot, which no one does. It feels like companies do have to evolve to a point where tools, if not people, can be given access to some of these things. I agree. I think it's the teams who have seen be the most productive in this spend, they make sure to set apart time. They give themselves some breathing room to say, okay, what should we smooth out? That was actually, it's kind of like

These things that are going to make teams more productive with agents actually would have made the team more productive anyway. But now there's just even higher upside to it. So it's really worth taking a step back. It's a nice excuse. I've always found having these nice excuses to take a step back and just breathe and improve developer life even within a team has been so great. Like when we realized many years ago that our changes were actually piling up. And the time from check-in to actually reaching production was, I think, weeks on average. And this was not ideal.

We wanted to be able to innovate faster for people. And so we looked at this, and this is when we're like, let's do this continuous deployment thing as an entire company. And that was just a great rallying North Star. We built an internal pipeline system so that everybody could manage their code as it was flowing through, automate as much as possible. But teams still had to do the things like, well, if teams were hesitant, to turn it on kind of full auto. Why were they hesitant? Well, we don't trust our tests.

Okay, spend time and write the test because it'll pay off. Like, oh, we don't trust the deploy. Well, okay, have better monitoring so there's a roll back. Well, what about this edge case? We'll monitor that. So it's really this nice rallying North Star of how can we just actually make this all operate a lot better. And so this is a good time for that with AI.

It seems like there's an opportunity here for a lot of companies to improve their processes with this just because something, like a powerful LLM assistant like this, that keeps smacking into the same procedural guardrails, and that being forced to wait for someone to escalate is going to sound a lot more credible than when an engineering team does it. Oh, our engineers are just crappy slash lazy slash maliciously complying with policy. Okay, now the robots doing it lands a bit differently, I suspect. And I wonder if that starts to act as internal ammunition to drive cultural change. I think you're right. I agree. That's in phase two of the body.

It's going to be a dashboard explicitly aimed at that, I'm hoping. Now, the problem is your crappy policies. Great. That has its own problems. Just write code the way that we do, and thus was launched Kubernetes. It was the world in which we live. So what's exciting to you? If we look at the world four years ago versus today, technically speaking, it's hard to recognize just how far we've come in a short period of time.

Predicting the future is always dangerous. But what do you think is coming down the road next? You know what I look at the kind of evolution of operations at AWS over the 20 years. Like the one thing that's remained, well, constant, of course, constantly changing, but constant in terms of the priority is the culture is you really have to, operations is one of these things that it can be too easy to backseat to a squeakier wheel. And so that's one thing that everybody, like all companies have to think about, is how do we make sure that operations is something that people care about all the time?

Especially important for AWS because, you know, that is our job. We are doing the ops so you don't have to. That is the whole thing. But the things that have changed is kind of maybe the maturity around it, around like starting from when we were first building AWS, nobody had built a cloud before. And so we are kind of figuring, teams are figuring it out of the right ways to do things. Like how do you measure availability? So teams would measure it by like when I was on DynamoDB or we were measuring latency.

Well, latency is the, you look at percentiles of how long it takes to respond to certain APIs. Well, when we were building DynamoDB, it was all about predictable performance. That's the main thing that slow is slow and consistent is better from a lot of use cases than fast, but spiky. Well, that's why DynamoDB went for fast and consistent. That was the real. Exactly. Hey, well, if I could have all three of the constraints in one, then terrific. Playing with cap theorem is a very, we just ignore cap theorem.

Sure, why not? Actually, we were able to play some really cool trips with it. But anyway, so measuring performance even. So, okay, how do you do that? Well, we found in early pre-release beta, we were seeing our latency graphs were flapping. What's going on? And actually wasn't that the latency was actually flapping, it's our measurement was, because we were clumping together kind of one-kilabyte reads that were buffer pool hits

with four megabyte scans that were going all over the disk. And that was in the same measurement. So it's, oh, let's break that out. Let's have three different latency buckets. So we'll have the buckets for the super, like super small reeds, another bucket for the medium-sized weeds, a bucket for the large reads. So these kinds of operational practices, everybody was learning. That was kind of the first phase. Then we started writing it down and sharing it more to say, turning things into checklist, saying, okay, well, it's kind of like well architected where you would say, okay, we know that it's important to do these things and organize a pipeline this way, scale this way, have resiliency set up in multiple availability zones.

having checklists. Then we started automating the evaluation of the checklist to say, well, let's just let teams know if they have something that isn't following what we think is probably a better way to do it. Then we started fixing things automatically, saying, okay, here's a poll request that updates Java for you, like upgrade and all your dependencies, like something that would take you a long time to do. So I think the future is like if I follow that trend line of automating operations, I think the future is going even further to. just getting it done. The operational backlog of improving any application is endless. There's an unlimited number of things you can do to improve your operational posture in a system. And everybody

wants to reach further into that backlog. And so I think just the getting it done for you, but that means agents, they need to be able to fully let low test. They need to be able to fully do everything to validate those changes. Like pushing a change to upgrade your application to a newer Java runtime. Before that wasn't the easy part. But now that's actually kind of the easy part. Like, it's actually the, how do you make sure that deploying that is actually going to work well without any hiccups along the way? That's the hard part. Is there a future where the entire infrastructure and DevOps side of the world today that's an entire career field just becomes something the platform does under the hood where people don't think about it of? Here's the application.

Make sure it runs, do what you've got to do. And it just goes down to application development in a lot of shops. Well, I think there's a difference between it happening automatically and people not thinking about it. I think people always have to obsess over their customer experience. And this is a lens ops and understanding that your operational characteristics are a lens with which to look at understand the customer. So that's not going to go away. But if I look at what coding agents are doing in the amount of complexity that they're encapsulating in a spinning wheel, there's a spinning wheel. Oh, yeah, working on working, oh yeah, yeah, working on implementing your entire application and then it's done.

You know, that's, that's, that's all a spinning wheel, an enormous amount of work abstracted into that. I think DevOps is like the next one. I'm like, okay, now let's like improve your resiliency. Let's optimize your application. Let's add monitoring. These are, yes, these are things that are just accessible to anyone as just, it'll just happen for you.

These are exciting times. These are fun products that are really making a lot of the historical toil, not nearly as to toil some. Even, even as a guided assistant, it's, okay, I'm out of ideas to troubleshoot this. robot do you have one that it starts to almost become a collaboration aid yeah it's kind of like rubber ducky like debugging it's accepted actually will give you some ideas instead of just being a reflection of your own the rubber duck has learned to talk it's it's it we've wound up in a very strange place suddenly and it happened very quickly yeah i have this rubber duck right here actually

this i just picked this up it's a captain jane way that's that's my my rubber duck of choice yeah i've started sneaking them into the house wherever my wife least expected i call it reducerating and I'm going to have to deal with the consequences of that someday. But not today. David, thank you so much for taking the time to speak with me. If we want to look more, where should they go? What's the best place to find you? LinkedIn, X, Blue Sky, the fragmentation of every social media thing. I'm there. Happy to chat.

Fantastic. And we'll, of course put links to that in the show notes. Thank you so much for taking the time to speak with me. I appreciate it. Thanks for having me. A lot of fun. David Yanichek, a senior principal engineer at AWS. I'm cloud economist Corey Quinn, and this is screaming. in the cloud. If you've enjoyed this podcast, please, leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please, leave a five-star review on your podcast platform of choice, along with an angry, insulting comment that you hopefully

were able to get the AWS DevOps agent to write for you.