Помните старую поговорку про семь раз отмерь? В мире AI-кодинга она обрела новый смысл.
Сегодня расскажу о практике AI-Driven разработки (AIDD), которую мы у себя в команде ежедневно применяем для разработки ИИ-решений. Она успешно зарекомендовала себя в различных проектах и задачах — будь то стартапы или легаси, приложения на Python, Java или даже 1C.
Демонстрировать практику будем в AI редакторе Cursor, но повторить методику вы сможете в любой подобной IDE.
Поехали.
AI Driven Development (AIDD)
Наш подход основан на простом понимании: AI — это не замена программиста, а его усилитель.
Вся AI-разработка держится на трёх китах:
Большие языковые модели (LLM) — для генерации решений. Мы будем использовать claude-sonnet-4
Контекст — правильно структурированная информация, которая превращает идеи в понятные инструкции
Соглашения — чёткие договорённости с 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 предлагает четыре режима применения правил:
Manual — ручное добавление правила в контекст
Specific files — правило активируется при работе с определёнными файлами или директориями
Intelligent — AI сам решает, когда применять правило на основе контекста
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.
astenix
Мне понравилось
smirnoff_ai Автор
Спасибо! А что-то конкретное понравилось или в целом подход?