Отдал сайт ИИ‑агентам: из 111 находок аудита 25 пошли в мусор, 4 оказались выдумкой

Мой сайт ведут ИИ‑агенты. Они пишут код, правят тексты, проводят ревью, собирают и выкатывают. 207 коммитов.

Я не буду рассказывать, как это ускорило работу — ускорило, это скучно и все уже слышали. Расскажу про то, о чём говорят реже: узкое место переехало с написания кода на его проверку. Агент производит правки быстрее, чем человек успевает их прочитать, и если не встроить проверку в конвейер, разница между «работает» и «выглядит как работает» перестаёт быть заметной.

Две цифры для затравки:

• ИИ‑аудит кодовой базы дал 111 находок. После проверки вторым проходом 86 подтверждены, 25 отклонены — и 4 из них были просто неправдой: описанного дефекта не существует, а предложенная правка ломала ровно тот сценарий, который «чинила».

• Комментарий в шапке скрипта, написанный агентом, утверждал: «сырьё в git не попадает». git log показал 42 файла, попавших в историю. Один из них назывался по имени клиента под NDA.

Ниже — как устроен этот конвейер, что в нём ловится на сборке, и чего он не ловит.

Отдел

Слово «агент» обычно означает одну сущность в цикле. У меня это несколько ролей с разной задачей, и главное в конструкции — они не доверяют друг другу.

• Исполнители. Пишут код и тексты. Обычная работа: правка, сборка, коммит.

• Ревьюеры‑линзы. Аудит идёт не одним проходом «найди проблемы», а несколькими независимыми, у каждого своя оптика. В последнем прогоне по дизайну линзы распределились так: токены 27 находок, общий аудит 18, анимация 16, CSS 15, мобильная вёрстка 15, типографика 15, GSAP 4, 3D 1.

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

• Скептики. Каждую находку атакует отдельный агент, которому поставлена обратная задача: опровергнуть. Не «оценить», а именно опровергнуть, с установкой считать находку ложной при любых сомнениях. Для текстового аудита я ставил по три скептика на находку с разными углами: существует ли цитата дословно, настоящая ли это проблема или придирка, не хуже ли предложенная правка оригинала. Находка проходит, если выжила у большинства.

• Сторож. Детерминированная проверка на сборке. Про неё дальше отдельно, это главное.

Почему скептики обязательны

Вот цифры того же дизайн‑аудита: 111 находок на входе, 86 на выходе. Каждая четвёртая отсеяна.

Из 25 отклонённых большинство — «верно, но не окупается»: наблюдение справедливое, а правка стоит дороже пользы. Это нормальный рабочий исход.

Интереснее четыре, где вердикт был real: false. Разберу одну, потому что она показывает характерный тип ошибки.

Находка гласила: каскадная задержка появления элементов не срабатывает ни разу, все блоки выезжают одновременно. Описание механики было абсолютно верным — правильно назван IntersectionObserver, правильно указано, что при первичном наблюдении колбэк приходит на все элементы разом, правильно процитированы номера строк.

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

Это не галлюцинация в привычном смысле. Модель не выдумала факты: она верно прочитала код и сделала из него ложный вывод. Такую находку невозможно отличить от настоящей, читая её текст — она звучит компетентно, ссылается на конкретные строки, предлагает конкретное решение. Отличить можно, только открыв код и проверив.

Поэтому проверка находок ИИ должна выполняться против исходников, а не против текста находки. Скептику в задаче прямо сказано: открой файл, посмотри на указанную строку, решай по тому, что видишь.

Сторож: правила, которые роняют сборку

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

Пример из жизни. Агент делал глобальную замену значения на ссылку на токен. Замена попала и на строку объявления, получилось:

--red: var(--red);

Свойство становится недействительным. Цвет пропадает. На всём сайте. Тесты зелёные, типы сходятся, линтер молчит, сборка успешна. Случилось это дважды за вечер — второй раз поймал уже сторож.

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

Что они проверяют:

Обратите внимание на природу этих правил. Ни одно из них не про корректность кода. Все — про соответствие фактам: тому, что написано в источнике данных, тому, что разрешено договором, тому, что физически существует.

Типы этого не ловят. Тесты не ловят, потому что тест проверяет то, что вы предвидели. А ИИ‑агент ошибается в местах, которые вы не предвидели, — иначе вы бы их уже закрыли.

Правило, которое я считаю главным: проверить саму проверку

Каждое новое правило я проверяю подсадкой ошибки. Ставлю нарушение в файл, запускаю сборку, убеждаюсь, что она падает с внятным сообщением, убираю нарушение.

Звучит как паранойя, но половина багов в этой истории — баги не агента, а самих страховок. Проверка на имена под NDA сначала ловила только латиницу: b в JavaScript опирается на w, а это [A-Za-z0-9_], и перед кириллической буквой граница слова не возникает. Регулярка не падала, не предупреждала — просто молча ничего не находила.

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

Непроверенная проверка — это не защита, а ощущение защиты. Оно хуже отсутствия защиты, потому что вы перестаёте смотреть руками.

Комментарий, который соврал

Отдельная история, ради которой стоит дочитать.

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

Я проверил:

git log --all --diff-filter=A --name-only -- '*raw*.png' | grep -c png42

42

42 файла в истории. Один назывался по имени клиента под NDA — то есть соглашение о неразглашении нарушалось не текстом на странице, а именем файла в истории git, куда сторож тогда не заглядывал.

Мораль шире, чем про git. Комментарий, написанный ИИ, — это не документация, а предположение автора о том, как должно быть. Человек тоже пишет устаревающие комментарии, но у человека за комментарием стоит намерение. У модели за ним стоит правдоподобие: она пишет то, что обычно пишут в таких шапках.

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

Чего всё это не даёт

Честный раздел, без него статья была бы рекламой.

• Никаких цифр по трафику здесь нет, и это намеренно. Я рассказываю про инженерию, а не про маркетинговый результат: корректной методики, отделяющей вклад агентов от всего остального, у меня нет, а рисовать графики роста под тезис — ровно та беда, ради борьбы с которой всё это строилось.

• Сторож ловит факты, а не замысел. Он поймает несуществующий кейс, чужое имя, пропавший цвет. Он не поймает текст, который формально корректен и при этом бессмыслен, неудачную структуру страницы или решение, которое технически верно и коммерчески вредно. Всё, что требует вкуса, остаётся на человеке.

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

• Скептики тоже ошибаются. Они отсеяли четверть находок, но какая доля отсеянного была верной, я не знаю: чтобы это выяснить, нужен третий контур, а он стоит дороже пользы. Знаю только, что без скептиков в работу ушли бы четыре правки, ломающие работающий код.

Что забрать с собой

1. Считайте, что агент ошибается, и стройте под это конвейер. Не «а вдруг», а «регулярно, в местах, которые вы не предвидели».

2. Проверяйте находки ИИ против исходников, а не против их текста. Самые опасные звучат компетентнее настоящих: верное описание механики, ложный вывод.

3. Ставьте на проверку отдельного агента с обратной задачей. Не «оцени», а «опровергни», с установкой отклонять при сомнении. У меня так отсеивается каждая четвёртая находка.

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

5. Выносите инварианты фактов в сборку. Тесты проверяют предвиденное, а агент ошибается в непредвиденном. Правило, роняющее сборку, — единственное, что работает, пока вы спите.

6. Проверяйте саму проверку подсадкой ошибки. Половина моих багов — в страховках, и все они молчали.

7. Комментарий, написанный агентом, — гипотеза. Проверяйте командой, а не чтением.

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