Reading code and asking AI for help
Occasionally, while developing software—especially if it has been a while and since it has grown significantly—it becomes hard to wrap your head around some of the actual functionality that code expresses.
It is true when they say the hardest part that also takes the majority of the time is reading the code, not writing it.
Writing is easy when you have a clear idea in your mind. Actually, it is also somewhat doable if you don't have a clear idea. Because you can do what artists do: get in the flow and just feel it.
However, once the project grows reading and reasoning about the code prevails. And it gets exponentially harder if you don't take precautions and don't separate parts of your application cleanly. It can become one entangled mess of a code base.
This is where refactoring comes in.
And in contrast to the modern winds of thought around the AI and how it enhances productivity. If you blindly ask Claude Code or Codex to simply refactor part of your code base there is a very real and high chance that you will end up with a garbled mess of a code.
What's worse is that it is now you job to make sure that code is correct. It is your responsibility to make sure it hasn't introduced any new regressions and preserved the old ones (sic).
What might surprise you is that I don't advocate against AI here. I do advocate, however, caution when using it. It is a fine exercise, in fact, to wield this new tool. It can help us ascent the "just the developer" mindset and onto more business oriented, founder-like focus of giving command and controlling the output.
Put simply: using it strategically, sparingly and cautiously can lead to great results and save a lot of time.
How? Well, I try to write short posts and this one has gone for a while already. Stay tuned for tomorrow.