«У вас в резюме указаны навыки ИИ. Что вы имели в виду?» Что отвечать, кроме количества потраченных токенов

Всё началось с чата с однокурсниками. Кто‑то обронил фразу «сейчас без ИИ никуда, это уже базовый навык», и следующие два дня мы выясняли, что каждый понимает под этим что‑то своё.

Один говорил, что весь навык сводится к умению нормально сформулировать запрос, всё остальное сделает модель. Другой доказывал, что настоящее умение это как раз не пускать ИИ туда, где он навредит, и что главный навык это дисциплина отказа. Третий считал, что тема надутая, а через год всё устаканится само и учиться нечему. Четвёртый прислал скриншот своего CLAUDE.md ^[1] на двести строк и сказал, что вот она, настоящая работа.

Меня зацепило, что мы все вроде бы делаем одно и то же каждый день, а описываем это несовместимыми словами. Ни у кого, включая меня, не оказалось внятного ответа на простой вопрос: если разработчик говорит «я умею работать с ИИ», что конкретно он умеет?

А потом выяснилось, что вопрос не академический. У половины из нас в резюме стоит строчка про навыки работы с ИИ, и на собеседованиях за неё уже начали цепляться. «У вас тут указаны навыки ИИ. Что вы имели в виду?» И вот тут начинается неловкое. Потому что честный ответ большинства звучит примерно так: пользуюсь Claude Code каждый день, беру модель посильнее, когда задача сложная, в прошлом месяце сжёг столько то токенов. Всё это правда, и всё это ничего не говорит о вас как об инженере. Количество потраченных токенов характеризует вас ровно так же, как количество написанных строк кода: то есть никак, а иногда и в минус.

Проблема в том, что альтернативной формулировки у нас просто нет. Мы умеем называть инструменты и не умеем называть умения. Поэтому я сел и попробовал собрать перечень. Не «топ 10 промптов», а честный список умений, каждое из которых можно проверить, показать в работе и внятно описать словами, когда спросят.

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

Сразу отвечу на возражение, которое возникнет у половины читателей примерно на середине списка. Да, git, тестирование, ревью, работа с legacy и проектирование это не навыки работы с ИИ, а обычная инженерия, которой много десятилетий. Это не недосмотр, это и есть главный вывод, к которому я пришёл, пока составлял список. Примерно половина того, что сегодня называют навыками работы с ИИ, это давно известная инженерная дисциплина, которую ИИ резко повысил в цене. Раньше её отсутствие обходилось в недели, теперь в дни, потому что плохого кода производится больше и быстрее. Так что если по ходу чтения захочется написать «вы просто перечислили навыки хорошего разработчика», считайте, что мы уже согласились.

Список целиком:

1. Работа с кодинг агентом (инструментальный слой) ^[2]

2. Управление контекстом сессии ^[3]

3. Постановка задачи и планирование ^[4]

4. Передача модели стандартов кодирования и архитектуры ^[5]

5. Ревью и контроль качества сгенерированного кода ^[6]

6. Отладка кода, который писал не ты ^[7]

7. Тестирование ^[8]

8. Работа с legacy и чужой кодовой базой ^[9]

9. Git и управление изменениями ^[10]

10. Понимание сильных и слабых сторон инструмента ^[11]

11. Экономика: стоимость и время ^[12]

12. Безопасность рабочей среды ^[13]

13. Командная работа ^[14]

14. Документирование ^[15]

15. Параллельная работа с несколькими агентами ^[16]

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

Три уровня вместо одной шкалы

Первая версия этого текста делила навыки на «Базовый минимум» и «Роскошный максимум». Получалось плохо, потому что обязательность зависит от того, чем вы занимаетесь. Человеку, который в одиночку пилит продукт, безопасность агента в командном репозитории не нужна вообще, а тимлиду она нужна вчера.

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

Уровень 0. Вайб‑кодер. Пишет с ИИ и получает работающий результат, но не отвечает за то, что будет с этим кодом дальше. Проверяет по принципу «запустилось и ладно», в диффы не смотрит, о том, как решение поведёт себя через полгода, не думает. Это не оскорбление и не приговор: для прототипа, скрипта на один раз или пет‑проекта, который посмотрят десять человек, такой режим совершенно нормален и часто оптимален. Проблема начинается там, где написанное нужно поддерживать.

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

Уровень 1. Соло‑разработчик. Человек‑оркестр: сам пишет, сам ревьюит, сам чинит в проде. Может с помощью ИИ поднять новый проект и, что важнее, потом его развивать, не утонув в собственном коде. Граница с нулевым уровнем проходит именно здесь, и она не про качество промптов: написать проект может почти каждый, а вот через три месяца развития у одного он живой, а у другого встал намертво, и никто, включая автора, уже не понимает, как это работает.

