Умный вайб-кодинг или семь раз отмерь, один раз сгенерь

Помните старую поговорку про семь раз отмерь? В мире AI-кодинга она обрела новый смысл.

Сегодня расскажу о практике AI-Driven разработки (AIDD), которую мы у себя в команде ежедневно применяем для разработки ИИ-решений. Она успешно зарекомендовала себя в различных проектах и задачах — будь то стартапы или легаси, приложения на Python, Java или даже 1C.

Демонстрировать практику будем в AI редакторе Cursor, но повторить методику вы сможете в любой подобной IDE.

Поехали.

AI Driven Development (AIDD)

Наш подход основан на простом понимании: AI — это не замена программиста, а его усилитель.
Вся AI-разработка держится на трёх китах:

1. Большие языковые модели (LLM) — для генерации решений. Мы будем использовать claude-sonnet-4

2. Контекст — правильно структурированная информация, которая превращает идеи в понятные инструкции

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

Давайте смотреть, как это работает на практике в Cursor. Будем идти по-шагово от идеи до деплоя так, чтобы вы могли потом воспроизвести это на своем проекте.

Шаг 1. Фиксация идеи — idea.md

Каждый проект начинается с идеи. В нашем случае — с желания создать умного ассистента c LLM под капотом.

Вместо того чтобы открывать блокнот и формулировать техническое задание, мы сразу фиксируем мысль в проекте.

# Промпт 1. Фиксация идеи — @idea.md Зафиксируй мою идею по разработке LLM-ассистента в файле. LLM-ассистент должен быть выполнен в виде Telegram-бота. Основной задачей бота является вести диалог с пользователем и отвечать на его вопросы.

Cursor интерпретирует наши слова, структурирует их и создаёт первый файл проекта с продуманным описанием. Хаотичная мысль превращается в чёткую формулировку: интеллектуальный бот для ведения естественного диалога с пользователями.

Шаг 2. Проектирование — генерация видения проекта vision.md

У нас есть идея, но этого недостаточно. Любой опытный разработчик знает: между идеей и работающим продуктом лежит множество технических решений. Какую архитектуру выбрать? Как организовать код? Где хранить данные?

Обычно на этом этапе начинаются часы размышлений, рисования диаграмм и споров в команде. Точно также и языковая модель не сможет угодить нам, если мы пойдем просто по пути «вбросить идею — получить результат». Результат, конечно, будет и будет даже работать, но вероятность, что модель попадет в наши ожидания и хотелки ничтожна мала. А нам в продакшене нужны решения, которые будут не только работать, но и главное работать так, как нам нужно и устроены так, как нам нужно. Ведь нам их потом сопровождать и развивать. Думаю согласитесь.

Поэтому открываем новую вкладку в Cursor (Ctrl + T) и приглашаем AI к совместному планированию. Не просим написать код, а сначала продумываем архитектуру решения.

# Промпт 2. Генерация видения — @vision.md Давай создадим файл vision.md В нем мы отразим техническое видение проекта @idea.md: — технологии — принцип разработки — структуру проекта — архитектуру проекта — модель данных — работа с LLM — мониторинг LLM — сценарии работы — деплой — подход к конфигурированию — подход к логгированию Данный документ будет служить нашей отправной точкой и техническим проектом для последующей разработки. Давай создавать последовательно. Проанализируй состав документа. Иди последовательно по разделам. Задавай мне вопросы, предлагай итоговое видение, после согласования со мной фиксируй в документе. После переходи к следующему разделу. Самое главное: Нам нужно создать максимально простое решение для проверки своей идеи, по принципам KISS. Никакого оверинжиниринга. Только самое необходимое и простое во всех разделах!

Далее вместе с AI раздел за разделом проектируем наше будущее решение.

По ходу проектирования, мы уточняем детали, местами корректируем или направляем AI, советуемся, спрашиваем о предлагаемых технологиях, если они для нас новые.

Хорошей практикой будет тут же фиксировать выбранные архитектурные решения в Architecture decision records (ADR)

В итоге у нас формируется полноценный проект, оформленный в виде документа vision.md, который рассматривает проект с разных углов: бизнес-логика, технологический стек, архитектурные паттерны. По сути полноценная «разжеванная» постановка задачи для последующей кодо-генерации.

Разобраны технологии и принципы разработки — критически важно сразу договориться об этом перед началом кодинга. Языковые модели склонны к проектированию больших универсальных «космолетов», которые сразу включают в себя все, что можно на все случаи жизни. Но, если мы за простоту и удобство сопровождения и отладки, то это будет лишь избыточным шумом, в котором потом сама модель будет блуждать, как в потемках. Поэтому фиксируем принципы: KISS, YAGNI, MVP, Fail Fast, итеративная разработка.

Визуализируем архитектуру

Фиксируем модель данных

Договариваемся как будем работать с LLM. В нашем случаем выбираем подход работы через провайдера https://openrouter.com/, но используя универсальный интерфейс OpenAI client

Сразу решаем, как мы будем мониторить работу нашего приложения.

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

Решаем как будем собирать и развертывать готовое решение.

