Введение:

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

Однако между локальными экспериментами с ChatGPT для написания одной функции и реальной промышленной разработкой целого проекта с помощью ИИ лежит огромная пропасть. В этой статье мы исследуем эволюцию подходов к AI-разработке - от такого подхода как Vibe Coding к системной методологии AI Software Engineering (AI SWE), которая позволяет превратить AI-агентов в управляемый инструмент для создания больших и сложных систем.

Меня зовут Дмитрий, а моего наставника и соавтора этой статьи - Денис @deksden. Под его руководством я осваивал новую парадигму разработке и сегодня мы хотим поделиться видением, наработками, идеями. В этой концептуальной статье мы представляем общую картину AI SWE методологии и намечаем направления для детального изучения каждого компонента в будущих статьях.

Часть 1: От Vibe Coding к AI SWE - эволюция подходов к AI-разработке

1.1 Эйфория Vibe Coding

Большинство из нас начинало свой путь в разработке кода с ИИ одинаково. Мы использовали чаты с ChatGPT, Claude, или Gemini как продвинутый Stack Overflow: задавали вопросы, просили написать функцию, объяснить фрагмент кода или помочь с отладкой. Это было удобно, но оставалось в рамках локальных задач.

Настоящий прорыв произошел с появлением кодовых агентов, интегрированных в среду разработки (IDE), таких как Cursor и Windsurf, а также терминальных агентов, например, Aider и Claude Code. Возможность работать с кодом напрямую, без постоянного копирования и переключения между окнами, дала колоссальный прирост эффективности и породила такой подход, как Vibe Coding.

При Vibe Coding разработчик действует «по наитию», давая агенту общие инструкции. Это такой ультра-аджайл на ИИ-топливе, где итерационные циклы сжимаются до минут, для максимально быстрого воплощения идей в работающий продукт. Типичный сценарий выглядит так:

1. Основная задача: «Сделай мне приложение для управления задачами».

2. Доработка: «Теперь добавь темную тему».

3. Исправление ошибок: «Вот лог, исправь это».

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

• Дублировать функционал, уже существующий в другой части проекта.

• Нарушать архитектурные принципы, о которых "не было сказано".

• Ломать существующую бизнес-логику, внося изменения в неочевидные, но связанные модули.

• Создавать сотни бесполезных юнит-тестов, которые не следуют принятым паттернам и никогда не будут переиспользованы.

Корень этих проблем не только в LLM и его ограниченном контексте. Проблема в отсутсвии системы как таковой.

1.2. AI SWE как решение: Системный подход к разработке

В противовес интуитивному Vibe Coding рождается AI Software Engineering (AI SWE) - применение системных инженерных практик к процессу разработки с использованием кодовых агентов.

Лучший способ понять этот новый подход - через аналогию онбординга нового сотрудника. Представьте, что в вашу команду пришел невероятно продуктивный разработчик, способный работать 24/7. Vibe Coding - это когда вы просто говорите ему: "Вот проект, начинай работать". Результатом будет хаос.

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

• Бизнес-контекст: Что это за проект? Какие бизнес-цели он решает и для кого предназначен?

• Техническое окружение: Как его развернуть локально? Как запускать тесты, линтеры и сборку?

• Архитектура: Какие архитектурные паттерны используются? Как модули связаны между собой? Где лежат "общие" компоненты?

• Командные практики: Какие у нас стандарты кодирования? Как мы именуем ветки? Как оформляем коммиты?

• База знаний: Где искать информацию о конкретных модулях или принятых решениях?

Этот процесс формализации знаний и правил и есть первый и самый важный шаг в AI SWE.

Новая роль: от исполнителя к проектировщику AI-системы

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

Это фундаментальный сдвиг в мышлении. В парадигме AI SWE ваши ключевые задачи теперь:

• Декомпозировать большие бизнес-задачи на четкие, атомарные технические подзадачи.

• Формализовать неписаные правила, практики и знания команды в понятные для ИИ инструкции.

• Проектировать процессы и рабочие потоки (workflows), по которым будет действовать AI-агент.

В этой новой модели вы и кодовый агент становитесь единой командой, настоящей компанией в миниатюре, где:

• Вы - CEO, продакт-менеджер, тимлид и главный архитектор. Вы определяете видение, ставите задачи, принимаете стратегические решения и контролируете качество.

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

Иерархия в этой команде плоская, но вы всегда остаетесь на вершине, задавая направление и неся ответственность за конечный результат.

