Gorewood Logs

The Rediscovery Threshold

Ask a coding agent for a cache in a particular language and watch what it does.

It may go looking for a library. But I often see mine simply build one for the task at hand. No comparison of five packages, no rubric for maintenance and compatibility, no integration work to accommodate someone else's design. Just the behavior the application needs, with tests, evolved as needed.

That's an observation from watching agents develop software for me. I haven't measured how common it is across models or projects. But it keeps raising a question: when implementing something gets cheap, which dependencies still earn their keep?

I wrote about this in January in Maybe We Need Fewer Dependencies?. I still think there's something there, but “fewer dependencies” is a blunt way to describe it. The more useful distinction is how much knowledge you would have to rediscover by replacing one.

The code is only part of what you're acquiring

If you need a small, well-understood component, acquiring it has a cost. You have to find a package, understand its assumptions, assess whether you trust it, and integrate it. You inherit its dependencies and some relationship with its future releases.

Writing the code yourself also has a cost. You have to specify the behavior, check that it works, and maintain it. An agent can help with all of that. It doesn't make those responsibilities disappear.

The interesting change is that implementation can become cheap enough for the comparison to come out differently.

For a bounded cache, maybe you need a particular eviction policy, a fixed capacity, and a clear rule for replacing entries. If those requirements are understood and straightforward to check, a small implementation might be less work than evaluating and accommodating a general-purpose package.

But add concurrent access, persistence, subtle memory constraints, or guarantees under failure, and the decision changes. “A cache” can describe a small utility or a substantial engineering project. Knowing the category doesn't mean you understand the requirements.

The rediscovery threshold

Expecting an agent to casually rewrite a database driver or a cryptography library would be ridiculous. The same goes for replacing React or Git because the agent can generate something that resembles the obvious parts.

You aren't just acquiring code in those cases. You're acquiring years of compatibility work, security expertise, performance tuning, and experience with situations you haven't encountered yet.

Unicode handling and operating system adapters belong in this conversation too. A small interface can conceal an enormous amount of hard-won knowledge. Line count tells you very little about how expensive that knowledge would be to reconstruct.

That's what I mean by the rediscovery threshold: the point where replacing a dependency means taking responsibility for a body of knowledge you cannot cheaply reconstruct and verify.

An agent making the first implementation quickly doesn't tell you where you are relative to that threshold. A convincing demo might exercise exactly none of the behavior that makes the existing library valuable.

The question I want answered before accepting the bespoke version is: what would we unknowingly be taking responsibility for by building this ourselves?

There is another end of the spectrum

Then there's the npm micro-library extreme, where a package can save you a few straightforward lines while adding another dependency relationship to the application.

It's reasonable to ask whether that trade still makes sense when an agent can write and check the required behavior with little effort.

That doesn't make every tiny package foolish. Something short can still be subtle. Nor does a quiet issue tracker mean a library is abandoned; some things are finished. The value has to come from examining what the package actually does and what you would inherit by replacing it.

Dependency evaluation itself still matters. You need enough investigation to distinguish ordinary implementation work from a problem whose complexity you haven't recognized. Cheap code is a reason to reconsider the choice, not a reason to stop thinking about it.

Ownership isn't immunity

My earlier post was too confident about the security benefits of bringing code in-house. Owning an implementation doesn't make it safe, and generating it yourself doesn't remove the rest of your toolchain or supply chain.

You may avoid a particular package and its transitive dependencies. You also become responsible for defects that an upstream maintainer might otherwise have found and fixed. A conversation with an agent can produce a patch; it cannot establish that you've discovered every important failure mode.

The sensible comparison includes the work of checking and maintaining the implementation, alongside the work of acquiring and integrating the dependency. The cost of getting it wrong belongs in that comparison too.

I expect cheap implementation to move some decisions toward bespoke code. I don't expect it to erase the value of accumulated engineering. If anything, it makes that value a more useful thing to look for.

A dependency should earn its keep through what it lets you safely avoid having to know and maintain. Sometimes that is an enormous amount. Sometimes it's a few lines you could understand completely.

The rediscovery threshold is the difference I want my agents to recognize before they start typing.

Optional reading