Договариваемся о конфигурациях и настройках.

Фиксируем формат ведения логов, что, как и где журналируем.

Теперь мы вместе с AI знаем не только что делать, но и как это делать правильно.

Движемся дальше.

Шаг 3. Соглашения по разработке — conventions.md

Представьте, что вы нанимаете нового разработчика в команду. Вы объясняете ему процессы, стандарты кодирования, этапы работы. Точно так же мы поступаем с нашей AI-моделью.

Заключаем соглашения по разработке:

• Как писать код

• Как структурировать проект

• Что можно делать, а что категорически запрещено

# ПРОМПТ 3. Генерация соглашения по разработке — @conventions.md Создай файл conventions.md c правилами для разработки кода для передачи их code ассистенту, который будет генерировать код Правила должны отражать все главные наши принципы разработки из документа @vision.md и ссылаться на сам документ @vision.md, не дублируя информацию из него. Правила должны быть лаконичными, по принципу KISS, не содержать лишнего, только главное влияющее на качество

Важно фиксировать не только желаемое поведение, но и то, что делать категорически нельзя.

Шаг 4. План работы — tasklist.md

Далее создаём детальный план работы — пошаговый таксклист от простого эхо-бота до полнофункционального умного помощника.

ПРОМПТ 4. План работы — @tasklist.md Создай пошаговый итерационный план разработки: doc/tasklist.md Каждый шаг должен позволять протестировать работу бота. Каждая итерация добавляет новый функционал. Сверху отведи место для отчета по прогрессу, который будет обновляться после каждой итерации. Отчет красивый в таблице, со статусами, иконками. Каждая задача должна быть отмечена чекбоксом для наглядного отслеживания прогресса План тоже должен быть лаконичным, содержать только главное и следовать принципу KISS

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

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

Шаг 5. Соглашение по процессу работы — workflow.md

Но план — это ещё не всё. Нужно установить правила игры. Как будет проходить взаимодействие? Когда AI должен спрашивать разрешения? Когда может действовать самостоятельно?

Заключаем еще один «контракт» с AI — создаем описание процесса совместной работы:

• Сначала планируем, потом делаем

• Каждая итерация завершается тестированием

• Обязательное подтверждение перед переходом к следующему этапу

# ПРОМПТ 5. Соглашение по процессу работы — @workflow.md Создай файл doc/workflow.md с правилами выполнения работ по тасклисту @tasklist.md, чтобы проинструктировать кодового ассистента о разработке нашего бота по @vision.md Важно: — выполнять работу строго по плану — перед каждой итерацией вначале согласовывать предполагаемое решение с отрезками кода — после согласования реализовывать — после чего ожидать подтверждения — обновлять прогресс в тасклисте — отмечать выполненные задачи — согласовывать переход к следующей итерации — делать коммит в репозиторий Workflow должен быть лаконичным, содержать только главное и следовать принципу KISS

Процесс работы — это еще один критически важный элемент устойчивой работы, тем более совместной, тем более совместной с AI.

Процесс работы инструктирует модель «есть слона по‑кусочкам», двигаться последовательно, вначале думать, потом обсуждать с нами и после этого приступать к генерации кода. Давать нам возможность проверить, протестировать работу, а только после этого делать коммиты, отмечать прогресс и переходить к следующим задачам.

Шаг 6. Cursor Rules: настройка

Созданные нами соглашения и план работы мы будем использовать при каждом взаимодействии с языковой моделью. Мы можем добавлять их в контекст модели вручную, но в каждой AI IDE есть для этого более удобные механизмы.

В Cursor они называются Cursor Rules. Да, правила работы, которым языковая модель должна следовать

Здесь мы сталкиваемся с интересной особенностью Cursor — системой правил.

А именно файлы с расширением .mdc — это правила Cursor.

Существует вид правил User Rules — общие правила среды для любого проекта — инструкции, которые всегда добавляются в контекст работы языковой модели.

Но нас в первую очередь интересуют Project Rules, разместим в них наши правила из conventions.md и workflow.md. Для этого создадим директорию .cursor/rules и скопируем туда файлы, изменив им расширение на .mdc

Для каждого правила надо выбрать режим применения. Cursor предлагает четыре режима применения правил:

1. Manual — ручное добавление правила в контекст

2. Specific files — правило активируется при работе с определёнными файлами или директориями

3. Intelligent — AI сам решает, когда применять правило на основе контекста

4. Always — правило всегда активно в контексте

Мы выбираем режим «Always» — пусть AI всегда помнит о наших соглашениях.

Шаг 7. Генерация кода: итерация 1

Переходим к практической части. Все приготовления завершены, «контракты с AI подписаны», план утверждён. Время писать код.

# ПРОМПТ 6. Начинаем разработку по плану # одновременно с промптом в контекст добавляются соглашения из правил conventions.mdc и workflow.mdc Начинаем работу над проектом @vision.md строго по тасклисту @tasklist.md

Cursor анализирует план задач, определяет приоритеты и начинает работу. Следуя инструкциям, вначале предлагает нам свое видение реализации первой итерации. Останавливается и ждет согласования.

