Ваш конспект

Эффективная разработка с ИИ: от промтов к системному подходу

Ключевые тезисы:

• Современный разработчик должен управлять ИИ, а не бесконечно переписывать промты.
• Главная проблема — неправильный контекст, из-за которого ИИ «сжигает» токены и пишет не то.
• Решение — системная работа со спецификациями, документацией и короткими итерациями.
• Цель — перейти от точечного использования ИИ к AI-Driven разработке, где агенты выполняют рутинные задачи.

Проблема современного подхода

Большинство разработчиков используют ИИ неэффективно:

• Открывают агента (Cursor, Claude и т.д.) и пишут промт в диалоговое окно.
• Если результат плохой — докидывают контекст (файлы, логи, скриншоты).
• Итог: процесс остаётся ручным, разработчик всё контролирует «в прямом эфире». Это тот же ручной кодинг, только с «дорогими подсказками».

Почему «просто больше контекста» не работает:

• Модель видит слишком много лишнего, путается, начинает «выдумывать».
• Каждый запрос становится дороже (весь контекст уходит в запрос).
• Агент дольше «думает».
• Повышается шанс, что ИИ уйдёт «не туда» и начнёт делать лишнее.
• Сложнее контролировать качество результата.

Правильный подход: управление контекстом

Формула AI-Driven разработки:

1. Фиксируем задачу (что нужно сделать).
2. Создаём спецификацию для решения.
3. Собираем нужные документы (не все!).
4. Работаем короткими итерациями (маленькие части).
5. Проверяем результаты (финальное решение за человеком).
6. Фиксируем изменения и технический долг.

Результат: ИИ перестаёт быть случайным генератором кода и начинает предсказуемо выполнять задачи. Это дешевле и позволяет использовать более простые (и дешёвые) модели.

Спецификация — основа всего

Спецификация — это не руководство для людей, а промт для ИИ, часть контекста и набор правил исполнения.

Что должно быть в спецификации:

• Стек и версии (Python 3.13, FastAPI 0.104.1, а не просто «Python и FastAPI»).
• Архитектура (MVC, FSD, Clean Architecture) + конкретная структура папок и файлов.
• Ограничения (что нельзя трогать, какие библиотеки запрещены).
• Критерии готовности (как проверять результат, какие тесты запускать).
• План работы с техническим долгом (что с ним делать, если возникает).

Пример: Если не указать, что в проекте есть UI-kit, ИИ напишет компоненты с нуля. Если не указать версии — может использовать устаревшие методы.

Документы проекта: минимум шума, максимум пользы

Документы нужно разделять, чтобы агент работал только с нужной частью системы.

Для маленького проекта:

1. README.md — описание проекта, архитектура, подходы, структура папок, стек.
2. AGENT.md / план — задачи с ID, описанием, статусом (что сделано, что осталось). Используется для работы в цикле.

Для среднего/большого проекта (с фронтом, беком, БД):

• stack.md — языки, версии, фреймворки, библиотеки, запрещённые зависимости.
• architecture.md — архитектурный подход, слои, структура папок, правила создания файлов, взаимодействие модулей.
• edgecases.md — нестандартные сценарии, ошибки, пустые состояния, валидация, сетевые сбои (чтобы ИИ не тестировал только happy path).
• db_schema.md — схема БД: таблицы, поля, типы, связи, индексы, правила чтения/записи.
• links.md — ссылки на официальную документацию, гайдлайны команды.
• ui_kit.md (если есть) — где лежит, какие компоненты использовать, какие запрещено писать с нуля.
• current_sprint.md — задачи текущей итерации, приоритеты, статусы.

Правило: Один спринт = один агент (с субагентами) = один контекст. В контекст попадают только нужные для текущих задач документы.

Работа с существующим (legacy) проектом

Если проект не готов для работы с ИИ, нужны три «скилла» (навыка/функции):

1. Context Dump / Context Builder — изучает проект и создаёт нужные файлы (архитектура, зависимости и т.д.). Дорогой шаг один раз, чтобы не платить много каждый раз.
2. Change Request — задача/функция, которая возвращает промт: «что нужно изменить?».
3. Legacy Warning — специфический контекст, в котором ИИ находит всё устаревшее, проблемное (техдолг). Нужно, чтобы ИИ знал о костылях и либо использовал их, либо предлагал улучшения.

Практическое задание (для самостоятельной пробы)

1. Возьмите любой репозиторий (например, RAG-проект с GitHub).
2. Сделайте форк, создайте отдельную ветку.
3. Удалите старый README.md (он может быть устаревшим).
4. Сделайте Context Dump проекта.
5. Проанализируйте результат, создайте улучшения.
6. Зафиксируйте технический долг в Legacy Warnings.

Выводы и главные ошибки

Хороший подход:

• Разделять проектные документы.
• Давать чёткую спецификацию.
• Давать только нужный контекст.
• Работать короткими итерациями.
• Фиксировать изменения и техдолг.

Плохой подход: Загружать в ИИ весь проект и надеяться, что он сам разберётся.

Основные ошибки и их причины:

• ИИ сжигает токены и пишет не то → Нет спецификации.
• ИИ перечитывает весь проект → Нет разделённой документации или она плохо описана.
• Путается в архитектуре, вводит новые паттерны → Существующая архитектура нигде не описана.
• Использует не те библиотеки → Не описано, где смотреть на зависимости.
• Не понимает задачу → Задача неправильно описана, нет change_request.
• Теряет историю проекта → Спринт неправильно оформлен или его нет, работа ведётся в слишком большом контексте.
• Тяжело работать с legacy-кодом → Не объяснено, что это legacy; не использован context_dump.

Навык работы с LLM ≠ навык AI-разработки

Сегодня нужно уметь больше, чем писать промты:

• Полный цикл от задачи до деплоя.
• Понимание архитектуры и метрик качества кода (который вы, возможно, уже не пишете).
• Умение решать, где ИИ поможет, а где навредит (не всё можно автоматизировать).
• Объяснение архитектурных решений (не только приложения, но и системы работы с ИИ, скиллами, контекстом).

Два пути развития

1. Самостоятельно: Искать информацию в интернете, пробовать, ошибаться на своих проектах. Медленно, есть риск что-то упустить.
2. С ментором/в команде: Перейти от разрозненного использования к системной разработке, где больше задач делегируется агентам. Научиться экономить токены, быстрее выполнять задачи, упаковывать опыт для рынка.