AI-ассистенты в разработке

AI-ассистенты в разработке: практический workflow с Claude Code

Этот сайт целиком написан в паре с Claude Code, от бэкенда на Rust до текста, который ты сейчас читаешь. Разбираю, как реально выстроен этот workflow: настройка, CLAUDE.md, ревью, границы автономии и провалы, которые всему научили.

15 июля 2026 г.·25 мин чтения·

Почему это не автодополнение

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

Этот сайт целиком сделан в таком режиме: бэкенд на Rust, фронтенд на Next.js, админка на React, деплой через systemd. Всё это написано в паре с Claude Code, включая текст, который ты сейчас читаешь. Дальше конкретный разбор того, как этот workflow реально устроен: с чего начать настройку, как писать инструкции для агента, как ревьюить его код, где проводить границу автономии и что из этого провалилось у меня лично, прежде чем заработало.

Важная оговорка перед тем, как переходить к деталям: ничего из описанного ниже не универсально для любого agentic-инструмента в равной мере, хотя общие принципы переносятся. Я использую конкретно Claude Code, и часть механики (структура CLAUDE.md, режимы разрешений) специфична именно для него. Но сами принципы, ради которых стоит читать этот текст, если пользуешься другим инструментом, переносятся почти без изменений: конкретность постановки задачи, постепенное расширение автономии, обязательное ревью, работают одинаково независимо от конкретного бренда агента.

Как настроить Claude Code для своего проекта

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

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

Частая ошибка новичков в agentic coding: сразу давать агенту широкие права, чтобы "не отвлекаться на подтверждения". Звучит как ускорение, а на практике убирает именно тот механизм, который спасает от случайного rm -rf или коммита в основную ветку без проверки. Права стоит расширять постепенно, по мере того как накапливается доверие к конкретным типам действий в конкретном проекте, а не выдавать всё сразу авансом.

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

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

Ещё один практический момент настройки: интеграции через MCP (Model Context Protocol) и похожие механизмы, которые дают агенту доступ к внешним системам вроде багтрекера, базы знаний, специфичных для компании внутренних инструментов. Здесь работает то же правило, что и с правами на файловую систему. Подключать по мере реальной необходимости, а не сразу весь доступный набор интеграций, потому что каждая лишняя интеграция расширяет поверхность для непредсказуемого поведения.

CLAUDE.md: как писать инструкции для AI-агента

CLAUDE.md — файл в корне репозитория, который агент читает в начале каждой сессии. Это не документация для людей (хотя частично пересекается), а именно контекст для агента: что за проект, как он устроен, какие команды использовать для сборки и тестов, каких паттернов придерживаться.

Рабочая структура, которая используется в этом самом проекте, держится на четырёх блоках. Архитектурный обзор: из каких частей состоит проект и что за что отвечает, буквально таблицей с колонками директория, описание, порт. Команды разработки: как поднять каждую часть локально, без необходимости гадать или искать в истории команд. Структура бэкенда: где лежат хендлеры, где модели, где миграции, чтобы агент не тратил вызовы на исследование структуры заново в каждой сессии. И ключевые паттерны: вещи, которые не самоочевидны из кода, например что публичные API принимают необязательный параметр локали, или что миграции выполняются идемпотентно при каждом старте, а не отдельными файлами.

Главная ошибка при написании CLAUDE.md: превращать его в общее описание проекта вместо конкретных, действенных инструкций. Фраза "проект использует Rust и Axum" бесполезна, агент это и так увидит по Cargo.toml. А вот пояснение "миграции пишутся через INSERT OR IGNORE, потому что схема пересобирается на каждом старте, а не через отдельные файлы миграций" реально экономит время: без этой строчки агент, скорее всего, попробует создать отдельный файл миграции по привычному для большинства проектов паттерну, и это будет неправильно именно для этого проекта.

Второй важный момент: CLAUDE.md должен обновляться так же, как и код. Устаревшая инструкция хуже отсутствующей: она уводит агента в неправильную сторону с уверенностью, как будто это всё ещё актуально.

