Как я делаю сайты с ИИ-агентами: разбор конвейера

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

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

Что здесь называется конвейером

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

Шаг	Кто делает	Что на выходе
Контекст проекта	человек, один раз	файл правил, который агент читает перед работой
Задание на волну	человек	список того, что сделать, и того, чего делать нельзя
Черновик	агент	код, тексты, тесты
Гейты	автоматика	сборка, типы, линтер, тесты — зелёные или красные
Ревью	человек	приёмка или возврат с замечаниями
Релиз	автоматика по команде человека	новая версия на сервере

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

Шаг 1. Контекст проекта лежит в самом репозитории

В корне проекта живёт файл с правилами: стек, структура папок, решения и причины, по которым они приняты, а ещё — список грабель конкретной рабочей машины. Агент читает его перед каждой задачей. У меня таких файлов два — CLAUDE.md для Claude Code и AGENTS.md для Codex; содержимое общей части обязано совпадать, и это тоже записано правилом.

Что туда попадает:

Стек и почему именно он. Не «Next.js», а «Next.js, потому что тот же стек у соседнего проекта и его сопровождает один человек».
Запреты. Например: цены нельзя писать в тексте страницы, они берутся из одного конфига; шрифты — только системные, внешние CDN запрещены.
Грабли окружения. У меня там записано, что порт 5432 занят контейнером соседнего проекта, а однажды npm install висел минутами, потому что в зависимостях стояла несуществующая версия пакета — и менеджер пакетов молча перебирал дерево. Второй раз на это не наступает уже никто.

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

Шаг 2. Задание на волну — и список того, чего делать нельзя

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

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

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

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

Шаг 3. Гейты вместо обещаний

Агент не сдаёт работу словами «готово, всё работает». Он показывает результат команд, которые ничего не знают про его уверенность:

Гейт	Что ловит
Сборка проекта	страницу, которая не собирается на проде
Проверка типов	несуществующее поле, переименованный ключ, забытую ветку кода
Линтер	мёртвый импорт, забытую переменную, стиль вразрез с проектом
Юнит-тесты	ошибку в расчёте цены, дыру в фильтре безопасности
Сквозные тесты в браузере	форму, которая внешне работает, а заявка не доходит
Lighthouse на мобильном	просевшую скорость, контраст, доступность

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

Шаг 4. Стражи — тесты про структуру, а не про код

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

Мёртвая ссылка в меню. Меню есть на каждой странице, поэтому битая ссылка в нём — самая дорогая. Тест сверяет каждый адрес меню с файловой структурой роутов и роняет сборку, если страницы нет.
Статья без перехода в действие. Материал, из которого некуда пойти, не работает. Тест проверяет, что в каждой статье есть ссылка хотя бы на один интерактив — калькулятор, аудит или контакты.
Клоны страниц городов. У страниц Краснодара, Сочи, Анапы общий только каркас. Если тексты двух городов совпадут дословно, поиск склеит страницы — тест ловит такое совпадение до публикации.
Дата обновления раньше даты выхода. Мелочь, но «опубликовано 27 августа · обновлено 27 августа» — это шум в выдаче, а не сигнал свежести.

Каждый такой страж родился из уже сделанной ошибки. Это, пожалуй, главное отличие рабочего набора тестов от ритуального: тест пишется не «для покрытия», а после того, как что-то один раз сломалось.

Шаг 5. Ревью и релиз делает человек

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

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

Про доступность, кстати, отдельная история: ссылку «К содержимому» — ту, что появляется на этом сайте по первому нажатию Tab, — я добавил не потому, что её попросил клиент, а потому что продаю приведение сайтов к требованиям доступности. Не иметь обхода блоков на собственном сайте было бы неловко.

Чего конвейер не делает

Честный список ограничений, без которого всё вышесказанное звучало бы как реклама:

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

Что из этого можно забрать себе

Если вы делаете сайт сами, с нейросетью или без, три вещи из конвейера работают и в одиночку:

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

А если хотите просто понять, в каком состоянии сайт сейчас, — есть экспресс-аудит: техника, SEO, 152-ФЗ-минимум и то, что видят нейросети, прямо на экране и без регистрации.

Коротко

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

Частые вопросы

Код пишет нейросеть — значит, сайт хуже?

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

Кто отвечает, если что-то сломается?

Я. Инструмент не бывает ответственным лицом: договор подписывает ИП, ошибки в своей работе исправляю за свой счёт. Что именно обещаю письменно — на странице «Как я работаю».

Мой сайт потом сможет вести другой разработчик?

Да, и это заложено в выбор стека: обычный Next.js, обычный Postgres, никаких самодельных фреймворков. Исходники, домен и доступы оформляются на вас. Полный список инструментов — на странице «Чем я работаю».

Сколько времени экономит такой подход?

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

Почему в блоге нет клиентских кейсов?

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