ИИ пашет, Саша одобряет

Дата-центры или личные чипы с локальными моделями?

Из прикольного, куда может повернуть мир ИИ, это личный чип у каждого, который он обновляет раз в год с какой-либо локальной моделью.

Ребята из Taalas создали уже первую версию такого чипа с qwen 8B, которую в итоге разогнали до 17000 токенов в секунду.

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

Возможно 1-2 года и мы уже увидим такие чипы в продаже с достаточно хорошими моделями.

Оригинальная статья https://taalas.com/the-path-to-ubiquitous-ai/

Как я настраиваю Claude Code под работу в продуктовых проектах

Изначально я работал с CLAUDE.md и настройками отдельных агентов, но это не до конца решало мои задачи: агент всё равно иногда забывал важные детали, путался в инфраструктуре или начинал работать “как обычно”, без учёта контекста проекта.

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

Коротко о том, как это устроено у меня.

L1 — глобальный слой.

Это короткие правила про работу со всей нашей инфраструктурой: где искать задачи, как ходить в вики, какие CLI использовать, как посмотреть комменты с PR, как искать код и т.д. У меня это около 15 небольших файлов примерно на 6к токенов, которые лежат в глобальных правилах на маке:

/Users/<username>/.claude/rules/

Благодаря этому Claude Code в любой директории понимает, какая инфраструктура у меня есть и как с ней работать.

L2 — проектный слой.

Под каждый проект я добавляю отдельные правила. Если нужно, между L1 и L2 появляется ещё слой для домена: мобильная разработка, фронт, бэкенд и т.п. А уже после него идут конкретные проектные правила.

Что находится в проектных правилах?

Я сторонник коротких, но точных правил. Обычно там лежит: краткое описание архитектуры проекта, сжатая карта проекта, основные “нельзя”, базовые паттерны и ссылки, куда смотреть примеры. Для большого проекта это особенно важно: когда у тебя десятки тысяч файлов и сотни модулей, агенту нужно не “читать всё”, а быстро понять, куда идти.

Что это даёт?

Получается слоёная структура: L1 + L2 + LN, которая меняется в зависимости от проекта. Она занимает немного кэшируемого контекста, но сильно повышает предсказуемость агента. Вместо одного огромного файла с правилами получается набор маленьких кирпичиков, каждый из которых отвечает за свою часть рабочего процесса.

Мне такой подход кажется очень эффективным: его недорого внедрить, легко поддерживать и удобно переиспользовать между проектами. Особенно если вы активно работаете с агентами в разных проектах

Попробуйте — возможно, вам тоже понравится, насколько меняется работа Claude Code при таком подходе.

Пора создавать действительно важные скилы для ваших агентов)

Как настроить ast-index в вашем проекте для агентов?

Так как инструмент должен стать первым выбором вместо grep и search агента, просто положить скилл не даст максимального эффекта: про скиллы агенты иногда могут забывать и предпочитать базовые инструменты.

Начнем с простого.

Инструмент можно поставить разными способами в зависимости от платформы: brew / npm / winget. Подробный гайд тут:

https://github.com/defendend/Claude-ast-index-search/blob/main/USER_GUIDE.md

В Claude Code и Cursor есть понятие правил, и вот с ними ast-index ложится идеально. Просто добавляем прикрепленный к посту файл в .claude/rules/ или .cursor/rules/.

В Claude Code необходимо разрешить ast-index, через Bash(ast-index *), иначе агент будет спрашивать подтверждение на каждый вызов.

С Codex чуть сложнее: ему можно подключить либо скилл и указать его в AGENTS.md для постоянного использования, либо сразу вставить правила целиком в файл.

Для больших репозиториев или монореп можно добавить .ast-index.yaml в корень проекта и явно указать, какие директории индексировать, а какие пропускать:

include:
  - app
  - packages/shared
exclude:
  - generated
  - vendor

После изменения .ast-index.yaml лучше один раз выполнить ast-index rebuild, чтобы индекс пересобрался уже с новой конфигурацией.

