Обновить

Как мы пускаем ИИ на боевые сайты, или Что происходит после команды «исправляй»

Уровень сложностиСредний
Время на прочтение23 мин
Охват и читатели8.8K
Всего голосов 5: ↑5 и ↓0+7
Комментарии8

Комментарии 8

Я бы ещё добавил проверку через пару часов после правки. Сразу всё зелёное, а потом срабатывает кэш или задача по расписанию и начинается веселье. Интересно, как агент будет разбирать такие отложенные поломки, когда уже успел отчитаться)

Да, это обязательно надо учитывать. Потому что сразу после правки обычно всё идеально: проверки зелёные, агент довольный, разработчик уже мысленно закрыл задачу. А через пару часов приходит клиент. С телефона. Где каким-то чудом живёт кэш времён динозавров. И пишет: «У меня всё сломалось».

И дальше начинается любимая часть работы: кэш, cron, CDN, фоновая задача — кто сегодня решил сделать тебе вечер. Так что повторная проверка нужна. А агенту придётся привыкать, что «готово» — это не всегда конец истории.

Зелёные проверки сразу после правки - отдельная ловушка, если их пишет тот же агент, что и правку. Я как-то подал заведомо правильное решение в тесты, сгенерированные моделью: 129 наборов из 168 его завернули. А самый неприятный случай был обратный. Код считал гласные и забывал про заглавные, а тест ровно этого и ждал. Тест и баг совпали в одном непонимании задачи, проверка сказала PASS, починка даже не запустилась. Поймал только внешний тест, написанный руками. С тех пор решающая проверка у меня всегда снаружи агента.

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

«Если баланс не сошёлся - в нем одна ошибка. Если сошелся - ошибки две». Классика.

Вот тут я бы уже поспорил. Потому что фраза «достаточно хотя бы не сделать его хуже» звучит удобно для разработчика, но для SEO это довольно опасная логика. Допустим, на странице цена 25 000, в JSON-LD 50 000, canonical смотрит вообще не туда, а в meta остался текст двухлетней давности. Все это было до правки. Агент поменял какой-нибудь блок, site-check ничего нового не нашел и радостно сказал, что все хорошо. Но хорошо там не было ни до него, ни после.

Получается, вы просто узакониваете уже существующий бардак. Новых ошибок нет, зато старые ошибки теперь официально считаются нормальным состоянием. Почему не проверять еще и смысловые вещи? Что цена в разметке совпадает с ценой на странице, canonical ведет туда, куда должен, JSON-LD вообще соответствует содержимому, а одни и те же данные не живут в пяти местах с пятью разными значениями. Иначе агент получается очень аккуратно следит за тем, чтобы не сломать то, что уже сломано. Вы это сознательно оставили за пределами site-check или просто пока до этого не дошли?

Да, это справедливое замечание. Но сайт-чек у меня сейчас про другое. Его задача довольно приземленная, убедиться, что после конкретной правки страница открывается, не приехали новые ошибки, не поехала верстка и ничего рядом не отвалилось.

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

Я не понял, что у вас вообще решает запрет на одновременную запись. Один агент читает старое состояние, что-то на его основе готовит, ждёт, пока другой закончит, и спокойно пишет уже в изменившийся сайт. Гонку вы не убрали. Вы просто поставили агентов в очередь. Как вам такое?

Да, вот тут спасибо, ткнули ровно туда, куда надо. Мы так увлеклись тем, чтобы два агента не полезли одновременно что-то писать, что пропустили более противную вещь. Второй-то вполне может успеть прочитать старое состояние, приготовить по нему правку, дождаться своей очереди и потом аккуратно внести уже протухшее изменение. То есть дверь мы закрыли, а окно оставили открытым.
По крайней мере теперь я уже точно знаю, с чего начнется завтрашний рабочий день.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации