Что отдать машине при переносе корпоративного сайта

Про ИИ в разработке распространены три заблуждения.

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

Третье менее заметное, и для нашего процесса оно оказалось самым вредным: весь выигрыш от перестройки процесса приписывается искусственному интеллекту. Хотя значительная часть приходит оттуда же, откуда приходила всегда, — от чек-листов, скриптов и записанных правил.

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

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

Наша первая попытка была очевидной — дать одному агенту задачу «собери сайт из этой вёрстки». Она провалилась, и не из-за качества кода.

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

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

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

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

Главное разделение, которое стоит сделать до всякой автоматизации. Работа делится не на две части, а на три. Мы исходно смешивали работу модели с обычной автоматизацией, и это стоило нам неверных выводов о том, что именно даёт результат.

Сюда попадает больше, чем кажется.

Прохождение чек-листа перед сдачей. У 1С-Битрикс есть встроенный Монитор качества с двадцатью шестью обязательными тестами: настройки сайта, права доступа, тестовые данные, почта, производительность, безопасность.

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

Пример, на котором разница видна яснее всего. Копия сайта снимается утилитой wget. Параметр --page-requisites подтягивает ресурсы страницы, но по умолчанию только с исходного домена. Если сайт держит изображения и стили на отдельном домене — такую схему регулярно используют внешние платформы, — нужен ещё --span-hosts, разрешающий переход на другие хосты. Руководство GNU Wget рекомендует ограничивать переходы: технически --span-hosts работает и без ограничений, но тогда утилита может перейти на непредусмотренные домены и скачать лишние ресурсы, поэтому разумно использовать его вместе с --domains со списком разрешённых хостов.

Проверяли на реальном сайте с ассетами на стороннем CDN: команда без --span-hosts принесла разметку без единого изображения, с ограниченным переходом на CDN изображения скачались.

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

Здесь языковая модель особенно полезна — она снижает объём правил, которые пришлось бы описывать отдельно под каждый сайт.

Инвентаризация. Разметка у всех сайтов разная, и распознавание «карточки услуги» в чужих классах не сводится к одному универсальному правилу разбора. Но операция делится на три шага, и только первый принадлежит агенту: он предлагает признаки блока и группирует варианты разметки; человек подтверждает классификацию; скрипт считает все совпадения и формирует проверяемый отчёт.

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

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

Подготовка документов. Из инвентаризации собирается заготовка технического задания со ссылками на конкретные места в исходной разметке.

Применение накопленных правил. Три примера.

В композитном режиме 1С-Битрикс динамические области доставляются отдельным запросом уже после первоначальной загрузки. Слайдер, инициализируемый только по событию загрузки DOM, не увидит элементы, пришедшие позже, — инициализацию нужно связывать с обновлением динамической области. Для заказчика это может проявиться как неработающий слайдер или другой динамический элемент после включения ускорения сайта.

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

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

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

О них отдельный раздел ниже.

Здесь легко ошибиться.

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

Действия языкового агента воспроизводимыми не являются. Модель отвечает вероятностно: на одинаковый запрос она может дать разные формулировки и разные варианты решения. Гарантировать, что второй прогон даст в точности то же самое, нельзя.

Практический вывод: полагаться нужно не на то, что агент сделает одинаково, а на то, что его результат каждый раз проходит одни и те же проверки. Устойчивость обеспечивает первая категория работы, не вторая.

Формулировка важна: речь не о том, что агент принципиально неспособен, а о том, что мы не поручаем ему эти решения.

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

Поэтому изменения модели данных разумно оставлять под человеческим контролем: последствия накапливаются годами, а полноту и непротиворечивость переданного агенту бизнес-контекста гарантировать нельзя.

