Yo, seriously, you're still reading the code. What are you doing? You're wasting all of this time. Well, other people are going to say, I can't believe you're not reading the code. Don't you have people who care about what you're building? And honestly, it is a spectrum. This whole, do you read the code, don't you read the code, is a spectrum based on the level of risk that you're willing to go for and how tight and good your agentic loop is and how good your AI reviewers are. And ultimately, we've talked about being factory engineers before. We've got a video that you can watch that later. But the idea of a factory that you have as little human interaction as possible, and yes, you do still need to understand the product, that we're all over the spectrum on here. But I think one thing is clear for myself in trying to determine what are the durable skills that I can learn. And that is we are moving in a direction where we will be producing way more code than we could ever possibly review for the majority of cases. Now, there are absolutely still cases where you do want to read the code. And what really kicked all of this discussion off recently was from Mitchell, where he posted something that he had done and somebody said, "Oh, that's like so much stuff. "How do you know?" And they deleted that post. But he simply responded, "I read the code. "That's how I know that it's quality." And this, of course, got almost 800,000 views and a lot of people provided their own takes. And actually, I really liked the take from the primogen and his idea of read the code. And that's where he comes talking about, like it's kind of a spectrum and there are some cases where I just really want to read the code and I really want to understand how this works. So definitely recommend you take a look at what he has got over on YouTube as well, 'cause it's really great. This is Better with Kent, where you and I learn durable skills together to continue to get better. And I want to say that, yes, I do read the code sometimes, but in fact, most of the time, and like increasingly is becoming more rare that I actually do read all of the code. And instead, I'm more reviewing systems. And I've got another video about that here. But what do I do to make it so that I'm not so much in the loop for code that I'm not actually going to necessarily be reading all that much. And that's what I want to talk about with you today. So here's the problem is that for a repo that you're not actively reading the code a whole lot, you end up being a babysitter, where the agent will open up a PR, or maybe you're just committing to main and you have less of a problem. But in the project that I'm working on, I actually do want to have pull requests so that there are very defined areas of work and I can have other agents reference it and stuff. So if you're working on like a total prototype, nobody cares about it or whatever, yeah, go ahead and commit to main. But if you're working on something that you actually sort of do care about, you just don't want to have to read the code all the time, you should absolutely be doing PRs. Anyway, so the agent opens up the PR and you're checking on CI, you read the AI review, and then you tell the agent to go check the review or you're providing that feedback back to the agent. Like you are absolutely a bottleneck there. And we talked about this in my loops video earlier as well. So you can take a look at that. You really should find ways to speed up this and get yourself out of that loop. Now we can do this even better. And in my loops video, I actually talked about turning that loop into a skill. And so I have actually done that now and that's what I want to show you. So now what I am getting is I get pull requests like this that are completely generated by the AI. And as I showed in the other video, I also have the system recap and the agent is iterating with the review bots. And ultimately, once it gets down to the bottom, the agent is the one that actually merges these pull requests, deletes the branch and everything. And then it actually will go and watch the deployment and test things as in so far as it can in production. This is a really pretty awesome thing. And what we end up with is I get these sorts of messages in Discord from Cody saying, hey, this is what I did. Here's the summary of the changes. Here are some relevant links. Go ahead and dive into those if you need to see what the PR looked like and the validation and the production deploy of all of this. So sometimes though, it's not going to just auto merge. Sometimes it's gonna find something like this one where it's like, hey, you know what? This is actually kind of a, it's a medium risk as far as the primitives are concerned, but it kind of has impact on a lot of things. Here we're changing how Cody runtime exports are bound. So like every execute call in Cody, which is like the primary interaction mechanism in Cody is going to be affected by this. And here's the agent conversation on this one. It decided to not auto deploy because it extends core runtime contracts. So with the details below, it changes this sandbox runtime contract used in every execute and package run. So it's well tested, but medium risk rather than genuinely low. So per your instruction, it's waiting on human look before deploy. So that instruction actually came from the skill ship PR that I wrote. So this actually integrates really tightly with Cody. Cody is what enables me to close the agentic loop in this way. So here, first I have the agents mark the PR as ready so that AI reviewers will go ahead and review it. And now it's going to wait on CI. It's going to fix any failures that could be in AI reviewer feedback, or of course, ignoring insignificant knits and already fixed things and wrong things. So it is going to be thoughtful and verify. And then it's also going to check mergeability with base branch and it's going to rebase. So like if there was some sort of conflict or something, it's going to fix that failure as well. And then if everything's looking good and there's no valid feedback left, then break out of the loop. Otherwise we're going to continue the loop. So there's your ship PR loop. But then when it's all done, it's going to squash and merge, but only if the requested change is a low risk or I explicitly requested that. So it'll squash and merge using Cody and then watch the deploy and then grab any relevant links. And also giving some other useful packages in case the agent that's using this doesn't have the GitHub CLI or something like that. So Cody has the tools that it needs to be able to do all of this stuff. And then here's an example of the code that it needs to write to send me the message on Discord. And that works super, super well. So this is what I have been using to make my agents as autonomous as possible. And it has been really awesome. I have had some pull requests that were autonomously developed and deployed that were like 8,600 lines of code across 82 files. And it was something that I knew that the agent was going to just nail just fine. And it would not be a big deal. And even if I had to fail forward, it would be fine. These are new features that users aren't going to encounter yet anyway, or they're hidden behind a feature flag. That's another really good use case for just ship it and we'll review it after it's been deployed, all of that, review that experience. These agents are just getting really, really good. So depending on the situation where you're at, you might be able to just ship, ship, ship and come back and review things after the fact. Maybe not necessarily the code, but the system, all of that. So really it comes down to this spectrum of how comfortable you are with the factory that you have constructed to turn out features and bug fixes and how good those agents are at doing that, as well as the primitives that you have available and how easy it is for the agent to decide whether this is a high risk or a low risk thing. And this is something that I've set up in the CODI repo really well at this point. And so the agent has a really good read on whether the changes it's making are going to be high risk or low risk. And so I'm able to tell the agent, hey, if you think that this is a low risk thing, then go ahead and just ship it. Like I don't have to be involved with that and just send me a Discord message when you're done so that I know that it's finished and I can do some more testing or whatever from my point of view. So all of that really comes down to how good of a factory you've built and how comfortable you are with shipping stuff that you haven't actually read yet. Now we are not at the place where you can be building like autonomous plane flying software or a medical device or something and you can just ship blindly. I don't want you to do that. But I do think that we're headed in that direction and that is the trajectory that we are going to be shipping more and more code that we're not reading. And I think that that's okay. I think you do need to step away from the code as Uncle Bob said on the "Become an Epic Product Engineer" podcast, which at the time of this recording is not out yet, so look forward to that on the "Become an Epic Product Engineer" podcast. But yeah, pretty much I have been doing this workflow for a long time. It's only recently that I decided to make this an actual skill and I invite you to go ahead and use it. And you know, I actually wanna make one point and that is that I didn't just jump straight to this skill. I kind of dragged my feet on this a little bit. In fact, I looked and I had done this loop thing 92 times before I turned it into a formal skill. And that helped me make sure that I was writing a skill that was actually useful and it was doing what I actually wanted it to do. I think that sometimes we just jump into these skills too fast and it might be better to just work with the agent a little bit more manually at first until you figure out what the right flow is. And so you also end up writing so much more when you're not sure what the thing should actually do when skills really should be shrunk down and as minimal as reasonable for what you're trying to do. So your homework for today is to try shipping a PR. You don't have to use the ship PR skill if you don't want to. You can fork this and make it your own. It's got like some Cody specific things. So if you don't have Cody currently, then reach out to me and I will give you early access. Or you can just adapt to this for whatever skills and MCP servers that you currently have. But see how tight you can make this feedback loop. And when you know that a change that you're making is going to be pretty simple and you think that the agent is going to nail it, just go ahead and tell the agent to merge it itself and test it out in production. You'll be surprised what's possible. But yeah, make sure that your team is good with that before you do this in the product at work. With that, I just want to say thank you so much for taking some time to get better with me on Better with Kent. And please like, comment, and subscribe and all of those good things. Share this video with the people that you love. And I look forward to seeing you in the next video. Thank you for getting better with me.