The Era of AI-Assisted Coding and Its Hidden Technical Debt
Technical debt refers to choosing quick solutions like snap judgment over the slow thinking well-thought solutions. Such choices would incur a long-term cost. These fast solutions accumulate silently in the long run and while everything still seems to work, no one knows the details to the bit level.
Recently I was able to produce far more code in a day compared to before. I have been writing code since high school and, to be honest, I am truly amazed by this productivity boost, but I used to know every part of my code to the bit level. The more I rely on AI generated code the more I feel a fear building up about my hidden technical debt. Of course, the code runs, stuff work, and development is fast—yet the structure slowly goes out of your grasp and possibly deteriorates. You don't feel that you know every part of the code.
In small projects this is usually fine, but in larger codebases it can be serious. It AI generated code creates duplicated logic, low level code, and increasingly hard to reason about.
I keep noticing with AI-generated code that there is more **Low-level code without abstraction.** For instance, when I was generating this simple github homepage, the output was a collection of raw HTML files meant to be edited by hand. As I had a bit of experience with web development, I preferred using shared templates, headers, footers, or dynamic content loading. So I had to iteratively prompt the AI tool to hammer the product into a better shape. That created a new issue of having a lot of **Unused code**. AI tends to generate variants for each prompt that you never end up using. Specially when you are testing new ideas and iterating (which is usually the case in my experience).
I have been thinking about this issue and figured that using **functional-style design patterns** tend to reduce side effects and make the flow easier to oversee. Classes—especially with inheritance—can introduce hidden state and rigid structure.
I am not criticizing the use of object-oriented programming in general. I rather believe that OOP is useful when it fits the problem. Yet many programmers start with classes by default seems they assume OOP without thinking twice. I blame academia for this programming habit, where they teach OOP as **the** way to go.
I think in the age of AI generated code, we need to revisit those defaults. Generating code is becoming easy. Designing a good structure is becoming more relevant. Should we continue using OOP or not? I doubt it.
Recently I was able to produce far more code in a day compared to before. I have been writing code since high school and, to be honest, I am truly amazed by this productivity boost, but I used to know every part of my code to the bit level. The more I rely on AI generated code the more I feel a fear building up about my hidden technical debt. Of course, the code runs, stuff work, and development is fast—yet the structure slowly goes out of your grasp and possibly deteriorates. You don't feel that you know every part of the code.
In small projects this is usually fine, but in larger codebases it can be serious. It AI generated code creates duplicated logic, low level code, and increasingly hard to reason about.
I keep noticing with AI-generated code that there is more **Low-level code without abstraction.** For instance, when I was generating this simple github homepage, the output was a collection of raw HTML files meant to be edited by hand. As I had a bit of experience with web development, I preferred using shared templates, headers, footers, or dynamic content loading. So I had to iteratively prompt the AI tool to hammer the product into a better shape. That created a new issue of having a lot of **Unused code**. AI tends to generate variants for each prompt that you never end up using. Specially when you are testing new ideas and iterating (which is usually the case in my experience).
I have been thinking about this issue and figured that using **functional-style design patterns** tend to reduce side effects and make the flow easier to oversee. Classes—especially with inheritance—can introduce hidden state and rigid structure.
I am not criticizing the use of object-oriented programming in general. I rather believe that OOP is useful when it fits the problem. Yet many programmers start with classes by default seems they assume OOP without thinking twice. I blame academia for this programming habit, where they teach OOP as **the** way to go.
I think in the age of AI generated code, we need to revisit those defaults. Generating code is becoming easy. Designing a good structure is becoming more relevant. Should we continue using OOP or not? I doubt it.