itogai

Инструменты · Anthropic

Claude Code: как вести агентную работу с кодовой базой

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

До первого запроса

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

  • посмотрите git status и сохраните понятную исходную точку;
  • убедитесь, что зависимости установлены, а ключевые проверки действительно запускаются;
  • назовите область проекта и файлы, которые нельзя менять;
  • вынесите устойчивые соглашения и команды в проектный CLAUDE.md;
  • заранее решите, какие команды и внешние данные допустимы для этой работы.

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

Как проходит хорошая сессия

Официальные рекомендации Anthropic сводят надёжную работу к циклу explore → plan → code → verify. Его ценность в разделении режимов. Пока агент исследует, от него не требуется сразу защищать выбранную реализацию. План можно поправить до того, как неверное допущение разойдётся по коду.

Explore

Найти вход в сценарий, связанные типы, тесты и уже принятые решения. Изменения пока не нужны.

Plan

Зафиксировать минимальный набор файлов, порядок работы, риски и сигналы готовности.

Code

Выполнить согласованный шаг. Если открывается новая архитектурная развилка, остановить реализацию и вернуть решение человеку.

Verify

Запустить проверки, воспроизвести сценарий и просмотреть diff. Исправлять конкретный сбой, а не просить «сделать получше».

Реалистичный сценарий: отладка вместо угадывания

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

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

Правдоподобное объяснение не равно найденной причине. Просите агента ссылаться на конкретный поток в коде и подтверждайте гипотезу воспроизведением до изменения.

Почему терминал и git хорошо сочетаются с этим форматом

Claude Code часто используют из терминала: там уже находятся команды проекта, логи, git и инструменты поиска. Это делает переход между разговором и проверкой коротким. Агент может запустить существующую команду, а разработчик — тут же посмотреть её полный результат и независимый diff.

Но называть Claude Code только терминальным инструментом уже неточно. Официально он также доступен через IDE, desktop и web-поверхности. Для устойчивого текста важнее другое: сессия строится вокруг реального репозитория и инструментов, а не вокруг изолированного фрагмента, вставленного в чат.

Разрешения, секреты и недоверенный контент

Агент, который умеет менять файлы и запускать команды, получает реальную операционную силу. Настройки permissions нужно выбирать под задачу, а не один раз «для удобства». Чтение проекта, локальная сборка и публикация пакета имеют совершенно разный радиус последствий.

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

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

Когда такой workflow неудобен

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

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

Пример хорошего стартового задания

В форме публикации иногда не сбрасывается состояние загрузки после ошибки API. Сначала изучи текущий поток отправки, обработчик ошибок и связанные тесты. Ничего не меняй. Опиши вероятную причину со ссылками на файлы и предложи минимальный план. Нельзя менять контракт API и общий компонент кнопки. После согласования добавь регрессионную проверку и запусти существующие lint и test-команды.

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

Актуальные интерфейсы, способы установки и подробности permissions сверяйте с официальной документацией Claude Code.

Попробуйте подход на реальной задаче

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

Связанные материалы