Помните старую поговорку про семь раз отмерь? В мире 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.

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


  1. astenix
    29.08.2025 10:11

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


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

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


      1. astenix
        29.08.2025 10:11

        В целом то, что заранее «и об этом подумай, и об этом не забудь», и плавно брюки превращаются в «товарищ, у нас тут для вас/LLM задан контекст проекта, причем глобально… это уже не условная ерундятина, just think».

        Я про такое раньше думал, но это казалось очевидно-невероятным, потому что ну вроде да, все это нужно сделать ДО, но если этого не просят… А тут понятно, что таки надо, таки контекст для llm.

        Из удобностей в плане "док о проекте" я придумал себе только вписывать в readme.md содержимое отдельного файла plan.md, и если план выполнен, то файл с ним можно переименовать/переместить, и для readme.md он «исчезает», и моя «документация по проекту» генерируется в html не запинаясь. Или где-то в тот же readme положить диаграмму если не модулей, то хотя бы этапов выполнения шагов в main.py, чтобы постоянно видеть, к чему надо придти в итоге и где я сейчас.

        Я пришел из мира скриптов на bash, они в принципе монолитно-индивидуальные, «сделай все в одном файле», а сейчас привыкаю разносить шаги в тематические модули единого проекта, и окрепло ощущение необходимости поясняющей информации и в отдельных модулях, и более глобально, потому что постоянно переключаюсь между двумя уровнями восприятия проекта. Наверное, стоит и про vision подумать заранее.


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

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

          Да, пробуйте создавать мини тех проекты на подобии vision. Лучше потратить лишние 15 минут на объяснение LLM общей идеи, но зато сэкономить часы на этапах генерации кода далее )) Кстати опять же, как и с человеком )) Только у "человеков" есть возможность, а у многих и привычка, думать над дизайном в процессе работы над кодом - поэтому нам это сходит с рук местами.


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

          Схему с plan не до конца понял, что значит "вписывать содержимое файла plan.md" (это какая-то директива для системы автогенерации документации)?


          1. astenix
            29.08.2025 10:11

            Да.

            В файле readme.md есть строка
            <!-- INSERT_PLAN_MD -->

            Сборка документации по проекту через pdoc проходит так:

            • создаю файл /tmp/README.md,

            • в который вставляю содержимое оригинального readme.md,

            • а внутри него вместо строки <!-- INSERT_PLAN_MD --> вставляю содержимое файла plan.md.

              ввва

            Если файл plan.md отсутствует (удален или переименован), то вместо <!-- INSERT_PLAN_MD --> будет пустота, и сборку документации это не остановит.

            Дальше выполняю сборку документации через "pdoc", который бегает по всем файлам и собирает описание модулей из докстрингов, и в браузере открывается html, на главной странице Readme и внутри него раздел «План работы» — он же список задач, он же отчет о том, какие из задач уже сделаны (расставляю смайлики в начале строки).

            Когда всё доделаю, переименую файл plan.md в 1plan.md и раздел «План работы» в readme уже не будет отображаться.


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

              Понято. Спасибо )


  1. NightKiro
    29.08.2025 10:11

    Ну текст то можно было и ручками набрать

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


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

      Не использовать сейчас ИИ для работы с контентом, конечно, по крайней мере странно. Особенно для статьи про применение ИИ )
      Смею вас уверить, что эту статью я писал руками, отдельные идеи обсуждал и структурировал с ИИ.


  1. EvgeniyRasyuk
    29.08.2025 10:11

    +1 от меня вам в карму


  1. fixikus
    29.08.2025 10:11

    Для хеллоувордов сойдет, не более


    1. SerBuryat
      29.08.2025 10:11

      Не соглашусь с Вами.

      Действую по принципу описанному в статье.

      Работаю на основном проекте и фриланс проекте.

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

      ИМХО подход НЕ только для "холоу ворлдов"


      1. fixikus
        29.08.2025 10:11

        А я работаю с решениями в несколько десятков(бавало даже сотен) проектов на разных языках(в основном С/C++, C#) и фреймворках, несколько таких решений написал и спроектировал сам, и есть у меня такое ощущение, что я буду дольше такую доку писать, чем сам проект, это без учета проверки и отладки того, что нагенерировалось, еще есть ощущение, что то, что нагенериться для онбординга будет полным мусором. Если вы думаете, что написать код ручками сложно - нет, не сложно, сложно его поддерживать, оптимизировать, расширять и делать понятным. У вас просто таких потребностей нет, так как пишете отдельные, небольшие, одноразовые проекты.


        1. SerBuryat
          29.08.2025 10:11

          Мериться и спорить крупностью проектов не буду.
          Но, говорить, что у меня проекты "маленькие и глупенькие", не стоит.
          Я, как написал автор, "слона по кусочкам режу".
          Иногда, проще самому написать код, а иногда лучше написать "доку", разбить ее на части, оперируя бизнес логикой, а дальше...ничем не отличается от ревью МРа джуна.
          Так что, не знаю.
          Все эти "поддерживать, оптимизировать и расширять" я понимаю и также придерживаюсь, НО, при этом, ничего не мешает писать код за счет AI, того же cursor.
          Так что, скажу еще раз: "ИМХО, не только для `холоу ворлдов`" и чуть расширю мысль - такой подход закрывает часть задач, "СВОЕГО уровня" и такие задачи могут быть на ЛЮБОГО уровня и габарита проектов.


          1. fixikus
            29.08.2025 10:11

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

            а иногда лучше написать "доку", разбить ее на части, оперируя бизнес логикой, а дальше...ничем не отличается от ревью МРа джуна.

            Сомнительно, но окей. Тут две проблемы для большого проекта: либо описывай кучу функционала в больших задачах, либо кучу задач с маленьких функционалом. И там и там куча функционала, а значит и документации. И опять же, как это все потом будет вместе работать - не понятно. Весь проект у вас в мозги ИИ не влезет, отсюда еще одна проблема, кто вам эту портянку из документации валидировать будет, все ли там согласовано или нет. А с учетом галюнов, то на сколько эта валидация будет корректна. То, что автор указал в качестве архитектуры проекта - типичный хэлоуворд и только для такой архитектуры применим описанный в статье принцип разработки ПО, о чем и был первый мой комментарий.


            1. maxim_ge
              29.08.2025 10:11

              Весь проект у вас в мозги ИИ не влезет, отсюда еще одна проблема

              Это верно, конечно.

              Но ведь если следовать low coupling, и всяким буквочкам типа S, I и D - зачем "всему" влезать в мозги?


              1. fixikus
                29.08.2025 10:11

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


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

                  Конечно, нужно грамотно разделывать уметь.
                  Этого никто не отменяет. Пока ИИ за нас такие вещи решать не умеет. Все же ИИ это ассистент.
                  В одном из докладов разработчиков Антропик - они сказали, что уже дошли до этапа, когда они не проводят ревью кода, сгенеренного ИИ, но это пока только "листовые" куски кода - тот функционал, который не будет меняться в обозримом будущем.
                  Остальные вещи они у себя в Антропик, кстати решают, очень похожими методами, как описано в статье. Да, мы и сами всеми этими методами пользовались до появления ИИ.
                  А потом просто многие либо забыли, либо стало лень готовить и разжевывать для ИИ задачу. Не говоря, уже о том, что сильно упал порог входа, и многие без понимания основ и базовых практик SE начали вайбкодить. А по факту, грамотно используй, так как нужно тебе или твоей команде, отталкиваясь от ее уровня.


                  1. fixikus
                    29.08.2025 10:11

                    Такая бюрократия не всегда хорошо, так как много времени отнимает, то есть нужно нанимать промп-инженеров, которые по цене как разработчики, но только промт-инженеры. Опытному разработчику задача понятна по 2-3 предложениям из таска, на крайний случай 1 созвон на 5-10 мин. Будет ли такая задача понятна промт-инженеру для генерации нужного промта, сомневаюсь. В общем, тут много скользких моментов, а профита маловато, если вообще есть.


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

              Мы применяем ИИ как на новых проектах, так и на масштабных легаси проектах с многолетней историей.

              Конечно описанный подход, и сам ИИ, не серебряная пуля. В каждом проекте свои особенности, свои нюансы.

              Но суть ведь подхода в том, что ИИ это не магия, и относиться к нему нужно, не как к магу, а как к человеку. У ИИ ограничен контекст и у человека ограничен, ИИ не выдаст сразу "конфетку", но и новый в проекте человек тоже не выдаст и т.д. и т.п.
              Ну и этапы решения задачи в целом схожи, надо вначале разобрать задачу, подумать, спроектировать решение, построить план решения, учесть существующие соглашения, написать код и т.д. Каждый из этапов ИИ помогает сильно ускорить. Понятно, что для каждого профи точки ускорения будут отличаться.

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


              1. fixikus
                29.08.2025 10:11

                LLM - это костыль, костыль может быть инструментом, но остается костылем.

                У ИИ ограничен контекст и у человека ограничен, ИИ не выдаст сразу "конфетку", но и новый в проекте человек тоже не выдаст и т.д. и т.п.

                Тут интересно. Новый человек может загрузить себе в мозг основной контекст и держать его, это сложно, но можно. То же самое можно сделать и с нейросетью. Не с LLM, а отдельной локальной специализированной неросетью, под конкретный проект, тогда ей уже можно давать задачи как обычному разработчику, без развернутой документации. Утверждать ничего не буду, еще не пробовал, все руки не доходят.

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


                1. rettsu
                  29.08.2025 10:11

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

                  Я сам, конечно, совсем не разработчик (аналитик данных), но с помощью той же нейросети за 4 вечера успешно сделал покерный калькулятор на C# (при том что ранее ни разу ничего не кодил на C#). Калькулятор с точным расчетом Equity и EV. С тепловой картой стартовых рук (которая меняет диапазоны, в зависимости от позиции игрока, есть ли ставка оппонента и соотношении ставки оппонента к банку). С рекомендациями по игре на разных улицах (учитывая количество оппонентов, размер банка и так далее). Считается это все за секунду при 100 тысячах симуляций по Монте-карло (через адаптированный алгоритм оценки руки от Кевина Саффекула). И немного GTO-логики при оценке действий под капотом (которую ещё нужно докручивать). Смог бы ли я сделать тоже самое без нейросети? Нет. А сколько времени бы занял такой небольшой проект у среднего программиста? Наверное неделю, может две. При этом, как уже отметили ранее, для нейросети КРАЙНЕ важен контекст и количество деталей. Мой первый запрос был подробно расписан на нескольких листах А4. И в дальнейшем никаких проблем с написанием кода не возникало.


                  1. fixikus
                    29.08.2025 10:11

                    Я рад за Ваши успехи, но контекст проектов, с которыми я работал и работаю, это сотни( тысячи) листов А4, которые изменяются и дописываются в отличие от правил покера, т.к. появляются новые хотелки, обновляются инструменты, изменяется законодательство, политическая и экономическая ситуация в мире и т.д. И еще один интересный вопрос : каким кухонным комбайном лучше обработать печень рыбы фугу и кто, если что, понесет ответственность? А также насколько критична скорость обработки?


            1. Desprit
              29.08.2025 10:11

              Весь проект и в ваши мозги не влезет. А если влезет, то едва ли вы видели большие проекты. В любом случае, слишком много «у меня ощущение», зачем вообще спорить если вы даже не побывали по обе стороны и, соответственно, не понимаете, о чем говорите?


              1. fixikus
                29.08.2025 10:11

                Да что Вы говорите, если у Вас не получается, это не значит, что у других нет. Чего я не понимаю, объясните, а не делайте голословных заявлений


  1. SerBuryat
    29.08.2025 10:11

    За статью спасибо. Очень близко, т.к. действую в той же "парадигме".

    В некоторых "узких местах", добавляю псевдокод или оперирую техническими компонентами. Хз как объяснить, зачем именно так, чем это лучше простого написанич кода, кроме как: "я тян - пруфов не будет"


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

      Спасибо! Интересно было увидеть, что еще кто-то на практике успешно использует ИИ в своих проектах похожим образом! Лучшие практики рождаются от здравого смысла )
      А псеводокод вполне себе хорошая тема, во-первых нет синтаксического шума, во-вторых это просто удобнее для передачи логики работы.