Чтобы эта система работала слаженно, нам нужен фундамент. И этим фундаментом станет специально разработанная методология - Memory Bank.

Часть 2: Memory Bank - «мозг» проекта для AI-агента

Чтобы превратить AI-агента из слепого исполнителя в полноценного члена команды, ему нужна память. Не временная, ограниченная одним сеансом, а постоянная, структурированная и развивающаяся вместе с проектом.

2.1. Что такое Memory Bank?

Memory Bank - это концепция, представленная в виде официальной инструкции для Cline, предназначенная для оптимизации обмена контекстом с ИИ. Это не специальный плагин или инструмент, а методология структурированного управления документами.

Memory Bank - это не просто папка с документацией. Это живая, структурированная база знаний о проекте, она выполняет две ключевые функции:

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

2. Операционная система для агента: Содержит четкие инструкции и рабочие процессы (workflows), которые направляют действия агента.

Memory Bank становится единым источником истины и диспетчером задач для вашего AI-разработчика.

2.2. Архитектура и структура Memory Bank

Физически Memory Bank представляет собой директорию в корне вашего проекта, обычно с именем .memory_bank/.

Пример файловой структуры:

.memory_bank/
├── README.md              # Главная навигационная карта и точка входа
├── product_brief.md       # Описание продукта: ЗАЧЕМ мы это делаем
├── tech_stack.md          # Технологический паспорт проекта
├── current_tasks.md       # Живая Kanban-доска с текущими задачами
│
├── patterns/              # Архитектурные паттерны и решения
│   ├── api_standards.md
│   └── error_handling.md
│
├── guides/                # Практические руководства по подсистемам
│   ├── coding_standards.md
│   └── testing_strategy.md
│
├── specs/                 # Технические задания на новые фичи
│   └── feature_xyz.md
│
└── workflows/             # Пошаговые инструкции для типовых задач
    ├── bug_fix.md
    └── new_feature.md

Карта зависимостей:

Эта структура не случайна. Она отражает иерархию знаний, которую можно представить в виде графа, где README.md является корневым узлом.

Краткое назначение ключевых файлов:

• README.md: Самый важный файл, точка входа. Его задача - не описывать все, а служить маршрутизатором. Он содержит краткую философию проекта и ссылки на все остальные ключевые документы. Агент начинает любую сессию с чтения этого файла.
  

  Пример README.md:

  # Memory Bank: Единый источник истины проекта
  
  Этот банк памяти — твой главный источник информации. Перед началом любой задачи **обязательно** ознакомься с этим файлом и перейди по релевантным ссылкам.
  
  ## Обязательная последовательность чтения перед ЛЮБОЙ задачей
  
  1.  **[Технический стек](./tech_stack.md)**: Узнай, какие технологии, библиотеки и версии мы используем.
  2.  **[Стандарты кодирования](./guides/coding_standards.md)**: Ознакомься с правилами форматирования, именования и лучшими практиками.
  3.  **[Текущие задачи](./current_tasks.md)**: Проверь список активных задач, чтобы понять текущий фокус команды.
  
  ## Карта системы знаний
  
  ### 1. О проекте (Контекст "ЗАЧЕМ")
  - **[Описание продукта](./product_brief.md)**: Бизнес-цели, целевая аудитория, ключевые функции. Обращайся сюда, чтобы понять *ЧТО* мы строим и *ДЛЯ КОГО*.
  
  ### 2. Техническая основа (Контекст "КАК")
  - **[Технический стек](./tech_stack.md)**: Полный список фреймворков, библиотек и их версий. **ЗАПРЕЩЕНО** добавлять новые зависимости без обновления этого файла.
  - **[Архитектурные паттерны](./patterns/)**: Фундаментальные решения. Изучи их перед внесением изменений в структуру модулей.
  - **[Гайды по подсистемам](./guides/)**: Детальное описание ключевых модулей (например, аутентификация, платежная система).
  
  ### 3. Процессы и задачи (Контекст "ЧТО ДЕЛАТЬ")
  - **[Рабочие процессы (Workflows)](./workflows/)**: Пошаговые инструкции для стандартных задач. Выбери нужный workflow для твоей текущей задачи.
    - **[Разработка новой фичи](./workflows/new_feature.md)**
    - **[Исправление бага](./workflows/bug_fix.md)**
  - **[Спецификации (ТЗ)](./specs/)**: Детальные технические задания на новые фичи.
  
  ---
  **Правило:** Если ты вносишь изменения, которые затрагивают архитектуру или добавляют новую зависимость, ты должен обновить соответствующий документ в Memory Bank.
  
  

