Эта статья написана для тех, кто работает с кодом — но прочитать её полезно и без
технического бэкграунда. Claude Code — это ИИ-агент, который запускается прямо в
терминале разработчика и умеет самостоятельно читать, искать и править файлы проекта:
те же самые принципы (набор инструментов, диалог с уточнениями, пошаговые изменения)
лежат в основе и Хелпера — ассистента на этом сайте. Даже если вы сами код не пишете,
понимание того, как ИИ-агент устроен изнутри, помогает точнее формулировать задачи для
него или для подрядчика, который его использует — правите ли вы текст на сайте,
логику Telegram-бота или автоматизацию — и лучше понимать, что вообще произошло, когда
приходит ответ «готово, всё поправил».
Как Claude Code читает код
У агента нет «зрения» в привычном смысле — вместо этого он пользуется набором
инструментов, каждый под свою задачу:
- Read — открывает конкретный файл целиком или частями и
показывает его содержимое, как будто вы сами открыли файл в редакторе.
- Glob — ищет файлы по маске имени/пути (например «все файлы
*.py в папке services»), не заглядывая внутрь содержимого.
- Grep — ищет текст или паттерн (в том числе регулярные
выражения) внутри содержимого файлов по всему проекту или его части.
- Bash — выполняет команды терминала: от простого
ls/find, чтобы посмотреть структуру папок, до запуска
тестов, сборки или установки зависимостей.
Комбинируя эти четыре инструмента, агент строит для себя карту проекта примерно так
же, как это делал бы человек, впервые открывший чужой репозиторий.
Изучение нового проекта и точечное исследование флоу
Самый эффективный способ начать знакомство с незнакомой кодовой базой — задать
широкий обзорный вопрос: «Опиши архитектуру этого проекта», «Из каких основных
модулей он состоит и как они связаны». Такой вопрос заставляет агента пройтись по
структуре папок, конфигурационным файлам и точкам входа — и вернуть что-то вроде
карты кодовой базы, прежде чем переходить к деталям.
Когда общая картина есть, дальше эффективнее спрашивать точечно — просить проследить
конкретный сквозной сценарий («флоу») от начала до конца. Например: «Проследи путь
авторизации пользователя от формы логина до записи сессии в базу» или «Как устроен
процесс оформления заказа — от нажатия кнопки „Купить“ до отправки уведомления». Такие
вопросы заставляют агента пройти по цепочке файлов в порядке реального выполнения, а
не просто перечислить их список.
Эффективный поиск по коду
Инструмент Grep особенно полезен для конкретных, часто повторяющихся задач поиска —
вот несколько рабочих формулировок запроса:
- Найти все места, где импортируется определённый модуль или библиотека —
полезно перед его удалением или заменой.
- Найти все пометки
TODO/FIXME по проекту — быстрый
способ увидеть накопленный технический долг.
- Найти все вызовы конкретной функции — чтобы понять, где она используется, прежде
чем менять её поведение или сигнатуру.
- Найти файл по имени или паттерну имени, если известна только часть названия или
тип файла.
Чем конкретнее формулировка (что именно ищем и в какой части проекта), тем точнее и
быстрее агент найдёт нужное — расплывчатое «посмотри, что тут есть» заставляет его
гадать, с чего начинать.
Разбор сложного кода
Если попадается непонятный участок — сложное регулярное выражение, запутанная логика
управления состоянием, нетривиальный алгоритм — можно прямо попросить объяснить его
человеческим языком: «Что делает это регулярное выражение построчно», «Объясни, как
здесь меняется состояние объекта на каждом шаге». Агент разбирает код построчно или
блоками и переводит его в обычное описание логики, что часто быстрее, чем
разбираться самостоятельно, особенно в чужом или давно не тронутом коде.
Ревью кода
Для быстрого автоматического ревью изменений есть однострочный приём — передать
вывод git diff прямо в Claude Code через конвейер:
git diff | claude -p "Проверь этот diff на ошибки и риски"
Это неинтерактивный режим — команда выполняется один раз и печатает результат. Для
более глубокого разбора (когда хочется задавать уточняющие вопросы по ходу, а не
просто получить список замечаний) удобнее интерактивный режим — обычный диалог с
агентом внутри терминала, где можно уточнять «а почему это риск» или «покажи, где
конкретно».
Инструменты для изменений
Когда доходит до самих правок, у агента тоже есть разделение по задачам:
- Edit — точечная замена конкретного фрагмента в уже существующем
файле, без переписывания всего файла целиком.
- Write — создаёт новый файл или полностью перезаписывает
существующий, когда изменений слишком много для точечной правки.
- Bash — тот же инструмент, что и для чтения, только теперь
используется для действий: установка зависимостей, запуск тестов, сборка проекта,
прогон линтера.
Разделение важно и для формулировки задачи: если нужно поправить одну строку — это
явно про Edit, если пересобрать файл с нуля — про Write, а «проверь, что ничего не
сломалось» — это про запуск команд через Bash.
Изменения в нескольких файлах сразу
Не все задачи укладываются в один файл. Сквозной рефакторинг — например,
переименование функции или переменной, которая используется в десятках мест по всей
кодовой базе — требует найти все вхождения (через Grep) и последовательно поправить
каждое. Похожая история с фичей, которая затрагивает сразу несколько слоёв
приложения одновременно — например изменение структуры базы данных, которое тянет за
собой правку API-эндпоинта и логики на фронтенде. Агент способен провести такую
цепочку правок за один заход, но чем яснее описана связь между частями («если меняешь
поле в базе — обнови и то, как его читает API, и то, как его показывает интерфейс»),
тем меньше риск, что что-то из цепочки будет упущено.
Итерация и отмена изменений
Работа с агентом — это диалог, а не разовая команда. Если результат не совсем то, что
нужно — правку можно уточнить следующим сообщением, не начиная всё заново: «сделай
то же самое, но без этого побочного эффекта». Если правка оказалась ошибочной или
вы передумали — можно отменить конкретное изменение или откатиться назад через
обычные git-команды (git checkout, git reset) — агент
работает поверх той же системы контроля версий, что и обычный разработчик, а не в
какой-то параллельной песочнице.
Лучшие практики постановки задачи
- Одна задача — одно сообщение. Наваливать сразу несколько несвязанных просьб в
одном запросе («поправь баг и заодно обнови дизайн и добавь новую фичу») усложняет
агенту приоритизацию и увеличивает риск, что часть задачи потеряется.
- Проверяйте результат сборкой или тестами, а не на глаз — то же правило, что и для
правок человека: «работает» подтверждается прогоном, а не тем, что код выглядит
правильно.
- Понимание того, какой инструмент за что отвечает (см. разделы выше), помогает
точнее формулировать сам запрос — вместо «посмотри на проект» можно сразу попросить
нужное действие («найди все вызовы этой функции», «проверь diff перед коммитом»),
и агент быстрее придёт к результату.
Если разбираться самостоятельно нет времени или желания — постановка задач для ИИ-агента,
настройка автоматизаций и сопровождение таких инструментов в рабочих процессах компании
как раз то, чем занимается услуга «Консультации по
внедрению ИИ» на этом сайте. Про базовый формат, в котором такие агенты обычно
отвечают — читайте статью про Markdown.