Выберите одну доработку сайта и поручите её Claude Code и другому harness в одинаковых условиях. Harness — это рабочая среда ИИ-агента: она даёт ему доступ к файлам, командам и проверкам. Для малого бизнеса полезнее сравнивать готовый результат, затраты и возможность отменить изменения, чем убедительность ответов в чате. Ниже разберём, как подготовить такое сравнение, что записывать во время работы и по каким признакам выбрать инструмент для дальнейших доработок сайта.
Какую задачу сайта дать ИИ-агентам для сравнения?
Возьмите небольшую задачу с понятным результатом: добавить блок услуг, исправить мобильное меню или привести цены к единому формату. Например, для сайта компании из Беларуси можно проверить, как агент обновит карточки услуг с ценами в BYN и сохранит их читаемость на узком экране. Это условный сценарий для теста, без обещаний роста заявок.
Свяжите задачу с действием посетителя. Если человек выбирает услугу, ему нужны понятное описание и рабочий переход к обращению. В исходном материале о разработке сайтов в Беларуси работу тоже предлагают начинать с цели: получить звонки, собрать заявки, продать товар или записать клиента на услугу (источник: Saitodrom).
Запишите критерии приёмки до запуска агента. Иначе красивый результат легко принять, даже если он нарушает логику страницы.
- Что меняем: конкретную страницу или элемент интерфейса.
- Как выглядит готовый результат: что посетитель видит и какое действие выполняет.
- Что сохраняем: существующие ссылки, оформление и поведение соседних элементов.
- Как проверяем: действия в браузере и доступные тесты проекта.
- Где агент останавливается: какие изменения требуют согласования с человеком.
Задание «улучши сайт» для сравнения не подходит: каждый агент выберет собственный объём работы. Используйте формулировку вроде: «Исправь мобильное меню: кнопка открывает и закрывает список, переход по ссылке закрывает меню, на широком экране прежняя навигация сохраняется».
Как создать одинаковые условия для Claude Code и другого harness?
Подготовьте отдельную тестовую копию сайта для каждого участника. Начальное состояние файлов должно совпадать. Не запускайте агентов по очереди в одной рабочей папке: второй получит чужие исправления и уже другую задачу.
Модель и harness влияют на результат по-разному. Модель предлагает решения, а среда определяет доступные действия и порядок работы. Если инструменты поддерживают одинаковую модель, используйте её для более чистого сравнения. Если такой возможности нет, оценивайте связку целиком и запишите это ограничение в итогах.
- Сохраните исходное состояние проекта в системе контроля версий, чтобы видеть изменения и возвращаться к рабочей версии.
- Передайте каждому агенту одинаковое задание и общие инструкции проекта.
- Выдайте одинаковые разрешения на чтение файлов, изменение кода и запуск команд.
- Задайте общий предел расходов и времени, после которого остановите попытку.
- Записывайте уточнения, ручные исправления и команды, которые пришлось выполнять вместо агента.
Передавайте одинаковый смысл инструкций, даже если harness хранит их в другом формате. Не рассчитывайте, что одна среда автоматически прочитает настройки другой. Попросите агента сначала перечислить ограничения задачи и доступные проверки: так проще заметить, что инструкция потерялась.
На первом сравнении оставьте только необходимые расширения и скиллы, то есть дополнительные инструкции для отдельных задач. Иначе вы будете сравнивать ещё и разные наборы дополнений. Их влияние можно проверить отдельно по схеме из статьи о сравнении скиллов Claude Code на задачах сайта.
Что оценивать, кроме внешнего вида страницы?
Смотрите на изменения в файлах, поведение сайта и объём вашего участия. Красивый ответ агента не подтверждает, что меню работает после перезагрузки страницы. Попросите его назвать выполненные проверки, а затем повторите основные действия самостоятельно.
| Критерий | Что проверить | Что записать |
| Выполнение задачи | Пройти сценарий посетителя по критериям приёмки | Что работает и какие дефекты остались |
| Границы изменений | Посмотреть список изменённых файлов и правки в них | Какие изменения выходят за пределы задания |
| Проверки | Повторить тесты и открыть страницу в браузере | Что проверено, что пропущено и по какой причине |
| Участие человека | Посчитать уточнения и ручные исправления | Минуты вашей работы и расходы на попытку |
| Возврат к исходной версии | Проверить отмену правок на тестовой копии | Удалось ли вернуть рабочее состояние |
Расходы записывайте в одной валюте. Если приводите их к BYN, сохраните исходную сумму и курс пересчёта, который использовали. Время владельца тоже фиксируйте отдельно: дешёвая попытка с долгой ручной правкой может не подойти для регулярной работы.
Уточняйте, что именно агент называет успешной проверкой. Сборка подтверждает, что проект удалось собрать, но не доказывает, что посетитель может открыть меню или перейти к нужной услуге. Отчёт «всё работает» без перечня действий оставляйте как неподтверждённый результат.
Разделяйте дефекты кода и сбои среды. Например, ошибка 503 означает, что сервер сейчас не может обработать запрос; среди причин бывают перегрузка и технические работы. Сам по себе этот код ещё не доказывает ошибку ИИ-агента (источник: KalinkinDev). Сначала проверьте доступность исходной версии в тех же условиях.
Как проверить безопасность и возможность отменить изменения?
Проводите сравнение вне рабочего сайта и не выдавайте агенту доступ к публикации без необходимости. Для исправления меню достаточно тестовой копии проекта. Подходящий режим разрешений можно выбрать по инструкции о безопасной работе с Claude Code для сайта.
Попросите агента перед правками коротко описать план. Если вместо изменения меню он предлагает заменить библиотеку интерфейса или перестроить весь проект, остановите выполнение и уточните границы. Широкая переделка требует отдельной задачи и отдельной проверки.
Разделите подготовку изменений и разрешение на публикацию. В русском руководстве по Claude Code описан подход с несколькими уровнями контроля: проверками перед запросом на слияние, ревью безопасности, автоматическими тестами и одобрением человеком в зависимости от риска. Там же подчёркнута возможность быстро откатить изменения (источник: claude-code-handbook-ru на GitHub).
Для небольшого сайта начните с доступного набора: просмотр правок, проверка сценария в браузере и возврат к исходной версии на тестовой копии. Если принять результат некому, отдельная техническая проверка поможет закрыть конкретный пробел: специалист проверит код и перечислит условия, при которых доработку можно публиковать.
Какие типичные ошибки мешают выбрать harness?
- Сравнивать разные задания. Исправление кнопки и переделка каталога требуют разного объёма работы; используйте один исходный проект и одно задание.
- Считать скорость ответа скоростью решения. Замеряйте время до результата, который прошёл проверку, включая ваши исправления.
- Доверять отчёту вместо проверки. Просите назвать команды и действия, затем повторяйте ключевой сценарий в браузере.
- Менять инструкции по ходу только для одного агента. Если нашли пробел в задании, внесите уточнение в обе версии и повторите сравнение.
- Объявлять победителя после одной удачной правки. Зафиксируйте вывод для этого типа задач, а перед более сложной работой проведите отдельную проверку.
Выбирайте harness по условиям дальнейшей работы. Для регулярных правок важны понятные изменения и небольшое число вмешательств человека. Для сложного проекта добавятся требования к тестам и совместной работе. Связать эти требования с задачами бизнеса поможет материал о выборе harness для доработки сайта малого бизнеса.
Сохраните результат сравнения в короткой записи: задача, модель, настройки среды, расходы, время ручной работы и оставшиеся дефекты. Рабочим результатом считайте доработку, которая проходит согласованный сценарий и которую удалось отменить на тестовой копии. Сейчас за две минуты запишите одно действие посетителя вашего сайта, которое должны проверить оба агента, например: «На телефоне открываю меню и перехожу на страницу услуги».
