Сервисы, которые собирают продукт по описанию, легко принять за ответ на любую задачу. Это не так, и границы лучше знать до того, как потрачены деньги и недели. В статье — где ИИ-сборка действительно сильна, в каких случаях нужен живой разработчик и как выглядит промежуточный путь. В конце — пять вопросов, которые помогут быстро понять, какой вариант подходит вашей задаче.
Где ИИ-сборка сильна: типовые продукты с данными, формами и кабинетами
ИИ-команда Roboweb собирает четыре типа продуктов: лендинг; интернет-магазин; портал с объявлениями, поиском и кабинетами; рабочую панель с таблицами, показателями и доступами. Это фуллстек: заявки пишутся в базу данных, каталог живой, корзина и оформление заказа работают, посетители регистрируются и видят в кабинете свои данные. Чем такой продукт отличается от макета, разобрано в статье про фуллстек от ИИ за часы.
Общее у этих задач: логика понятна и много раз реализована в индустрии. Страница с предложением, форма, каталог с фильтрами, кабинет со списком своих записей, таблица с правами доступа. Здесь ИИ-сборка берёт на себя каркас, который разработчик всё равно написал бы по известной схеме, и сокращает путь до первой рабочей версии.
Условный пример: небольшая сеть студий йоги хочет страницу с направлениями и расписанием, запись на пробное занятие, заявки в одном месте и кабинет, где клиент видит свои записи. Всё это — типовые сценарии, их можно описать обычными словами и проверить в превью.
Признак, что задача подходит: продукт можно описать словами на одной-двух страницах, и в описании нет фраз «как у нас в учётной системе» или «должно работать с нашим оборудованием».
Мобильные приложения в сторах — другой класс задач
Roboweb собирает веб-продукты. Они открываются в браузере телефона: опубликуйте проект по ссылке и откройте его на своём смартфоне, чтобы увидеть, как он выглядит на узком экране. Но приложение, которое публикуется в магазинах приложений, — отдельная разработка: свои технологии, правила модерации, цикл обновлений через магазин.
Если приложение действительно нужно — из-за работы без интернета, доступа к камере и датчикам или постоянного присутствия на экране телефона, — это работа для мобильного разработчика. Веб-версия при этом может стать разумным первым шагом: проверить спрос и сценарии до больших вложений в приложение.
Глубокие интеграции: учётные системы, телефония, платёжные сервисы
Готовых интеграций в продукте нет:
- с учётными системами вроде 1С — обмена остатками, заказами, документами;
- с телефонией — записи звонков, карточки звонящего, подменных номеров;
- с платёжными сервисами и онлайн-кассами. Оформление заказа в собранном магазине работает, сумма считается на сервере по ценам каталога, но приём оплаты, фискальные чеки и возвраты подключает разработчик.
Сложность интеграции не в кнопке «подключить». Это договорённость двух систем о данных: какая из них главная, что делать при расхождении остатков, как повторить запрос после сбоя, кто узнает об ошибке. Такие решения принимает человек, который понимает обе системы и отвечает за последствия: ошибка здесь стоит реальных денег — двойное списание, продажа товара, которого нет на складе.
Практическое правило: если без интеграции продукт не работает с первого дня, начинайте с разработчика. Если можно подождать — запускайтесь с ручным процессом (заявки в кабинете, выгрузка в CSV) и планируйте интеграцию отдельным этапом.
Высокие нагрузки и нестандартная бизнес-логика
Выгруженный код — каркас на Next.js + Prisma + PostgreSQL. В README честно перечислены ограничения: поля моделей в схеме хранятся как строки, типы и связи уточняет разработчик; схема разворачивается без миграций; защита стартовая, и для продакшена нужны HTTPS, доверенный обратный прокси и чистка просроченных сессий. Для типового проекта это нормальная отправная точка. Для сервиса с большим числом одновременных пользователей и тяжёлыми запросами — нет: там нужны проектирование базы, кэширование, нагрузочное тестирование и мониторинг.
Нестандартная логика узнаётся по признакам:
- цена или условия считаются по многим правилам с исключениями;
- есть многоступенчатые согласования с разными ролями и сроками;
- система совершает действия, которые нельзя просто отменить: списывает деньги, резервирует, формирует юридически значимые документы.
ИИ соберёт интерфейс и серверные функции, но проверять корректность такой логики должен человек, который понимает процесс и пишет тесты.
Отрасли с особыми требованиями к данным и сертификации
Медицина, финансы, работа с государственными информационными системами, обработка специальных категорий персональных данных, например сведений о здоровье, — здесь требования касаются не только функций, но и инфраструктуры, документов и процедур. Могут понадобиться особые условия хранения, аттестация или сертификация, регламенты доступа.
Сборка продукта эти требования не закрывает. Нужны юрист и специалист по защите информации, а ИИ-сборка может пригодиться как прототип интерфейса для обсуждения с ними.
Гибридный путь: каркас от ИИ, сложное — руками разработчика
Во многих проектах большая часть типовая, а особенная — небольшая. Тогда работает такая схема:
- ИИ-команда собирает типовую часть: страницы, формы, каталог, кабинеты, панель.
- Вы проверяете сценарии в превью и публикуете проект по ссылке, чтобы показать сотрудникам и первым клиентам.
- Код выгружается на Next.js + Prisma (на платных тарифах) и размещается в вашем репозитории.
- Разработчик проводит ревью, уточняет схему базы, добавляет интеграции и сложную логику.
Две оговорки, чтобы не ошибиться с бюджетом. Первая: интерфейс переносится в код как HTML-разметка, а не набор React-компонентов по экранам; если разработчику нужна компонентная структура, раскладку он делает сам. Вторая: доработки руками живут в вашем репозитории, поэтому заранее решите, где продукт развивается дальше. Перед запуском в работу пройдите чек-лист код-ревью сгенерированного кода, а смету на доработку сверьте с тем, из чего складывается стоимость разработки.
Пять вопросов, чтобы понять, какой путь ваш
- Можно ли описать продукт словами без отсылок к внутренним системам? Если да — ИИ-сборка подходит.
- Нужна ли с первого дня автоматическая связь с учётной системой, телефонией или платёжным сервисом? Если да — закладывайте разработчика в план и бюджет.
- Нужно ли приложение в магазине приложений, а не веб-продукт? Если да — это мобильная разработка.
- Пострадают ли деньги, документы или обязательства перед регулятором, если логика ошибётся? Если да — нужен человек, который отвечает за проверку.
- Известно ли заранее о большой нагрузке? Если да — архитектуру планируйте со специалистом.
Если на первый вопрос ответ «да», а на остальные четыре — «нет» или «не с первого дня», начните с ИИ-сборки и привлекайте разработчика точечно, когда появится конкретная задача.
Скорость запуска и владение кодом хорошо сочетаются с работой живых специалистов — подробнее об этом в материале о будущем веб-разработки. Следующий шаг простой: выпишите функции будущего продукта и отметьте, какие из них типовые, а какие требуют интеграций или особой логики. Типовую часть можно собрать и проверить на бесплатном тарифе, остальное — обсудить с разработчиком, когда каркас уже готов.
