Dependencies Are Over. The Risk Is Not.

Jarred Sumner, who built Bun, posted a prediction this week: dependencies are over. His example was Brotli. One vulnerability in one compression library landed in .NET, Node, Bun, and Envoy at the same time.

He is right about the blast radius. He is right about the trend. Here is the part nobody is pricing in.

Why he is right

Your dependency tree is not yours. Forty direct packages in a Laravel or Node app easily become nine hundred installed ones, most of them written by people you have never heard of, some of them maintained by one tired person in their spare time.

I ran a credit-monitoring SaaS as Chief Technology Officer (CTO) for a decade. Seven million queries a month, ten thousand clients, and a stack of other people's code underneath all of it. Every serious incident review eventually walked down the same path: our code was fine, a package three levels deep was not.

AI just changed the economics of escaping that. Vendoring a small dependency used to take a week of careful work. Now it takes an afternoon and a good prompt. Teams will do it. They should, in the right places.

The risk moves. It does not leave.

Fewer eyes and more AI will leave doors open. Here is what a public package gives you that a rewrite never will:

1. A patch stream. When a flaw drops in a popular library, the fix is usually public within days and your tooling flags the upgrade. Your clone gets no advisory, no flag, no fix. It sits there, vulnerable, at the exact version you generated.
2. Other people's paranoia. Popular libraries get fuzzed, audited, and attacked in public, and they get stronger for it. Your rewrite gets read once, by you, on the day you were in a hurry.
3. A fighting chance the bug is new. A rewrite modeled on the original tends to inherit the original's behavior, including, faithfully reproduced in fresh syntax, the flaw you were running from.
4. An answer for the auditor. In regulated work, someone eventually asks what your software is made of. "A model wrote it from a prompt in March" is a short meeting.

And one more that gets skipped: provenance. A rewrite produced by studying licensed code is not automatically clean code. The license question follows the derivation, not the file extension.

Where I draw the line

Rewrite the small, boring, fully specified utilities. The date formatter. The slug generator. The little adapter only your app uses. Those were never worth a supply chain.

Never rewrite cryptography, compression, parsers, or authentication from a prompt. Brotli is the example that proves the rule twice: the flaw showed the risk of depending on it, and the fix showed the value of the crowd depending on it with you. A thousand teams found that bug because a thousand teams run that code.

For the critical layer: pin versions, watch the advisories, and patch on a schedule instead of in a panic.

The honest summary

I publish Laravel packages myself. I have been the dependency in other people's trees. So hear this from both sides of the fence: deleting a dependency does not delete the work. It transfers the work to you, forever, including the 2 AM parts.

Dependencies are over for the trivial layer. For everything else, the job was never installing the package. The job is maintaining it. Whoever writes the code owns that job now.

Choose what you adopt on purpose.