Maybe We Need Fewer Dependencies?
The "SaaS is dead" discourse has been circulating for a while now. Steve Yegge put a sharper edge on it: SaaS isn't exactly dead, but it's going to need harder moats. The easy-to-recreate automation tools are in trouble because businesses are discovering they can vibe-code their own. What survives is the stuff that's genuinely hard to replicate—years of enterprise bug fixes, deep industry knowledge, battle scars that can't be prompt-engineered.
I've been wondering if the same logic applies to open source.
Working with agents, I keep hitting a decision point: do I let Claude build something bespoke, or do I force it to find and integrate an established library? Increasingly, the bespoke path is easier. Not always better—easier. The agent can whip up a functional date formatter or retry wrapper or state machine faster than it can research which of the seventeen npm packages is actually maintained, figure out the API, and wire it up correctly.
This would've sounded insane a few years ago. The micro-library era taught us the opposite lesson. Node.js exploded onto the scene with a philosophy of tiny, composable packages—and then left-pad happened. Eleven lines of code got yanked and briefly broke half the internet. The supply chain attacks that followed were worse. We learned, painfully, that dependencies are attack surface, that node_modules weighing more than the app itself is a smell, that maybe we'd outsourced a little too much to strangers on the internet.
But the solution back then was better package management—lockfiles, security audits, provenance checks. The assumption was still that external dependencies were the right default.
Now I'm not so sure.
When an agent builds something in-house, I control the whole thing. I can run my own SAST tools. I can audit it line by line—or have the agent do it. There's no upstream maintainer who might abandon the project, no transitive dependencies I've never heard of, no possibility of a supply chain attack through code I didn't write. The agent can harden it on demand. If a vulnerability appears, fixing it is a conversation, not a dependency upgrade that breaks three other things.
This doesn't mean agents build better code than mature OSS. A well-maintained library with years of edge-case fixes will outperform a one-shot implementation. But "well-maintained" is doing a lot of work in that sentence. How many of your dependencies actually qualify?
So maybe OSS follows the SaaS trajectory. The battle-hardened, deeply complex, genuinely irreplaceable projects survive. Cryptography libraries. Database drivers. The stuff where getting it wrong means getting it catastrophically wrong. Everything else starts competing with "Claude can build that in ten minutes."
I don't know if this is good. OSS created a lot of value—shared infrastructure, community knowledge, careers built on visible contributions. If the middle tier hollows out, something is lost.
But I also remember the dependency hell. The phantom packages. The feeling of building on foundations I couldn't see and didn't control.
Maybe the future is fewer dependencies, better chosen. Maybe it's the return of "just write it yourself"—except now you're not the one writing.