Помните старую поговорку про семь раз отмерь? В мире 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 интерпретирует наши слова, структурирует их и создаёт первый файл проекта с продуманным описанием. Хаотичная мысль превращается в чёткую формулировку: интеллектуальный бот для ведения естественного диалога с пользователями.

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

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

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

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

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

# Промпт 2. Генерация видения - @vision.md

Давай создадим файл vision.md
В нем мы отразим техническое видение проекта @idea.md:
- технологии
- принцип разработки
- структуру проекта
- архитектуру проекта 
- модель данных
- работа с LLM
- мониторинг LLM
- сценарии работы
- деплой
- подход к конфигурированию
- подход к логгированию

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

Давай создавать последовательно.
Проанализируй состав документа.
Иди последовательно по разделам.
Задавай мне вопросы, предлагай итоговое видение, после согласования со мной фиксируй в документе.
После переходи к следующему разделу.

Самое главное:
Нам нужно создать максимально простое решение для проверки своей идеи, по принципам KISS.
Никакого оверинжиниринга.
Только самое необходимое и простое во всех разделах!

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

Генерация разделов vision.md
Генерация разделов vision.md

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

Генерация разделов vision.md
Генерация разделов vision.md

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

Генерация ADR
Генерация ADR

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

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

01 - vision.md
01 - vision.md

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

02 - vision.md
02 - vision.md

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

03 - vision.md
03 - vision.md

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

04 - vision.md
04 - vision.md

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

05 - vision.md
05 - vision.md

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

06 - vision.md
06 - vision.md

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

07 - vision.md
07 - vision.md

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

08 - vision.md
08 - vision.md

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

09 - vision.md
09 - vision.md

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

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

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

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

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

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

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

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

# ПРОМПТ 3. Генерация соглашения по разработке - @conventions.md

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

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

 conventions.md
conventions.md

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

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

ПРОМПТ 4. План работы - @tasklist.md

Создай пошаговый итерационный план разработки: doc/tasklist.md

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

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

Каждая задача должна быть отмечена чекбоксом для наглядного отслеживания прогресса
План тоже должен быть лаконичным, содержать только главное и следовать принципу KISS

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

Создание плана работы - tasklist.md
Создание плана работы - tasklist.md

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

tasklist.md
tasklist.md

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

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

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

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

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

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

# ПРОМПТ 5. Соглашение по процессу работы - @workflow.md

Создай файл doc/workflow.md с правилами выполнения работ по тасклисту @tasklist.md,
чтобы проинструктировать кодового ассистента о разработке нашего бота по @vision.md

Важно:
- выполнять работу строго по плану
- перед каждой итерацией вначале согласовывать предполагаемое решение с отрезками кода
- после согласования реализовывать
- после чего ожидать подтверждения
- обновлять прогресс в тасклисте
- отмечать выполненные задачи
- согласовывать переход к следующей итерации
- делать коммит в репозиторий

Workflow должен быть лаконичным, содержать только главное и следовать принципу KISS

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

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

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

workflow.md
workflow.md

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

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

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

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

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

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

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

Cursor Rules: настройка
Cursor Rules: настройка

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

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

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

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

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

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

Cursor Rules: apply patterns
Cursor Rules: apply patterns

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

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

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

Начинаем работу над проектом @vision.md строго по тасклисту @tasklist.md

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

Генерация кода: итерация 1 - планирование
Генерация кода: итерация 1 - планирование

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

Генерация кода: итерация 1 - кодирование
Генерация кода: итерация 1 - кодирование

Отчитывается о завершении работы над итерацией, предлагая удобную инструкцию для конфигурации и ручной проверки бота. Если кто-то впервые сталкивается с получением токенов к внешним сервисам (в нашем случае 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
Генерация onboarding документации
Генерация onboarding документации
Диаграмма последовательности
Диаграмма последовательности

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

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

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

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

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

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

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

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

make build
make run
Запуск в docker
Запуск в docker

Образ собирается, контейнер запускается. В логах видим все признаки успешной работы— наш бот запускается в 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.

Комментарии (2)


  1. astenix
    29.08.2025 10:11

    Мне понравилось


    1. smirnoff_ai Автор
      29.08.2025 10:11

      Спасибо! А что-то конкретное понравилось или в целом подход?