Engineers have always strived to write less code. We’ve created paradigms, principles and ways of working to help us with this. DRY, utility functions, abstractions, shared sources of truth to help us build mature, stable solutions. Writing less code wasn’t the motivation but it did become the side effect.
But now code is cheap to produce, who is keeping an eye on these things? Why use an abstraction, or a utility function when AI can just reimplement it in seconds? Why even care opening your IDE to find out if these things even exist in your codebase anymore? Duplication is cheaper than understanding and you may be starting to just hope that your agents ‘know’ about them.
Most of the LLM generated code will compile, it will pass tests, it will provide you with a working feature or a fix but if no one is keeping an eye on the overall architectural decisions it could also be making your system weaker. By not understanding your codebase you end up delegating the implementation to an agent and then the judgement to a reviewer.
These many poor decisions wont announce themselves immediately either. Duplicate logic might behave identically for months before one implementation changes and the other does not. A bypassed abstraction might work until a new requirement needs to be applied consistently across the system. A badly placed dependency might remain invisible until a team attempts to remove or replace it. By then, the original pull request is long forgotten, the engineer has left and the cost is paid by someone else. During a migration, a redesign a sixth attempt to fix a bug that exists in three slightly different implementations.
A codebase can absorb poor decisions for a surprisingly long time. Until suddenly, every change becomes expensive.
Leave a Reply