Как создать приложение
с помощью ИИ

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

Мы пишем руками всё меньше кода. Зато каждую строку, которая уходит в продакшн, кто-то из команды прочитал и понял.

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

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

Процесс почти не отличается от классической разработки. Меняется скорость отдельных шагов и то, кто пишет код.

1. 1Описываем продукт словами. До первой строки кода — страница текста: кто пользователь, какую одну задачу он решает, что видит на каждом экране. Если это не получается написать, ИИ тоже не поймёт, что строить.
2. 2Собираем прототип за день. Показываем клиенту живой интерфейс вместо ТЗ на 30 страниц. Правки на прототипе стоят минуты, правки в готовом продукте — дни. Подробнее о том, зачем это нужно, — в статье про прототипы сайтов.
3. 3Записываем правила проекта для ИИ. Стек, структура папок, стиль кода, что нельзя трогать — в отдельный файл (CLAUDE.md для Claude Code, rules для Cursor). Модель читает его в каждой сессии и перестаёт изобретать свой стиль.
4. 4Режем работу на маленькие задачи. Одна функция — одна задача — один коммит. Запрос «сделай мне CRM» даёт большой и красивый хаос, который никто не может проверить. Запрос «добавь фильтр по статусу в таблицу заявок» даёт код, который читается за пять минут.
5. 5Проверяем каждую правку. Сборка, типы, ручной прогон в браузере на телефоне и десктопе, чтение диффа. ИИ уверенно пишет код, который компилируется, но делает не совсем то, что нужно.
6. 6Перед запуском — чеклист. SEO, скорость, безопасность, аналитика. Мы прогоняем SEO-чеклист на 110+ пунктов для каждого проекта, независимо от того, кто писал код — человек или модель.

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

1. →Давайте контекст, а не команду. Не «сделай форму», а «форма заявки на странице услуги: имя и Telegram, отправка в наш /api/contact, стиль как у ContactModal».
2. →Говорите, что переиспользовать. Без подсказки модель охотно напишет новый компонент рядом с уже существующим. Назовите файл, который нужно взять за основу.
3. →Сначала план, потом код. Для задачи больше чем на пару файлов попросите план изменений. Ошибку в плане исправить проще, чем в двадцати отредактированных файлах.
4. →Задайте критерий готовности. «Готово, когда сборка проходит, а на экране 375 px нет горизонтального скролла». Без этого модель решит, что готово, как только код написан.
5. →Одна задача — одна сессия. Длинный диалог копит устаревший контекст, и модель начинает путаться в том, что уже сделано. Закончили задачу — начните заново.

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

Код от нейросети редко падает с понятной ошибкой. Опаснее то, что работает, но работает не так, как нужно.

1. 1Красиво, но невидимо для поиска. Наш собственный пример. Карточки услуг на главной странице были кнопками, которые открывали шторку. Для человека всё работало, для поискового робота это были не ссылки. В итоге Google Search Console знал о 4 страницах сайта из 12 и проиндексировал одну. ИИ не предупредил — его об этом не спрашивали.
2. 2Секреты в коде. API-ключи прямо в клиентском коде, который скачивает любой посетитель. Ключи должны жить в переменных окружения на сервере.
3. 3Несуществующие функции. Модель уверенно использует метод библиотеки, которого нет или который убрали две версии назад. Сборка и документация — единственная защита.
4. 4Дубли вместо переиспользования. Три почти одинаковых компонента в разных папках. Проект распухает, а правка в одном месте не доезжает до остальных.
5. 5Мобильная версия по остаточному принципу. Модель проверяет результат на том, что видит, а видит она обычно код, а не экран телефона. Проверять на реальном устройстве — ваша работа.

Делайте сами, если это прототип, лендинг для проверки идеи или внутренний инструмент на несколько человек. Зовите специалиста, если в проекте есть хотя бы одно из этого: приём платежей, персональные данные, интеграции с CRM или 1С, ожидаемая нагрузка, или продукт — это и есть ваш бизнес.

Хороший промежуточный вариант — делать самому, но с наставником, который ревьюит код и подсказывает, где модель свернула не туда. Так команда учится работать с ИИ на своём же проекте.

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