• tech_stack.md: «Технический паспорт» проекта. Определяет разрешенные технологии, библиотеки, версии и, что важно, запрещенные практики (например, «не использовать any в TypeScript»).

  Пример tech_stack.md:

  # Технологический стек и конвенции
  
  ## Core Stack
  - **Frontend**: React 18 (использовать **ТОЛЬКО** функциональные компоненты с хуками).
  - **State Management**: Redux Toolkit + RTK Query для всех асинхронных запросов.
  - **Styling**: CSS Modules. **ЗАПРЕЩЕНО** использовать inline-стили или глобальные CSS-селекторы.
  
  ## Запрещенные практики
  - ❌ Использование `any` в TypeScript. Все типы должны быть явно определены.
  - ❌ Использование классовых компонентов в React.
  - ❌ Прямые DOM-манипуляции. Всегда использовать React-way.
  
  ## API Конвенции
  - Все API-запросы должны проходить через единый клиент `src/api/apiClient.ts`.
  - Обработка ошибок должна соответствовать схеме, описанной в **[./patterns/error_handling.md](./patterns/error_handling.md)**.
  
  

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

  Пример workflows/bug_fix.md:

  # Процесс исправления бага
  
  ## 1. Подготовка и анализ
  - [ ] Создать ветку от `develop` по шаблону `bugfix/TICKET-NUMBER-short-description`.
  - [ ] Сгенерировать гипотезы о причинах бага
  - [ ] Локализовать проблему в кодовой базе. Найти все релевантные файлы.
  - [ ] Проанализировать связанные документы в `guides/` и `patterns/` для понимания контекста затронутой системы.
  
  ## 2. Разработка
  - [ ] Внести исправления в код, следуя **[стандартам кодирования](../guides/coding_standards.md)**.
  - [ ] Запустить весь набор тестов (`npm test`), чтобы убедиться, что ничего не сломалось.
  
  ## 3. Завершение
  - [ ] Обновить документацию, если исправление затронуло публичное поведение компонента.
  - [ ] Обновить статус задачи в **[../current_tasks.md](../current_tasks.md)**.
  - [ ] Создать Pull Request и краткое описание решения.
  
  

• current_tasks.md: Живая Kanban-доска. Простой, но эффективный инструмент для синхронизации. Агент всегда знает, над чем работать сейчас и что уже сделано.

  # Текущие задачи
  
  ## To Do
  - [ ] [FE-42] Реализовать авторизацию через Google.
  - [ ] [BE-17] Оптимизировать запросы к базе данных в отчете по продажам.
  
  ## In Progress
  - [x] [FE-39] Сделать адаптивную верстку для главной страницы. 
  
  ## Done
  - [x] [BE-15] Внедрить кэширование для API-ответов каталога.
  
  

• product_brief.md: Помогает агенту понять бизнес-контекст: что мы строим, для кого и какие цели преследуем.

• /patterns: Директория с описанием фундаментальных архитектурных решений. Агент обращается сюда, прежде чем вносить изменения в структуру модулей.

• /guides: Руководства по конкретным подсистемам (например, аутентификация) или общим практикам (стандарты кодирования, стратегия тестирования).

2.3 Принцип самодокументирования: Ключ к «живой» системе

Главное отличие Memory Bank от статической документации - принцип самообновления. AI-агент не только читает из этой базы знаний, но и обновляет ее в процессе работы. Это требование зашито в его рабочие процессы (workflows). Например агент отмечает задачу как In Progress / Done в файле current_tasks.md или добавляет документацию на новую фичу в specs/, а при необходимости - создает или обновляет гайд в guides/ с примерами использования или

2.4 Как запускать Memory Bank?

Запуск Memory Bank - это, по сути, начало сессии разработки с AI-агентом. Процесс состоит в том, чтобы заставить AI прочитать ключевую информацию и погрузиться в контекст проекта.

Начало сессии: Например, для Claude Code можно создать специальный файл CLAUDE.md или кастомную команду, которая будет содержать единственную инструкцию: «При любой задаче начинай с чтения файла .memory_bank/README.md».

