It’s likely that we’re headed towards a near-future where most (not all!) software is vibe coded. Those who write it will specify it in a natural language and not look at the underlying code, in the same way that I wrote JS code for fifteen years without looking at what was emitted by the interpreter.

In this setting, and with LLMs becoming pretty good at coding, I sense that fewer libraries will be used. Except for big frameworks (like React), very specialized libraries (like ffmpeg or pdfminer), or general purpose libraries (like grep or curl), LLMs will probably write the needed code from scratch. By “scratch”, I mean that they will probably approximate existing open source solutions to that problem they solved since they were trained on that code. But the hard dependency on many libraries will be gone. Before, we used libraries so we wouldn’t have to write that code, but now the LLM will write it for us.

As a maker of libraries, this saddens me. There’s a lot of bittersweet stuff going on now. However, there’s another way to be useful: code guidelines. LLMs have internalized a decent number of code guidelines, but they are still making lots of bad decisions. Many of these bad decisions could be prevented by good guidelines. Vibe coders could pick a set of guidelines that comes recommended by others and they could instruct their agents to follow those guidelines.

In other words, code guidelines could be the “libraries” that can help make a lot of vibe coded apps more secure, correct, accessible and performant. I think it makes sense to write and publish good guidelines for LLM agents so that vibe coders can avoid hitting a lot of walls. I’m going to do that in vibey, which is a vibe coding tool. If you’re building vibe coding tools, it may make sense too to bundle your own guidelines (or even provide a way to inject other guidelines) into your users’ vibe coding workflow.