AI Killed Clever Libraries

This is the second post in a series where I share how I use AI in practice on a real SaaS project -- what works, what doesn’t, and where the hype breaks down.

For most of my career, I picked tools the same way many engineers do: by reaching for elegance. I liked small APIs, clean abstractions, and libraries that felt like someone had really thought about the problem. When an LLM recommends something with that same "clever-but-minimal" vibe, it's easy to trust it--especially when the recommendation comes packaged with confident reasoning.

The problem is that cleverness doesn't age well. In practice, the libraries that feel the most "right" in isolation are often the ones that quietly fall behind the ecosystem around them. You don't notice it on day one. You notice it when you're a few weeks in, when the examples don't work, when the docs describe an API that changed two releases ago, or when a dependency chain pulls you into deprecated packages you didn't choose.

What breaks first is the ecosystem

Usually the core idea is fine. The implementation might even be excellent. What fails is everything around it: documentation drift, incomplete examples, stale Stack Overflow answers, and issues that never get a response. For a human, this is frustrating but survivable. You can read source, skim old issues, patch locally, and keep moving. You pay a tax, but you stay in control.

Where this becomes more than an annoyance is when you're relying on AI assistance to keep velocity high. The ecosystem isn't just "nice to have" anymore--it's part of what keeps the development loop grounded. When the ground disappears, the whole loop changes.

Agents don't degrade gracefully

Humans adapt. Agents don't, at least not in the same way. When an agent runs into a documentation gap or a version mismatch, it tends to keep pushing on the same surface. It will retry the failing approach with minor variations, propose fixes that sound plausible, and invent APIs that would make sense if the library still worked the way the docs claim it does.

That failure mode is subtle because it looks productive. There's always more code being generated, more attempts, more suggestions. But the output stops being connected to reality. Instead of making forward progress, you spend time filtering confident noise.

When unsure, the model hand-rolls

Even when a good library exists, models often avoid using it. Depending on a library means committing to an API surface that the model may only partially recall, plus a bunch of version-specific details that aren't in the prompt. From the model's perspective, it's often safer to just implement a "good enough" subset.

So you get bespoke parsing, homemade retry logic, a quick caching layer, or a hand-built rate limiter. It's not always wrong, but it tends to be shallow. It ignores the weird cases, the concurrency hazards, the production scars--the things that pushed a library into existence in the first place. You end up recreating old bugs in new code, except now it feels "fresh" because it was generated.

Popularity becomes a practical advantage

This is the part that used to feel unfair to me: popular tools are often messier. They have historical baggage. They ship features you'll never touch. They aren't elegant in the way a tight side project can be. But they come with something that matters more in an AI-assisted workflow: a living ecosystem.

With popular frameworks, there are recent examples, current blog posts, answered questions, and issues that reflect the code as it exists today. Even when the official docs are imperfect, the collective output of the community fills in the gaps. That creates many more "anchors" for both you and the model. When something breaks, you're less likely to fall into a reality mismatch where the model is reasoning from an outdated mental snapshot.

Popularity is also a proxy for model reliability

There's a second-order effect here that's easy to miss. For an LLM, popularity isn't just social proof--it's training data density. The more widely a tool is used, the more likely it is that common usage patterns are represented in examples, discussions, and code. That makes it easier for the model to stay on the rails. It's less tempted to improvise, and more likely to converge on solutions that actually work.

This doesn't mean popular equals good. It means popular equals recoverable. When you hit a snag, there's enough shared context in the world for both you and the model to find your way back.

My dependency checklist got more boring

This has pushed me to change how I evaluate libraries. I care less about whether something feels "right" and more about whether it's alive. Recent commits matter. Multiple maintainers matter. Ongoing discussion matters. Evidence that people are using the tool in production matters. These are boring signals, but they correlate strongly with whether the tool will still be usable when you need it--especially when you're asking an agent to navigate it.

It also changes how I think about long-term maintenance. Clever tools often encode a very specific mental model. That can be a strength early on, but it becomes brittle as systems evolve. Popular tools tend to absorb change better, not because they're prettier, but because they accumulate migrations, workarounds, and shared understanding over time.

The conclusion I didn't expect

If you're building systems you expect to grow--and you expect AI agents to be part of the loop--then elegance is secondary. The safest choice is often the boring one: popular, actively maintained frameworks that come with an ecosystem big enough to keep both humans and machines grounded.

Cleverness without an ecosystem doesn't stay clever for long. It just turns into technical debt with a nice API.