Таким образом, каждая рабочая сессия начинается с того, что AI «загружает мозг» проекта, изучает карту знаний и только после этого приступает к выполнению конкретной задачи, следуя инструкциям из соответствующего workflow.

Теперь, когда у агента есть память и карта, нам нужно научиться правильно ставить ему задачи - декомпозировать, подробно описывать и не позволять додумывать там, где это недопустимо.

Давайте перейдем к этой, не менее важной, части подготовки.

Часть 3: «Планирование-Исполнение-Ревью»

Трехэтапный рабочий процесс: от планирования до самоконтроля

Наличие Memory Bank решает проблему долгосрочной памяти и операционной системы агента. Но даже самый информированный разработчик может не справиться, если ему поставить расплывчатую задачу. Принцип мусор на входе - мусор на выходе работает с AI-агентами безотказно.

Чтобы предотвратить потенциальный хаос, мы используем строгий трехэтапный рабочий процесс: Планирование, Исполнение и Ревью.

Этап 1: Планирование с Gemini (Роль Архитектора)

На этом этапе наша цель - не написать код, а создать исчерпывающее техническое задание.

Для этого мы используем модель с большим контекстным окном, например, Gemini 2.5 Pro, что позволяет применить «чит-код» для проектирования. Мы можем загрузить в модель весь репозиторий целиком (например, через упакованный в XML файл проект с помощью repomix), дать задачу и заставить ее думать на уровне системного архитектора, который видит всю картину сразу.

Важно понимать: Gemini на этом этапе будет инстинктивно пытаться сразу написать готовый код под вашу задачу. Вы должны пресечь это. Нам от него нужно не решение, а архитектурно проработанный план. Хотя, как показывает практика, иногда можно позволить ему сгенерировать базовые классы или структуры данных - это тоже станет частью ТЗ.

⚠️Вы не получите идеальное ТЗ с первой попытки. Процесс итеративен: вы задаете первоначальный вопрос, получаете ответ, задаете уточняющие вопросы, просите добавить детали, пересмотреть решение. Обычно после 3-5 таких итераций у вас на руках оказывается готовый документ.

Финальный артефакт этого этапа - подробный Markdown-файл, содержащий:

• Четко сформулированную цель и подробное описание задачи.

• Список файлов, которые нужно будет создать или изменить.

• Требования к API, моделям данных и структурам.

• Ссылки на существующие компоненты проекта, которые нужно переиспользовать.

• Требования к тестам и критерии приемки.

Вот как может выглядеть фрагмент такого ТЗ, подготовленного для AI-агента:

# FT-052: Разработка API для управления парком IoT-устройств (Command & Control)

**Эпик:** [EPIC-05: IoT Platform Core](EPIC-05-IoT-Platform-Core.md)

**Аннотация:** Реализовать центральный API-шлюз (Command & Control API), который служит единой точкой для отправки команд на парк IoT-устройств. API должен принимать команды, валидировать их, логировать и публиковать в Kafka для асинхронной доставки.

### Описание задачи
Этот API заменяет старый RPC-сервис, который работал нестабильно. Новый API не доставляет команды сам, а лишь быстро регистрирует их. Специализированные воркеры будут слушать топик Kafka и отвечать за доставку.

### Ключевые компоненты для реализации
1.  **FastAPI Application**: Основа для API. Расположить в `services/command_control/main.py`.
2.  **Pydantic Schemas**: Модели для валидации запросов.
    - **Важно:** Базовые схемы, такие как `BatchCommandRequest`, уже реализованы в `core/src/schemas.py`. **Ты должен импортировать и расширять их**, а не создавать новые.
3.  **Kafka Producer**: Для отправки команд в топик `device-commands`.
    - **Важно:** Взаимодействие с Kafka должно осуществляться через готовый клиент, реализованный в `core/src/kafka/kafka_client.py`. **Импортируй и используй `kafka_producer` из этого модуля.**

