Набор вопросов для собеседования по Vibe Coding / Agentic Flow

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

Адресаты: разработчики, которые ежедневно используют agentic CLI-инструменты вроде Claude Code, Codex и т. п., особенно те, кто хочет превратить программирование с ИИ из режима «человек ↔ чат» в инженерно выстроенный рабочий процесс.

Содержание

1. Блок фоновых знаний 2. Блок детализации 3. Блок рабочих потоков 4. Блок системного проектирования: открытая дискуссия 5. Блок концептуальной философии: открытая дискуссия 6. Приложение: рекомендуемый путь обучения 7. Ссылки

I, Блок фоновых знаний

Q1. Что такое /command? В чём разница между skill и command? Когда использовать command, а когда skill?

Рекомендованный ответ

/command, то есть Slash Command, — это механизм расширений ранних версий Claude Code. Пользователь может положить .md-файл в .claude/commands/, а затем вызвать его в диалоге, набрав /command-name. По сути это «фрагмент prompt, который явно вызывается пользователем».

Skill — это механизм расширений нового поколения, обычно располагающийся в .claude/skills/<name>/SKILL.md, ~/.claude/skills/ или в плагине. Основное отличие от command:

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

command по-прежнему можно использовать в редких простых случаях, например для легаси-активов команды или для некоторых строго вручную вызываемых prompt-обёрток. Но в новых проектах не рекомендуется продолжать активно опираться на command.

Q2. Что такое agent? Когда использовать agent, а когда skill?

Рекомендованный ответ

Agent, особенно Sub-agent, можно понимать как «небольшой Claude» с собственным system prompt, отдельным окном контекста и отдельным allowlist инструментов. В Claude Code sub-agent обычно задаётся через .claude/agents/<name>.md, а задачи ему передаёт основная сессия. После завершения задачи sub-agent возвращает только итоговый summary в основной диалог, и большой объём промежуточного поиска, чтения и логов не загрязняет основной контекст.

Skill — это набор инструкций или процедур. Он не создаёт новый контекст, а задаёт, как Claude должен действовать дальше в текущем диалоге.

Простое правило:

• Если задача — задать Claude рабочий регламент (например: «перед коммитом всегда запускай lint и тесты»), используйте skill.
• Если задача породит много вывода инструментов (чтение десятков файлов, запуск grep, анализ логов), используйте agent.
• Если нужно просто прочитать один известный файл, читайте его прямо в основном диалоге — поднимать agent не нужно.
• Если нужен полный ход рассуждений в основном диалоге, не отдавайте задачу sub-agent.

Q3. Что такое Sub-agent? Могут ли Sub-agent общаться между собой напрямую?

Рекомендованный ответ

Ключевая особенность sub-agent: отдельный контекст, отдельный набор инструментов и возврат только summary в основной диалог.

По умолчанию sub-agent не могут общаться напрямую. Их модель взаимодействия близка к звёздной: основной диалог — центр, а все sub-agent общаются только с ним. Если результат A должен дойти до B, обычно это делает центр (основной диалог).

У такого подхода есть преимущества:

• Консолидация информации в основном диалоге упрощает аудит пользователем.
• Исключает неконтролируемые циклы диалогов между агентами.
• Сдерживает рост затрат на контекст и инструментальные вызовы.

Экспериментальная модель Agent Teams может добавить обмен сообщениями между агентами на одном уровне, но это уже более сложная модель сотрудничества.

Q4. В чём главное различие Agent Team и Sub-agent?

Рекомендованный ответ

Sub-agent — это скорее «нанять временного исполнителя для конкретной задачи и получить отчёт». Обычно это разовый сценарий: основной диалог ставит задачу, sub-agent выполняет и возвращает summary.

Agent Team — это «сформировать длительную команду из нескольких участников». Каждый teammate может иметь отдельную роль, отдельный контекст и потенциально обмениваться сообщениями через механизм сообщений.

На практике для большинства повседневных задач sub-agent обычно достаточно. Agent Team ближе к исследовательской многoagent-кооперации, полезен для сложных проектов, но и сложнее в отладке.

