AI has made code cheap to create, but more code means more overhead.
Before coding agents, creating more code cost time and effort because engineers had to write it.
That naturally encouraged us to reuse code as much as possible: libraries, frameworks, keeping implementations concise, and thinking twice before rebuilding functionality that already existed.
Coding agents have dramatically reduced that natural cost.
Today, generating another implementation costs almost nothing. But you still have to maintain it.
🤖 Just Let the Agent Build It
There’s a growing mindset that because agents can generate code quickly, there’s less reason to worry about reuse.
Why spend time finding an existing library when an agent can recreate the functionality in seconds? And initially, that might feel faster, better.
But let’s say you have six applications that all need to validate email addresses against your internal requirements.
Instead of creating a common package, you let your coding agent implement email validation directly in each application. As long as the prompt is the same, it’s fine, right? Not necessarily. You can easily end up with six implementations, all slightly different.
Then you find a bug.
🪳 Creation is Cheap, Maintenance Isn’t
Fixing the application with the bug is easy.
Tell the agent about the bug; it fixes the implementation, maybe it adds some tests, done.
What about those five other implementations? Do they also have this bug?
Maybe, maybe not. Because each application has a different implementation, they may have the same bug or different bugs.
You’ve essentially found yourself in a situation where, depending on the application, an email might work, or it might not. Maybe it works in three of the six, or two. What happens if that email works for a registration page, but not the login page?
Not a great user experience.
🧱 Reuse Still Matters
Compare that to using a shared package. You write it once, everyone uses the same package.
You find a bug, fix it once, add tests, and release a new version.
Every instance using that new version has that bug fixed.
Now your suite of applications is consistent, and consistency matters most. Rejecting a valid email isn’t great, but if you’re consistent about it, that's a much better experience than it sometimes working and sometimes not.
That consistency is much easier to manage if the implementation is in one reusable library.
⚖️ Don’t Go DRY Crazy
Don’t use the above example to go to the other extreme, where every similar three lines of code turns into a shared library. Breaking everything into its own little shared library creates overhead costs, too.
It’s important to strike a balance between reusable and duplicative.
If you’re writing something with complex or nuanced behavior that’s needed across multiple applications, or more importantly, needs to behave consistently across them, a shared library is probably a good idea.
If it’s simple, situationally unique, and unlikely to change, don’t bother.
🧐 Final Thoughts
The cost of creating code has changed significantly. But the cost of managing it hasn’t.
Testing it, patching it, securing it, and keeping implementations consistent all become more expensive as the amount of code you own grows.
AI has made it incredibly cheap to create more code.
Don’t confuse cheap to generate with cheap to own.