Video oldindan ko‘rish uchun mavjud emas
Telegram'da ko‘rish
Как сжечь токены за 15 минут и получить дозу дофамина
Раньше проводил аудиты производительности на старых проектах, и каждый раз это была разовая история. Недавно решил так же проверять текущие проекты, причём уже здоровье целиком.
Агенты для этого подходят на удивление хорошо, а регулярный аудит как раз из тех повторяющихся задач, которые автоматизируешь первыми. Эксперимент я запустил сразу на пяти репозиториях и, чего мелочиться, одновременно. Задача же однотипная))
Но на большой кодовой базе агент же будет пропускать код, и как это блин вообще проверить?
Поискал, как это решают другие, и нашёл RepoAudit, LLM-агента для аудита целых репозиториев. Авторы пишут, что контекст и галлюцинации портят отчёт. На деле агент выдаёт уверенный текст и молча пропускает половину кода. То есть легко получить отчёт с базовой информацией, что проект на React 19 и TypeScript, стили на SCSS, и всё, идите к клиенту, пускай платит деньги, но это он может посмотреть и сам.
RepoAudit и не пытается прочитать всё. Агент берёт место, где данные приходят извне (запрос, форма, файл), и идёт за ними по коду до места, где они реально что-то ломают. Например, строка из формы без проверки попадает в SQL-запрос. Находки перепроверяет валидатор. На 15 проектах так нашли 40 подтверждённых багов с точностью 78%, в среднем за 0,44 часа и $2,54 на проект.
Я пошёл прямолинейнее, через доказуемое покрытие. Сначала агент прогоняет линтер, проверку типов, тесты и сборку, если они уже настроены. Потом код режется на скоупы под размер контекста, и субагент читает все файлы своего скоупа, перечисляя, что открыл. Из этих списков собирается ledger, журнал покрытия, где видно, какой файл открыт, какой пропущен и почему.
Проверяет субагент семь категорий (выделил для себя столько, можно расширить или сузить от потребности).
– Корректность. Что сломается на пустом ответе API или граничном значении там, где считаются финансы и распределяются доступы.
– Безопасность. Не лежат ли в репе ключи и проверяет ли эндпоинт права, а не только логин.
– Архитектура. Циклические зависимости, дубли и мёртвый код.
– Тесты. Покрыты ли расчёты и не падают ли тесты через раз.
– Производительность. Запросы к базе в цикле и выборки без пагинации.
– Зависимости. Пакеты с известными уязвимостями.
– Документация. Поднимется ли проект у нового человека по README.
Около 3700 файлов агент нарезал на скоупы и запустил 15 субагентов параллельно, каждому досталось от 150 до 650 файлов. Шкала лимитов бежала быстро, как установка небольшого приложения на пк. Несколько субагентов упали и перезапустились с нуля, а один раздал свои 400 файлов собственным субагентам, и его работу доделывали остальные.
В итоге все проверки прошли, на работу агентов ушло около 15 минут. В самом большом репозитории на 1571 файл все 662 теста зелёные, но выяснилось, что тесты покрывают меньше 10% кода, а в коде 358 скопированных кусков. Набралось 52 находки со сценариями поломки, 10 из них уровня medium и покрытие 100% по файлам, вот тут я получил порцию дофамина.
Вернёмся к расходу токенов, у которого причина структурная. Каждый субагент живёт в своём контексте и оплачивает свои 400 файлов отдельно. RepoAudit дешёвый как раз потому, что не читает всё подряд. Упавший агент теряет всё прочитанное, и перезапуск оплачивает ту же работу второй раз.
Поэтому после прогона оптимизировал расход. Агент ищет подозрительные места, например пустой catch или прямой SQL запрос, а ещё сразу читает целиком всё про авторизацию и внешние интеграции. Так целиком читается примерно каждый восьмой файл, а сгенерированный код не трогается вовсе. Агенты идут волнами по 3–5, отчёт дописывается каждые 20–30 файлов, чтобы упавший агент не читал всё заново, а делегировать чтение запрещено. Полное чтение всё равно стоит денег, поэтому в начале скилла теперь предупреждение, во что обойдётся запуск. После повторного прогона разница сократилась в 2-4 раза.
Следующий шаг это сменить отбор по файлам на отбор по потоку данных, как в RepoAudit, и читать целиком только путь от входных точек до мест, где ошибка негативно влияет на бизнес.
#ai
Раньше проводил аудиты производительности на старых проектах, и каждый раз это была разовая история. Недавно решил так же проверять текущие проекты, причём уже здоровье целиком.
Агенты для этого подходят на удивление хорошо, а регулярный аудит как раз из тех повторяющихся задач, которые автоматизируешь первыми. Эксперимент я запустил сразу на пяти репозиториях и, чего мелочиться, одновременно. Задача же однотипная))
Но на большой кодовой базе агент же будет пропускать код, и как это блин вообще проверить?
Поискал, как это решают другие, и нашёл RepoAudit, LLM-агента для аудита целых репозиториев. Авторы пишут, что контекст и галлюцинации портят отчёт. На деле агент выдаёт уверенный текст и молча пропускает половину кода. То есть легко получить отчёт с базовой информацией, что проект на React 19 и TypeScript, стили на SCSS, и всё, идите к клиенту, пускай платит деньги, но это он может посмотреть и сам.
RepoAudit и не пытается прочитать всё. Агент берёт место, где данные приходят извне (запрос, форма, файл), и идёт за ними по коду до места, где они реально что-то ломают. Например, строка из формы без проверки попадает в SQL-запрос. Находки перепроверяет валидатор. На 15 проектах так нашли 40 подтверждённых багов с точностью 78%, в среднем за 0,44 часа и $2,54 на проект.
Я пошёл прямолинейнее, через доказуемое покрытие. Сначала агент прогоняет линтер, проверку типов, тесты и сборку, если они уже настроены. Потом код режется на скоупы под размер контекста, и субагент читает все файлы своего скоупа, перечисляя, что открыл. Из этих списков собирается ledger, журнал покрытия, где видно, какой файл открыт, какой пропущен и почему.
Проверяет субагент семь категорий (выделил для себя столько, можно расширить или сузить от потребности).
– Корректность. Что сломается на пустом ответе API или граничном значении там, где считаются финансы и распределяются доступы.
– Безопасность. Не лежат ли в репе ключи и проверяет ли эндпоинт права, а не только логин.
– Архитектура. Циклические зависимости, дубли и мёртвый код.
– Тесты. Покрыты ли расчёты и не падают ли тесты через раз.
– Производительность. Запросы к базе в цикле и выборки без пагинации.
– Зависимости. Пакеты с известными уязвимостями.
– Документация. Поднимется ли проект у нового человека по README.
Около 3700 файлов агент нарезал на скоупы и запустил 15 субагентов параллельно, каждому досталось от 150 до 650 файлов. Шкала лимитов бежала быстро, как установка небольшого приложения на пк. Несколько субагентов упали и перезапустились с нуля, а один раздал свои 400 файлов собственным субагентам, и его работу доделывали остальные.
В итоге все проверки прошли, на работу агентов ушло около 15 минут. В самом большом репозитории на 1571 файл все 662 теста зелёные, но выяснилось, что тесты покрывают меньше 10% кода, а в коде 358 скопированных кусков. Набралось 52 находки со сценариями поломки, 10 из них уровня medium и покрытие 100% по файлам, вот тут я получил порцию дофамина.
Вернёмся к расходу токенов, у которого причина структурная. Каждый субагент живёт в своём контексте и оплачивает свои 400 файлов отдельно. RepoAudit дешёвый как раз потому, что не читает всё подряд. Упавший агент теряет всё прочитанное, и перезапуск оплачивает ту же работу второй раз.
Поэтому после прогона оптимизировал расход. Агент ищет подозрительные места, например пустой catch или прямой SQL запрос, а ещё сразу читает целиком всё про авторизацию и внешние интеграции. Так целиком читается примерно каждый восьмой файл, а сгенерированный код не трогается вовсе. Агенты идут волнами по 3–5, отчёт дописывается каждые 20–30 файлов, чтобы упавший агент не читал всё заново, а делегировать чтение запрещено. Полное чтение всё равно стоит денег, поэтому в начале скилла теперь предупреждение, во что обойдётся запуск. После повторного прогона разница сократилась в 2-4 раза.
Следующий шаг это сменить отбор по файлам на отбор по потоку данных, как в RepoAudit, и читать целиком только путь от входных точек до мест, где ошибка негативно влияет на бизнес.
#ai