Пишу код с шестью AI. Что это меняет на самом деле

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

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

Главное правило для владельца

AI ускоряет черновик. Он не снимает с подрядчика обязанность объяснить, что сделано, и не заменяет ваши приемочные проверки. Если результат нельзя показать, воспроизвести и откатить, он еще не готов, сколько бы моделей ни участвовало.

Роли: как разделить работу между моделями

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

• Аналитик брифа (у меня Claude): читает ТЗ и переписку, ищет противоречия и дыры. Выход: список вопросов, а не сразу код.
• Сборщик каркаса (Open Code): поднимает структуру проекта, типы, базовые экраны. Выход: понятный diff, который человек читает.
• Черновик интерфейса (z.ai + GPT): предлагает блоки по вашим правилам дизайна. Выход: макет/верстка на проверку, не «финальный бренд».
• Второй ревьюер (MiniMax + Kimi): ищет регрессии и пропущенные случаи. Выход: список замечаний с шагом воспроизведения.

Роль | Вход | Выход | Кто принимает
Бриф | ТЗ, переписка | вопросы и риски | владелец + исполнитель
Каркас | согласованный объем | структура и код | исполнитель
UI | токены/референсы | черновик экранов | владелец по смыслу
Ревью | diff + сценарии | баги и пробелы | исполнитель чинит, владелец смотрит демо

Как владельцу использовать multi-AI без хаоса

• Держите один источник правды: бриф, список страниц, критерии приемки. Модели читают его, а не три версии в чатах.
• Не вставляйте в промпты секреты: пароли, ключи API, персональные данные клиентов.
• Просите у подрядчика не «мы сделали с AI», а артефакты: список страниц, доступы, как проверить форму, что в аналитике.
• Любое спорное решение фиксируйте письменно: что выбрано и почему. Иначе модели будут «улучшать» уже согласованное.
• Один человек отвечает за релиз. Несколько моделей не равны нескольким ответственным.

Что проверить в сдаче (даже если «все на AI»)

• Сценарий заявки: тестовая отправка доходит в почту/CRM с нужными полями.
• Мобильный просмотр: ключевые экраны читаются, кнопки нажимаются.
• Юридическое и контакты: реквизиты, политика, телефон/мессенджер совпадают с реальными.
• Аналитика: цель на отправку срабатывает; в отчете виден тестовый источник.
• Доступы: хостинг, домен, репозиторий/исходники, инструкции по смене паролей у вас, не «потом вышлем».
• Границы AI-ответов (если есть бот): что бот имеет право сказать, когда зовет человека, чего не выдумывает.

Шаблон короткого ТЗ, которое модели не размоют

Цель: [заявка на услугу X / меньше ручных переносов в CRM]
Не цель: [редизайн всего бренда / «чтобы было современно»]
Страницы: [список]
Обязательные поля формы: [...]
Куда падает заявка: [email / CRM / Telegram]
Ограничения: [не трогать оплату, не менять домен]
Приемка: [3 пользовательских шага + 1 техническая проверка]
Срок и кто отвечает на вопросы со стороны бизнеса: [...]

Где AI бессилен, и это нормально

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

Шесть AI не заменяют разработчика. Они убирают часть рутины, которая мешала думать. Для вас как заказчика это значит: быстрее черновики и больше времени на смысл, если контроль качества не выключили.

Красные флаги в работе подрядчика

• Не может объяснить кусок сдачи своими словами.
• Отказывается от тестов «потому что модель уже проверила».
• Нет списка изменений и способа отката.
• В проде лежат ключи и тестовые заглушки.
• Обещает рост продаж от «внедрения AI» без сценария и метрики.

Мини-процесс на один спринт сайта

• День 1: бриф и список противоречий от аналитика. Вы подтверждаете объем письмом.
• День 2-3: каркас и черновые экраны. Вы смотрите кликабельный черновик, не пиксель-перфект.
• День 4: формы, аналитика, мобильная проверка по чек-листу сдачи.
• День 5: второе ревью, правки, доступы, короткая инструкция «как поменять текст/пароль».
• Если модель предложила лишнюю фичу вне брифа, она в бэклог, не в релиз.

Что попросить у исполнителя на созвоне на 15 минут

1) Покажите тестовую заявку end-to-end.
2) Где исходники и кто владелец доступов?
3) Что ломалось на этой неделе и как чинили?
4) Какие проверки гоняются перед выкладкой?
5) Что из сдачи сгенерировано, а что проверено руками?

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