AI Software Engineering: От хаоса Vibe Coding к системной разработке с AI-агентами / Habr

Введение:

В мире разработки программного обеспечения происходит фундаментальная революция. Мы стоим на пороге перелома в самом подходе к созданию кода: от традиционного программирования, где код пишется вручную, к новой эпохе, где 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 разработчик действует «по наитию», давая агенту общие инструкции. Это такой ультра-аджайл на ИИ-топливе, где итерационные циклы сжимаются до минут, для максимально быстрого воплощения идей в работающий продукт. Типичный сценарий выглядит так:

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

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

Дублировать функционал, уже существующий в другой части проекта.
Нарушать архитектурные принципы, о которых "не было сказано".
Ломать существующую бизнес-логику, внося изменения в неочевидные, но связанные модули.
Создавать сотни бесполезных юнит-тестов, которые не следуют принятым паттернам и никогда не будут переиспользованы.

Корень этих проблем не только в 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 - это не просто папка с документацией. Это живая, структурированная база знаний о проекте, она выполняет две ключевые функции:

Долгосрочная память проекта: Решает проблему ограниченного контекста, предоставляя агенту единый, достоверный источник информации об архитектуре, бизнес-логике, технологиях и процессах.
Операционная система для агента: Содержит четкие инструкции и рабочие процессы (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-агент не всегда идеален. Чтобы убедиться, что он в точности выполнил задачу, мы создаем эффективный цикл самоконтроля.

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