Разговор с заказчиком. Под словом «каталог» один клиент понимает витрину без цен, другой — магазин с корзиной, третий — справочник для менеджеров. Агент способен провести структурированное интервью по списку вопросов. Но понимание уточняется не с первого раза: человек видит первые макеты и говорит «нет, я имел в виду другое». Здесь нужно выявлять неформализованные ожидания и проверять понимание на прототипах.

Приоритеты. Где вылизывать, а где достаточно рабочего варианта — решение, определяющее сроки не меньше, чем скорость исполнения.

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

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

Агент работает только в изолированной копии и не имеет доступа к серверу клиента. Его изменения попадают в репозиторий и проходят отдельный процесс проверки, сборки и развёртывания.

Одна из причин — свойства самих инструментов. На официальном форуме Cursor подтверждены случаи удаления файлов в режиме Remote SSH после переподключения; в одном из сообщений рабочей областью была домашняя директория, что увеличило масштаб потери. Это частная ошибка конкретного инструмента, но она показывает общий принцип: агентская среда не должна открывать боевую директорию как рабочую. Другие сообщения о том же семействе ошибок — в примечаниях.

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

Для заказчика смысл этой схемы прост: она уменьшает вероятность простоя и даёт проверенный путь отката.

Риск, специфичный для языковых агентов.

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

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

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

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

Для заказчика это отдельный обязательный вопрос.

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

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

На практике это шесть вопросов, на которые у подрядчика должен быть письменный ответ:

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

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

Измерять имеет смысл не объём сгенерированного кода, а скорость поставки вместе с качеством и стабильностью — по отдельности любой из показателей вводит в заблуждение. Быстрый поток дефектов и безупречный, но экономически бессмысленный процесс одинаково плохи. Методика DORA рассматривает пропускную способность и нестабильность совместно, и для нашей задачи это верный подход.

Применительно к переносу сайтов рабочий набор такой: срок от постановки до публикации, доля неуспешных публикаций, время восстановления после сбоя, объём незапланированных переделок, число возвратов с приёмки, количество пропущенных обязательных проверок и трудозатраты на проверку.

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

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

Без таких измерений любые утверждения о пользе остаются впечатлением. В том числе наши.

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

Ошибка выглядит как правильный ответ. Ошибочный ответ модели бывает столь же связным и категоричным, как верный. Иногда его выдают противоречия внутри текста или несуществующие ссылки, но универсального внешнего признака нет, поэтому содержательная проверка обязательна. Пример из нашего опыта: при подготовке материалов по агрономической тематике агент перепутал числовой показатель скороспелости и категорию, которая из него выводится, и изложил это связно, убедительно и неправильно. Если бы материал вышел без проверки, профильный специалист быстро заметил бы ошибку.

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

Правка одного места может создать противоречие в другом. Локальная правка длинного документа может создать расхождение с соседним разделом, который не попал в текущий контекст проверки. Значит, после серии правок нужна сквозная проверка, а не только проверка исправленного.

Инструменты требуют проверки перед внедрением. Готовые наборы правил и расширений для агентов бывают релевантны по названию и не по сути. Предварительная проверка позволяет отсеять неподходящий инструмент до внедрения.

Ревью может стать узким местом. Чем больше кода генерируется, тем больше его нужно просматривать, и скорость генерации без роста пропускной способности проверки в скорость поставки не превращается. В том же опросе Sonar 38% респондентов сообщили, что проверка ИИ-кода требует больше усилий, чем проверка кода коллег, — это самоотчёт, а не измерение, но ограничение обозначает.

Вопрос «используете ли вы ИИ» сам по себе полезен: он открывает разговор о передаче данных, поставщике модели и ответственности, а у части компаний это ограничено договором. Но одного ответа мало: сам факт использования ИИ ничего не говорит о зрелости процесса.

Спрашивать стоит о процессе:

Ответы на эти вопросы показывают, есть ли за словами про ИИ выстроенный процесс. Отсутствие ответа на последний — само по себе честный ответ: значит, эффект пока не измеряли. Это нормально, если признаётся прямо.

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