Что делать с worktree?

Индекс сохраняется в ~/Library/Caches/ast-index/<project-hash>/index.db на macOS, в ~/.cache/ast-index/<project-hash>/index.db на Linux и в пользовательский cache-dir Windows, внутри ast-index/<project-hash>/index.db.

У каждого дерева вашего git-репозитория будет свой хэш, поэтому индексы будут полностью независимыми.

При обновлении ветки, ребейзе и т.п. можно вызвать ast-index update. Это команда инкрементального обновления индекса: она сравнивает текущий список файлов и сохраненный mtime в SQLite.

Также можно включить ast-index watch &: он слушает файловые события, группирует частые изменения и запускает инкрементальное обновление индекса.

Как посчитать используемость инструмента в компании?

Можно взять исходники с GitHub, дополнить их в вашем CI телеметрией и собирать информацию.

Экономия на чтении файлов

В ast есть команда outline позволяющая на лету распарсить файл в ast дерево за ~10 мс, и вычитать это позволяет вычитывать файлы на 500+ строк за 200-500 токенов.

Ну и в общем проще всего настроить скормив клоду ссылку на репозиторий и попросить его погонять агентов, пока не получите желаемый эффект под ваш проектик🙃

С чего начать внедрять агентов в работу компании?

В текущий момент, если посмотреть на то, как я работал с агентами до Нового года и как работаю сейчас, становится очевидным простое направление — инфраструктура.

Почему именно она?

Тут всё просто: создав инструменты для работы с трекером / Git / мониторингами / вики и подобными частями вашей компании, вы получаете ядро, вокруг которого любой сотрудник сможет построить свои скиллы и рабочие процессы.

Если у вас нет такого, станьте этим человеком: сядьте с агентом, разберите вашу инфру на API, создайте MVP-версии инструментов и продемонстрируйте их внутри компании. Это изменит жизнь с агентами в компании на “до” и “после”.

Безопасность

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

Что это в итоге даёт?

После появления инструментов для агентского ядра любой сотрудник — менеджер, дизайнер, аналитик и т.п. — сможет вокруг них построить автоматизацию части своих задач.

Базово они будут кривоваты, но за пару недель использования, например, менеджер сможет доработать скилл под себя, и он будет стабильно работать.

А как это масштабировать?

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

Из важного: где-то рядом должно быть кратко написано, что делает скилл, сколько он стоит и на какой модели автор его полностью протестировал.

Если вы не разработчик, то начните искать однотипные вещи в работе, которые занимают время, и автоматизируйте их. А затем продайте эту идею остальным ребятам — для вас это окупится.

Grep vs структурный AST-поиск на больших проектах

У агентов есть базовая проблема: когда они начинают что-то искать в рабочем проекте на 15-20К+ файлов, можно пойти налить кофе, выпить его, вернуться, а он всё ещё будет грепать.

В январе, после почти полугода работы с Claude, меня это окончательно достало. Я в очередной раз открыл Android Studio, дважды нажал Shift, ввёл нужный класс и подумал: а почему агент не может так же?

Так появился ast-index: локальный CLI, который индексирует код через AST, складывает символы, связи, импорты, usages и модули в SQLite, а потом через FTS5 находит нужное за 1-10 мс.

https://github.com/defendend/Claude-ast-index-search

На проекте в ~30К файлов поиск даёт примерно 60-70% экономии токенов относительно обычного grep-подхода агентов и ускорение в 10-15 раз. У ребят на проекте в ~70К файлов ускорение доходило примерно до 600x.

Сейчас инструментом пользуются 1200+ человек внутри компании (инфровая версия), плюс open-source версия живёт отдельно.

Настроить можно легко с агентом вместе, все необходимое в репозитории, тула используется через bash.

Главный профит: агент перестаёт получать на вход простыню из grep-матчей, не пытается сам угадать, какие строки важные, и меньше уезжает в сторону от исходной задачи.

Channel created