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-матчей, не пытается сам угадать, какие строки важные, и меньше уезжает в сторону от исходной задачи.
У агентов есть базовая проблема: когда они начинают что-то искать в рабочем проекте на 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-матчей, не пытается сам угадать, какие строки важные, и меньше уезжает в сторону от исходной задачи.
🔥15❤🔥3❤2👍2
С чего начать внедрять агентов в работу компании?
В текущий момент, если посмотреть на то, как я работал с агентами до Нового года и как работаю сейчас, становится очевидным простое направление — инфраструктура.
Почему именно она?
Тут всё просто: создав инструменты для работы с трекером / Git / мониторингами / вики и подобными частями вашей компании, вы получаете ядро, вокруг которого любой сотрудник сможет построить свои скиллы и рабочие процессы.
Если у вас нет такого, станьте этим человеком: сядьте с агентом, разберите вашу инфру на API, создайте MVP-версии инструментов и продемонстрируйте их внутри компании. Это изменит жизнь с агентами в компании на “до” и “после”.
Безопасность
У CLI для инфраструктуры обязательно должны быть ограничения. Например, если у вас есть инструмент для чтения баз в проде, то он должен иметь только функцию чтения, а токен, выписанный для него, не должен иметь прав записи.
Что это в итоге даёт?
После появления инструментов для агентского ядра любой сотрудник — менеджер, дизайнер, аналитик и т.п. — сможет вокруг них построить автоматизацию части своих задач.
Базово они будут кривоваты, но за пару недель использования, например, менеджер сможет доработать скилл под себя, и он будет стабильно работать.
А как это масштабировать?
Вам нужно создать хранилище скиллов / инструментов с их валидацией перед добавлением туда. Так ваши менеджеры смогут масштабировать их на других, ускорив часть работы.
Из важного: где-то рядом должно быть кратко написано, что делает скилл, сколько он стоит и на какой модели автор его полностью протестировал.
Если вы не разработчик, то начните искать однотипные вещи в работе, которые занимают время, и автоматизируйте их. А затем продайте эту идею остальным ребятам — для вас это окупится.
В текущий момент, если посмотреть на то, как я работал с агентами до Нового года и как работаю сейчас, становится очевидным простое направление — инфраструктура.
Почему именно она?
Тут всё просто: создав инструменты для работы с трекером / Git / мониторингами / вики и подобными частями вашей компании, вы получаете ядро, вокруг которого любой сотрудник сможет построить свои скиллы и рабочие процессы.
Если у вас нет такого, станьте этим человеком: сядьте с агентом, разберите вашу инфру на API, создайте MVP-версии инструментов и продемонстрируйте их внутри компании. Это изменит жизнь с агентами в компании на “до” и “после”.
Безопасность
У CLI для инфраструктуры обязательно должны быть ограничения. Например, если у вас есть инструмент для чтения баз в проде, то он должен иметь только функцию чтения, а токен, выписанный для него, не должен иметь прав записи.
Что это в итоге даёт?
После появления инструментов для агентского ядра любой сотрудник — менеджер, дизайнер, аналитик и т.п. — сможет вокруг них построить автоматизацию части своих задач.
Базово они будут кривоваты, но за пару недель использования, например, менеджер сможет доработать скилл под себя, и он будет стабильно работать.
А как это масштабировать?
Вам нужно создать хранилище скиллов / инструментов с их валидацией перед добавлением туда. Так ваши менеджеры смогут масштабировать их на других, ускорив часть работы.
Из важного: где-то рядом должно быть кратко написано, что делает скилл, сколько он стоит и на какой модели автор его полностью протестировал.
Если вы не разработчик, то начните искать однотипные вещи в работе, которые занимают время, и автоматизируйте их. А затем продайте эту идею остальным ребятам — для вас это окупится.
❤6💯4👍1
Как настроить 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 в корень проекта и явно указать, какие директории индексировать, а какие пропускать:
После изменения .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 токенов.
Ну и в общем проще всего настроить скормив клоду ссылку на репозиторий и попросить его погонять агентов, пока не получите желаемый эффект под ваш проектик🙃
Так как инструмент должен стать первым выбором вместо 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 токенов.
Ну и в общем проще всего настроить скормив клоду ссылку на репозиторий и попросить его погонять агентов, пока не получите желаемый эффект под ваш проектик🙃
❤5🔥3
Как я настраиваю Claude Code под работу в продуктовых проектах
Изначально я работал с CLAUDE.md и настройками отдельных агентов, но это не до конца решало мои задачи: агент всё равно иногда забывал важные детали, путался в инфраструктуре или начинал работать “как обычно”, без учёта контекста проекта.
Когда в Claude Code появился удобный механизм rules, я начал строить рабочий процесс вокруг этих правил. Идея простая: не пытаться запихнуть всё в один огромный файл, а разложить правила на небольшие, хорошо отлаженные слои.
Коротко о том, как это устроено у меня.
L1 — глобальный слой.
Это короткие правила про работу со всей нашей инфраструктурой: где искать задачи, как ходить в вики, какие CLI использовать, как посмотреть комменты с PR, как искать код и т.д. У меня это около 15 небольших файлов примерно на 6к токенов, которые лежат в глобальных правилах на маке:
Благодаря этому Claude Code в любой директории понимает, какая инфраструктура у меня есть и как с ней работать.
L2 — проектный слой.
Под каждый проект я добавляю отдельные правила. Если нужно, между L1 и L2 появляется ещё слой для домена: мобильная разработка, фронт, бэкенд и т.п. А уже после него идут конкретные проектные правила.
Что находится в проектных правилах?
Я сторонник коротких, но точных правил. Обычно там лежит: краткое описание архитектуры проекта, сжатая карта проекта, основные “нельзя”, базовые паттерны и ссылки, куда смотреть примеры. Для большого проекта это особенно важно: когда у тебя десятки тысяч файлов и сотни модулей, агенту нужно не “читать всё”, а быстро понять, куда идти.
Что это даёт?
Получается слоёная структура: L1 + L2 + LN, которая меняется в зависимости от проекта. Она занимает немного кэшируемого контекста, но сильно повышает предсказуемость агента. Вместо одного огромного файла с правилами получается набор маленьких кирпичиков, каждый из которых отвечает за свою часть рабочего процесса.
Мне такой подход кажется очень эффективным: его недорого внедрить, легко поддерживать и удобно переиспользовать между проектами. Особенно если вы активно работаете с агентами в разных проектах
Попробуйте — возможно, вам тоже понравится, насколько меняется работа 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 при таком подходе.
👍15❤6✍1
Дата-центры или личные чипы с локальными моделями?
Из прикольного, куда может повернуть мир ИИ, это личный чип у каждого, который он обновляет раз в год с какой-либо локальной моделью.
Ребята из Taalas создали уже первую версию такого чипа с qwen 8B, которую в итоге разогнали до 17000 токенов в секунду.
По сути как было и с другими технологиями, когда например строили огромные компьютеры размером с большие комнаты, а потом уже получили компактные девайсы, так и с Ai, это сильно увеличит его доступность и уменьшит цены.
Возможно 1-2 года и мы уже увидим такие чипы в продаже с достаточно хорошими моделями.
Оригинальная статья https://taalas.com/the-path-to-ubiquitous-ai/
Из прикольного, куда может повернуть мир ИИ, это личный чип у каждого, который он обновляет раз в год с какой-либо локальной моделью.
Ребята из Taalas создали уже первую версию такого чипа с qwen 8B, которую в итоге разогнали до 17000 токенов в секунду.
По сути как было и с другими технологиями, когда например строили огромные компьютеры размером с большие комнаты, а потом уже получили компактные девайсы, так и с Ai, это сильно увеличит его доступность и уменьшит цены.
Возможно 1-2 года и мы уже увидим такие чипы в продаже с достаточно хорошими моделями.
Оригинальная статья https://taalas.com/the-path-to-ubiquitous-ai/
🔥16
Как понять, что ваш агент — не нейрослоп?
Недавно столкнулся с ситуацией: агент, которого добавили в один из флоу с тикетами, не помогал, а скорее мешал работе.
Я пришел с претензией в духе: “текущий подход никуда не годится”. В ответ получил справедливый вопрос: “окей, а как сделать лучше? Чего агенту не хватает до нормального решения?”
В итоге собрались с ребятами пообсуждать, а какие у меня есть идеи по их агенту.
Одна из идей была простая: собрать отдельную очередь размеченных тикетов. По сути — золотой набор, где заранее понятно, какие флаги, оценки или действия мы ожидаем от агента.
Ребята быстро собрали и разметили такую очередь.
Дальше возник следующий вопрос: окей, размеченные тикеты есть. А что с ними делать?
Мы собрались еще раз и за пару часов накидали рабочее MVP:
— прогнать агента по всей размеченной очереди;
— получить оценку от LLM-судьи;
— получить предложения валидатора по улучшению промпта;
— почистить или обновить тикеты;
— снова прогнать агента;
— сохранить историю прогонов в отдельный тикет.
В итоге получился набор из четырех скриптов, которые может запускать любой участник команды. Не надо спорить на ощущениях — можно быстро проверять гипотезы на одной и той же выборке.
Важное требование:
агент, судья и валидатор должны быть из разных семейств моделей. Например: Claude, GPT и GLM/Kimi/DeepSeek. Это не убирает все проблемы оценки, но снижает риск того, что модель будет сама себе подыгрывать или переоценивать похожий стиль генерации.
Еще одно важное правило: золотые корзинки не должны протекать в промпт агента. Иначе мы не улучшаем агента, а просто учим его проходить конкретный тест.
Что получили в итоге?
За неделю прогонов и проверки гипотез команда пришла к версии агента, который уже нормально решает свою задачу и не мешает пользователям ошибками. Но главный результат даже не в этом.
Главный результат — появился воспроизводимый процесс оценки. Теперь качество агента можно обсуждать не в формате “мне кажется, он тупит”, а через конкретные прогоны, ошибки, регрессии и сравнение версий.
Вот это, кажется, и есть первый шаг от “нейрослопа” к нормальному инженерному инструменту.
Недавно столкнулся с ситуацией: агент, которого добавили в один из флоу с тикетами, не помогал, а скорее мешал работе.
Я пришел с претензией в духе: “текущий подход никуда не годится”. В ответ получил справедливый вопрос: “окей, а как сделать лучше? Чего агенту не хватает до нормального решения?”
В итоге собрались с ребятами пообсуждать, а какие у меня есть идеи по их агенту.
Одна из идей была простая: собрать отдельную очередь размеченных тикетов. По сути — золотой набор, где заранее понятно, какие флаги, оценки или действия мы ожидаем от агента.
Ребята быстро собрали и разметили такую очередь.
Дальше возник следующий вопрос: окей, размеченные тикеты есть. А что с ними делать?
Мы собрались еще раз и за пару часов накидали рабочее MVP:
— прогнать агента по всей размеченной очереди;
— получить оценку от LLM-судьи;
— получить предложения валидатора по улучшению промпта;
— почистить или обновить тикеты;
— снова прогнать агента;
— сохранить историю прогонов в отдельный тикет.
В итоге получился набор из четырех скриптов, которые может запускать любой участник команды. Не надо спорить на ощущениях — можно быстро проверять гипотезы на одной и той же выборке.
Важное требование:
агент, судья и валидатор должны быть из разных семейств моделей. Например: Claude, GPT и GLM/Kimi/DeepSeek. Это не убирает все проблемы оценки, но снижает риск того, что модель будет сама себе подыгрывать или переоценивать похожий стиль генерации.
Еще одно важное правило: золотые корзинки не должны протекать в промпт агента. Иначе мы не улучшаем агента, а просто учим его проходить конкретный тест.
Что получили в итоге?
За неделю прогонов и проверки гипотез команда пришла к версии агента, который уже нормально решает свою задачу и не мешает пользователям ошибками. Но главный результат даже не в этом.
Главный результат — появился воспроизводимый процесс оценки. Теперь качество агента можно обсуждать не в формате “мне кажется, он тупит”, а через конкретные прогоны, ошибки, регрессии и сравнение версий.
Вот это, кажется, и есть первый шаг от “нейрослопа” к нормальному инженерному инструменту.
❤11👍6🔥1
ИИ пашет, Саша одобряет
Grep vs структурный AST-поиск на больших проектах У агентов есть базовая проблема: когда они начинают что-то искать в рабочем проекте на 15-20К+ файлов, можно пойти налить кофе, выпить его, вернуться, а он всё ещё будет грепать. В январе, после почти полугода…
Ускорил индексацию в 3.6 раза, новый фича флаг в ast-index v3.43.1
Как попробовать?
Недавно позвали на одну из внутренних встречек рассказать про ast с метричками и всяким подобным, в итоге ребята накидали разные идеи + увидели что условный проект 250К файлов индексируетс за 400-500 секунд и это как-то долго выходит.
В общем сел вечером и начал изучать, а где вообще проблема в скорости и что можно сделать? Тут сразу нашел узкое место это запись батчей в sql базу + скорость волкера по дереву файлов и разные не большие оптимизации с транзакциями в базу.
В общем ускорение на проекте в 32 К файлов до 11 секунд, я еще сел и подумал, а что если можно еще ускроить?
И в общем начал пробовать, потом запустил индексацию огромного проекта и где-то после его половины, на такой скорости я загнал мак в ребут. 🫠
Ошибся, но где?
Дальше буду отдельно еще изучать перфоманс, в данном случае погубила жадность))
В общем понял, что лучше под экспериментальным флагом иметь стабильную реализацию безопасную и после этого откатился до ускорения в 3.6 раза
А зачем вообще это ускорение?
На проектах в 30К файлов будто не сильно важно, но ребята приходят с тем, что хотят работать из корня репозитория своего БЮ и индексировать сразу все, такие дела)
Пробуйте фичу, должно быть полезно прям на огромных проектах. Ну и сильно приятнее с индексацией проектов на 10-30 К файлов за считанные секунды.
Как попробовать?
ast-index rebuild --experimental-fast-rebuild
Недавно позвали на одну из внутренних встречек рассказать про ast с метричками и всяким подобным, в итоге ребята накидали разные идеи + увидели что условный проект 250К файлов индексируетс за 400-500 секунд и это как-то долго выходит.
В общем сел вечером и начал изучать, а где вообще проблема в скорости и что можно сделать? Тут сразу нашел узкое место это запись батчей в sql базу + скорость волкера по дереву файлов и разные не большие оптимизации с транзакциями в базу.
В общем ускорение на проекте в 32 К файлов до 11 секунд, я еще сел и подумал, а что если можно еще ускроить?
И в общем начал пробовать, потом запустил индексацию огромного проекта и где-то после его половины, на такой скорости я загнал мак в ребут. 🫠
Ошибся, но где?
Дальше буду отдельно еще изучать перфоманс, в данном случае погубила жадность))
В общем понял, что лучше под экспериментальным флагом иметь стабильную реализацию безопасную и после этого откатился до ускорения в 3.6 раза
А зачем вообще это ускорение?
На проектах в 30К файлов будто не сильно важно, но ребята приходят с тем, что хотят работать из корня репозитория своего БЮ и индексировать сразу все, такие дела)
Пробуйте фичу, должно быть полезно прям на огромных проектах. Ну и сильно приятнее с индексацией проектов на 10-30 К файлов за считанные секунды.
❤13👍5
Нужен ли код-ревью процесс в AI-first компаниях?
Годами мы делали ревью кода, чтобы держать проекты в порядке, обучать коллег и расширять общий инженерный кругозор.
Но с появлением агентов объем кода резко вырос. И PR-ревью очень быстро стало узким горлышком. Сначала люди еще пытались внимательно смотреть изменения, но за последние месяцы во многих командах это часто превращается в формальность: approve без глубокого просмотра.
Почему так происходит?
Во-первых, многое уже покрыто тестами, автотестами, CI-checks и прогонами на фермах. Критичные сценарии проверяются автоматически лучше и стабильнее, чем человеком в PR.
Во-вторых, после ревью, само тестирование задач тоже становится узким горлышком. Поэтому команды начинают искать путь, где код после успешного пайплайна просто едет дальше быстрее, без лишних ручных блокеров.
В итоге получается странная ситуация: код-ревью формально есть, но как реальный процесс проверки кода людьми оно постепенно исчезает.
Из этого, как мне кажется, следует простая вещь: если у вас хорошо настроены агенты под задачи команды, если они в большинстве случаев пишут надежный код, учитывают edge cases, а качество дополнительно держат тесты и CI/CD, то обязательное ручное ревью каждого PR теряет смысл.
Что остается вместо этого?
Остается пайплайн: PR, автоматические проверки, при необходимости тестирование, и дальше заливка. А если регресс все же случился, команда быстро доливает фикс. Это снимает главный блокер скорости: человеческий фактор в ревью.
Мое мнение: в агентской разработке сплошное ревью всех PR людьми или агентами будет приносить только убытки и не давать никакого эффекта. Особенно для внутренних систем, админок и low-risk задач.
Скорее всего, будущее за полным отказом от ревью в 90% задач, оно может остаться в агентском виде только в областях с высоким риском что-то сломать.
А вы думали вообще что будет с такими процессами в Ai-first компаниях?
Годами мы делали ревью кода, чтобы держать проекты в порядке, обучать коллег и расширять общий инженерный кругозор.
Но с появлением агентов объем кода резко вырос. И PR-ревью очень быстро стало узким горлышком. Сначала люди еще пытались внимательно смотреть изменения, но за последние месяцы во многих командах это часто превращается в формальность: approve без глубокого просмотра.
Почему так происходит?
Во-первых, многое уже покрыто тестами, автотестами, CI-checks и прогонами на фермах. Критичные сценарии проверяются автоматически лучше и стабильнее, чем человеком в PR.
Во-вторых, после ревью, само тестирование задач тоже становится узким горлышком. Поэтому команды начинают искать путь, где код после успешного пайплайна просто едет дальше быстрее, без лишних ручных блокеров.
В итоге получается странная ситуация: код-ревью формально есть, но как реальный процесс проверки кода людьми оно постепенно исчезает.
Из этого, как мне кажется, следует простая вещь: если у вас хорошо настроены агенты под задачи команды, если они в большинстве случаев пишут надежный код, учитывают edge cases, а качество дополнительно держат тесты и CI/CD, то обязательное ручное ревью каждого PR теряет смысл.
Что остается вместо этого?
Остается пайплайн: PR, автоматические проверки, при необходимости тестирование, и дальше заливка. А если регресс все же случился, команда быстро доливает фикс. Это снимает главный блокер скорости: человеческий фактор в ревью.
Мое мнение: в агентской разработке сплошное ревью всех PR людьми или агентами будет приносить только убытки и не давать никакого эффекта. Особенно для внутренних систем, админок и low-risk задач.
Скорее всего, будущее за полным отказом от ревью в 90% задач, оно может остаться в агентском виде только в областях с высоким риском что-то сломать.
А вы думали вообще что будет с такими процессами в Ai-first компаниях?
👍8🤯4😁1
Нужны ли IDE в новых реалиях?
Тут, по личному опыту, студии всегда жрали очень много оперативы, мешали работать и подбешивали.
Условно, Android Studio базово всегда отжирала 8-16 Гб. Хоть на маке и 36 Гб, но если добавить индексацию в IDE и запустить какой-нибудь билд, мы получаем зависающее приложение и подтормаживающий мак, потому что уходим в своп по памяти.
Еще в сентябре, когда начал использовать Клода, я задумался: а зачем мне вообще ее открывать?
Но в целом еще какое-то время, примерно до ноября, держал ее открытой, чтобы посмотреть код или что-то найти.
И в какой-то момент подумал: а зачем она мне вообще нужна?
К ноябрю я как раз уже достроил своего агента для выполнения задачек, описал правила и воркфлоу, плюс проводил через него первичное ревью, а дальше только по критичным вещам пробегался в PR.
И вот это постоянное дополнительное пожирание памяти очень мешало, особенно когда агенты начинали делать рабочие задачки в 2-3 рабочих деревьях и ресурсы становились главным узким горлышком всей работы.
Доходило до того, что мак просто висел, и ни я, ни агенты не могли нормально работать, что в итоге сильно просаживало производительность и качество.
Что было дальше?
Тут все просто: я снес IDE и пошел в сторону допиливания работы с агентами, создания для них инструментов под себя, чтобы стабильно получать высокое качество задачек.
Жалею ли я о том, что больше не использую IDE?
Ни разу не пожалел. На самом деле все поделилось на до и после: это позволило осознать, что студии только мешали работать. И даже если надо что-то глянуть, проще открыть файл через open в терминале.
Ну и в целом отказ от студий позволил взглянуть на разработку с агентами под другим углом, лучше понять, какие есть недостатки и проблемы, и пойти в их точечное решение вместо попыток дальше работать по-старому.
Кстати, по опыту других ребят вокруг тоже слышу, что они полностью отказались от использования IDE.
А вы еще пользуетесь студиями или уже тоже отказались?
Тут, по личному опыту, студии всегда жрали очень много оперативы, мешали работать и подбешивали.
Условно, Android Studio базово всегда отжирала 8-16 Гб. Хоть на маке и 36 Гб, но если добавить индексацию в IDE и запустить какой-нибудь билд, мы получаем зависающее приложение и подтормаживающий мак, потому что уходим в своп по памяти.
Еще в сентябре, когда начал использовать Клода, я задумался: а зачем мне вообще ее открывать?
Но в целом еще какое-то время, примерно до ноября, держал ее открытой, чтобы посмотреть код или что-то найти.
И в какой-то момент подумал: а зачем она мне вообще нужна?
К ноябрю я как раз уже достроил своего агента для выполнения задачек, описал правила и воркфлоу, плюс проводил через него первичное ревью, а дальше только по критичным вещам пробегался в PR.
И вот это постоянное дополнительное пожирание памяти очень мешало, особенно когда агенты начинали делать рабочие задачки в 2-3 рабочих деревьях и ресурсы становились главным узким горлышком всей работы.
Доходило до того, что мак просто висел, и ни я, ни агенты не могли нормально работать, что в итоге сильно просаживало производительность и качество.
Что было дальше?
Тут все просто: я снес IDE и пошел в сторону допиливания работы с агентами, создания для них инструментов под себя, чтобы стабильно получать высокое качество задачек.
Жалею ли я о том, что больше не использую IDE?
Ни разу не пожалел. На самом деле все поделилось на до и после: это позволило осознать, что студии только мешали работать. И даже если надо что-то глянуть, проще открыть файл через open в терминале.
Ну и в целом отказ от студий позволил взглянуть на разработку с агентами под другим углом, лучше понять, какие есть недостатки и проблемы, и пойти в их точечное решение вместо попыток дальше работать по-старому.
Кстати, по опыту других ребят вокруг тоже слышу, что они полностью отказались от использования IDE.
А вы еще пользуетесь студиями или уже тоже отказались?
👍11
Релиз ast-index 3.44.0
Вышла новая версия инструмента https://github.com/defendend/Claude-ast-index-search/releases/tag/v3.44.0
C++ поиск стал namespace-aware: теперь работают и symbol Client, и symbol foo::bar::Client, плюс pattern-поиск вроде ::Client и foo::bar*
rebuild и update стали надежнее: безопаснее SQL query, корректнее работа с include и extra roots
часть безопасных оптимизаций rebuild вынес в дефолт из под флага (--experimental-fast-rebuild) и добавил новые бенчи для индексации / update / module graph / Android XML+resources
В общем фикс мелких ишью от ребят из c++, теперь ast там наконец-то умеет в базу)))
Ну и базовые ускорения ребилда без эксп флага, конечно чем больше юзеров, тем аккуратнее приходится делать обновления 🫠
Тут уже не скажешь клоду/кодексу как в начале, го с питона на раст разом перепишем, хоть и было все покрыто тестами)))
upd: поддержаны enum для парсинга в плюсах 3.44.2
Вышла новая версия инструмента https://github.com/defendend/Claude-ast-index-search/releases/tag/v3.44.0
C++ поиск стал namespace-aware: теперь работают и symbol Client, и symbol foo::bar::Client, плюс pattern-поиск вроде ::Client и foo::bar*
rebuild и update стали надежнее: безопаснее SQL query, корректнее работа с include и extra roots
часть безопасных оптимизаций rebuild вынес в дефолт из под флага (--experimental-fast-rebuild) и добавил новые бенчи для индексации / update / module graph / Android XML+resources
В общем фикс мелких ишью от ребят из c++, теперь ast там наконец-то умеет в базу)))
Ну и базовые ускорения ребилда без эксп флага, конечно чем больше юзеров, тем аккуратнее приходится делать обновления 🫠
Тут уже не скажешь клоду/кодексу как в начале, го с питона на раст разом перепишем, хоть и было все покрыто тестами)))
upd: поддержаны enum для парсинга в плюсах 3.44.2
🔥9😁2