As you surely have, I’ve spent most of my work time this past year coding with AI. Fumbling with it at first, then finding a relationship with it, and now having it largely do all the hard work.
I peek in and out of the codebase at times, but the rush of excitement to have giant leaps of work done in a shot often usurps the urge to really clean things up along the way.
My approach with this new way of building is unlike most. I’m into build smaller things now. Contained things. Beautiful things at the surface. Things that I release without an expectation I will ever augment them. Like a finished book or song, it was my creative thought in that space of time.
This, unexpectedly, has created a confounding dilemma.
You see, I don’t have to go back in and clean the code up later. When the finish line is pretty close, and there is no v2 or v3, let alone a v1.2 or v1.3, a thing that works well should just always work well.
What if the code is ugly? If, peering under the hood, you see all sorts of cruft, does it matter? If a closed codebase is ugly and no one is around to look at it, does it cause a problem?
Clean, beautiful code was always a means to a larger goal—of maintenance, extensibility, and so forth. But if ugly code works, and the goal is to not change it, is it worth changing?
I’m finding the answer to this question hard. I’ve spent my whole career keeping code pristine for both the sake of the larger goal and the simple principle that things should look nice. If the former is gone, is it worth the latter?