Q5. Что такое MCP? Чем он отличается от API-интерфейсов?

Рекомендованный ответ

MCP, Model Context Protocol, — протокол, который представляет внешние инструменты, ресурсы и prompt в стандартизированном формате для клиентов LLM. MCP server может объявлять, какие tools, resources и prompts он предоставляет; после подключения клиент может автоматически их обнаружить и вызывать.

С API и MCP можно сравнить так:

Аналогия: API — это «кабель разного типа у каждого поставщика», а MCP — «USB-C для вызова LLM-инструментов».

Ключевая ценность MCP — не только перенос данных, но и наделение инструментов «самоописательностью»: модель знает, как называется инструмент, какие у него параметры, может ли он записывать, требует ли подтверждения, и решает, когда и как его вызвать.

Q6. Может ли sub-agent создавать своих собственных sub-agent?

Рекомендованный ответ

Обычно — нет. Sub-agent не должен запускать собственные sub-agent.

Такой дизайн направлен на исключение трёх проблем:

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

Если действительно нужно «вложенное делегирование», лучше:

• Распределять несколько sub-agent плоско из основного диалога.
• Внутри sub-agent использовать skill для организации шагов.
• Для крайне сложных задач рассмотреть Agent Team с чёткими границами и бюджетами.

II, Блок детализации

Q7. Что такое CLAUDE.md / AGENTS.md? Каков порядок загрузки и приоритет?

Рекомендованный ответ

CLAUDE.md и AGENTS.md можно рассматривать как «постоянную инъекцию prompt» на уровне проекта или пользователя. Они фиксируют правила, которые агент должен знать при каждом запуске: стиль кода, команды проверки, запрещённые файлы, требования к коммитам и т. д.

Типичные уровни:

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

• Перед изменением кода сначала прочитай соответствующие тесты.
• Не редактируй .env и файлы с секретами.
• После завершения обязательно запускай npm run typecheck.
• Не добавляй ненужные зависимости.

Практический опыт: лучше держать каждый файл максимум в пределах ~200 строк. Слишком длинные документы стоит разносить по отдельным файлам и связывать через ссылки.

Q8. Что такое Hooks? Приведите примеры распространённых hook-сценариев.

Рекомендованный ответ

Hook — это детерминированный callback, регистрируемый на событиях жизненного цикла Claude Code или похожих agentic-инструментов. Это не то, что модель «запомнит и выполнит», а принудительное выполнение средой инструмента.

Типичные события:

• Перед вызовом инструмента: например, блокировка опасных команд.
• После вызова инструмента: например, автоформатирование после изменения файлов.
• При старте сессии: например, инъекция текущего состояния git.
• При остановке: например, отправка уведомления на рабочий стол.

Распространённые сценарии:

Ценность hooks в их «детерминизме»: prompt может быть проигнорирован моделью, а hook — это уже ограничение на уровне инструмента.

Q9. Какие есть режимы Permission Mode и для чего они подходят?

Рекомендованный ответ

Permission Mode определяет, нужно ли подтверждение пользователя для чтения/записи файлов, выполнения команд и обращения к внешним инструментам.

По принципу: чем ближе к production, тем консервативнее доступ; чем ближе к изолированному разовому эксперименту или sandbox, тем шире разрешения.

Q10. Что сохраняется, а что теряется при /compact?

Рекомендованный ответ

/compact по сути сжимает диалоговый контекст. Он сохраняет часть high-priority информации, но не хранит полностью детали исторических вызовов инструментов.

Как правило, сохраняются или повторно инжектируются:

• System prompt.
• Проектные правила, например CLAUDE.md.
• Пользовательская или проектная memory.
• Сводка диалога.
• Часть high-priority описаний skill.

То, что обычно теряется:

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

Практический совет: не держите длительные ограничения только в чате. Ключевые правила лучше хранить в CLAUDE.md, AGENTS.md, memory, PROGRESS.md или проектной документации.

Q11. Каковы отношения между Plugin и Skill?

Рекомендованный ответ