Уровень 2. Командный игрок. Отвечает за качество промышленного решения и работает не один, а рядом с людьми и агентами сразу. Понимает безопасность, следит за стоимостью, умеет договориться о единых правилах и не завалить коллег потоком непроверенных изменений. Это тот уровень, на котором вас пускают в продакшн без надзора.

Уровень 3. Архитектор изменений. Решает с ИИ задачи, которые раньше считались неподъёмными или требовали года работы отдела: сквозной рефакторинг большой системы, перевод проекта с одного языка или фреймворка на другой, распутывание legacy, к которому десять лет боялись подходить. Здесь ИИ перестаёт быть ускорителем повседневных задач и становится инструментом трансформаций.

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

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

Блок 1. Инструментальный слой

Что входит. Уверенная работа с агентом в его среде: режимы запуска, слэш команды, headless и streaming для скриптов и CI, настройка проектного контекста через CLAUDE.md ^[1] с его иерархией, конфигурация через settings.json, оформление повторяющихся задач в Skills, управление сессиями и памятью агента.

Почему важно разработчику. Это фундамент, на котором стоит всё остальное. Разработчик, который каждый день заново объясняет агенту одно и то же в чате, тратит на это часы в неделю и получает нестабильный результат. Тот же человек, который один раз положил правила в файл проекта, получает предсказуемое поведение ^[21] и экономит время всей команды, потому что файл лежит в репозитории.

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

Пример. Рабочий минимум для CLAUDE.md ^[1] выглядит примерно так и умещается в экран.

# Биллинг

## Стек
TypeScript, NestJS, PostgreSQL, pnpm.

## Конвенции
Ошибки возвращаем через Result, исключения только на границе HTTP.
Даты форматируем через utils/date.ts, свои форматтеры не пишем.
Тест лежит рядом с кодом: user.service.ts и user.service.spec.ts.
Файлы в src/generated не трогаем.

## Команды
Тесты: pnpm test
Линтер: pnpm lint --fix

Всё, что длиннее этого, скорее всего должно быть не здесь, а в Skills, которые подгружаются под конкретную задачу.

Как научиться. Начните с раздела про память проекта ^[22]: там иерархия CLAUDE.md ^[1], правила с привязкой к путям и авто память. Сразу обратите внимание ^[23] на предупреждение о длине, потому что почти все пишут слишком много: файлы за двести строк съедают контекст и снижают следование инструкциям, а команда /doctor умеет предлагать, что из файла выбросить. Дальше упражнение на вечер: возьмите рабочий репозиторий, напишите для него CLAUDE.md ^[1] с реальными конвенциями и неделю дописывайте туда всё, что приходится объяснять агенту повторно. Когда упрётесь, откройте полный индекс документации ^[24] и посмотрите, сколько разделов вы ни разу не открывали.

Как рассказать на собеседовании. Плохой ответ звучит как «пользуюсь Claude Code, ну, обычно». Хороший ответ показывает систему: расскажите, что у вас в CLAUDE.md ^[1], почему именно эти правила там оказались и какие вы оттуда убрали, потому что они не работали. Отдельно ценится, если вы можете объяснить, что вынесли в Skills и почему именно это.

Блок 2. Управление контекстом сессии

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

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

На практике. Вы третий час разбираете баг в проде. В контекст успели попасть вывод тестов на тысячу строк, два лога и три отменённых варианта решения. Агент начинает предлагать то, что вы забраковали час назад. Правильная реакция ^[25] не в том, чтобы объяснить ему ещё раз, а в том, чтобы вынести исследование в отдельного субагента с чистым контекстом и вернуть в основную сессию только вывод, а не весь путь к нему.

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

# форк сессии: копия со всей историей, оригинал остаётся нетронутым
claude --resume <session-id> --fork-session

Второй приём требует файла. Субагент это markdown с заголовком в формате YAML, который лежит в .claude/agents/ проекта:

---
name: explorer
description: Исследует кодовую базу и возвращает выжимку. Использовать перед правкой незнакомого модуля и для поиска мест использования.
tools: Read, Grep, Glob
model: haiku
---

Ты исследуешь код и никогда его не меняешь.

Порядок работы:
1. Найди релевантные места по запросу.
2. Прочитай только то, что нужно для ответа.
3. Верни выжимку: список файлов с номерами строк, краткое описание контракта, замеченные несоответствия.

Не пересказывай содержимое файлов целиком. Ответ не длиннее двадцати строк.

