After attending Toronto Tech Week and hearing all about the endless coding being done by AI, I thought about what happens to all that code. Understanding code lifecycles is vital for a developer, and I'm sure that much of their code is meant for a short cycle. Maybe even just a demo or one-time query. But what about the speed of development on projects that actually matter? What happens if we code too much? I've heard many stories about AI adding unnecessary items to code, writing useless functions, and bloating it overall.

So that brings me to the following.

Code is cheap. Code is also a cost. How can we not let cracks appear in repo with code bloat?

Firstly, we define "cost" and "cracks". In large part, code is considered a cost because of maintenance. But there are other costs to code.

• Firstly, it's frozen in time, and requires even more code to make it adaptive to time. Even then, there is no promise that we allowed it to adapt properly. The context behind why code was written a certain way changes over time, and decisions made years ago can become liabilities that need to be tracked and accounted for.
• There is a communication burden to code. There are layers of abstraction to code, from code which is what actually occurs, to comments which try and describe it, to documentation which is at a higher level, to even broader layers like the "prompt" where someone sends the general idea into an LLM. But because code is the source of truth, there is a burden to understanding it. Whether that burden is relieved with comments or other forms of documentation, they can fall apart over time as the code changes and they aren't updated. Even AI tools can only help so much, where you then need to have the context behind why code was written one way at the beginning, and the new context for why it is changing to properly adapt the documentation to the code changes.
• Code becomes a dependency, and small functions that weren't meant to stick can have whole systems built on top of them. The more that grows around it, the harder it is to improve that original bit of code because it requires changing everything that grew. Personally, I worry that with AI speeding up development, a lot more can grow in a short time, meaning that when the time comes to make a change, the cost associated will be astronomical.
• For cracks, I really mean any issue related to the above costs that start to show. Another example off the top of my head is a monorepo that grows so large that even an LLM has trouble parsing through it, and ideas/important information gets lost in the cracks. Some might argue that if you send an agent into the repo and give it enough time, it'll map it out and document it, but that itself is a cost and can have errors. If you trust the AI fully, you might not care. Personally, I would always worry that it missed something. Then again, I probably wouldn't trust a human reviewer either if the codebase got that large, so it comes down to us needing to work with the hands that we're dealt, and maybe AI is simply the best so it'll have to work, mistakes or not.
• If you read all this and think that it really isn't an issue - you don't see code bloating that much or believe that your tools will prevent any of these issues - perhaps I am simply a doomsayer. However, I will always believe that people will have moments of less effort, and without proper procedures in place, these will add up to a codebase that becomes increasingly complicated to navigate, add to, and refactor. AI tools will certainly make it easier, but even if they can navigate bloat better than some humans, the costs of their mistakes can be greater and harder to verify as codebase size increases.

In my opinion, the basic answer of how to prevent this is rigorous engineering standards. It can be having every single PR reviewed by an engineer (and trusting that they do it well), or perhaps augmenting reviews with AI review tools.

Given that people will code with AI for speed increases and less friction, it's impossible to discount its use. Do we trust that prompting it and using skills is enough to reduce bloat? There are cases of people noticing unused imports, unnecessary functions, and more, so is that really enough to mitigate these problems? I'm sure some would argue that with a good enough agentic-review workflow, yes. I would like to think so, but the side of me that focuses on risks argues that there is no guarantee because AI is a black box, and we cannot trust it completely. Again, I circle back to the fact that "good enough" is likely the answer, where it's the best option that we have.