Skill — это единица способности, Plugin — готовый распространяемый пакет расширений.

Plugin может включать:

• Несколько skills.
• Описания sub-agent.
• Hooks.
• MCP server.
• LSP server.
• Бинарные инструменты.
• Значения настроек по умолчанию.

Можно сказать так: skill — это деталь, plugin — собранный в комплекте набор инструментов. Если в команде есть стабильный AI-workflow, его можно упаковать в plugin, чтобы новым участникам установить его одной командой.

Q12. Что такое ToolSearch / Deferred Tools? Зачем это нужно?

Рекомендованный ответ

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

Причины такого подхода:

1. Экономия токенов: у крупного MCP server может быть десятки и сотни инструментов, а их полные схемы сильно потребляют контекст. 2. Снижение «шума внимания»: неактуальные инструменты в постоянном prompt мешают модели принимать решения. 3. Загрузка по требованию: детальные описания грузятся только при реальной необходимости.

Цена: при первом обращении к конкретному инструменту может возникнуть дополнительный round trip, но в среднем это выгоднее.

III, Блок рабочих потоков

Q13. Как разобрать задачу среднего уровня сложности на новый функционал с помощью agentic-инструментов?

Рекомендованный ответ

Типичный процесс:

1. Сначала перейти в plan mode и провести read-only исследование, не меняя код сразу. 2. Параллельно запустить Explore sub-agent для поиска по связанным файлам, входам, потоку данных и расположению тестов. 3. Основной диалог или Plan sub-agent формируют TDD-план: acceptance criteria, тест-кейсы, минимальная реализация, стратегия валидации. 4. Второй моделью или review agent провести cross-model review, закрывая blind spots. 5. На важных проектных развилках задавать вопросы пользователю, а не принимать решения с высоким риском автономно. 6. Выйти из plan mode в режим редактирования. 7. Сначала написать или обновить тесты, затем реализовать функциональность. 8. После реализации прогнать релевантные тесты, typecheck, lint. 9. Финально самопроверка через review skill или code-review agent.

Смысл процесса — не в том, чтобы «показать много агентов», а в разделении этапов: исследование, проектирование, реализация, валидация и разбор результатов.

Q14. Когда стоит запускать sub-agent, а когда не стоит?

Рекомендованный ответ

Стоит запускать sub-agent, если:

• Нужно прочитать более 10 файлов для исследования.
• Предстоит много grep/find и анализ логов.
• Требуется самостоятельный code review или security review.
• Есть несколько независимых параллельных подзадач.
• Вывод инструментов будет большим и нежелательным для основного контекста.

Не стоит запускать sub-agent, если:

• Задача требует 1–3 вызовов инструмента.
• Нужно лишь прочитать известный путь.
• Требуется частое подтверждение пользователя.
• Нужен полный поток рассуждений в основном диалоге.

Коротко: sub-agent подходит для задач «много поиска, много чтения, много логов», но не для «быстрых и коротких» задач.

Q15. Как избежать загрязнения контекста основного диалога?

Рекомендованный ответ

Контроль можно вести несколькими способами:

• Исследование и массовое чтение отдавать Explore sub-agent и оставлять только summary.
• Для длинных выводов команд использовать head, tail, grep, сжимая объём, а не закидывая в диалог тысячи строк логов.
• Повторяющиеся процессы упаковывать в skill, а не каждый раз вставлять большой блок правил вручную.
• После завершения этапа делать /compact.
• Ключевые длительные сведения записывать в CLAUDE.md, AGENTS.md, memory или PROGRESS.md.
• Не заставлять агент многократно читать один и тот же файл; состояние фиксируется через diff, тесты и контроль версий.

Главный принцип: полезность контекста — это не его размер, а сигнал/шум.

Q16. Как с помощью agentic-инструментов отлаживать баги в коде?

Рекомендованный ответ

Более надёжная последовательность:

