AI makes code cheap to create, not cheap to own

AI has made code cheap to create, but more code means more overhead.

Photo by Christopher Gower on Unsplash

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.

---

Originally posted on #Bengineering.

If this hit home, share the original with someone who needs it: AI makes code cheap to create, not cheap to own

---

More from #Bengineering

• Agent Skills Are Becoming the Best Way to Capture Institutional Knowledge
  Reuse works better when standards and workflow knowledge are captured somewhere agents can actually use them.

• Your coding agent is missing one thing: architectural context
  Agent output improves when reusable context shapes the implementation instead of every prompt starting from scratch.

• Most teams put low-level architecture in the wrong place
  Component-level decisions belong close to the code so consistency survives day-to-day implementation.

• Generating Code Faster Is Only Valuable If You Can Validate Every Change With Confidence
  Faster generation still needs validation, or the maintenance cost just moves downstream.

More from Latency Slayer

• In-Flight Request Tracking: Lessons from Card Payments and HTTP/2
  A deeper look at correctness when duplicated assumptions meet distributed uncertainty.

• Are Atomic Operations Faster and Better Than a Mutex? It Depends
  A practical reminder that simple-looking implementation choices still need ownership and tradeoff analysis.