I delete tests every night, and I have my AI agent do this. This is part of the loop that I have my agent on to make my code base better every single day. And in a way that I don't have to be super involved. So this is better with Kent, where you and I get better together by learning durable skills that will be valuable even as AI agents improve. And in this video, we're going to talk about the PR that I wake up to every morning to keep my code base, my software factory in tip top shape. So every morning I wake up with a PR that deletes more lines than it adds. And yes, I know that's actually very difficult to do when we're talking about AI, which seems to only want to add code. It's so hard to get them to delete it, but I manage it every single morning. I get rid of a whole bunch of tests. And now, wait a second, Kent, like what's going on? Why do you want to get rid of tests? Aren't tests really good? Aren't you the testing guy? TestingJavaScript.com. I learned testing from you. No, I actually really am very intentional about my tests and more tests does not necessarily mean better tests. I don't want to have flaky tests. I don't want to have broken tests. I don't want to have low signal tests with tiny cases and wrappers and duplicates that are all over the place. And honestly, this is what AI is generating now. Maybe in the future AI will get better at all of this, but even in that future, it will be useful for you to understand what makes for a good software factory so that you can develop better software. And that means that you're intentional about your tests. So a couple of the reasons why this matters is because tests are actually expensive, not just in the process of creating them. That has actually gone down in expense. Like this is a thing that AI agents naturally do as they're writing the implementation as they often will write the test for it as well. I suppose it depends on your harness, but mind you. And so yeah, creating them is actually really cheap now, but what makes it expensive is how much it takes for them to run and how much it makes it a pain for AI agents to make changes. And the fact that like with the localized changes an agent is over here and it's making a bunch of changes going to test its stuff. There's going to be duplicate a test coverage from somewhere else, completely somewhere else in the code base and the agent has no idea that this is already covered and so it doesn't need to have a test for that, all of these things. So fact is that agents love these really tiny little tests and even so tiny that they will export a constant value from one module and then in a test, they will import that value and assert that value. So it'd be like magic number equals 42 and then in the test, it imports magic number and asserts that it's 42. It's bonkers, it's crazy. And so maybe one day the agents will get better at this, but today they're not quite there and that is like the least of our worries as far as like tests that aren't very helpful. So yeah, they love the tiny test. They love to pin every single error string and stick that right in the test. They like to test edge cases that won't ever happen. And of course, there's all the fallbacks that we have to worry about as well. Often they will make a test that has only one assertion and just have a whole bunch of tests that do basically the same thing over and over and over again and just have one assertion for each one of these things when really those should all just be combined. So just because you have a whole bunch of green checks in your CI suite and like a whole bunch of tests that doesn't necessarily mean that you're more confident that your software isn't going to break and let's all remember here, the whole purpose of having a good test suite is so that you can have confidence. And so just because you have many of them doesn't mean that that's good and in fact it can mean that it's worse because it's slower, it's harder to change and it's still missing on the actual user journey that you're trying to validate is actually working. And so we do have to be mindful about these tests. So there are actually some principles that I use when I am writing tests and I have handed these off to agents to implement in the test that they write. This doesn't quite make the agents do exactly what I want them to do, which is why I delete tests every night and we'll talk about that in a second. But let's take a quick detour to talk about these testing principles. So here in the Kody repo, I have this testing principles.md file. This is referenced by the agents.md file, which is just a really short file, just links to some documentation that agents naturally will go and find. It's similar to skills, but they're not callable or loaded automatically or anything like that. And this works really well for me. But if you want to stick this in a skill somewhere, be my guest. In any case, testing principles is basically just like distilled all of my education, my blog posts, everything, and also those of others into some basic principles that I think are really valuable. One of the most valuable is this fewer longer tests, which I wrote about years ago, where it's just so common back in the day and even today that you'll have individual tests for every single thing and just repeating yourself for every one of those things. And this used to be really valuable because that test message would show up in the output and it'd be really easy to see which part of the whole process failed from that test output. Well, our test output has gotten really good now and so you can have many assertions in there and it doesn't hinder your experience in debugging and finding out what went wrong. So you want fewer tests that are longer. They actually should go through an entire flow. And we could go through every one of these and feel free to ask me if you'd like a video where I do a deep dive on some of these principles in here. Some of these also are kind of specific to my test base as well. But the point here is that you have some principles. You are intentional about the way that tests are written in your code base. And this has worked out really well for me in kind of guiding the agent to build out test base that I'm happy with. And actually, here's another example where I am steering the agent to do something that it's not used to doing. There's nothing in the training data about this symbol.dispose or async-dispose API with the using keyword. That's just a relatively new JavaScript feature that drastically simplifies our cleanup process. And I use it all over the place. So I've got this especially longer section to explain how that works because it cleans up the tests quite a bit. Now you might be saying, OK, Ken, well, that's all well and good. But do you actually care about the way that the tests are being written? And maybe in the future, I won't. But I find that when the tests are cleaner, the agent is able to work in that area better. And so it actually does make some benefit. So here's an example of a pull request I wake up to. Here it's test trim, low signal, community suites, and consolidate coverage. So we've got this feature in Kody for community packages. And I added a feature the day before this showed up where an agent added a whole bunch of tests. And you can take a look at the files changed and see we've got a bunch of stuff getting deleted and removed some files that are completely deleted altogether. I never really look at this. What I pretty much look at when I look at these is I first make sure that we are reducing the number of lines because typically when you're combining tests and deleting, low signal tests and things, you're going to end up with fewer lines. And then the other thing I look at is the removed, consolidated, and kept. This normally the pull request is going to say here are the general summary things that we did in here. And I'm going to say, OK, here's some low signal or duplicate stuff. Here's what we consolidate and stuck together. And here are the things that we absolutely kept because they're really a high signal, valuable, end user journey stuff. And then sometimes I will go through this, and you'll see that we're deleting this test, but we're keeping these assertions. And this is one where we're actually merging the previous to the current. So my point here is not necessarily to show you a specific test or a specific principles, but to show you the automation that powers all of this stuff. So here is the automation. I just call it Keep Tests Tight. And it's active in the Kody repo on the main branch. And every day at 3 in the morning, my time, it will go through. And it'll check if there are any changes in the last 24 hours. If there weren't, then we just exit. So we've already hand cleaned everything up. I don't want to waste tokens on nothing, though it might still be useful, but we'll just do it in the next 24 hours. If I'm not actively working on the project, then I don't want this automation to run anyway. And then I explain to the agent that sometimes agents are going to create many regression tests and other tests to help them verify the work. This is good. I don't want them to stop doing this. And so you could just say, hey, can't, why don't you just tell the agent in the first place to do the right thing. But really, the right thing is to validate its work. Like if I say, hey, we're removing this feature, and it has a test assertion that that feature no longer exists in the UI, that's actually useful for it as it's iterating and making sure that it did the thing that I asked it to. But two months in the future, when that feature doesn't exist anymore, do I really need a test that verifies that feature isn't there? No, the answer is no. I don't need that test. And so it's useful to have for the agent when it's building it, not useful for us to keep around. And so that's why this is an automation and not just something that I tell the agent to do in the first place. And on top of that, they don't always do it quite right in the first time. And so having something to come through and clean things up and tighten things up, whatever, is quite useful. So I tell it to check the testing guidelines in the repo, which it very easily finds because it's linked from the agent's MD. And make sure that everything's high signal and follows the guidelines. For any which don't, edit, combine, delete, or otherwise update the tests that we carry. Don't carry the weight of tests that provide minimal value. So if changes were necessary, create a PR. Market is ready for review. And also make sure to run formatting before commits. I think I could probably delete that now. The models are better now. But when I wrote this-- oh, actually, I'm using Composer 2.5, which is quite good. But now I'm actually going to switch it right now to Grok 4.5 because it's even better. So that'll be nice. We'll see how it changes my PRs going forward. The other thing that I might add in here is Kody, as an MCP server, because Kody can help occasionally in the investigation and everything. Cursor does itself have integrations with GitHub. And that's probably all that it needs. But it could be useful in the future. So I'm going to add Kody to that as well. And with that, that is what I do. I wake up every single morning with a PR that reduces the amount of duplicate or already covered or unnecessary workflows that are repeated. And we are left with just high signal stuff that keeps our tests tight. And it's really nice. And ensures that even though things were valuable at the time the agent built it originally, we trim it down when it's time to keep something long term. And it makes it just a lot easier to keep up with. So my encouragement to you and my homework that I'm going to leave with you is for you to just do this once. Just ask an agent with-- like you could copy paste my automation if you want. That prompt. Just give an agent say, here are my testing principles. And I want you to go through the code base and just make sure that we're following that, delete things and combine things, whatever, so that our test base is better. And just take a look and see if it actually does reduce the number of tests and improve the test base going forward. So that's your homework for today. This has been Better with Kent, where you and I get better together. And now I'm going to go ahead and delete some more tests. Thank you for getting better with me.