1. Не спешить менять код, сначала воспроизвести баг. 2. Написать стабильно падающий минимальный тест или кейс. 3. Убедиться, что тест действительно падает и проблема понята. 4. Через Explore найти файлы, связанные с путём возникновения ошибки. 5. Сформулировать гипотезы и проверять их по одной, а не лихорадочно патчить. 6. После фикса прогнать релевантные тесты. 7. В конце — полный или критический набор валидаций. 8. Если агент неоднократно не может исправить проблему, сменить контекст и попросить другой модельный взгляд.

Главная проблема agent-отладки — «исправление методом проб и ошибок». Без воспроизводимого кейса модель быстро начинает разносить код сильнее, чем лечит.

Q17. Как внедрить agentic-рабочий процесс на уровне команды в репозитории с несколькими участниками?

Рекомендованный ответ

Ключевое — превратить личный опыт в активы репозитория.

Командный слой может включать:

• Корневой CLAUDE.md / AGENTS.md: жёсткие правила команды.
• .claude/skills/: общие workflows.
• .claude/agents/: общие sub-agent.
• .claude/settings.json: общие settings для permission, hooks, whitelist инструментов.
• Шаблоны PR: требование фиксировать ключевые AI-решения и команды проверки.

Личный слой:

• CLAUDE.local.md: личные предпочтения, обычно не коммитится.
• .claude/settings.local.json: локальные переопределения прав.

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

IV, Блок системного проектирования: открытая дискуссия

Ниже вопросы без стандартного ответа; фокус в развитии рамки выбора и осознании рисков.

Q18. Спроектируйте agentic low-code платформу. Какие принципы сначала определить?

Направления для обсуждения

Сначала нужно определить source of truth. Что является авторитетным: код, сгенерированный агентом, или low-code DSL? Двунаправленная синхронизация звучит красиво, но на практике часто превращается в инженерный хаос.

Также нужно учесть:

• Обратимость и контроль версий: после того как агент изменил 50 компонентов за раз, это должно быть diff-нуемо, revert-нуемо и review-нуемо.
• Песочница и многоуровневая авторизация: пользователи платформы не должны напрямую ходить в базу данных, нужен permissions gateway.
• Подача контекста: как предметные знания попадают в агент? Через ручные правила пользователя или автоматическую экстракцию из существующей документации?
• Наблюдаемость сбоев: если agent вызвал внешний API или MCP и получил ошибку, должен быть replay.
• Подтверждение критичных решений: не заменять мышление пользователя, критические действия требуют явного подтверждения.
• Прозрачность стоимости: для каждой операции должны быть видны token, API-вызовы и задержки.

Качественная agentic low-code платформа — это не «волшебная кнопка», а аудируемая, откатываемая и композиционная инженерная система.

Q19. Спроектируйте корпоративный MCP gateway: как решать права, аудит, rate limiting?

Направления для обсуждения

Минимальный набор задач для enterprise MCP gateway:

• Права: разные роли видят разные инструменты. Роль «только чтение» не должна получать схему инструментов delete_*.
• Аудит: каждый tool call логируется с user, agent_id, параметрами, размером ответа, временем и статусом результата.
• Ограничение частоты: лимиты QPS, параллелизма и суточных вызовов по пользователю и agent.
• Маскирование данных: перед передачей в agent убирать PII, ключи и внутренние чувствительные поля.
• Деградация: при сбое backend возвращать структурированную ошибку, а не зависать бесконечно.
• Управление версиями: изменения схему tool должны иметь версии, чтобы старые клиенты не ломались внезапно.
• Изоляция арендаторов: у разных команд и проектов инструменты и данные должны быть изолированы.

Суть MCP gateway — не «подключить больше инструментов», а «безопасно дать модели возможность их использовать».

Q20. Какую модель мультиагентного сотрудничества выбрать: звезду или mesh? Почему?

Направления для обсуждения

Звёздная структура проста, контролируема и хорошо аудитируется: основной диалог в центре, все sub-agent докладывают туда. Недостаток — центральное звено становится bottleneck, ограничивая параллелизм.

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

• Возможны циклы между агентами.
• Риск взрыва контекста.
• Нечёткие границы ответственности.
• Существенный рост сложности отладки.

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

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

