9: Reflection

Blog 10! Here’s what I’ve learned, as it relates to larger patterns within myself, during my senior project.

Some people say that there’s no end to optimizing an AI model (or the software development cycle, in general), and they might say I fell into that trap when pacing my senior project. However, I propose an alternative issue that hindered progress—my unwillingness to write code.

Unwillingness to write code? Isn’t your entire project writing code? You may ask. Well, yes, it is writing code. But a lot of machine learning isn’t just implementing the model architecture with lines of code, but rather adjusting the parameters within that code. How many epochs will you train your model on? In those epochs, how many datapoints will comprise a single batch? What is your dropout rate? What is the patience of your learning rate optimizer? These are just a segment of the features, when tuned, which can produce vastly different results for model performance.

This is the trap I fell in.

You see, at many points in model development, I had, through output inspection, determined fundamental model problems that could be resolved with a model redesign—set- and player-agnosticism, a weakness in LSTM memory, or greater logic in preengineered features—that I chose to delay the development and evaluation of. This is because, as I will realize later, I don’t like coding. 

Specifically, I don’t like having to build code to implement new features. There is so much mental burden in typing out the algorithms pertaining to a feature. I can have a vision for how the algorithm would be implemented in mental abstractions—the firing and connection of neurons—but having to write the code itself is boring. 

Contrast this with my enjoyment of debugging. Perhaps from years of competitive math training, I have grown accustomed to solving problems. My simian brain gains a particular neuronal activation successfully resolving bugs that cannot be replicated with any fulfillment of implementing a new feature. When I spoke to my other software friends, they could not disagree harder—their frustrations when debugging is to me a practice of grit, an exercise of intellect. 

My habit of tuning parameters was born not from an obsession with parameters, but rather, a boredom with coding itself. Ironically, I do enjoy devising clever structural solutions to the problems my models faced. From breaking down the task of one model into two, to devising a system that’s agnostic to set or player; these small tricks are the second product of my competitive math background. Debugging isn’t the only outlet for problem-solving; these designs are, too. Perhaps that’s what I’ve graduated into: from math proof writing to AI research; from math solution checker to programming debugger. 

I shouldn’t romanticise my disdain for implementing new features. After all, coding is a necessity in every line of work from every possible branch of my future. Thankfully, I also avoid vibecoding due to a mix of informed and biased prejudice, so I am forced to write my own code, and in turn, conquer that disdain.