Как перестроить производство сайтов с AI: этапы, роли и контроль

Авторская модель производства сайтов с AI: что проверять на каждом этапе и как понять, изменилась ли экономика проекта.

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

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

Четыре уровня готовности

1. Сгенерирован результат: есть текст, экран или код, которые можно обсудить.

2. Работает сайт: он размещён в подходящем окружении и выполняет необходимые функции.

3. Принят проект: заказчик проверил результат по согласованным требованиям.

4. Подтверждён бизнес-эффект: отдельные данные показывают, какую задачу решил сайт. Сам факт запуска этого не доказывает.

Как подтверждает документация OpenAI Sites, в поддерживаемых сценариях можно создать и опубликовать сайт по текстовому описанию. При этом доступность функции и ограничения среды различаются. Это не гарантия выполнения произвольного клиентского ТЗ. Следовательно, руководитель должен различать скорость генерации и трудозатраты на принятый результат.

Почему у эксперта получается иначе

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

Когда я просто прошу AI «сделай дизайн сайта», результат обычно выходит посредственным. Я могу запрашивать новые варианты, но мне не всегда хватает профессиональных знаний, чтобы точно объяснить, что именно нужно изменить: композицию, визуальную иерархию, порядок блоков или логику действий посетителя.

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

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

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

Именно это наблюдение привело меня к следующему вопросу: если AI помогает эксперту быстрее воплощать то, что он уже понимает, как должна измениться вся система производства сайтов в digital-студии?

Производство сайта как цепочка решений

В нашей digital-студии партнёр занимался дизайном и графикой, а я - разработкой и технической инфраструктурой. Мы выполняли разные виды работ, но со временем для меня всё важнее становился вопрос: какой результат они дают клиенту? Этот этап я описывал в своём предпринимательском пути. Здесь он нужен только как профессиональный контекст. Это не история об использовании AI и не измерение его эффективности.

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

1. Бриф, задача бизнеса и аудитория.
2. Оффер и продуктовый смысл.
3. Структура сайта и пользовательские сценарии.
4. Тексты, визуальная концепция и экраны.
5. Разработка и интеграции.
6. Проверка качества.
7. Приёмка, запуск и сопровождение.

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

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

1. Бриф: проверить исходную задачу

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

Кто принимает: руководитель проекта проверяет полноту брифа, а заказчик подтверждает сведения о своём продукте и требования к результату.

Что передаётся дальше: согласованный бриф со списком неизвестных, а не набор догадок, оформленных как факты.

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

2. Оффер: сначала содержание, затем экран

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

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

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

3. Архитектура: проверить путь пользователя

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

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

AI способен создавать варианты структуры и подсвечивать пропущенные состояния. Но выбор маршрута зависит от цели и согласованного объёма работ.

Решение: проектировщик или руководитель производства с необходимыми согласованиями заказчика.

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

Меряем: часы проектирования, изменения структуры после передачи дизайнеру и разработчику, повторные согласования.

Этапы 1-3 могут идти с возвратами: найденный факт о продукте меняет оффер, а новое требование к сценарию - структуру. Это не обязательная ошибка. Но такие возвраты надо учитывать.

4. Тексты и дизайн: первый вариант ещё не согласованный результат

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

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

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

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

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

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

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

5. Разработка с AI: от кода до работающей функции

AI-агенты для разработки действительно могут вносить изменения в файлы проекта, искать по кодовой базе, выполнять команды и помогать исправлять ошибки. Например, эти функции описаны в документации Cursor Agent. Доступные действия и способы контроля зависят от инструмента и окружения.

Но если агент создал форму заявки, это ещё не доказывает, что заявка поступает в нужную систему.

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

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

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

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

Проверка качества, приёмка и сопровождение

6. Проверка качества

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

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

Хороший пример ограничения автоматизации приводит W3C Web Accessibility Initiative: инструменты проверки доступности помогают находить проблемы, но не способны автоматически оценить все аспекты. В ряде случаев требуется человеческое суждение. Это не доказательство плохой доступности AI-сайтов, а граница возможностей автоматического контроля.

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

