I don’t really use libraries anymore

Software teams are increasingly treating many third-party libraries as liabilities—something to delete, rewrite, or even replace with prompts—because AI makes reimplementation cheaper while dependency risk keeps compounding. The core shift is psychological and practical: the “cost” of not understanding a dependency is rising, while the “cost” of generating an alternative is falling. That combination is pushing developers to rethink what belongs in package.json and what should live inside their own codebase.

The argument starts with the smallest, most meme-able packages—like is odd or leftpad—where the functionality is essentially a few lines of code. Those packages became popular because npm made reuse effortless, but that convenience also encouraged teams to adopt code they barely understand. Supply-chain threats, version churn, and dependency chains that obscure what’s actually safe are real risks, especially when a project’s package.json becomes a “glossary” of transitive dependencies. Yet the transcript draws a pointed comparison: the same people who criticize dependency sprawl often also criticize AI-assisted coding, even though AI can reduce the need for those tiny libraries by letting less experienced developers generate the code directly.

From there, the discussion expands to larger, harder-to-replace libraries where the tradeoff isn’t “two lines vs one import,” but operational reliability. A concrete example is Tkumi, used to render React components on the server to generate images for the T3 chat “wrapped” feature. Tkumi wouldn’t bundle in production, and once shipped it caused production errors that took the service down for about 25 seconds. After reverting and troubleshooting for roughly 15 minutes, the solution was to “vibe code” a client-side JavaScript workaround. That change reduced server-side capability and altered the user experience (images had to be generated client-side), but it restored stability and let the team control layout details like spacing, word wrapping, and aesthetics—areas where AI agents struggled when trying to automate the rendering pipeline.

The transcript then connects this pattern to broader dependency categories: some libraries exist beyond a developer’s knowledge (useful for beginners or for complex domains), while others exist because reimplementation is tedious. Even when a library is technically “cool,” maintenance and extensibility matter—especially when future features (login, blogs, sessions, SEO via server rendering) might require architectural flexibility. Next.js is cited as an example of a framework that can absorb many future needs even if it’s not perfectly understood.

A key conceptual model is “complexity vs capability.” As capability rises, willingness to adopt external code drops—particularly for complex problems—because teams now feel they can generate or adapt solutions. The transcript claims this bends the old linear relationship between problem difficulty and dependency adoption.

Finally, it argues that the replacement for libraries may increasingly be prompts and code copied into the repo. The transcript cites a quote from Simon “Sty Pete” (as referenced) about preferring prompt requests over pull requests because prompts preserve intent. It also highlights tools and practices that make this feasible: copying code directly (as with shadcn-style approaches), using codebase-aware agent tooling (like BTCA, which clones the repo and uses search tools rather than token-heavy doc indexing), and using AI code review tools (Code Rabbit) to keep generated changes safe.

The takeaway is not “never use libraries,” but “measure risk differently.” Some dependencies are worth forking, some are worth buying, and some should be avoided or replaced—because AI lowers reimplementation friction while supply-chain and maintenance risks keep growing. The transcript closes with a challenge: uninstall packages, or accept that this is a real shift in how modern teams decide what to depend on.