🧠 ast-index — индекс кода для Claude Code, ускоряющий поиск по кода в десятки раз 🤯

Claude Code из коробки ищет по коду через grep и чтение файлов. На небольших проектах это работает, на больших — медленно и неточно. ast-index закрывает этот пробел: строит локальный индекс кода по вашего проекта и подключается к Claude Code как плагин, после чего агент сначала ищет через индекс (~1–11 мс), а grep — только как запасной вариант. Ускорение в десятки, а иногда и в сотни раз 🤯

Установка и подключение:

# 1. Устанавливаем
brew tap defendend/ast-index
brew install ast-index

# 2. Переходим в корень проекта и строим индекс
cd /path/to/project
ast-index rebuild

# 3. Устанавливаем плагин в Claude Code
ast-index install-claude-plugin

# 4. Перезапускаем Claude Code

Третья команда прописывает .claude/settings.json: регистрирует маркетплейс, включает плагин и выдаёт Claude разрешение запускать ast-index от своего имени. После этого Claude автоматически использует индекс при любом поиске по коду.

Про актуальность индекса — это важный момент. Автоматического обновления внутри сессии нет: Claude не детектирует сам, что индекс устарел, и не запускает update самостоятельно. Поэтому логика такая:

# Один раз при клонировании / настройке
ast-index rebuild

# После git pull или merge
ast-index update  # только изменённые файлы

# Или запустить в фоне на время сессии — сам следит через FSEvents/inotify
ast-index watch

watch — наиболее практичный вариант: запустил в отдельном терминале перед началом работы, и индекс держится актуальным всю сессию без ручного вмешательства. Также вариант встроить команды в Git Hooks или Claude Rules

Для Android в индексе есть специализированные команды: composables, suspend, flows, provides, inject, xml-usages, анализ зависимостей между Gradle-модулями с unused-deps.

🐱 AST Index GitHub

#ClaudeCode #AICoding #AI #ИИ #Производительность

‼️ Главное в работе с AI-агентом не промпт, а что считать источником правды для приемки!

В моём текущем процессе самое инженерное в задаче — это не «как это написать», а «как мы поймём, что это сделано правильно». Когда ответ есть и сформулирован явно, дальше работа с агентом превращается в нормальный инженерный цикл. Когда ответа нет, то получится не инженерия, а получится игра в казино. Если источник правды не сформулирован, агент сделает что-то «своё». Может быть, даже хорошее. Но проверить, то ли это, что нужно, ты не сможешь пока не опишешь свои ожидания о результате.

Потому что «правильно/неправильно» - не абсолютная метрика. Это всегда относительно какого-то эталона. И этот эталон нужно сначала иметь, прежде чем что-то поручать агенту.

Несколько примеров, как это выглядит на практике:
👉 Миграция legacy-кода на новую технологию. Источник правды — поведение старого кода. Приложение должно выглядеть так же и вести себя так же, даже если в старом коде есть баги. Агент не должен ничего «улучшать» по ходу — задача в миграции, а не в фиксе.
👉 Новая фича. Источник правды — спека и требования. Если их нет, агент будет угадывать, и проверить его никак нельзя.
👉 Рефакторинг. Источник правды — внешний контракт (тесты, API). Внутри агент может делать что угодно, но снаружи поведение должно остаться идентичным.

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

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

💬 Если у вас есть свои паттерны, как фиксировать source of truth перед тем, как отдать задачу агенту - делитесь в комментариях.

#AICoding #SoftwareEngineering #ClaudeCode #TechLeadership