Работа с AI-агентом в монорепозитории

Проект с несколькими подпроектами в одном репозитории (бэкенд, фронтенд, админка) создаёт для агента специфическую сложность: контекст одной части может быть нерелевантен для задачи в другой, а неверно угаданный контекст тратит и время, и деньги на токены.

Практики, которые снимают эту сложность:

Отдельный раздел CLAUDE.md на каждый подпроект, а не один общий раздел на всё сразу. Задача в бэкенде не должна тянуть за собой инструкции про фронтенд-стек.
Явное указание границ задачи в постановке. "Поменяй эндпоинт в backend/src/handlers/blog.rs" работает быстрее и точнее, чем "поменяй эндпоинт блога", потому что снимает с агента шаг угадывания, в какой из трёх частей проекта искать.
Отдельные команды сборки и теста на каждую часть, задокументированные явно. Агенту не нужно гадать, каким образом собирается конкретно фронтенд, если это отдельная команда от сборки бэкенда.

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

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

Как ревьюить код, написанный AI-агентом

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

Три вещи, на которые стоит смотреть в первую очередь:

Границы изменений. Агент иногда решает "заодно" поправить что-то рядом с задачей, выходя за её рамки. Это может быть полезно, а может незаметно расширить область риска. Стоит явно проверять диф на предмет изменений, которых ты не просил.
Обработка ошибок. Модели склонны писать код для счастливого пути и добавлять try/catch или проверки только там, где явно попросили. Если задача не включала обработку граничных случаев в постановке, скорее всего, в результате её тоже не будет.
Соответствие существующим паттернам. Даже с хорошим CLAUDE.md агент иногда пишет код, который технически работает, но не похож на остальной проект: другой стиль именования, другая структура ошибок. Это накопительная проблема, по отдельности незаметная: за несколько месяцев кодовая база расползается по стилю.

Практическое правило: ревьюй диф от агента с тем же вниманием, что и pull request от нового сотрудника, который ещё не знает всех негласных договорённостей команды, потому что по сути это ровно та же ситуация.

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

Как ограничить AI-агента, чтобы не сломать прод

Автономия агента — это не бинарный переключатель "включено/выключено", а спектр, и правильная настройка зависит от того, что именно на кону в конкретном проекте.

Практическая иерархия ограничений от мягких к жёстким:

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

Ограничения не означают недоверие к инструменту. Это то же самое инженерное здравомыслие, которое применяется к правам доступа для любого нового участника команды: доверие растёт постепенно, вместе с историей успешных задач, а не выдаётся авансом.

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

Работа с секретами и переменными окружения

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

Практические меры, которые снимают этот риск, а не просто снижают его на глаз:

Секреты не должны лежать в файлах, которые агент читает по умолчанию. .env в .gitignore обязательный минимум, но стоит идти дальше и держать реальные продакшен-секреты вообще вне репозитория, в отдельном хранилище (менеджер секретов, переменные окружения самого сервера), а не в файле рядом с кодом, даже игнорируемом git.
Явный запрет в инструкциях проекта на чтение и вывод содержимого файлов с секретами, даже если технически к ним есть доступ. Это дополняет техническую защиту ещё одним уровнем, а не заменяет её.
Ротация ключей после любого инцидента, даже подозрения на инцидент. Если есть малейшее сомнение, что секрет мог засветиться в логе диалога с агентом или в истории коммитов, дешевле перевыпустить ключ, чем потом разбираться, утёк он или нет.

Это тот редкий случай в работе с AI-агентами, где стоит скорее переосторожничать, чем недооценить риск. Цена лишней предосторожности — пара минут. Цена утечки продакшен-секрета может обернуться серьёзным инцидентом.

AI-агент и git: практики коммитов и PR

Git — это то место, где ошибки агента становятся особенно заметны, если не выстроить правильную дисциплину заранее.

Рабочие практики:

Небольшие, атомарные коммиты, а не один гигантский коммит на всю задачу. Легче ревьюить, легче откатить конкретное изменение, если что-то пошло не так, не трогая остальное.
Осмысленные сообщения коммитов, которые описывают "почему", а не только "что". Агент способен писать хорошие сообщения, если явно попросить, но по умолчанию склонен к формальному "update file.rs".
Никогда не пушить напрямую в защищённую ветку без явного разрешения в конкретной сессии, даже если технически права на это есть.
Явная проверка диффа перед коммитом, а не слепое доверие тому, что агент сделал именно то, что было запрошено. Пара секунд на просмотр git diff экономит часы на разбор, что вообще произошло, если что-то пошло не так через неделю.

Отдельно стоит сказать про co-authorship: если агент реально написал существенную часть коммита, честно отметить это в сообщении коммита. Это полезная информация для будущего тебя или коллеги, разбирающего историю изменений, а не формальность ради формальности.

Как обучить AI-агента специфике своего кодстайла

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

Агент учится этому через явное обучение на конкретных примерах, а не магией:

Вот пример кода из этого проекта, который хорошо отражает наш стиль:
[фрагмент кода].

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

Такой промпт работает лучше, чем абстрактное "пиши чистый код", потому что даёт конкретный референс, а не оценочное суждение, которое каждый понимает по-своему. Если после нескольких сессий агент продолжает регулярно нарушать один и тот же паттерн, обычно проще зафиксировать это правило явно в CLAUDE.md, чем повторять инструкцию заново в каждом новом диалоге.

Есть и более тонкий уровень стиля, который сложнее формализовать промптом: интуитивное чувство, когда абстракция уже нужна, а когда ещё рано. Агенты по умолчанию склоняются в одну из двух крайностей в зависимости от модели и настроек. Одна крайность: чрезмерно абстрагируют код, вынося в отдельные функции и модули вещи, которые пока используются один раз. Другая: пишут всё плоским текстом без структуры даже там, где повторение уже очевидно. Ни одна инструкция в CLAUDE.md не заменит здесь личного ревью на протяжении первых нескольких недель работы над конкретным проектом: правило вроде "пятое повторение уже повод для абстракции, а вот три одинаковых строки ещё нет" усваивается агентом через конкретные примеры правок в диалоге, а не через одну абстрактную формулировку.

Мультиагентные workflow: когда это оправдано

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

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

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

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

Мультиагентные workflow: практические ограничения

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

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

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

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

Автономная разработка: сколько задач реально доверить AI без надзора

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

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

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

Тесты как страховка для агентной разработки

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

Рабочий паттерн, который стоит держать по умолчанию: перед тем как просить агента внести изменение в существующий код, убедиться, что покрывающие этот код тесты уже есть и проходят. Если тестов нет, первая просьба к агенту — написать их для текущего поведения, прежде чем менять само поведение. Это даёт объективный критерий "ничего не сломалось" вместо субъективного "вроде работает", который проверяется беглым ручным тестированием и может пропустить регрессию в неочевидном месте.

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

Отдельно полезная практика для agentic-workflow: просить агента сначала написать падающий тест, который описывает желаемое поведение, и только потом писать код, который его проходит. Классический TDD-цикл работает с агентом даже лучше, чем с человеком в одиночку, потому что явно разделяет два разных режима работы, формулировку требования тестом и реализацию под уже зафиксированное требование, а не смешивает их в одном непрерывном потоке правок.

Дебаг с AI-агентом: как эффективно описывать баги

Качество бага, который ты формулируешь агенту, напрямую определяет скорость и точность решения. Здесь работает тот же принцип, что и в общении с живым коллегой: расплывчатое описание получает расплывчатую помощь.

Рабочий шаблон постановки бага:

Баг: [что именно происходит не так, конкретно и без интерпретаций].
Ожидаемое поведение: [что должно происходить вместо этого].
Шаги воспроизведения: [1, 2, 3].
Контекст: [что менялось перед появлением бага, если известно].
Что уже проверено и исключено: [если пробовал что-то сам].

