With AI, it's Cheap to Reinvent. But, Maintenance doesn't go away.

Before you can finish evaluating a library or framework, an AI coding assistant can reinvent a custom implementation for you.

In the moment, that can be astonishingly productive.

LLMs are exceptional at reproducing prior art, which creates a tendency to favor bespoke software. Generating a new tool can feel faster than understanding, adopting, and configuring an existing one.

This is a version of the greenfield trap: Starting with a clean slate is psychologically and structurally satisfying. Reinventing feels clean because constraints are hidden.

Diagram illustrating key features of mature libraries including backoff with jitter, cancellation, idempotency, error handling, retry support, deterministic tests, metrics and tracing, and synchronous/asynchronous support around a central code snippet. — A draft implementation misses the years of battle-tested decisions present in mature libraries.

The economics of creating software changed

Software used to be incredibly expensive to create.

Even small software components required engineering time for design, programming, catching edge cases, testing, and documentation. The high cost of software drove developers to use existing libraries or frameworks whenever possible.

When you use an agent harness for coding, really anyone, including non-developers, can create a custom cache, scheduler, auth wrapper, or deployment script, in minutes. It may even work as intended in the first draft.

So Generative AI has reduced the cost of generating code.

But what about the cost of owning software?

Ownership means comprehension: is the implementation understood? Are real failure paths tested? Is production behavior adequately monitored? Are vulnerabilities patched, users supported, upgrades implemented, and future migrations considered?

From experience, ownership isn’t as exciting as creating. Ownership introduces a sort of drudgery: fickle users, tricky bugs, and a never-ending parade of CVEs to patch, test, and validate.

Fast output vs. slow work

With a decent agent harness and model, you can crank out code at a volume that wouldn’t otherwise be possible.

So Generative AI makes coding progress visible very quickly. The crux is that perceived speed isn’t sufficient evidence of delivered value. METR’s randomized study found that experienced developers took longer on real tasks, despite believing they were faster.

It’s true that most established software components are reproducible by coding tools, as we’ve seen with the “rewrote project X in Y days” flavor of AI coding announcements.

But, the value of established software often comes from the years of testing, battle scars, and accumulated community trust.

Thus, the hidden work is:

Which assumptions did the generated implementation make?
What happens under concurrency or partial failure?
Were architecture decisions copied from outdated examples?
Who will understand the code six months from now? Will anyone need to?
Who owns the next version, patching, and software lifecycle?

Diagram illustrating hidden ownership costs associated with cheap generation, featuring sections for prompting a draft and listing inherited ownership costs such as comprehension, testing, security, monitoring, support, and patching.

Technical debt and reinvention

Custom implementations will have fewer users, fewer deployments, and less accumulated knowledge. This doesn’t mean custom implementations aren’t useful; they definitely are. It means custom implementations require their own validation, which must be owned by creators. Reuse is associated with less maintenance effort.

ownership debt

As with any project, someone must maintain it: someone who can explain the behavior, patch vulnerabilities, and respond to change requests. This includes practices like tracking security requirements, design decisions, supply chain/BOM verification, and so forth. If you don’t accept this debt, your project is likely to face severe security challenges and much more painful debugging.

organizational fragmentation

If you give five teams a similar problem, you’ll likely get five generated wrappers, clients, validation frameworks, and deployment tools. This is inexpensive at the beginning, but complex in the long tail: You get duplicated documentation, inconsistent behavior, and repeated security vulnerabilities.

Adopt, adapt, invent

Before jumping to AI generation, consider your options.

Adopt

Existing tools/components are great. Use them when you can. However, remember that dependencies bring their own risks:

abandoned maintainers;
vulnerable transitive dependencies;
incompatible licenses;
oversized APIs;
poor operational behavior;
upgrade pressure;

Adapt or Contribute

Small adapters can extend existing components: something like a custom plugin or integration. If you have a need that isn’t represented in an open-source project, consider contributing back (but only after testing, vetting, understanding your change).

Invent

If you have domain-specific needs, build something new. Existing tools may either not meet your constraints, or the need is important enough to justify long-term ownership.

Notice that “AI can generate it” is not one of those reasons. AI tools are excellent at helping you discover, evaluate, and use existing tools. However, sometimes they introduce their own biases: For example, I wouldn’t ask Claude for opinions on competing products.

Final Thoughts

Implementation is both easy and abundant, which changes the calculus of assessing engineering effort.

Judgement becomes more valuable, changing the question from “Can we build this?” to “Should we build this?”

Strong teams will use generation selectively, and retain judgement on reuse, standards, and ownership. Knowing both what not to build and what efficient design looks like is still valuable.