Q21. Спроектируйте AI security review agent. Какие ошибки нужно избегать?

Направления для обсуждения

Безопасность проверяет не только diff. Многие уязвимости возникают в цепочке вызовов и контексте, а не в нескольких изменённых строках текущего PR.

Дополнительно важно избегать:

• Слепая вера в passing тестов: именно зоны вне покрытия обычно и дают много уязвимостей.
• Выполнение атакующих команд самим review-агентом: на этапе review лучше оставаться read-only, чтобы не создать новую атакующую поверхность.
• Стремление к нулю false positive: лучше разумные ложные срабатывания, чем пропуск критичных уязвимостей.
• Отсутствие градации: нужно явно различать P0, P1, P2, чтобы фокусировать ручной review.
• Непонятность выводов: нельзя просто писать «unsafe», нужно объяснять, почему опасно, какой уязвимостью и как исправлять.

Надёжнее: один агент делает review, второй кросс-чекит, итог принимает человек.

Q22. Спроектируйте механизм долгосрочной памяти: что помнить, что не помнить?

Направления для обсуждения

Следует запоминать:

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

Не стоит запоминать:

• Одноразовые временные диалоги.
• Содержимое с чувствительными данными.
• Устаревшие статусы багов.
• Недостаточно проверенные предположения о долгосрочной значимости.

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

V, Концептуальная философия: открытая дискуссия

Q23. Почему нужно держать context простым? Разве не лучше «засыпать» его максимально полезной информацией?

Направления для обсуждения

Ценность context не в его длине, а в сигнал/шуме.

Слишком «переполненный» контекст приводит к:

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

Хороший context — это не «меньше данных», а «только то, что реально нужно именно сейчас».

Q24. Агент должен быть proactive или reactive? Когда спрашивать пользователя, а когда решать самому?

Направления для обсуждения

Можно опираться на три критерия:

1. Обратимость действия: обратимые локальные изменения можно решать самостоятельно; push, delete, send email — обязательно спрашивать. 2. Радиус влияния: локально на машине — можно действовать активнее; на команду, production или клиентов — осторожно. 3. Неопределённость: если модель не уверена, лучше спросить, чем «ставить всё на удачу».

Хороший агент не «всё время спрашивает» и не «никогда не спрашивает», а задаёт правильные вопросы: по важным развилкам, а мелкие вопросы не дожимает.

Q25. Vibe Coding — это hype или смена парадигмы?

Направления для обсуждения

Скептики (hype) утверждают: это лишь более умная автодополнение. В сложных проектах агент по-прежнему делает глупые ошибки, а эксплуатационные расходы недооцениваются.

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

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

Ключевые вопросы для обсуждения:

• Если код пишет агент, где накапливаются знания: в репозитории, документации, тестах или в голове разработчика?
• Не станет ли review важнее самого написания кода?
• Как изменятся entry-level роли и обучение программированию?

Q26. Если агент много раз подряд не чинит баг, продолжать его пытаться или отключить и подключить себя?

Направления для обсуждения

Если агент повторяет одну и ту же неверную гипотезу несколько раз, вероятно, контекст загрязнён. Продолжать «сжигать» токены часто только углубляет тупик.

Лучше:

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

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

Q27. Почему TDD в agentic-потоке важнее, чем в традиционном?

Направления для обсуждения

Агент склонен уверенно писать неправильно: он может ошибиться в API, полях, возвращаемых значениях. Тесты — один из немногих объективных механизмов проверки фактического выполнения задачи.

В agentic-потоке TDD особенно ценен, потому что:

• Тест — это контракт коммуникации с агентом.
• Падающий тест даёт чёткий цикл обратной связи.
• Тест переводит размытые требования в исполнимую спецификацию.
• Acceptance-тесты защищают от «казалось, что сделано, но на деле не сделано».

Но важно: не стоит полностью отдавать агенту цикл «он написал тест → он написал реализацию → он сам отметил pass». Критичные acceptance и security-тесты лучше писать человеку или независимому второму модели для review.

Q28. Что делать с аргументом «код, написанный агентом, нечитаемый»? Это проблема инструмента или пользователя?

Направления для обсуждения

И того, и другого.

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

Практические меры:

• В CLAUDE.md или AGENTS.md задать жёсткие правила читабельности.
• Ограничивать длину функций, стиль именования, стиль комментариев.
• Отдельным шагом включать «упрощение / рефакторинг / удаление лишнего».
• Принудительно запускать code-review skill для самопроверки агента.
• Для критичных модулей требовать ручное чтение diff человеком.

Если вы вообще не читаете код, написанный агентом, по сути вы отдаёте production-код в аренду неопытному стажёру с root-доступом без персональной ответственности.

Q29. «Я оставил агенту задачу на ночь, он сделал что-то, но я не понимаю». Это вина агента или пользователя?

Направления для обсуждения

Ответ: ответственность общая.

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

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

Чем дольше автономный режим, тем больше нужны ограничения. Полностью незакреплённый «длительный» agent — это аналог «стажёра с sudo и без контроля», что в production рискованно.

Q30. Сделают ли agentic-инструменты профессию программиста ненужной?

Направления для обсуждения

Более вероятен сценарий не «исчезновения программиста», а роста уровня абстракции его работы.

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

На горизонте важность могут приобрести:

• Архитектор агентных систем: проектирование схем сотрудничества агентов, каталога skill и стратегии контекста.
• AI-редактор: быстрый review output агентов.
• Context-инженер: структурирование доменных знаний в форму, удобную для потребления агентом.
• Инженер-руководитель: решение, какие задачи автоматизировать, а какие требуют обязательного ручного контроля.

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

VI, Приложение: рекомендуемый путь обучения

Начальный уровень

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

• Проектные файлы правил: CLAUDE.md / AGENTS.md
• skill
• agent
• hooks
• /compact
• memory
• базовые permission mode Codex / Claude Code

Цель не в заучивании терминов, а в понимании того, какие задачи они решают.

Продвинутый уровень

Упакуйте 3 свои самых частых задачи, например:

1. Генерация commit message. 2. Написание PR summary. 3. Автозапуск тестов и typecheck после изменений в коде.

Ключ — перейти от «я каждый раз повторяю AI одни и те же инструкции» к «я превращаю процесс в командный актив».

Экспертный уровень

Постройте полноценный agentic workflow для команды или личного проекта:

• CLAUDE.md / AGENTS.md: долгосрочные правила.
• skills/: переиспользуемые регламенты.
• agents/: специализированные роли для исследования, review, debug и т. д.
• hooks/: детерминированные ограничения.
• PROGRESS.md: фиксация состояния длительных задач.
• TASKS.md: декомпозиция задач.

VII, Ссылки

• Документация Claude Code: llms.txt
• Документация по hooks в Claude Code
• Claude Code Docs: Automate workflows with hooks
• OpenAI Codex: Get started
• OpenAI Codex GitHub Repository
• OpenAI Codex: Installation Docs
• OpenAI Cookbook: Codex Prompting Guide

Дополнительные практики с Codex можно посмотреть в статье «Глубокий практический Codex»; для быстрой смены между инструментами Claude см. введение в CC Switch.

Часто задаваемые вопросы

Для какого уровня разработчиков эта статья?

Смотрите раздел «Ориентировано для…» в самом тексте. В рубрике «Программирование» на этом сайте есть материалы от новичков до тем, связанных с AI-рабочими процессами, для разных уровней подготовки.

Будут ли инструменты или команды из статьи отличаться между системами?

Да. В macOS, Linux и Windows различаются terminal-среды, форматы путей и синтаксис команд. Если не указана конкретная ОС, ориентируйтесь на официальную документацию для вашей платформы.

Какие AI-инструменты лучше использовать для изучения программирования?

Claude Code и Codex сейчас — наиболее мощные AI-инструменты для программирования: они помогают объяснять код, дополнять логику, отлаживать ошибки и писать скрипты. Смотрите обзоры в статье о CC Switch и наборе вопросов Vibe Coding.

Какой самый важный навык в обучении программированию?

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