Дальше вызываете его явно: «Используй субагента explorer, чтобы найти все вызовы OrderService.cancel». Тяжёлое чтение произойдёт в его контексте, а в вашу сессию вернутся двадцать строк вместо тридцати прочитанных файлов. Ограничение списка инструментов здесь не косметика: если в наборе нет инструментов записи, править файлы по дороге агенту просто нечем.

Как научиться. Понаблюдайте за собой неделю: отмечайте момент, когда качество ответов поехало, и что этому предшествовало. Обычно виноваты три вещи: длинный вывод тестов или логов, попытка решить в одной сессии две несвязанные задачи и долгий спор по кругу. Дальше освойте два инструмента. Первый это субагенты ^[26], чтобы шумная подзадача жила в своём контексте, а в основную сессию возвращался только вывод. Второй это управление сессиями ^[27], где разобраны форк, возврат к прошлым сессиям и то, где физически лежат транскрипты. Приёмы сжатия истории вынесены в блок про экономику, потому что это в первую очередь вопрос цены длинной сессии. Про сесcии еще поговорим в блоке 11.

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

Блок 3. Постановка задачи и планирование

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

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

На практике. Задача «добавить экспорт отчётов в CSV». Плохой заход: отдать её одной фразой и получить тысячу строк, где выгрузка собирает весь отчёт в память, потому что про объёмы никто не сказал. Хороший заход занимает десять минут: согласовать сигнатуру функции, решить, пишем потоком или целиком, договориться, где появится файл и что происходит при выборке на миллион строк. После этого код можно просить срезами, и каждый срез будет проверяемым.

Пример. Вот как выглядит план целиком. Он лежит в файле, согласуется с агентом до первой строки кода и занимает один экран.

# План: выгрузка отчёта в CSV

## Ограничения
Отчёт может содержать миллионы строк, в память целиком не собираем.
Формат совместим с Excel, разделитель точка с запятой.

## Сигнатуры
exportCsv(reportId: ReportId, out: Writable) -> Promise<void>
CsvWriter.writeRow(row: ReportRow) -> void

## Файлы
+ src/export/csv-writer.ts        новый, потоковая запись
+ src/export/csv-writer.spec.ts   новый
~ src/report/report-service.ts    добавляем exportCsv
~ src/http/report-controller.ts   новый маршрут

## Дерево вызовов
  httpController.exportReport
+   ReportService.exportCsv
+     CsvWriter.writeRow (по строке, без сборки в память)
      ReportRepo.streamRows (курсор)

## Срезы
1. Эндпоинт отдаёт файл из трёх захардкоженных строк
   проверка: curl возвращает валидный csv
2. Строки берутся из репозитория, пока целиком в память
   проверка: выгрузка реального отчёта на сто строк
3. Потоковая запись через курсор
   проверка: отчёт на миллион строк не роняет память
4. Ошибки, отмена запроса, пустой отчёт
   проверка: тесты на краевые случаи

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

Что такое срез и как получить его от модели

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

Посмотрите на раздел «Срезы» в плане выше. После каждого пункта систему уже можно потрогать: сначала на заглушке, потом на реальных данных, потом на потоке. Если на втором срезе станет ясно, что схема данных не та, вы потеряете двадцать минут, а не полтора дня.

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

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

Дальше просите строго по одному, и обязательно с явной остановкой, потому что по умолчанию модель постарается доделать всё до конца:

Сделай только первый срез. Захардкодь данные, репозиторий пока не трогай. После этого остановись и покажи diff, дальше не иди.

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

Как научиться. Возьмите следующую среднюю задачу и запретите себе просить код, пока не согласуете три вещи: типы и сигнатуры, список создаваемых и изменяемых файлов, дерево вызовов. Дальше просите реализацию срезами и смотрите на результат после каждого. По формулировкам полезен гайд по промпт инжинирингу ^[28]: ясность инструкций, примеры, ограничения формата вывода. По процессной части документации нет, зато есть эссе Декса Хорти «Why Software Factories Fail», где подробно разобраны вертикальные срезы и планирование до кода.

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

Блок 4. Стандарты кодирования и архитектура

Что входит. Кодификация правил проекта в контекст агента. Формулировка правил так, чтобы им можно было следовать и их можно было проверить. Согласование архитектуры до генерации: контракты, схемы данных, взаимодействие компонентов. Спуск на уровень program design перед реализацией. И понимание, что правило в файле контекста и правило в линтере это разные по силе вещи.

Почему важно разработчику. Вот ключевая мысль всего списка. У модели нет надёжного механизма долгосрочной оценки архитектурных решений. Хорошие архитектуры она видела в обучении ^[29] в изобилии, человеческие предпочтения в её обучении тоже присутствуют, и на отдельно взятом файле результат бывает отличным. Проблема в другом: поддерживаемость проявляется на горизонте месяцев, и обратной связи такой длины в обучении нет, а привычные критерии вроде прохождения тестов её не улавливают. Поэтому на практике архитектура попадает в код одним из двух путей: либо вы отдали её модели заранее, либо поймали её отсутствие на ревью. Расчёт на то, что она сама разложится красиво, иногда оправдывается, но полагаться на это в проекте, который вам ещё поддерживать, я бы не стал.

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

Откуда это известно. Тезис про то, что модель не отвечает за архитектуру, не мой. Подробнее всего его разобрал Декс Хорти в докладе и эссе «Why Software Factories Fail». Если совсем коротко, логика ^[30] такая: обучение с подкреплением ^[31] требует быстрого и надёжного критерия качества, а такого критерия для поддерживаемости пока нет, в отличие от прохождения тестов. Разрыв в обратной связи тут принципиальный: тесты дают ответ за секунды, а цена архитектурного решения проявляется через месяцы, и связать одно с другим на практике почти не удаётся. Отсюда его вывод, с которым можно спорить, но который стоит проверить на своём опыте ^[32]: обвязка вокруг модели эту проблему не закрывает, человека приходится возвращать в контур планирования и ревью. Разбору этой работы вместе с данными, которые в ней приводятся, я посвящу отдельную статью, здесь ограничусь этим резюме.

На практике. Возьмём простое правило: не трогать сгенерированные файлы. Записанное в CLAUDE.md ^[1], оно будет выполняться почти всегда. Именно почти: в длинной сессии, в неоднозначной ситуации или под давлением задачи модель может его нарушить. То же самое правило, оформленное как PreToolUse hook, который отклоняет запись по маске пути, срабатывает независимо от того, что решила модель, потому что это код, а не просьба. Разница между «обычно соблюдается» и «не зависит от решения модели» это и есть разница между инструкцией и гарантией.

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

Записанное в контекст, правило звучит так:

<!-- CLAUDE.md -->
HTTP слой обращается только к сервисам. Импортировать репозитории
и сущности в src/http нельзя. Если в сервисе нет нужного метода,
добавь метод в сервис, а не обходи слой.

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

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

{
  "overrides": [
    {
      "files": ["src/http/**"],
      "rules": {
        "no-restricted-imports": ["error", {
          "patterns": [
            {
              "group": ["**/repo/**", "**/entities/**"],
              "message": "HTTP слой работает через сервисы. Добавьте метод в сервис."
            }
          ]
        }]
      }
    }
  ]
}

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

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

Как научиться. Здесь нет обходного пути мимо классики: Ousterhout “A Philosophy of Software Design” и Fowler “Refactoring” дают язык, на котором вообще можно формулировать правила. Практическое упражнение: перепишите свой CLAUDE.md ^[1], превратив размытые формулировки в проверяемые, где «пиши чистый код» становится «функции короче тридцати строк, никаких any, ошибки возвращай явным типом». Дальше самое важное: разнесите правила по механизмам. Документация по памяти проекта ^[22] прямо говорит, что эти файлы Claude трактует как контекст, а не как принудительную конфигурацию, и чтобы заблокировать действие независимо от решения модели, нужен PreToolUse hook. Как их писать, смотрите в справочнике по хукам ^[33], а что куда класть, разобрано в официальной статье про ^[26]CLAUDE.md ^[1], Skills, хуки и субагентов ^[26].

Как рассказать на собеседовании. Это ваш звёздный момент. Расскажите, как вы передаёте архитектурные решения агенту и что вы делаете с правилами, которые он всё равно нарушает. Мысль «правило в промпте это пожелание, правило в CI это гарантия» на собеседовании звучит очень зрело, потому что показывает понимание разницы между вероятностным и детерминированным поведением.

Блок 5. Ревью и контроль качества

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

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

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

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

Как научиться. Заведите привычку смотреть diff после каждого среза, а не в конце дня. Дальше возьмите список вопросов ниже как стартовый и дополняйте его тем, что регулярно делает именно ваш агент на именно вашем проекте. Скорее всего он окажется короче, чем кажется: набор типичных промахов на конкретном проекте обычно повторяется. Дальше подключите механику из документации, чтобы рутинная часть проверок не зависела от вашей внимательности. Основной инструмент здесь это хуки ^[33]: в справочнике перечислены события жизненного цикла, на которые можно повесить свой скрипт, и для ревью интересны два. PostToolUse срабатывает после каждой правки файла, на него вешают линтер и тесты. PreToolUse срабатывает до вызова и умеет его отклонить, если скрипт завершится с кодом два. Настраивается всё в файлах настроек через сопоставление по имени инструмента.

Два хука, которые стоит поставить сразу

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

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path // empty' | xargs -r npx eslint --fix"
          }
        ]
      }
    ]
  }
}

#!/usr/bin/env bash
# .claude/hooks/protect-tests.sh
path=$(jq -r '.tool_input.file_path // empty')

case "$path" in
  *.test.ts|*.spec.ts|*_test.py|*/tests/*)
    echo "Правка тестов в этой задаче запрещена. Если тест действительно неверен, скажите об этом явно." >&2
    exit 2
    ;;
esac
exit 0

Одна оговорка: имена полей во входном JSON и набор событий меняются от версии к версии, поэтому перед тем как копировать эти примеры, сверьтесь со справочником по хукам ^[33]. Проверить готовый хук проще всего так: сделайте заведомо запрещённое действие руками и убедитесь, что оно отклонено.

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

Блок 6. Отладка кода, который писал не ты

Что входит. Умение отделить баг в сгенерированном коде от ситуации, когда агент неправильно понял задачу. Анализ трейса сессии, чтобы понять, что именно он сделал и почему. Способность залезть в код руками, когда агент застрял.

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

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

Пример. Разбор неудачного захода начинается не с нового промпта, а с чтения того, что вообще произошло.

claude --resume    # вернуться в нужную сессию и просмотреть её ход
/doctor            # проверить, какие файлы правил подгрузились в эту сессию

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

Транскрипты сессий лежат локально:

# macOS / Linux
~/.claude/projects/<project>/<session-id>.jsonl

# Windows
%USERPROFILE%.claudeprojects<project><session-id>.jsonl

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

Как научиться. В следующий раз, когда агент выдаст неработающее решение, не бросайтесь переспрашивать. Сначала сформулируйте гипотезу: он ошибся в реализации или не понял, что от него хотят. От ответа зависит, чинить код или переписывать постановку. Дальше научитесь работать с самой сессией, для этого нужны три раздела документации. В слэш командах ^[34] лежит рабочий инструментарий отладки: возврат к предыдущему состоянию, сжатие истории, встроенная диагностика конфигурации и просмотр того, какие файлы правил вообще подгрузились в эту сессию. Интерактивный режим ^[35] описывает горячие клавиши и приёмы навигации по длинной сессии, включая прерывание агента на середине неудачного захода, что дешевле, чем ждать окончания и разбирать результат. А управление сессиями ^[27] объясняет, где физически лежат транскрипты, как вернуться к нужной сессии по имени или по номеру пул реквеста и как форкнуть её, чтобы проверить альтернативную гипотезу, не потеряв основную линию разбора.

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

Блок 7. Тестирование

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

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

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

Пример. Проверка нового теста на осмысленность занимает тридцать секунд.

git stash push -- src/                 # убираем только код, тесты остаются
pnpm test src/export/csv-writer.spec.ts # новый тест обязан упасть
git stash pop

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

Как научиться. Правило первое: ни один срез не считается готовым, пока вы не потрогали его снаружи. Правило второе: проверяйте, что новый тест падает на старом коде, иначе он не тестирует ничего. Чтобы это не держалось на одной дисциплине, повесьте прогон тестов и линтера на событие PostToolUse из справочника по хукам ^[33]: хук срабатывает всегда, в отличие от намерения модели проверить свою работу.

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

Блок 8. Legacy и чужая кодовая база

Что входит. Введение агента в незнакомый проект с объяснением существующих конвенций. Требование сначала исследовать код, потом менять. Подавление склонности агента тянуть паттерны из обучения вместо паттернов проекта. И работа с кодом, который несколько месяцев назад написал другой агент.

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

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

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

CLAUDE.md                    общее для репозитория
packages/api/CLAUDE.md       конвенции сервиса
packages/ui/CLAUDE.md        конвенции фронтенда

Это работает, пока конвенция привязана к каталогу. Но часть правил режет поперёк структуры: все тестовые файлы, все места, где обрабатываются деньги, весь Terraform в инфраструктуре. Заводить под это отдельный CLAUDE.md ^[1] в каждом каталоге неудобно, и вместо этого используется правило с glob по пути, оформленное тем же YAML заголовком, что и в файле субагента:

---
paths:
  - "services/billing/**"
---

# Правила биллинга

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

Файл лежит в .claude/rules/ и подхватывается только тогда, когда агент открывает файл внутри services/billing, а не висит в контексте постоянно. У этого механизма есть подтверждённая шероховатость: поле paths в некоторых конфигурациях документировано, но ведёт себя ненадёжно, а более стабильной заменой на практике оказывается недокументированное поле globs. Прежде чем полагаться на путь как на гарантию, проверьте через /memory, что правило вообще загрузилось в текущую сессию.

А перед правкой незнакомого модуля работает простой запрос, после которого сразу видно, правильно ли агент понял устройство кода:

«Опиши, как устроен модуль orders, какие в нём приняты конвенции и что уже реализовано рядом. Код пока не меняй».

Как научиться. Перед изменениями в незнакомом коде просите агента сначала описать, как устроен нужный участок и какие конвенции он видит. Это стоит двух минут и резко снижает количество чужеродных решений, а заодно сразу показывает, если он неправильно понял устройство проекта. Для монорепозитория освойте правила с привязкой к путям и импорты через @path ^[36], чтобы для каждого пакета подгружались свои конвенции, а не общий свод на все случаи: это описано в разделе про память проекта ^[22].

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

Блок 9. Git и управление изменениями

Что входит. Мелкие коммиты, чтобы было куда откатиться. Умение читать большой diff за один заход. Изоляция экспериментов агента в ветках. Понимание момента, когда дешевле откатить всё и переформулировать задачу, чем чинить сделанное.

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

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

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

git commit -am "точка перед выгрузкой отчётов"

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

> Сделай третий срез: потоковая запись через курсор.
Остановись после этого и покажи diff.

● Изменяю csv-writer.ts, report-service.ts, report-repo.ts
Тесты проходят.

Смотрим diff и видим проблему, которую тесты не поймали: курсор открывается заново на каждой строке. Формально работает, на миллионе строк ляжет база. Правку в таком виде принимать нельзя, но и разбирать её руками смысла нет, проще откатиться и переформулировать:

Вернуть только файлы Вернуть только диалог Вернуть файлы и диалог

> /rewind

Вернуть только файлы
Вернуть только диалог
Вернуть файлы и диалог


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

> Тот же срез, но курсор открывается один раз на всю выгрузку.
Проверь это тестом на десяти тысячах строк.

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

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

Как научиться. Правило из примера выше входит в привычку примерно за неделю, дальше вы перестаёте о нём думать. Механика чекпойнтов, включая то, какие именно изменения они охватывают и чего не покрывают, описана в отдельном разделе документации ^[37], и прочитать его стоит до того, как вы на них понадеетесь.

Как рассказать на собеседовании. Тут достаточно показать, что вы вообще об этом думаете. Фраза «коммичу перед тем, как отдать агенту большую задачу, чтобы откат стоил одну команду» звучит буднично и убедительно.

Блок 10. Понимание сильных и слабых сторон инструмента

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

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

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

Пример. Четыре типовых расклада, на которых граница видна лучше всего. Это не редкие случаи, а ситуации, которые встречаются почти в каждом проекте.

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

• Разбор незнакомой библиотеки. Тоже сильная сторона, и этот расклад ломает популярное правило «не отдавай то, в чём не разбираешься». Ломает по понятной причине: предложенный пример достаточно запустить и посмотреть, работает ли он. Незнание темы опасно не само по себе, а только в связке с дорогой проверкой.

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

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

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

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

Блок 11. Экономика решений

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

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

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

Пример. Механическая работа не должна идти по той же цене, что и написание кода.

# разбор лога это работа для дешёвой модели
cat app.log | claude -p "Типы ошибок и их частота" --model haiku

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

import anthropic

client = anthropic.Anthropic()

# правила миграции, общие для всех файлов, помечаем как кешируемые
system = [{
    "type": "text",
    "text": open("migration-rules.md").read(),
    "cache_control": {"type": "ephemeral"},
}]

requests = [
    {
        "custom_id": f"file-{i}",
        "params": {
            "model": "claude-sonnet-4-6",
            "max_tokens": 4096,
            "system": system,
            "messages": [{
                "role": "user",
                "content": f"Перепиши модуль по правилам:nn{src}",
            }],
        },
    }
    for i, src in enumerate(sources)
]

batch = client.messages.batches.create(requests=requests)

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

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

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

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

Подробности в разделах про кеширование промптов ^[38] и пакетную обработку ^[39].

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

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=4096,
    thinking={"type": "adaptive"},
    output_config={"effort": "medium"},
    messages=[{"role": "user", "content": "..."}],
)

Как научиться. Посмотрите на свой реальный расход за неделю и на то, какие задачи его дали. У меня обычно выяснялось, что львиную долю съели несколько заходов, где стоило остановиться и переписать постановку, а не повторять ^[41] запрос. Дальше разберитесь с механикой: учёт токенов, оценка стоимости и настройка кеширования промптов ^[42]. Заодно загляните во frontmatter своих субагентов и проверьте, какая модель им прописана: разведчику, который только читает и ищет, незачем работать по верхнему тарифу. И держите в голове нюанс, о котором редко говорят: у субагента свой контекст, поэтому суммарный расход токенов от их использования может даже вырасти. Выигрыш в другом: основная сессия остаётся чистой, вы реже упираетесь в сжатие истории, а дорогая модель не тратится на чтение того, что способна прочитать дешёвая.

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

Блок 12. Безопасность рабочей среды

Что входит. Отсутствие продовых ключей и данных на машине, где работает агент. Понимание рисков агента с доступом к шеллу. Изоляция среды выполнения. Проверка, что секреты не утекли в код. Минимальные привилегии для инструментов агента.

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

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

Пример. Начнём с того, где вообще живут настройки, потому что от этого зависит, на кого они действуют.

.claude/settings.json         настройки проекта, в git, на всю команду
.claude/settings.local.json   ваши личные, добавляются в .gitignore
~/.claude/settings.json       ваши настройки для всех проектов

Внутри объекта permissions три списка, и разница между ними принципиальная. Правила проверяются в порядке deny, затем ask, затем allow, и побеждает первое совпадение. Всё, что не совпало ни с одним правилом, обрабатывается по режиму сессии.

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(cat ./.env*)"
    ],
    "ask": [
      "Bash(git push:*)",
      "Bash(npm publish:*)",
      "Bash(psql:*)"
    ],
    "allow": [
      "Bash(pnpm test:*)",
      "Bash(pnpm lint:*)",
      "Bash(git status)"
    ]
  }
}

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

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

Настоящая граница проходит уровнем ниже, в изоляции, где ограничения обеспечивает операционная система:

{
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "denyRead": ["~/.ssh", "~/.aws", "~/.gnupg"]
    }
  }
}

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

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

#!/usr/bin/env bash
# .claude/hooks/guard-bash.sh, событие PreToolUse
cmd=$(jq -r '.tool_input.command // empty')

if echo "$cmd" | grep -Eq 'rm -rf|push --force|DROP TABLE'; then
  echo "Команда заблокирована политикой репозитория: $cmd" >&2
  exit 2
fi
exit 0

И последнее, про что почти все забывают ^[43]. Каждый раз, когда вы нажимаете «разрешить и больше не спрашивать», в ваши локальные настройки дописывается постоянное правило. За месяц работы их накапливаются десятки, и вы о них не помните. Команда /permissions показывает текущий список целиком, и заглядывать туда стоит хотя бы раз в пару недель.

/security-review

# .github/workflows/security-review.yml
name: Security Review
on: [pull_request]
jobs:
  security-review:
    runs-on: ubuntu-latest
    steps:
      - uses: anthropics/claude-code-security-review@main
        with:
          claude-api-key: ${{ secrets.CLAUDE_API_KEY }}

Как научиться. Начните с инвентаризации: какие ключи и доступы лежат в окружении, где работает агент, и какие из них реально нужны для задачи. Дальше пропишите запреты в файлах настроек ^[45], помня, что запреты вычисляются раньше разрешений, то есть закрытый путь становится для агента невидимым. Опасные команды блокируйте хуком на PreToolUse из справочника ^[33], а сам периметр поднимайте по разделу про изоляцию ^[46]: там разобрано, что именно ограничивается на уровне операционной системы и почему это надёжнее правил внутри приложения. И держите в голове границу из блока про стандарты: правила разрешений и изоляция это гарантии, а всё, что живёт в тексте инструкций, ими не является, о чём прямо пишет и сам вендор ^[26]. Про сканирование уязвимостей и его настройку в CI смотрите официальный анонс ^[47].

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

Блок 13. Командная работа

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

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

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

Пример. Разделение общего и личного в репозитории команды.

CLAUDE.md                     конвенции проекта, в git, проходит ревью
.claude/settings.json         общие запреты и хуки, в git
.claude/settings.local.json   личные настройки, в .gitignore
.claude/hooks/                скрипты проверок, в git
.claude/skills/               общие процедуры команды, в git

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

Из таблицы стоит запомнить одно исключение: массивы allow и deny в разных уровнях не замещают друг друга, а складываются, так что разрешение в личных настройках и разрешение в проектных действуют одновременно. А вот запрет на managed‑уровне складывается с остальными, но проигранным не бывает никогда: если администратор запретил Bash(rm -rf *), ни личный, ни проектный allow этого не отменят.

Главное правило простое: если правило важно для всех, оно лежит в git и проходит ревью как обычный код. Если оно живёт только на вашей машине, его нет.

Как научиться. Начните с общего файла правил в репозитории вместо личных настроек и проводите его через ревью как обычный код. Дальше два шага для организации: управляемые политики, которые администратор разворачивает централизованно и которые нельзя переопределить локальной настройкой, и упаковка общего набора Skills, субагентов и хуков в плагин, чтобы конфигурация ставилась одной командой. Оба механизма описаны в официальной статье ^[26] и в справочнике по плагинам ^[48].

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

Блок 14. Документация

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

Почему важно разработчику. У модели есть момент отсечки в обучении, и всё, что она «знает» про конкретную библиотеку, заморожено на этой дате. Библиотека тем временем продолжает жить: меняются сигнатуры, ломаются старые параметры, выходят мажорные версии. Модель об этом не предупредит, потому что не видит разницы между актуальным знанием и устаревшим, и код на основе старого API напишет так же уверенно, как и правильный. Это тот же принцип слепоты к тому, чего нет в контексте, что и в блоке про сильные и слабые стороны инструмента, только здесь речь не про ваш код, а про внешний мир.

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

На практике. Классический сценарий: попросили агента подключить библиотеку, которую он «знает» по обучению. Пакет с тех пор выпустил мажорную версию с несовместимым интерфейсом. Модель уверенно пишет код по старому API, компилируется без ошибок, а в рантайме падает или тихо работает не так, как задумано. Диагностировать сложно именно потому, что код выглядит совершенно разумным, просто написан для версии, которой уже нет.

Пример. Вместо того чтобы спрашивать напрямую «подключи библиотеку X», сначала подтянуть в контекст её актуальное состояние.

Прочитай https://example.com/docs/v3/migration ^[49] и только после этого напиши интеграцию с API. Не используй сигнатуры из версии до v3.

Инструмент для этого в Claude Code называется WebFetch: он забирает конкретную страницу и предпочитает Markdown, если сервер это поддерживает. Второй инструмент, WebSearch, находит страницы, а прочитать их всё равно придётся через WebFetch. Полезная деталь: у многих сайтов документации, включая документацию самого Claude Code, есть файл llms.txt, машиночитаемый индекс страниц специально для таких случаев, и указать агенту на него часто быстрее, чем на весь сайт целиком.

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

Добавь параметр timeout в exportCsv. В диффе обнови докстринг функции и раздел README про экспорт, если сигнатура изменилась.

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

---
name: docs-auditor
description: Сверяет документацию с фактическим кодом.
  Использовать периодически, перед релизом или когда
  накопились жалобы на устаревшую доку.
tools: Read, Grep, Glob
model: haiku
---

Сравни README и docs/ с фактическим кодом в src/.
Перечисли расхождения: сигнатуры, которые изменились,
но не отражены в доке, и примеры кода в доке, которые
больше не работают.

Не исправляй сам. Верни список для ревью.

Как научиться. Заведите привычку: прежде чем просить интеграцию с чем‑то внешним, спросите себя, менялось ли это после вашего последнего изучения темы, и если не уверены, дайте агенту актуальную страницу вместо того, чтобы доверять его памяти. Про сами инструменты и их ограничения, включая списки разрешённых и запрещённых доменов для WebSearch, смотрите в справочнике по инструментам ^[50]. Про формат llms.txt и то, как он устроен, можно почитать на llmstxt.org ^[51], это открытая инициатива, а не то, что придумал конкретный вендор.

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

Блок 15. Несколько агентов параллельно

Что входит. Запуск нескольких задач одновременно без потери контроля, предотвращение конфликтующих изменений в одних файлах, своевременное переключение и разбор результатов.

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

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

Пример. Разведение параллельных задач по рабочим деревьям, чтобы агенты не могли править одни и те же файлы.

git worktree add ../wt-export -b feat/export
git worktree add ../wt-search -b feat/search

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

claude --teammate-mode tmux

Как научиться. Когда почувствуете, что уверенно ведёте одну задачу, попробуйте вторую в отдельной ветке и на несвязанном участке кода. Пересечение файлов это первое, обо что все спотыкаются. Дальше посмотрите, как устроены субагенты и масштабирование на параллельные сессии ^[26], и загляните в справочник CLI ^[53], если собираетесь запускать агентов из скриптов, а не руками.

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

Выводы

Когда список был готов, стало видно то, ради чего я его и собирал.

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

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

Третье, и это ответ моим однокурсникам. Правы оказались все понемногу. Тот, кто говорил про формулировку запросов, описал блоки 3 и 4, только назвал их промптами. Тот, кто говорил про дисциплину отказа, описал блок 10. Тот, кто прислал двухсотстрочный CLAUDE.md ^[1], показал блок 1 и часть блока 4. А тот, кто считал, что тема надутая, ошибся ровно в одном: устаканится не само, устаканиваться придётся нам.

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

PS

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

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