### Структура события в Kafka
Каждая команда, отправляемая в Kafka, должна соответствовать этой JSON-схеме:
```json
{
  "command_id": "uuid",
  "device_id": "string",
  "command_type": "UPDATE_FIRMWARE" | "REBOOT",
  "metadata": { "source": "admin_dashboard", "issued_at": "timestamp" }
}
### API Endpoints для реализации

### 1. Отправка команды на одно устройство

- **Endpoint:** `POST /commands/send`
- **Request Body:** `SendCommandRequest(device_id: str, command_type: str, payload: dict)`
- **Действие:** Валидировать запрос, создать запись в `CommandHistoryDB` со статусом `queued`, опубликовать событие в Kafka.
- **Response:** `202 Accepted` `{ "success": true, "command_id": "...", "status": "queued" }`

### 2. Отправка команды на группу устройств

- **Endpoint:** `POST /commands/send/batch`
- **Request Body:** `BatchCommandRequest(device_ids: List[str], command_type: str, payload: dict)`
- **Действие:** Сгенерировать `batch_id`. Для каждого `device_id` из списка выполнить те же действия, что и для одиночного эндпоинта.
- **Response:** `202 Accepted` `{ "success": true, "batch_id": "...", "status": "queued" }`

### Критерии приемки

- [ ]  Вся валидация реализована с помощью Pydantic **с использованием схем из `core/src/schemas.py`**.
- [ ]  Взаимодействие с Kafka реализовано **исключительно через клиент из `core/src/kafka/kafka_client.py`**.
- [ ]  Все эндпоинты реализованы и возвращают корректные статусы и тела ответов.
- [ ]  Написаны unit-тесты, проверяющие успешную отправку команды в Kafka для каждого эндпоинта.

Масштабирование на большие проекты

Спасибо Gemini, за большое контекстное окно, которое позволяет проектировать мелкие и средние проекты быстро и дёшево. Но, «чит-код» с полным контекстом не будет работать вечно, когда проект вырастет больше чем 1 млн.токенов, и не будет вмещаться в контекст Gemini 2.5 Pro, мы естественным образом перейдем к более «навороченным» процессам планирования.

Этап 2: Исполнение с Claude Code (Роль Исполнителя)

Проработанное на первом этапе ТЗ передается AI-исполнителю, такому как Claude Code. Поскольку вся интеллектуальная работа по проектированию уже сделана, задача агента сводится к чистой реализации. Он получает предельно четкие инструкции и, опираясь на Memory Bank для дополнительного контекста, пишет код с гораздо большей точностью и меньшим количеством ошибок.

Этап 3: Ревью через чек-лист (Цикл самоконтроля)

AI-агент не всегда идеален. Чтобы убедиться, что он в точности выполнил задачу, мы создаем эффективный цикл самоконтроля.

1. Возвращаемся к Gemini (планировщику), у которого еще сохранился весь контекст обсуждения и даем команду: «На основе нашего финального ТЗ, создай чек-лист для проверки выполненной работы».

2. Этот сгенерированный чек-лист передается AI-агенту(ClaudeCode) с задачей: «Проверь свою работу по этому списку».

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

Часть 4. Субагенты

Основным материалом для создания по настоящему гибких и в то же время контролируемых рабочих процессов (workflow) является использование субагентов Claude Code.

Субагенты Claude Code - это специализированные помощники, которых можно создавать для выполнения определенных задач. Каждый субагент работает со своим собственным контекстным окном, настраиваемой системным промптом и определенными разрешениями на использование инструментов.

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

P.S. Более подробно эту тему расскроем в будущих статьях.

Часть 5: Лайфхаки и боли

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

5.1. Лайфхаки: Эффективное управление ресурсами

Работа с мощными AI-моделями - это всегда баланс между производительностью и затратами.

Система управления лимитами Anthropic

У Claude необычная модель подписки, и ее понимание — ключ к непрерывной работе.

• 5-часовые сессии с округлением: Сессия использования длится 5 часов. Важный нюанс: время начала сессии округляется до начала часа. Если вы отправили первый запрос в 09:55, система считает, что сессия началась в 09:00, и лимиты обновятся в 14:00, а не в 14:55. Планируйте начало работы в начале часа, чтобы использовать время по максимуму.

• Три корзины токенов: У вас есть отдельные, но связанные лимиты на разные модели: Opus (самая мощная), Sonnet (средняя) и Haiku (самая быстрая). Они связаны пропорционально: активное использование 10% лимита Opus "съест" примерно 10% лимитов на использование Sonnet и Haiku. Учитывайте это при переключении между моделями.

Бесшовное переключение аккаунтов для обхода лимитов

Самый эффективный способ обеспечить непрерывную работу - система из нескольких аккаунтов.

• Подготовка:

  1. Создайте 2-3 аккаунта Anthropic (для этого могут потребоваться разные email и номера телефонов).

  2. Используйте несколько разных браузеров (например, Chrome, Safari, Firefox) или профилей в одном браузере (Chrome Profiles).

  3. В каждом браузере/профиле войдите в отдельный аккаунт Anthropic.

Когда вы упираетесь в лимит на одном аккаунте, переключение на другой занимает 10-15 секунд и абсолютно прозрачно для AI-агента, так как весь контекст проекта хранится локально и в Memory Bank.

Автоматизация через кастомные команды

Claude Code позволяет создавать собственные команды, что является мощным инструментом для интеграции с нашей методологией.

• Создание команды: В директории ~/.config/claude/commands/ создайте Markdown-файл с именем команды.

• Содержание команды: Внутри файла вы пишете промпт, который будет выполнен при вызове команды. Переменная $ARGUMENTS позволяет передавать в команду пользовательский ввод.

Пример 1: Команда для "обновления памяти" агента

Файл ~/.config/claude/commands/refresh_context.md:

Контекст мог быть утерян или сжат. Необходимо освежить память. Выполни следующие шаги:

1.  Перечитай `.memory_bank/README.md` полностью, чтобы понять общую структуру.
2.  Изучи текущие задачи в `.memory_bank/current_tasks.md`, чтобы понять, над чем мы работаем.
3.  Просмотри последние изменения в коде, чтобы быть в курсе актуального состояния.

После этого выведи сообщение "Контекст обновлен" и кратко опиши текущий статус проекта и активную задачу.

Теперь, когда вы чувствуете, что агент "поплыл", достаточно вызвать /refresh_context, чтобы вернуть его в строй.

Пример 2: Команда для запуска workflow по исправлению бага

Файл ~/.config/claude/commands/m_bug.md:

Ты получил команду /m_bug. Это означает, что мы начинаем работу над исправлением бага.

Твоя задача: $ARGUMENTS.

Выполни следующую процедуру:
1.  Внимательно изучи `.memory_bank/workflows/bug_fix.md`.
2.  Следуй описанному там процессу шаг за шагом.
3.  Задавай уточняющие вопросы на каждом этапе, если что-то неясно.
4.  По завершении всей работы не забудь обновить `.memory_bank/current_tasks.md` и другую релевантную документацию, как указано в workflow.

Начинай с первого шага.

5.2. Боли и ограничения

Экономические вызовы

• Токены по API: При активной разработке с постоянным анализом кода расход токенов огромен. Если использовать API, стоимость может легко превысить $400 в неделю.

• Решение: На текущий момент использование пару Pro-подписок за $20 или за $100/200 является на порядки более экономически выгодным решением, чем прямой доступ через API для задач разработки.

Технические ограничения

• Сжатие контекста: Несмотря на заявленные 200k токенов, Claude Code при интенсивной работе все равно теряет или "сжимает" часть контекста. Это его фундаментальное ограничение.

  • Решение 1: Memory Bank и кастомная команда /refresh_context - инструменты для борьбы с этой проблемой. Они позволяют быстро и дешево восстановить понимание проекта.

  • Решение 2: Использование субагентов. Поскольку у каждого субагента свое контекстное окно, его должно быть достаточно для решения специализированной задачи. Это позволяет избежать “танцев с контекстом”.

• Критическая зависимость от качества ТЗ: Это самое важное ограничение. Если вы сэкономите время на этапе планирования с Gemini и дадите Claude Code сырое, неполное ТЗ, вы получите плохой код. Этап архитектурного планирования - не опция, а фундамент всего процесса.

Заключение

Путь от Vibe Coding к системной методологии AI SWE отражает естественную эволюцию любой революционной технологии - от первоначальной эйфории и экспериментов к зрелым, промышленным практикам. Vibe Coding был необходимым этапом знакомства с возможностями AI-агентов, но его интуитивный подход неизбежно упирается в стену сложности реальных проектов. AI Software Engineering предлагает иной подход и, возможно, выход из этого тупика, превращая AI-агента из непредсказуемого помощника в управляемый инструмент создания больших систем.

---

Эта статья была обзорной и преследовала цель лишь познакомить вас с некоторыми концепциями. В будущих же статьях мы продолжим раскрывать суть AI SWE и работы с ClaudeCode: углубимся в каждый из компонентов, подробно рассмотрим сам MemoryBank и техники создания таких документов, глубже погрузимся в проектирование workflow для работы субагентов и поделимся новыми стратегиями и приемами эффективной работы с ClaudeCode.

И не забывайте заглядывать в наши Telegram каналы Agent LLM и DEKSDEN notes.