Дальше процесс напоминает работу опытного разработчика: сначала общая структура, потом детали, затем финальные доработки.

Отчитывается о завершении работы над итерацией, предлагая удобную инструкцию для конфигурации и ручной проверки бота. Если кто-то впервые сталкивается с получением токенов к внешним сервисам (в нашем случае telegram и openrouter), то самый простой способ — в новой вкладке попросить языковую модель написать пошаговый гайд. Это будет еще и хорошей практикой документирования нашего проекта.

# ПРОМПТ 7. Создание инструкций Создай пошаговую инструкцию, как получить TELEGRAM_BOT_TOKEN Сохрани в файле в папке /doc/guides

Токены получили, в конфиг файл сохранили. Теперь можем прямо в чате языковую модель попросить запустить бота. Это иногда очень удобно, так как модель будет контролировать процесс запуска и работы, а при возникновении ошибок/исключений их сразу обработает и внесет правки в код.

Консоль показывает процесс запуска. Cursor проверяет файлы окружения, запускает бота, и он начинает работать.

Наш бот стартует с базовой функциональности — способности отвечать эхом на сообщения пользователей (интерфейс слишком понятный всем, чтобы демонстрировать его скринами).

Первая итерация завершена. Cursor делает коммит, отмечает прогресс в плане и готовится к следующему этапу.

Шаг 8. Генерация кода: эволюция проекта

Следующие итерации проходят по тому же принципу. Наш бот развивается пошагово:

Итерация 2: Интеграция с языковой моделью — бот получает интеллект
Итерация 3: Добавление памяти — бот начинает помнить контекст диалога
Итерация 4: Обработка ошибок — бот становится надёжным
Итерация 5: Логирование и мониторинг — бот становится прозрачным
Итерация 6: Контейнеризация — бот готов к продакшену

Каждая итерация добавляет новый уровень функциональности. Cursor AI справляется с каждой задачей методично и профессионально.

После шестой итерации Cursor сообщает о завершении работы. Смотрим на структуру проекта — простая идея превратилась в сложную, продуманную систему.

Мы создали полноценное production-ready решение:

• Docker-контейнеризация для удобного деплоя

• Автоматизация через Makefile

• Мониторинг и детальное логирование

• Гибкая конфигурация через переменные окружения

• Документация для быстрого старта

Шаг 9. Onboarding документация

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

AI поможет нам разобраться в проекте.

# ПРОМПТ 9. Создание технической документации Создай техническое описание разработанного проекта для быстрого ознакомления с проектом новому разработчику Используй не только текст, но и примеры кода, ссылки на файлы, диаграммы и другую визуализацию Сохрани описание в файл doc/intro.md

Появляется техническая документация enterprise-уровня:

• Архитектурная диаграмма системы

• Описание потока данных

• Инструкции по развёртыванию

• Планы дальнейшего развития

Шаг 10. Тестирование в реальных условиях

Время проверить, готово ли наше решение к встрече с реальным миром.

После запуска в development-режиме командой make dev через терминал проведем запуск в Docker, в условиях, максимально приближенных к продакшену.

make build make run

Образ собирается, контейнер запускается. В логах видим все признаки успешной работы— наш бот запускается в Docker-окружении.

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

От идеи до работающего продукта — всё это уместилось в 3 часа рабочего времени!

Результат

Мы создали функциональный интеллектуальный бот, используя AI-Driven подход. Процесс показал эффективность грамотного умного подхода к AI-кодингу. Его уже нельзя назвать просто «вайбкодингом».

Ключевые принципы методики

LLM как партнёр: Мы не заставляли AI писать код просто так — мы сотрудничали. Обсуждали архитектуру, планировали этапы, договаривались о стандартах.

Контекст как основа: Правильно структурированная информация превратила идеи в понятные инструкции. Cursor понимал не только задачи, но и их место в общей концепции проекта.

Соглашения как фундамент: Чёткие правила позволили AI действовать самостоятельно в рамках наших ожиданий.

Заключение

Все что мы делали, это внедряли обычные хорошие практики из старого доброго мира Software Engineering в работу с AI. Отрадно то, что сейчас многие разработчики IDE идут по этому пути и внедряют это прямо в UI/UX своих решений. В IDE Kiro от Amazon встроен процесс Spec-driven разработки, в новый IDE Qoder от Alibaba помимо Spec-driven встроен функционал Repo Wiki автогенерации полноценной вики документации проекта.

Грамотный AI-driven подход превращает разработчика в архитектора решений, который управляет процессом на высоком уровне, делегируя рутинную работу искусственному интеллекту.

На нашем интенсиве AI-coding ИИ-агентов мы обучаем как правильно использовать методику и разрабатывать функциональных автономных ИИ-агентов для персонального использования и трансформации бизнес-процессов.

Больше полезного, свежего и практического контента мы публикуем в Telegram-канале AI.Dialogs.

По вопросам консалтинга, корпоративного обучения или внедрения ИИ-решений в ваш бизнес обращайтесь напрямую в Telegram smirnoff_ai.

Источник: habr.com