The tale of the scheduled task that times out.
Another day in paradise. We are directed to fix a prod issue that has been happening on and off for some time. The scheduled task is timing out. Again. We need to fix it.We already moved the job to the middle of the night so it could have the whole machine to itself. More memory. More CPU. Still timing out. Ugh this thing. Someone ought to rewrite it. But this is a crucial piece of “the process”. If we rewrite it we got to be sure its rock solid. But there are no tests. We can see what the code is supposed to return, but how can we be sure it will do that when we change it?
We have to write tests now. A lot of tests. This is going to be such a slog. But wait! No it won’t. Lets open up our AI panel and ask [insert your favorite LLM here] to write us some tests. We can put in some inputs and see what is returned for real and then use that for our unit tests. Some of the tests are lacking. Sometimes our trusty assistant puts in assertTrue(true, "It works!") in our test. We need to have some conversation. An hour later we have us a test suite. This would have taken a week otherwise. Not because the coding takes a week. It would take that long to find the will to continue writing these tests. But now we are done. We have complete branch coverage so we know we are cooking.
We can now refactor safely. Hey this code seems to be doing a I/O within a loop. BTW if your code has few (under 10k records) and whatever you are doing is taking minutes instead of milliseconds its most likely you are doing I/O within a loop. Free tip.
Who wrote this stuff?
Another day in the land of the ticket system. GUMBO-2048 is our current assignment. 2048. That game went viral for a spell. But this bug has nothing to do with that game. Lets look at this code here. Oh my this does not look good. Who wrote this stuff. Got to pull out the trusty git blame. Oh man. I know this person. It is us from 6 months ago. What were we thinking! No seriously this code makes no sense. What does it even do. I bet I should ask my buddy Amy about it, she will know. But she is in a meeting I guess it will have to wait till later. But wait. We have our other buddy here. And they are never in a meeting. And they never get tired of talking to us. Lets analyze this code together shall we? Hey I found this text in old ticket, what do you think it has to do with this code AI? Oh yeah that makes sense. Can we rewrite this so its a bit more clear what it does? Maybe we can write a much better PR Description this time. I did not have you here 6 months ago and my descriptions were more like “Fixed bug GUMBO-911” and “removed unneeded code”. But now all the PRs are longer. Just be sure to proofread what we generate. Boy we got this sorted out without bugging Amy and we didn’t have to wait till “later”. Lets close this ticket. But before we do, why don’t we take 30 minutes to generate some tests. We can write stuff in the tests too, so people can see what the code is supposed to to. Comments in tests are wonderful BTW.
AI and Legacy Code
In Working Effectively with Legacy Code, Michael Feathers defines legacy code as code without tests. That definition remains extremely relevant today. In many organizations, tests are incomplete, ineffective, or cut entirely due to delivery pressure. Years later, teams are asked to refactor or modernize systems that nobody fully understands anymore.
But with modern AI tooling we can wrangle this legacy code no problem. The biggest obstacle to developers writing tests is time. For a relatively small section of code the tests can be ten times longer. Having them be generated by your friendly agent is a huge win. Another problem is that sometimes we gate ourselves because we want to bounce an idea on a colleague. In a lot of cases we can talk with our AI collegue first, and escalate only if we truly want a second opinion from someone else.