Последняя строка часто пропускается, а зря: если ты уже проверил и исключил очевидные причины, явное указание этого экономит агенту (и тебе) время на повторную проверку той же гипотезы. Без этой строки агент нередко начинает именно с самой очевидной причины, которую ты уже отмёл, и тратит впустую первую итерацию диалога.

Отдельно полезная практика: просить агента сначала объяснить гипотезу о причине, прежде чем менять код, а не сразу бросаться исправлять баг. Это ловит ситуации, когда предполагаемая причина неверна: лучше потратить минуту на проверку гипотезы словами, чем десять минут на правку кода, которая не решает исходную проблему, потому что диагноз был неправильным с самого начала.

Claude Code, Cursor, Windsurf: сравнение для реальных задач

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

Инструмент	Сильная сторона	Где не так хорош
Claude Code	Терминальный, агентный workflow с сильной автономией на многошаговых задачах, глубокая работа с контекстом всего проекта	Меньше визуального IDE-опыта, чем у конкурентов, привычка нужна, если раньше работал только в GUI-редакторе
Cursor	Полноценный форк VS Code с AI, встроенным в привычный редакторский интерфейс, низкий порог входа	Агентный режим менее автономен по умолчанию, больше рассчитан на построчные правки с подтверждением
Windsurf	Похожий на Cursor UX, отдельные функции для правок сразу в нескольких файлах	Экосистема плагинов и сообщество меньше, чем у Cursor и у решений на базе VS Code

Практический вывод: если рабочий стиль — терминал и явная постановка задач целиком, а не построчное редактирование с частыми подтверждениями, Claude Code выигрывает за счёт более глубокой автономии. Если привычнее классический IDE-опыт с AI как усилением, а не заменой ручного редактирования, Cursor или Windsurf будут ощущаться естественнее с первого дня. Ничего не мешает пробовать несколько инструментов на разных задачах: они не взаимоисключающие, и многие разработчики держат два инструмента для разных типов работы.

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

Во сколько это реально обходится

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

Стоимость складывается из объёма контекста, который агент читает и обрабатывает на каждой итерации. Маленькая, точечная задача с узким контекстом обходится дёшево. Задача, требующая прочитать половину кодовой базы, чтобы понять, что вообще происходит, обходится заметно дороже, причём рост стоимости иногда скачкообразный, а не линейный, если контекст разрастается до нескольких десятков файлов сразу.

Практические способы держать расходы под контролем, не жертвуя качеством:

Хороший CLAUDE.md сам по себе экономит деньги, а не только время: агенту не нужно заново исследовать структуру проекта в каждой сессии, если она уже описана.
Узко сформулированные задачи дешевле широких. "Почини баг в файле X" обходится дешевле, чем "разберись, почему что-то работает не так", потому что во втором случае агент сначала тратит контекст на поиск проблемы, и это может быть значительная часть всей стоимости задачи.
Не каждая задача требует самой мощной модели. Рутинные, хорошо специфицированные задачи часто справляются и с более быстрой и дешёвой моделью, а тяжёлую артиллерию стоит приберечь для действительно сложных случаев.

Мой личный опыт: за первый месяц я тратил заметно больше, чем ожидал, просто потому что давал агенту слишком широкие, неточные задачи, и он тратил токены на угадывание контекста, который я мог бы просто сразу дать сам. После того как я стал формулировать задачи конкретнее (см. раздел ниже про формулировки), стоимость упала примерно вдвое при том же объёме реально сделанной работы. Разница была именно в том, как я ставил задачи, а не в модели и не в тарифе.

Стоит ли оно того по сравнению с самостоятельным написанием кода? Для меня однозначно да, но не потому что это "бесплатно" или "заменяет думать самому", а потому что переносит время с рутинных частей задачи на архитектурные решения и ревью, где мой опыт реально нужен. Час, потраченный на постановку хорошей задачи и ревью результата, обычно даёт больше готового, проверенного кода, чем час самостоятельного набора текста, даже с учётом стоимости токенов.

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

