Simon Willison tagged 244 vibe-coded tools using tree-sitter

When AI writes code in a couple of minutes, the main problem quickly shifts. Instead of "how do I build this," the question becomes "where do I already have something similar." Simon Willison ran into this with his own collection: tools.simonwillison.net now holds 244 small tools, almost all written with the help of models. A flat list of that many items stopped working.

What he did

Willison decided not to tag the tools by hand. He had credits left on the Fable 5.2 model until the weekly limit reset, and he handed it the entire task. The model used tree-sitter, a parser that builds a syntax tree of code, and analyzed the JavaScript of each tool. From the code it extracted three things: which browser APIs are used, which libraries are loaded from CDNs, and which web API hosts the tool contacts.

The result appears on the home page as tag clouds, where a tag's size depends on the number of tools. Click a tag and you see a list of all the tools that use it.

What the numbers show

The statistics are interesting in themselves. 92 tools use ES modules, 69 use the Clipboard API, 44 use Canvas 2D, 38 use Blob URLs, and 30 use Drag and drop. 9 tools use the camera or microphone, while the browser's built-in AI (Built-in AI) appears exactly once so far.

Among libraries, Marked (12), Pyodide (11), and DOMPurify (7) lead. Next come Leaflet, markdown-it, and jSquash for WebP, with 4 each. Only libraries used by at least two tools make it into the cloud, so one-off noise is filtered out.

A cautious interpretation: the high numbers for the Clipboard API and Blob URLs most likely point to a typical scenario of "paste data, get a result, copy or download it." This is our inference from the numbers; the author does not claim it himself.

Why this matters in practice

The main idea isn't the tag cloud itself but the way of producing it. If you have accumulated a lot of generated code — internal utilities, prototypes, scripts — you can build navigation for it from the code itself. Hand-written descriptions go stale and get forgotten, while parsing the syntax tree always matches what is actually in the file.

Here is what you can replicate yourself:

• ask an agent to write a tree-sitter script that looks for calls to the APIs you care about and for imports;
• save the result as plain JSON and generate a page from it;
• set a threshold, such as "at least two tools," so the cloud doesn't turn into a dumping ground;
• rerun the tagging every time a new tool is added.

A side benefit is that this kind of tagging answers audit questions. For example, which of your tools pull third-party scripts from CDNs, which contact external hosts, and which work with the camera. For a small team that has quickly piled up internal apps, this is a cheap way to see the risk surface.

Limitations

This is a short note about a personal project, not a study. The collection belongs to one author and doesn't have to reflect how typical AI-written code is structured. Static analysis won't catch everything: APIs accessed dynamically, or libraries loaded in a non-standard way, may slip through. The note contains no data on how accurate the tagging is or whether the author checked it manually. The screenshot shows clouds for libraries and browser APIs, while the third category, web API hosts, is not visible in it.

Still, as a working technique it is useful. When code is written faster than people can remember it, tagging based on the actual contents becomes as essential a part of the process as tests. And the task "parse my files and compile a catalog" is exactly the kind an agent can handle in one evening on the remains of a weekly limit.