Создание приложения с ИИ: от идеи к проверяемому MVP

Черновик - да. Проверяемый MVP с данными, auth и внешними пользователями - с ревью инженерии, часто с разработчиком на прод-контуре. Вопрос из поиска «можно ли создать приложение с ИИ без разработчика» звучит как про кнопку «сгенерировать». На разборе в Telegram чаще приходит другая формулировка: «собрали демо, красиво, люди не возвращаются».

На одном разборе для оптового склада сгенерировали «приложение учёта» за выходные: формы, графики, даже тёмная тема. Через две недели кладовщики снова звонили менеджеру - потому что в демо не было их реальной job (отметить приход паллеты и увидеть остаток по SKU), а в проде не закрыли auth и не разделили тестовые данные.

Addyo в эссе про «70% problem» описывает типичный путь не-инженера: быстро собирается большая часть прототипа, последние тридцать процентов - безопасность, edge cases и деплой. Это не то же самое, что «последние двадцать процентов» из блога AI Mechanic про demo→prod - не смешивайте цифры из разных источников.

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

Разработка приложения с ИИ на практике - это не одна кнопка, а карта зон. Я делю работу на «ускоряет черновик» и «остаётся на человеке», и не отдаю вторую зону модели без diff и ревью.

RCT METR (ранний 2025, Cursor + Claude на зрелых OSS-репозиториях) показал +19% времени на задачах при том, что разработчики ожидали ускорение. Это не приговор ИИ и не аргумент «всегда быстрее» - контекст зрелого кода, не greenfield MVP. На прототипе выигрыш чаще в старте; на проде начинается инженерия.

Veracode в отчёте по GenAI-коду: около 45% образцов не прошли security-тесты, secure rate около 55% и слабо растёт с размером модели. OWASP LLM02 (Insecure Output Handling) и LLM09 (Overreliance) - про недоверенный вывод и слепое доверие. Я прогоняю SAST и смотрю diff после Agent, даже если «всего один вечер».

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

MVP приложение в моей рамке - эксперимент для обучения, не урезанный продукт со всеми фичами «кроме пары». Steve Blank в Build-Measure-Learn описывает цикл: гипотеза, минимальный тест, измерение, решение масштабировать или менять курс.

Ранняя цель - одна job для одной группы пользователей и доказать retention, а не собрать backlog из пятнадцати пунктов до первого живого теста. Customer Development - не focus group «какие фичи хотите»; это проверка гипотезы основателя минимальным набором.

Шаблон сценария, который я прошу заполнить до кода:

• Пользователь: одна роль (например, «кладовщик одной площадки»), не «все менеджеры».
• Job: одно действие с измеримой болью.
• MVP-артефакт: web-форма, бот, таблица + форма - что угодно, лишь бы тестировать job.
• Критерий: поведение (повторное использование, конверсия, время до действия), не «понравилось в опросе».
• Данные: что можно в облачный LLM, что только on-prem или enterprise tool.
• Gate: ревью auth, секретов и ввода до внешних пользователей.

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

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

Как создать приложение с помощью ИИ и не утонуть в вариантах - выбрать один сценарий по четырём фильтрам: частота job, цена ошибки, измеримый сбой, один канал доставки MVP.

Частота. Job, которую делают раз в квартал, плохо тестирует retention за две недели. Берите действие, которое болит еженедельно или ежедневно.

Цена ошибки. Если ошибка - испорченная партия или утечка PII, MVP нельзя отдавать «как сгенерировалось». Сначала mock и внутренний контур.

Измеримый сбой. «Менеджер тратит 40 минут на сводку» лучше, чем «неудобно». Критерий успеха привязывается к времени или к повторным входам.

Один канал. Web, Telegram-бот или внутренняя форма - не все сразу. Иначе не поймёте, что именно не работает.

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

GitHub Copilot: Business и Enterprise не используют ваш код для обучения моделей. На Free и Pro с 24 апреля 2026 interaction data может идти в обучение, если не включить opt-out в Privacy settings. Microsoft 365 Copilot: промпты и данные Graph не используются для обучения foundation LLM - формулировка из документации Microsoft, не «вообще ничего не обучают».

Gate до внешних пользователей: ревью auth, секретов в репозитории, санитизация ввода. Без gate демо превращается в инцидент.

Карточка сценария (плейсхолдеры, без секретов):

{
  "role": "кладовщик одной площадки",
  "job": "отметить приход паллеты и увидеть остаток по SKU",
  "mvp_artifact": "web-форма + таблица остатков",
  "success_metric": "≥3 повторных входов за 2 недели без напоминаний",
  "data_in_llm": "только обезличенные SKU-коды",
  "data_never_in_llm": "поставщики, цены, персональные данные",
  "gate_before_users": "ревью auth и секретов в репо"
}

Карта MVP - это не диаграмма ради диаграммы, а цепочка артефактов с владельцем на каждом шаге.

Пять-семь тест-кейсов на один сценарий - рабочий минимум: happy path, два исключения (пустой ввод, дубликат), мобильная ширина, logout/login, граничное значение поля.

Пример для job «отметить приход паллеты»:

1. 01

   Успешный приход: SKU есть, остаток увеличился.

2. 02

   Неизвестный SKU: понятная ошибка, без падения.

