Office Hours — Should I still invest time building and maintaining open-source libraries when LLMs can generate code on demand?

Should I still invest time building and maintaining open-source libraries when LLMs can generate code on demand?

Yes, and the reasons are almost the opposite of what you’d expect.

The intuition is seductive: if Claude or GPT-6 Astra can write a sorting algorithm or API wrapper on demand, why maintain a library that does the same thing? The answer is that LLMs are terrible at the jobs libraries actually do.

What libraries do that LLMs don’t

A well-maintained library encodes three things code generation can’t replicate: accumulated constraints, tested failure modes, and stable interfaces. When you call an LLM to write code, you get a plausible implementation for the happy path. When you maintain a library, you’re encoding “we tried this 47 ways, here’s why 46 of them broke in production.”

Example: httpx is a Python HTTP client. An LLM can generate an HTTP request function in 10 seconds. It will handle basic GET and POST. It won’t handle connection pooling edge cases, certificate validation across platforms, timeout cascades, or the specific way your organization’s proxies mangle headers. It certainly won’t know that keeping file descriptors open under load behaves differently on Linux, macOS, and Windows. A maintained library absorbs those constraints over time.

The real cost of LLM-generated code isn’t the generation—it’s the debugging cycle when it hits the tenth production edge case nobody mentioned in the prompt. That compounds.

Why open-source libraries are becoming more valuable, not less

As frontier models get better at code generation, they also get better at code that looks correct. This creates a new problem: how do you distinguish between plausible-sounding code and code that actually works under stress?

Open-source libraries become the ground truth. When you use httpx, you’re not trusting an LLM’s judgment about connection pooling. You’re trusting the collective judgment of maintainers who’ve shipped this code at scale. That’s a different risk calculus entirely.

The LLM can tell you what httpx does. It can integrate it into a prompt. It can suggest which parameters to use. But it can’t replace the library itself, because the library is the tested constraint, not the code.

The maintenance tradeoff is real

Maintaining a library is expensive. But the cost of not having a well-maintained library for a critical domain is now higher, because LLMs will confidently generate broken alternatives that developers will use.

This is already playing out. Developers are using LLMs to generate database query builders, API clients, and data validators. Most of those are subtly wrong. The projects that are winning now are the ones that provide a library you can trust, plus enough documentation that an LLM can safely reason about it.

Curl, SQLite, and PostgreSQL didn’t get less important as code generation improved. They got more important, because they became the authoritative reference everyone—including AI—defers to.

Where to focus your investment

Don’t build libraries to replace manual coding. Build libraries to encode domain-specific constraints that LLMs will get wrong if left alone.

This means:

• Libraries for your vertical, not horizontal utilities. An LLM can generate a generic JSON parser. It can’t generate a schema validator that understands your company’s financial audit rules.
• Heavy focus on test coverage and failure documentation, not just API elegance. Future maintainers (and LLMs reading your code) need to understand the why, not just the what.
• Integration with how LLMs reason about code. If your library has clear error types and structured logging, Claude will call it correctly. If it’s implicit and magical, the generated code using it will be broken.

The uncomfortable shift

This inverts the old open-source story. For decades, we built libraries because manual coding was slow. Now we’re building them because generated code is fast but wrong. The library is the stabilizer, not the accelerator.

If your library solves a real domain problem and people actually use it, LLM proliferation makes it more valuable as a reference point, not less. The library becomes the thing other LLM-generated code is compared against.

Bottom line: Maintain open-source libraries that encode hard-won constraints about failure modes and edge cases; don’t maintain boilerplate generators. LLMs will commoditize the latter and make the former irreplaceable.

Question via Hacker News