Саймон Уиллисон разметил 244 вайб-кодированных инструмента через tree-sitter

Когда ИИ пишет код за пару минут, главная проблема быстро смещается. Вместо «как это сделать» встаёт вопрос «а где у меня уже есть нечто похожее». Саймон Уиллисон столкнулся с этим на собственной коллекции: на tools.simonwillison.net лежит уже 244 небольших инструмента, почти все написаны с помощью моделей. Плоский список из такого количества позиций перестал работать.

Что он сделал

Уиллисон решил не размечать инструменты вручную. У него оставались кредиты на модель Fable 5.2 до недельного сброса лимитов, и он отдал ей задачу целиком. Модель использовала tree-sitter, парсер, который строит синтаксическое дерево кода, и проанализировала JavaScript каждого инструмента. Из кода она достала три вещи: какие браузерные API используются, какие библиотеки подгружаются с CDN и к каким хостам веб-API обращается инструмент.

Результат выведен на главной странице как облака тегов, где размер тега зависит от числа инструментов. Нажимаешь на тег и видишь список всех инструментов, которые его используют.

Что показывают цифры

Статистика сама по себе любопытна. ES modules использует 92 инструмента, Clipboard API — 69, Canvas 2D — 44, Blob URLs — 38, Drag and drop — 30. Камеру или микрофон задействуют 9 инструментов, а встроенный в браузер ИИ (Built-in AI) пока встречается ровно один раз.

Среди библиотек впереди Marked (12), Pyodide (11) и DOMPurify (7). Дальше идут Leaflet, markdown-it и jSquash для WebP по 4 штуки. В облако попадают только библиотеки, которые подключили не меньше двух инструментов, поэтому разовый шум отсеян.

Осторожная интерпретация: высокие цифры у Clipboard API и Blob URLs, скорее всего, говорят о типичном сценарии «вставил данные, получил результат, скопировал или скачал». Это наш вывод из чисел, сам автор такого не утверждает.

Зачем это знать на практике

Главная идея не в самом облаке тегов, а в способе его получить. Если у вас накопилось много сгенерированного кода — внутренние утилиты, прототипы, скрипты, — то навигацию по нему можно строить из самого кода. Описания, которые пишутся руками, устаревают и забываются, а разбор синтаксического дерева всегда соответствует тому, что реально в файле.

Вот что можно повторить у себя:

• поручите агенту написать скрипт на tree-sitter, который ищет вызовы нужных API и импорты;
• сохраните результат в обычный JSON и сгенерируйте по нему страницу;
• задайте порог, как «минимум два инструмента», чтобы облако не превращалось в свалку;
• перезапускайте разметку при каждом добавлении нового инструмента.

Побочная польза в том, что такая разметка отвечает на вопросы об аудите. Например, какие из ваших инструментов тянут сторонние скрипты с CDN, какие ходят на внешние хосты и какие работают с камерой. Для небольшой команды, которая быстро набрала внутренних приложений, это дешёвый способ увидеть поверхность риска.

Ограничения

Это короткая заметка о личном проекте, а не исследование. Коллекция принадлежит одному автору и не обязана отражать, как устроен типичный ИИ-код. Статический разбор не поймает всё: API, обращение к которым собирается динамически, или библиотеки, подгружаемые нестандартным путём, могут проскочить мимо. В заметке нет данных о том, насколько точна разметка и проверял ли её автор вручную. Скриншот показывает облака для библиотек и браузерных API, а третья категория, хосты веб-API, на нём не видна.

И всё же как рабочий приём это полезно. Когда код пишется быстрее, чем его успевают помнить, разметка по реальному содержимому становится такой же обязательной частью процесса, как тесты. А задача «разберите мои файлы и составьте каталог» как раз из тех, что агент решает за один вечер на остатках недельного лимита.