Наконец-то Фаза 3 «Создать». Вооружившись спецификацией, определённой во второй главе, и технологиями и инструментами, выбранными в третьей, вы приступаете к сборке того, что реально работает. Многие, кто спотыкается на этом этапе, на самом деле терпят неудачу вовсе не потому, что «не умеют писать код». Они сдаются, потому что пытаются сразу довести всё до готового результата. В этой главе мы покажем, как с ИИ в роли напарника быстро крутить цикл «создавать по чуть-чуть и запускать», — и для начального, и для практического маршрутов.
Цель — не «сразу всё готово», а «маленькими шагами вперёд»
Базовый подход к реализации — работать маленькими шагами
Самое важное в реализации — всего один принцип. Быстро повторять «создавать по чуть-чуть, запускать и дорабатывать». Не пытайтесь одним махом воплотить готовую картину из головы: сначала соберите самый маленький «работающий кусочек», а затем понемногу его растите.
Почему это работает. Потому что в программе только запустив её, вы понимаете, что именно не так. Если написать 100 строк и запустить всё сразу, вы не поймёте, где причина, и окажетесь в тупике. Если написать 10 строк и запустить, ошибка может быть только в этих 10 строках. С кодом, который пишет ИИ, всё точно так же: просить понемногу и сразу проверять — в итоге куда быстрее и надёжнее.
«Сделай сразу все функции» — и всё сваливается на ИИ. Выдаётся гора кода, но при запуске сплошные ошибки. Непонятно, где причина, и пропадает всякое желание чинить.
«Пока только экран со списком» — просите по одной функции. Заработало — переходите к следующей, и так по кирпичику. Можно двигаться вперёд, всё время сохраняя «рабочее состояние».
⚠️ ИИ тоже ошибается в коде — поэтому обязательно запускайте сами. Код, написанный ИИ, может выглядеть правдоподобно, но при запуске нередко выдаёт ошибку или работает не так, как задумано. «ИИ написал, значит верно» — недопустимо. Выданный код обязательно запускайте своими руками и проверяйте глазами. Это первое железное правило, которое стоит усвоить в инди-разработке. Если идти дальше, не запустив, ошибки накапливаются, и всё становится неуправляемым.
Порядок цикла «создать → запустить → доработать»
Этот принцип «маленьких шагов» превращён в конкретные 4 шага на схеме ниже. Одну функцию вы гоняете по этому циклу снова и снова. Один круг — от нескольких минут до нескольких десятков минут. Чем быстрее крутите, тем быстрее растёте.
«Теперь только эту одну функцию» — конкретно просите ИИ. Чем уже область, тем выше точность.
Как только выдано — сразу запуск. Проверяйте результат своими глазами в браузере или терминале.
Если есть ошибка или что-то не так — правьте в диалоге: «поправь здесь вот так». Повторяйте, пока не заработает.
Заработало — сохраните как контрольную точку (коммит). Зафиксируйте хорошее состояние и переходите к следующей функции.
💡 Не относитесь к ШАГУ 4 «сохранению» легкомысленно. Если сохранять (делать коммит в Git) каждый раз, когда заработала очередная функция, то, сломав что-то следующим изменением, вы сможете вернуться к последнему рабочему состоянию. Это спасательный трос от трагедии «вчера же работало». Как именно сохранять, подробно разберём в следующей, пятой главе.
Стили реализации для начального и практического маршрутов
«Работать маленькими шагами» — общий подход, но конкретный способ крутить цикл зависит от маршрута. Сверьтесь с тем, как двигаться, исходя из маршрута, который вы выбрали в первой главе. Разумеется, по ходу можно смешивать маршруты или переходить с одного на другой.
С помощью вайб-кодинга вы собираете приложение, общаясь с ИИ. «Сделай экран со списком» → «Кнопку сделай синей» → «Чтобы при нажатии сохранялось» — просите на обычном языке, смотрите на экран и снова просите. Само это повторение и есть «цикл маленьких шагов».
Совет: просите только по одному за раз. Если не вышло — достаточно сказать «отмени предыдущее изменение».
Передав, например, Claude Code спецификацию целиком, вы доверяете ему цельную реализацию. Ключевой момент — настраивать объём работы (effort) под масштаб задачи и безопасно автоматизировать, применяя режимы разрешений, чтобы он не переписывал файлы сверх нужного.
Совет: доверяйте по-крупному, но проверяйте по-мелкому. Застряли — ищите решение в сборнике ошибок.
На обоих маршрутах нельзя забывать про базовый подход: «запусти то, что выдано, и проверь сам». Собираете вы в диалоге или отдаёте на автоматику — проверять всё равно работа человека. Не пропускать этот один лишний шаг — вот развилка между тем, дойдёте ли вы до готового результата.
Если встраиваете ИИ-функции
Если то, что вы делаете, — это «приложение, использующее ИИ» (например, оно резюмирует текст, отвечает на вопросы, распознаёт изображения), то нужен механизм, который вызывает ИИ из самого приложения. Здесь становится чуть более технично, но варианты можно свести к трём. Достаточно выбрать только те, что нужны вашему приложению.
Если нужно всего лишь использовать из приложения одну ИИ-модель, основа — вызвать ИИ-API. Считайте это окошком: «отправляешь текст — приходит ответ ИИ».
Если хотите применять разные ИИ в зависимости от ситуации, унифицируйте единый способ записи через Vercel AI SDK. Для централизованного управления в эксплуатации удобен LLM-шлюз (gateway).
Если хотите, чтобы ответы строились на внутренних документах или ваших материалах, — RAG. Механизм, где ИИ передают «материалы лично для вас» и на их основе получают ответ, — так можно добавить уникальности.
🧭 Сомневаетесь — хватит и ①. Для первого MVP чаще всего достаточно просто вызвать один ИИ-API. ② и ③ можно добавить уже когда возникнет потребность «сравнить несколько моделей» или «отвечать по своим данным». И здесь верный ответ — «создавать по чуть-чуть».
Как действовать, когда застряли
В ходе реализации вы обязательно где-нибудь застрянете. Появляется ошибка, работает не так, как думалось, — это не провал, а доказательство того, что вы что-то создаёте. Важно, застряв, не паниковать и разбирать по порядку. Теперь, когда есть ИИ, из затыков выбираешься куда быстрее, чем раньше.
Скопируйте красный текст целиком и спросите: «Вышла такая ошибка. В чём причина и как исправить?» Текст ошибки — главная подсказка. Не переписывайте по-своему, сначала вставьте его.
Вспомните, «до какого места всё работало». В большинстве случаев причина — то единственное место, что вы изменили последним. Сузьте область — и причина обязательно найдётся.
Если всё запуталось, вернитесь к сохранённому последнему рабочему состоянию и начните заново. Нередко откатиться назад быстрее, чем упорно докапываться.
🔧 Тем, кто на практическом маршруте. Частые ошибки и их решения в Claude Code и т. п. собраны в сборнике ошибок. Мучиться над одной и той же ошибкой — пустая трата времени. Возьмите за привычку: застряли — сначала ищите, а если всё равно не выходит — спросите ИИ.
Итоги главы
Суть Фазы 3 «Создать» — не в технике, а в подходе «быстро крутить цикл: создать по чуть-чуть, запустить, доработать». Не пытайтесь дойти до готового одним махом — растите работающий кусочек понемногу.
- Базовый подход — быстро крутить «создать по чуть-чуть и запустить → доработать». Не гнаться за готовым сразу.
- ИИ тоже ошибается в коде. Выданное обязательно запускайте и проверяйте сами.
- 🌱 в начальном — вайб-кодинг с диалогом, 🔧 в практическом — отдать спецификацию и безопасно автоматизировать через объём работы и режимы разрешений.
- Встраиваете ИИ — начните с API. Несколько моделей — Vercel AI SDK / LLM-шлюз, свои данные — RAG.
- Застряли — отдайте текст ошибки → разбейте на части → вернитесь к рабочему состоянию. Пользуйтесь и сборником ошибок.
Когда рабочая вещь готова, дальше время безопасно выпустить её в мир. Можно вернуться к предыдущей главе 3 «Выбираем технологии и инструменты» и пересмотреть подготовку, но если реализация закрутилась — переходите к главе 5 «Тестируем и выпускаем в мир», где закрепим тестирование и безопасность и опубликуем.