Skip to main content
ClaudeAI automationразработка

Как я запускаю разработку с Claude без хаоса

Обсуждаемый подход простой: не прыгать от идеи сразу в код, а вести фичу через цепочку brainstorm → spec → plan → implementation. Для бизнеса это важно, потому что такая AI automation схема меньше теряет контекст, упрощает AI implementation и делает результат предсказуемее.

Технический контекст

Я здесь полностью согласен с формулой brainstorm → spec → plan → implementation. Когда я делаю AI implementation в реальной разработке, я почти никогда не прошу Claude сразу писать фичу целиком. В этот момент модель еще не понимает границы задачи, а значит начинает додумывать архитектуру за меня.

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

Дальше я не иду сразу в код. Я прошу сделать spec: что именно меняем, какие есть non-goals, acceptance criteria, edge cases, какие модули затронем. Если спецификация выглядит рыхлой, новая сессия не поможет, потому что проблема не в окне контекста, а в том, что задача еще не собрана.

После этого я прошу развернуть spec в plan. Не абстрактный план на уровне «сделать backend, потом frontend», а нормальную инженерную разбивку: порядок шагов, зависимости, файлы, тесты, миграции, rollback-риски. И вот уже из plan я запускаю implementation, обычно маленькими кусками.

Новую сессию я открываю часто, но не магически «для генерации кода», а чтобы зафиксировать чистую фазу работы. В новую сессию я передаю уже вычищенный spec, plan и нужный кодовый контекст. Это сильно лучше, чем тащить длинный back-and-forth, где вперемешку идеи, опровержения и тупики.

Делегирование тоже работает, но не как замена мышлению. Я могу попросить Claude отдельно собрать неизвестные, отдельно предложить структуру spec, отдельно проверить план на дыры. То есть я делегирую подзадачи, а не ответственность за инженерное решение.

Влияние на бизнес и автоматизацию

На практике здесь три выигрыша. Первый: меньше холостого кода, который потом надо выбрасывать. Второй: проще оценивать сроки, потому что plan уже разбит на реальные шаги. Третий: легче строить automation with AI в команде, где несколько людей и ассистентов работают над одной фичей.

Выигрывают команды, у которых дорогой контекст: легаси, интеграции, нестандартная логика. Проигрывают те, кто все еще просит модель «сделай готовую систему» одним промптом и потом удивляется, почему все разваливается на ревью.

Я у себя в Nahornyi AI Lab решаю именно такие задачи для клиентов: раскладываю хаотичную разработку на управляемый pipeline, где AI automation ускоряет выпуск, а не плодит новые риски. Если у вас фичи тонут в контексте, давайте посмотрим на ваш процесс и соберем такую AI integration схему, которая реально снимет лишнюю ручную работу.

Помимо начальных этапов генерации кода, по-настоящему эффективный пайплайн разработки на базе ИИ должен также обеспечивать высокое качество и интеграцию кода. Ранее мы исследовали, как параллельные агенты Claude Code можно эффективно использовать для выявления состояний гонки во время ревью pull-реквестов, что критически важно для снижения рисков CI/CD и оптимизации рабочих процессов разработки.

Поделиться статьёй