Кейс: как я автоматизировал деплой с помощью AI-агента

Деплой этого сайта раньше был у меня ручным: собрать бэкенд, скопировать бинарник, перезапустить systemd-сервис, отдельно повторить то же самое для фронтенда и админки. Каждый раз одинаковая последовательность команд, каждый раз риск забыть шаг, особенно если деплоил уставшим вечером после основной работы.

Я поставил агенту задачу конкретно, а не просто "напиши мне Makefile": описал текущую ручную последовательность команд шаг за шагом, показал структуру проекта и попросил собрать это в единые команды с проверкой на каждом шаге. Например, чтобы деплой бэкенда падал с понятной ошибкой, если в .env не хватает обязательной переменной, а не просто заваливал уже работающий сервис молча. Результат: Makefile с явными целями на каждую часть системы и отдельной проверкой окружения перед тем, как трогать уже работающий продакшен.

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

Интересный побочный эффект: когда пишешь Makefile вместе с агентом, приходится явно проговаривать каждый шаг ручного процесса, который раньше выполнялся "на автомате", не задумываясь. В процессе этого проговаривания я сам заметил пару шагов, которые делал по привычке, но которые на самом деле были избыточны или даже потенциально опасны: например, я раньше не проверял состояние .env файла перед деплоем бэкенда вообще, просто полагаясь, что он всегда на месте. Формализация процесса вскрыла этот риск раньше, чем он успел материализоваться в реальный инцидент.

Провалы AI-агентов: чему они научили

Не всё получалось с первого раза, и часть уроков стоила больше времени, чем сэкономил бы честный разбор чужого опыта заранее.

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

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

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

Доверие к уверенному тону вместо проверки результата. Агент, который ошибается, редко звучит неуверенно: он формулирует неправильное решение с той же убеждённостью, что и правильное. Я несколько раз ловил себя на том, что оцениваю качество результата по тому, насколько гладко и профессионально звучит объяснение агента, а не по тому, насколько оно на самом деле верно. Это ровно та же ловушка, о которой я писал в статье про обучение с AI: гладкость объяснения и его правильность разные вещи, и одно легко подменяет другое, если не проверять специально.

Общий урок из всех четырёх: чем более конкретно и с большим количеством контекста поставлена задача, тем меньше сюрпризов в результате. Это не специфика именно Claude Code, а общий принцип работы с любым agentic-инструментом, который я, честно говоря, до этого недооценивал, считая, что "умная модель сама разберётся".

Как формулировать задачи, чтобы получать предсказуемый результат

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

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

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

Куда двигаться дальше

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

Ревью кода от агента только половина проверки качества. AI code review: как автоматизировать ревью кода разбирает автоматизацию самого code review с помощью AI отдельно и подробно, включая инструменты и метрики.

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

Заключение

Agentic coding: смена роли с "пишу код" на "ставлю задачи и проверяю результат", а не более продвинутое автодополнение. Недооценка этой разницы главная причина разочарования у тех, кто пробовал и не впечатлился.
CLAUDE.md должен содержать конкретные, действенные инструкции, а не общее описание проекта, и обновляться так же регулярно, как и сам код.
Автономия — это спектр, а не переключатель: расширяй права агента постепенно, по мере накопления доверия к конкретным типам задач, и держи минимальную автономию там, где цена ошибки высокая.
Провалы почти всегда объясняются одним и тем же: слишком широкая или недостаточно конкретная постановка задачи. Чем больше контекста дано заранее, тем меньше сюрпризов в результате.
Стоимость agentic-разработки складывается из того, насколько конкретно поставлены задачи, а не из тарифа модели: узкий, точный запрос почти всегда дешевле и надёжнее широкого и расплывчатого, причём и по деньгам, и по качеству результата.