← На главную

LLM-агенты на ревью PR: куча багов от критических до мелких

25.05.2026 23:16 · hackernews

Многие уверены, что смысл AI-кодинга — писать как можно быстрее как можно более низкокачественный код. Выплевывать едва проходной шлак, открывать огромные PR и сливать их без проверки. Зашипперили — и готово.

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

Если история с Mythos чему-то научила, так это тому, что LLM-агенты отлично ищут баги. Забросьте их в кодовую базу — найдут столько, что вы не будете знать, куда деваться. Автор подтверждает: это верно и для других моделей. Последние публичные модели от Anthropic и OpenAI достаточно хороши, чтобы найти кучу багов в непроверенном коде.

Проблема не в поиске, а в приоритизации и валидации. Поэтому автор адаптировал навык для Claude из одной статьи: чем больше разных моделей бросить на ревью PR, тем меньше галлюцинаций. Навык (в пересказе): запустить Claude sub-agent, Codex и Cursor Bugbot, чтобы они нашли баги в PR с ранжированием по критичности. После — проверить их выводы, отсеять ложные срабатывания и написать финальный отчет. В определение «бага» можно добавить свои критерии: принципы KISS и DRY, доступный HTML/JSX, правильные индексы для SQL-запросов.

В опыте автора этот навык находит в PR кучу багов с околонулевым уровнем ложных срабатываний. Диапазон — от критических проблем безопасности до «этот комментарий вводит в заблуждение».

Типичный рабочий процесс: попросить агента пофиксить все критические и высокие баги (с направляющими указаниями), повторять, пока их не останется. Пропускать средние баги, если игра не стоит свеч. Бросать PR, если там так много критических ошибок, что весь подход изначально неверен.

С этой техникой скорость разработки автора не выросла — наоборот, ревью часто находит предсуществующие баги, и приходится писать юнит-тесты и фиксить тонкие проблемы, появившиеся до PR. Это полная противоположность «десятикратной продуктивности» в стиле шлакопушки, но автора это очень радует. Это отличный способ улучшить здоровье кодовой базы и заодно изучить её тёмные углы.

Автор призывает тех, кто использует агентов для написания многострочных PR, которые сами едва понимают, — замедлиться и попробовать этот более медленный стиль. Попросить агента объяснить, как работает PR и где может упасть. Пусть напишет документацию с Mermaid-диаграммами. Используйте навык /grill-me от Мэтта Покока, пока не поймёте PR от и до. Возможно, вы не станете «продуктивнее» в сырых строках кода, но это более супер-заряженная версия программирования, которым автор занимался и до LLM: тщательного, методичного, одержимого качеством, нацеленного на улучшение кода для следующего разработчика.

Читать оригинал →