7. Приёмка и дальнейшая ответственность

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

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

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

Только после этого можно обсуждать полную длительность проекта до принятого результата, а не скорость генерации его первого экрана.

Где на самом деле появляется переделка

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

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

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

Я бы фиксировал возвращения в компактном журнале:

Не стоит считать все замечания одинаковыми: исправить опечатку, изменить интеграцию и заново согласовать оффер - три разных объёма работы. Я бы разделял их и по причине, и по трудозатратам.

Здесь возникает главный для меня управленческий вопрос: каким стало время и качество полной поставки после учёта всех возвратов? Без ответа сравнение по скорости отдельных операций остаётся неполным.

Действительно ли AI ускоряет производство сайтов

Результаты исследований программирования показывают, почему здесь нельзя обещать один процент экономии.
В эксперименте GitHub, опубликованном в 2022 году, 95 разработчиков выполняли одну задачу: писали HTTP-сервер на JavaScript. Это исследование провели GitHub и Microsoft, создатели оцениваемого инструмента. Участники с Copilot справились в среднем на 55% быстрее. Это показатель конкретного задания, а не полного цикла клиентского сайта.

В исследовании METR 2025 года 16 опытных разработчиков выполняли 246 задач в знакомых открытых репозиториях. В этих условиях разрешение использовать AI сопровождалось средним замедлением на 19%. Такой результат не означает, что каждый разработчик в 2026 году работает с AI медленнее.

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

Эти работы не сравнивают себестоимость обычного и AI-assisted производства одного и того же сайта в конкретной digital-студии. Вывод, который я из них делаю, скромнее: важно измерять одну и ту же единицу результата и учитывать условия работы.

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

Какие показатели сравнивать

Часы специалистов. Включать подготовку задачи и данных, запросы к AI, создание результата, просмотр, исправления, тестирование, повторные согласования и сопровождение в выбранном периоде. Отдельно учитывать фактическую занятость человека проверкой результатов AI; время автономного ожидания агента не следует автоматически записывать в его трудочасы. Оно может влиять на календарный срок проекта.

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

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

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

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

Это именно аналитическая модель, а не универсальное бухгалтерское определение. Порядок распределения общих расходов должен быть одинаковым для сравниваемых проектов. Цена клиенту, накладные расходы и маржа - отдельные показатели. В этой статье речь о производстве, а не о коммерческой модели продажи услуг.

Шаблон сравнения

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

В таблицу для сопоставимых проектов я бы вносил такие поля:

«Не измерено» здесь не означает ноль. Я не подставляю условные часы и рубли, потому что они легко превращаются в мнимую экономию.

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

Какой эксперимент я бы поставил первым

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

Мой порядок действий:

1. Зафиксировать условия. Состав страниц и функций, требования, критерии качества и приёмки, допустимые изменения задания.

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

3. Назначить людей, принимающих решения. Кто формулирует задание, кто проверяет результат AI, кто разрешает передачу следующему участнику.

4. Заранее определить метрики. Часы людей, календарный срок, исправления, качество, стоимость инструментов. Успех должен быть определён до получения результата.

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

6. Принять решение по результату.

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

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

К какому выводу я прихожу

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

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

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

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

Источники и границы выводов

• OpenAI Help Center: создание и использование сайтов - функции и ограничения поддерживаемого продукта, не гарантия исполнения любого клиентского ТЗ.
• Cursor Agent - возможности агентного редактирования кода, не исследование экономической эффективности студий.
• GitHub: исследование Copilot, 2022 - ограниченный эксперимент с определённой задачей.
• METR: исследование 2025 года и обновление февраля 2026 года - разные условия исследований и ограничения переноса результатов.
• W3C WAI: инструменты проверки доступности - ограничения автоматизированной проверки.

Семь этапов, условный B2B-пример, приёмочные критерии и схема сравнения - предлагаемая аналитическая модель. Здесь нет моего выполненного A/B-теста полной себестоимости клиентских сайтов и нет основания обещать определённую экономию всем агентствам.