3. 03

   Повторная отправка той же паллеты: idempotent или предупреждение.

4. 04

   Пустое поле количества: блок на клиенте и сервере.

5. 05

   Экран 390px: кнопка не обрезана, таблица скроллится.

Шаблон MVP-брифа, который я прошу прислать одним сообщением в Telegram:

БРИФ MVP (одно сообщение)

1. Роль пользователя: [одна, не «все менеджеры»]
2. Job в одной фразе: [действие с измеримой болью]
3. MVP-артефакт: [web / бот / таблица + форма]
4. Критерий до запуска: [повторное использование / конверсия / время до действия]
5. Данные: что в ИИ, что никогда в облачный LLM
6. Черновик: [URL / репо / «с нуля в Cursor»]
7. Gate: auth, секреты, ввод - кто ревьюит до внешних пользователей

После брифа - один вечер на прототип, следующая неделя на измерение. Если критерий не выполнен, не расширяйте scope - меняйте гипотезу или job.

Создание мобильного приложения с помощью ИИ в поиске звучит как «сразу в App Store». Для проверки гипотезы mvp мобильного приложения чаще избыточен: web-MVP или PWA быстрее итерируется, один URL, нет цикла модерации магазина.

Разработка мобильных приложений с ИИ ускоряет UI-кит и навигацию, но не снимает подпись, релиз-каналы и crash-аналитику. Я не обещаю «собрать App Store за вечер» - обещаю честно сказать, когда job ещё не проверена на web.

Пример с разбора: сервис записи к мастеру. Заказчик хотел React Native. Job - «клиент выбирает слот и получает подтверждение». PWA с формой и Telegram-уведомлением закрыла гипотезу за десять дней. Native понадобился только когда добавили push и офлайн-календарь - после того, как retention на web подтвердился.

Запрос «создания приложения с помощью ии бесплатно» - сигнал про бюджет, не про метод. Бесплатный tier и no-code дают черновик и generic workflow; проверяемый MVP с вашей логикой, данными и критерием успеха - отдельная работа.

Under30CEO в матрице hire vs no-code (editorial, без статистики) разводит: no-code - невалидированная идея или типовой процесс; разработка - кастомная логика, traction, защищаемость. Я использую это как здравый смысл, не как исследование с цифрами.

Demo и production - разные слои. AI Mechanic перечисляет то, что часто отсутствует в демо: auth, CORS, сессии, env, CI/CD, мониторинг. Это не повод ругать no-code - это повод не называть демо «готовым продуктом».

Когда no-code нормален: внутренний чеклист, временная форма, тест оффера на знакомых. Когда нужен код и review: PII, платежи, нестандартные интеграции, git и staging. Страница разработка проектов - про второй контур, когда прототип упёрся в production layer.

Анти-обещания, которые я не даю: «бесплатно», «без кода навсегда», «за один день в прод с пользователями».

Как создать приложение с ии в Cursor на одном сценарии - список того, что Agent реально тянет на черновике, с пометкой «всё через diff и ревью»:

• UI-компоненты и layout одного flow.
• API-скелет с mock или SQLite.
• Черновик миграций и seed-данные без PII.
• Заготовки unit и smoke на критический path.
• README с командами запуска.

Режим Plan, затем Agent одним коммитом - мой рабочий порядок. Сначала план файлов и зависимостей, потом правки пакетом, потом git diff и smoke руками.

Промпт для MVP одного web-flow:

Задача: MVP web-приложения для [роль]: одна job - [job].

Стек: [Next.js / Vite+React] - только deps из package.json, новые согласовать.
Один пользовательский flow: [шаги 3-5].
Данные: mock или SQLite; секреты только в .env, не в клиенте.
Auth: минимальный [magic link / basic] - серверная валидация.
Тесты: 2-3 smoke на критический path.
Не галлюцинировать npm-пакеты. После правок - список файлов.
Режим: Plan, затем Agent одним коммитом.

После Agent я проверяю: нет ли секретов в клиентском бандле, проходит ли smoke, совпадает ли flow с карточкой сценария. Галлюцинированный пакет - рабочий риск, не экзотика.

Разработка приложений с помощью ии на этапе прототипа экономит часы на «пустом репозитории». Разработка приложений mvp в прод - это тот же репозиторий плюс gate, staging и мониторинг.

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

Сигналы, что прототипа мало и нужен инженерный контур:

• PII, медицинские или финансовые данные без compliance-рамки.
• Платежи, подписки, чеки - не mock.
• Интеграции с CRM, ERP, 1С, складом - не «потом».
• Нестандартная логика (тарифы, роли, мультитенант).
• Нужен git, staging, откат релиза - не только preview в билдере.
• Security gate не закрыт после внутреннего теста.

Primary путь - разработка проектов: описать job, критерий, черновик, что уже пробовали.

Чеклист «что прислать» перед созвоном:

1. 01

   Роль пользователя (одна).

2. 02

   Job в одной фразе.

3. 03

   Критерий успеха MVP (поведение, не «понравилось»).

4. 04

   Ссылка на черновик или репо.

5. 05

   Класс данных (что нельзя в облачный LLM).

6. 06

   Интеграции, без которых job не работает.

7. 07

   Что уже ломалось в прошлых попытках.

По теме в блоге: как создать сайт с помощью ИИ, разработка проектов.