Знаю, что у всех уже пушат SDD. Но поделюсь переводом официальной версии гайда от Anthropic по AI‑native SDLC, вдруг вам тоже пригодится.

---

Код больше не узкое место в разработке

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

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

Жизненный цикл разработки ПО (SDLC, software development lifecycle) — это процесс, который проходит ПО от идеи до продакшена. Большинство организаций работают по одной из версий одних и тех же 6 этапов: планирование, дизайн, разработка, тестирование, деплой и поддержка. Традиционно каждый этап — отдельная стадия, за которую отвечает отдельные специалисты. Продакт‑менеджеры пишут бизнесовые требования, технические архитекторы превращают их в архитектуру, дизайнеры и инженеры реализуют эту архитектуру, QA‑команды всё проверяют, релиз‑команды выпускают продукт, а операционные команды следят за тем, что уже работает в проде. Готовые части задач переходят между стадиями через документы, тикеты и согласования.

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

Традиционный SDLC также построен на том, что каждый этап выполняет человек. Сейчас эффективные организации перестраивают свой процесс вокруг возможностей агентного ИИ, при этом сохраняя человека в контуре принятия решений. В этом гайде мы разбирем несколько лучших регламентов команды Applied AI компании Anthropic по интеграции Claude на каждом этапе SDLC.

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

• Узкое место смещается на шаги слева и справа от фазы разработки — в основном это планирование, ревью/тестирование и деплой, которые всё ещё идут со скоростью человека.

• Ручной микро‑контроль перестал соответствовать реальности и становится невыполним. Построчное ревью имело смысл, когда код писал человек, но оно не поспевает, когда большую часть пишут агенты.

• Издержки на управление растут, потому что исключения по‑прежнему утверждаются через встречи и комитеты, которые собираются раз в неделю или раз в месяц.

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

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


СОДЕРЖАНИЕ
Код больше не является узким местом
Этапы разработки
Этап 1 — Планирование
Этап 2 — Дизайн
Этап 3 — Разработка
Этап 4 — Тестирование
Этап 5 — Деплой
Этап 6 — Поддержка
Заключение

Что такое AI‑native SDLC?

AI‑native SDLC — это переосмысленный процесс SDLC, который сохраняет старые цели контроля, но реализует их по‑новому. Вместо линейного потока процесс становится циклом, и ИИ встроен в каждую его точку. AI‑native SDLC поддерживает автоматическую передачу и запуск последующих этапов устраняя ручной и неповоротливый характер передачи задач между этапами традиционного SDLC.

Что нового в этапах AI‑native SDLC

Таблица ниже показывает крайние точки спектра между традиционным SDLC и AI‑native SDLC на базе Claude. Большинство компаний находятся где‑то между этими двумя столбцами.

Сквозная нить правого столбца — зафиксированный артефакт. Каждый этап заканчивается тем, что в систему контроля версий записывается артефакт (включая intent.md, spec.md, plan.md, дифф с тестами, PR с найденными проблемами ревью и запись об инциденте), а следующий этап начинается с чтения этого артефакта. На ранних этапах преобладающим артефактом являются.md‑файлы, потому что и владелец продукта, и агент могут прочитать и действовать на основе одного и того же файла. Начиная с этапа «Разработка», артефактом становится код и связанные с ним записи. Цепочка коммитов — это одновременно и аудиторский след: кто что запросил, что произвёл агент и кто это одобрил.

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

Этапы разработки

Этапы разработки — это ядро этого гайда, они сгруппированы в 6 нелинейных этапов (Планирование, Дизайн, Разработка, Тестирование, Деплой, Поддержка), которые в совокупности покрывают весь жизненный цикл разработки.

Каждый этап описывает:

• Что меняется;

• С чего начать;

• Конкретные шаги реализации;

• Соображения по управлению

• Как измерить, сработало ли это.

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

Этап заканчивается фиксацией артефакта, и такое действие запускает следующий этап. Принятый intent.md запускает проход требований и дизайна, одобренный spec.md запускает режим планирования, смёрженный PR запускает пайплайн, а нарушение контрольной границы в проде запускает новый intent.md — и так цикл продолжается.

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

---

Этап 1. Планирование

Фиксация артефакта в виде intent.md

intent.md, с которого начинается процесс разработки ПО, может появиться разными путями. У человека возникла идея, заведён тикет, или инцидент выявлен через алерт (см. Этап 6: Поддержка).

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

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

Независимо от того, возник ли замысел из события‑триггера или от агента, применяются одни и те же шаги: владелец продукта проверяет и исправляет написанный агентом intent.md, прежде чем он будет зафиксирован.

С чего начать

Предпосылки: нет.

Инфраструктура: доступ к Claude для не‑инженеров (claude.ai или Cowork); согласованный шаблон intent.md; общее место под контролем версий для замыслов, которое отслеживает владелец продукта. Для одного продукта проще всего использовать папку intent/ в репозитории продукта — так цепочка артефактов остаётся рядом с кодом, который из них следует. Отдельный репозиторий под замыслы имеет смысл заводить только тогда, когда замыслы охватывают много репозиториев, а в монорепозитории это просто директория. О том, как это место соотносится с уже существующей Jira, — см. врезку в этапе 3 «Разработка».

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

Как только репозиторий создан, участникам без опыта работы с git не нужно использовать git напрямую. Вместо этого коннектор к системе контроля версий (например, GitHub) позволяет Claude коммитить markdown‑файлы от их имени из claude.ai или Cowork.

Как это делать

1. Автор описывает Claude проблему своими словами. Он может рассказать, что не может сделать сегодня, кого касается идея, как выглядит «лучше» или что не входит в рамки. Формальный язык не требуется.

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

3. Просим Claude записать результат как intent.md по шаблону организации, который можно закодировать как skill, настроенный техническим сотрудником и одобренный руководителем. Шаблон может охватывать проблему, предлагаемый результат, затронутых пользователей и системы, ограничения и открытые вопросы.

4. Автор исправляет всё, что Claude понял неверно.

5. intent.md фиксируется в общем хранилище. К записи добавляются автор и метка времени, и владелец продукта забирает идею с этого момента.

# Intent: claims status self-service
Author: J. Ortiz (claims operations). Status: draft.

## Problem
Customers phone the contact center to ask where their claim is.
Handlers spend roughly a third of call time on status-only queries.

## Proposed outcome
Customers see claim status, next step and expected date in the portal.

## Affected users and systems
Claims handlers, portal team, claims-core API.

## Constraints
No new PII in the portal session. Existing authentication only.

## Open questions
Do third-party loss adjusters need access too?

Управление

Доказательством замысла (артефактом) служит зафиксированный intent.md, в котором указаны автор, метка времени и полная история изменений — она отражена в истории git хранилища замыслов. Владелец продукта одобряет решение, и решение принять или отклонить замысел, отправляющее его на Этап 2: Дизайн, фиксируется как merge или закрытие ревью.

Как измерить (метрики)

---

Этап 2. Дизайн

Требования и дизайн

После одобрения владельцем продукта Claude берёт принятый intent.md и создаёт спецификацию требований и дизайна. Этот процесс основан на skills организации — по бренду, безопасности, комплаенсу и UX.

Владелец продукта ревьюит эту спецификацию, но не пишет её. Цель процесса — создать спецификацию, по которой инженерная команда может планировать, с отмеченными зонами риска.

Фиксация артефакта в виде spec.md

Наиболее наглядный пример — фронтенд. После принятия intent.md владелец продукта делает макет в Claude Design (бета) на основе intent.md, дорабатывает макет, а затем экспортирует его в Claude Code для реализации.

С чего начать

Предпосылки: написан intent.md, регламенты по бренду, безопасности, комплаенсу и UX оформлены как skills.

Инфраструктура: владелец продукта с доступом к Claude. Инженерные навыки не требуются.

Как это делать

1. Владелец продукта открывает сессию с доступными skills организации и прикрепляет intent.md.

2. Запрос владельца продукта указывает на intent.md, называет ограничения и требует отметить зоны риска. Сначала запускаем вручную, затем кодифицируем как slash‑команду уровня организации. Далее делаем триггером принятие intent.md в хранилище замыслов — неинтерактивная задача запускается при merge, проходит с загруженными skills организации и фиксирует spec.md как pull request (техническая часть — в регламенте CI/CD на Этапе 5: Деплой). С этого момента первое участие владельца продукта — это ревью.

3. Тот же владелец продукта сверяет спецификацию с идеей. Решает ли спецификация заявленную проблему, и отвечены ли (или перенесены) открытые вопросы из intent.md?

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

5. spec.md фиксируется рядом с intent.md. Пара файлов фиксирует, что было запрошено и что было решено.

6. Владелец продукта решает, переходят ли спецификация и замысел в разработку, консультируясь с техлидом по всему, что организация классифицирует как более рискованное. Это решение всегда принимает человек, и принятие спецификации запускает режим планирования на Этапе 3: Разработка.

Как это выглядит (промпт)

Прочитай прикреплённый intent.md и подготовь спецификацию требований и дизайна для интеграции в нашу существующую кодовую базу. Применяй доступные тебе skills, чтобы план соответствовал нашим гайдлайнам по бренду, регламентам безопасности и стандартам UX. Полностью задокументируй спецификацию как spec.md, готовую для передачи инженерной команде. Чётко опиши зоны риска, особенно там, где ты не можешь удовлетворить противоречащие друг другу регламенты.

Управление

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

Как измерить (метрики)

---

Этап 3. Разработка\сборка

Режим планирования Claude Code как отправная точка по умолчанию

Инженеры начинают сессии Claude Code в режиме планирования, передают Claude одобренный spec.md в Этапе 2: Дизайн и позволяют ему опрашивать их, дорабатывая план, пока инженер не будет им доволен.

Фиксация артефакта в виде plan.md

С чего начать

Предпосылки: артефакт замысла (intent.md или spec.md) + файл CLAUDE.md.

Инфраструктура: Claude Code с доступом к репозиторию.

Как это делать

1. Инженер начинает сессию в режиме планирования с Claude.

2. Инженер передаёт Claude intent.md и spec.md и просит составить план реализации, порядок работы и тесты, которые докажут работоспособность.

3. Опрашиваем план: что может сломаться из‑за изменения, какой шаг самый рискованный и какие другие варианты Claude решил не использовать.

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

5. Одобренный план фиксируется как plan.md. План присоединяется к аудиторскому следу, и во время ревью PR (Этап 5: Деплой) сверяется итоговый список изменений с plan.md.

6. Принимаем план и даём Claude реализовать его. При хорошем плане реализация часто проходит за один проход.

7. Если реализация отклоняется от плана, plan.md обновляется в том же коммите. Стоит рассмотреть создание хука, обеспечивающего синхронизацию между ними.

Как это выглядит (plan.md)

# Plan: claims status self-service (from intent.md 2026-06-02)

## Files that change
portal/src/claims/StatusPanel.tsx (new), claims-api/routes/status.py,
claims-api/tests/test_status.py

## Order of work
1. Add the status endpoint behind existing auth.
2. Panel against the endpoint.
3. Wire into the portal nav.

## Risks
The claims-core API rate-limits at 50 rps; the panel must cache.

## Proof
test_status.py covers the four claim states; screenshot matches the
approved mock.

Управление

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

Как измерить (метрики)

Claude Code в авторежиме

Claude Code может также работать в авторежиме, где инженер одобряет план и, после этого Claude применяет каждое изменение без запроса на каждое отдельное действие. По мере того как защитные механизмы из последующих этапов дорабатываются (настроенный CLAUDE.md, skills, хуки, блокирующие небезопасные действия, и набор тестов, который Claude может запускать), авторежим становится стандартом для рутинной работы: чёткая spec.md и код, уже покрытый тестами.

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

Legacy‑системы и источник истины

Применяется к каждому артефакту, которые производятся в процессе.

Существующие процессы SDLC, скорее всего, уже отслеживают артефакты, просто не в markdown‑файлах. Рабочие элементы могут быть в вашей Jira, требования — в Confluence, дизайны — в Figma, а согласования изменений — в change board. Эти системы сложно вытеснить, потому что аудиторы и регуляторы их признают, и команды от них зависят, поэтому AI‑native SDLC должен вписаться в существующий ландшафт.

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

• Репозиторий как источник истины. Markdown‑артефакты — авторитетная запись, а legacy‑система ссылается на файлы внутри коммитов. Это может быть одна из самых лучших конфигураций для организаций, ориентированных на инженеров, поскольку все записи живут в одном инструменте с единым авторитетом меток времени.

• Legacy‑система как источник истины. Jira, ServiceNow или инструмент спецификаций хранит авторитетную запись, а markdown‑артефакты — рабочие копии. Claude читает запись в начале сессии и записывает результат обратно через MCP‑коннектор в той же сессии, где была создана spec.md или plan.md.

• Связывание как минимальное требование. Все артефакты содержат ID записи, а все legacy‑записи содержат SHA коммита markdown‑файла. Связывание — хорошая отправная точка при переходе на AI‑native SDLC, при этом придётся принять, что источников истины два.

И legacy‑система, и markdown‑first система могут сосуществовать, пока между ними есть связь, либо одна из них должна объявлена источником истины.

***СLAUDE.md

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

Фиксация артефакта в виде CLAUDE.md

С чего начать

Предпосылки: нет.

Инфраструктура: репозиторий, установленный Claude Code, и один инженер, хорошо знающий кодовую базу.

Как это делать

1. Запустить /init в репозитории. Claude сгенерирует стартовый CLAUDE.md на основе того, что найдёт.

2. Сократить сгенерированный файл до того, что нужно новому сотруднику в первый день. Оставить команды сборки, тестирования и линтинга, важные соглашения и то, в чём Claude чаще всего ошибается.

3. Закоммитить CLAUDE.md в git в корне репозитория, чтобы вся команда пользовалась одной версией и изменения ревьюились как код.

4. Здесь помогает простое правило: если Claude ошибается дважды в одном и том же, исправление идёт в CLAUDE.md.

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

Как это выглядит (CLAUDE.md)

# Payments service

## Commands
- Build: make build
- Test: make test (unit), make itest (integration, needs docker)
- Lint: make lint (runs in CI; fix before pushing)

## Conventions
- Java 21, Spring Boot 3. No new Lombok.
- Money is always BigDecimal, never double.
- Every endpoint needs an integration test in src/itest.

## Architecture
- api/ holds REST controllers, core/ holds domain logic,
  adapters/ talks to external systems.
- Kafka events are defined in schemas/; never edit generated classes.

## Things Claude gets wrong
- Do not bump dependency versions; the platform team owns them.
- The legacy v1/ package is frozen; changes go in v2/.

Управление

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

Как измерить (метрики)

***

SKILLS.md

Skills — это то, как организация превращает свои институциональные знания в операционные. Инструкции явные, версионируемые, применяются повсеместно и централизованно обновляются при изменении регламента процесса. Правило простое: пишите skill для институционального знания, которое должно применяться последовательно; не пишите skill для того, что относится к CLAUDE.md или промпту.

Фиксация артефакта в виде skill.md

С чего начать

Предпосылки: не обязательны. Наличие CLAUDE.md помогает, поскольку удерживает рабочее знание агента в репозитории, но skill от него не зависит.

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

Как это делать

1. Выбрать одно знание, которое сегодня применяется непоследовательно. Это может быть стандарт безопасности, соглашение по дизайну API или правило бренда.

2. Записать его как skill — папку с файлом SKILL.md, в шапке которого указано, когда он срабатывает, а в теле — что делать. Инженер пишет его на основе источника истины владельца регламента процесса, используя Claude как помощника.

3. Разместить skill в репозитории по пути.claude/skills//, чтобы он поставлялся вместе с кодом, либо распространить в масштабе всей организации через плагин.

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

5. При изменении регламента процесса — изменить skill, владелец регламента подписывает изменение.

6. Инженеры автоматически получают новую версию в следующей сессии.

Как это выглядит (.claude/skills/secure‑api‑review/SKILL.md)

---
name: secure-api-review
description: Apply the API security standard. Use whenever creating or
  modifying an external-facing endpoint, reviewing API code, or
  generating an OpenAPI spec.
---
# Secure API review

When you create or change an API endpoint:
1. Authentication: every endpoint requires the gateway JWT;
   no anonymous routes outside /health.
2. Input validation: validate request bodies against the OpenAPI
   schema and reject unknown fields.
3. Audit: every state-changing endpoint emits an audit event with
   actor, action, entity and timestamp.
4. Data classification: fields tagged pii in the schema must never
   appear in logs or error messages.

Run scripts/check-endpoints.sh and include its output in your summary.

Управление

Skill — это контроль, но рекомендательный. Он повышает вероятность того, что Claude применит регламент процесса при написании кода, но ничто не заставляет сессию ему следовать. Регламент процесса, который должен соблюдаться всегда, нуждается в чём‑то детерминированном для skill — например, в хуке, блокирующем действие, или в проходе ревью, повторно проверяющем регламент на этапе PR. Skill делает нарушения редкими, а хук — практически невозможными. Вызовы skills фиксируются в трассах сессий, а владелец регламента ревьюит изменения skill как код.

Как измерить

***

ХУКИ

Хуки как защитные механизмы на этапе разработки

Skill — рекомендательный контроль, а хук — детерминированный слой позади него. Большинство действий Claude во время реализации — это редактирование файлов и команды оболочки, поэтому именно фаза разработки — то место, где хуки срабатывают чаще всего.

Хуки на этапе разработки могут:

• Блокировать редактирование защищённых путей, таких как сгенерированные классы или замороженный пакет;

• Запускать форматтер и линтер после редактирования файлов, чтобы расхождения не накапливались;

• Не пускать учётные данные в дифф.

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

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

***

Параллельные сессии и субагенты

Один инженер может вести сразу несколько потоков работы.

Параллельная сессия — это ещё один полноценный экземпляр Claude Code, работающий над отдельной задачей в своей ветке git. Каждая независимая сессия ничего не знает о других, единственное, что их объединяет, — это инженер, который ими управляет.

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

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

С чего начать

Предпосылки: CLAUDE.md, поскольку его читают все сессии. Цикл обратной связи (Этап 4: Тестирование) тоже помогает, поскольку сессии требуется меньше присмотра инженера, если она может сама проверить свою работу.

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

Как это делать

1. Инженер разбивает работу на задачи, затрагивающие разные файлы, используя plan.md из режима планирования (Этап 3: Разработка), чтобы увидеть, где работа независима. Задачи, работающие с общими файлами, выполняются в одной сессии последовательно.

2. Каждая параллельная задача получает свою ветку (worktree) — например, claude --worktree feature-auth в одном терминале и claude --worktree fix-rate-limit в другом. Ветка (Worktree) — это отдельная рабочая копия репозитория на своей ветке, которая не даёт сессиям конфликтовать из‑за общих файлов.

3. Две или три сессии — разумная отправная точка. Практический потолок — сколько потоков один человек способен качественно проревьюить, поэтому сессии добавляются только пока ревьювер справляется.

4. Повторяющиеся работы превращаются в субагентов, определённых в markdown‑файлах в.claude/agents/, у каждого — имя, описание, когда его использовать, и инструменты, к которым у него есть доступ. Примеры: упроститель кода, убирающий лишнюю сложность после работы основного агента; верификатор, запускающий приложение и проверяющий поведение; исследователь, изучающий кодовую базу и отчитывающийся без переполнения основного контекста. Определения фиксируются в git, чтобы вся команда ими пользовалась.

Как это выглядит (.claude/agents/verifier.md)

---
name: verifier
description: Runs the app and checks the change works before the session
  reports done
tools: Bash, Read
---
Start the app with make run. Exercise the changed behavior and the two
nearest neighboring flows. Report what you ran, what you saw, and any
behavior that does not match plan.md. Do not fix anything; report only.

Управление

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

Как измерить

---

Этап 4. Тестирование

Дайте Claude цикл обратной связи

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

Цикл обратной связи не следует путать с субагентом‑верификатором (Этап 3: Разработка). Цикл обратной связи проходит через всю задачу столько раз, сколько нужно для работы. Субагент‑верификатор, напротив — это один из способов упаковать финальную проверку, запуская новое контекстное окно, когда сессия считает, что работа завершена.

С чего начать

Предпосылки: нет.

Инфраструктура: набор тестов и сборка, которые запускаются локально одной командой каждая. Для UI‑работы критически важен способ для Claude увидеть результат — либо инструмент браузера, либо утилита скриншотов, подключённая через MCP.

Как это делать

1. Если сегодня проверка работы требует последовательности команд и знания окружения, обернуть это в единую цель, например «make test» или «npm test», которая завершается с ненулевым кодом при ошибке.

2. В разделе Commands файла CLAUDE.md перечислить каждую команду с примером здорового вывода.

3. Сформулировать цель так, чтобы её можно было измерить — чтобы Claude мог проверить работу, не спрашивая вас: например, «все тесты в test_status.py проходят», «скриншот совпадает с прикреплённым макетом» или «эндпоинт возвращает 200 с новым полем».

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

5. Для UI‑работы замкнуть цикл визуальной проверкой. Дать Claude инструмент браузера или скриншотов, дать макет и позволить итерировать. Реализовать, сделать скриншот, сравнить, скорректировать. Два‑три раунда — это нормально, и результат должен улучшаться с каждым.

6. Сделать верификацию частью «готово». Инструкция живёт в CLAUDE.md. Запускать тесты перед тем, как сообщать о завершении задачи, и показывать вывод.

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

Как это выглядит (блок верификации в CLAUDE.md)

## Verifying your work

- Build: make build (must finish with "Build succeeded")
- Test: make test (all green; never skip or delete a failing test)
- Lint: make lint (zero warnings)

Run all three before reporting any task complete, and paste the output.
If a test fails, fix the code, not the test.

Управление

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

В чём доказательство: буквальный вывод «make test», лог сборки или сравнение скриншотов, которые запустил Claude и вставил в отчёт, — то есть доказательство исходит из самого инструментария.

Где это фиксируется: в транскрипте сессии, который экспорт OpenTelemetry передаёт в стек наблюдаемости организации, и в чек‑ране PR, где и ревьюер, и любой последующий аудитор могут это увидеть.

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

Как измерить

Непрерывные evals в CI

Evals (Evaluations) — это AI‑native эквивалент QA на границах этапов. На практике это набор тестов, который запускается при каждом изменении конфигурации агента. Когда подключается новая модель или переписывается промпт, набор тестов (evals) показывает, продолжает ли агент выполнять работу на том же уровне.

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

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

С чего начать

Предпосылки: CLAUDE.md и цикл обратной связи (Этап 4: Тестирование).

Инфраструктура: CI, способный запускать Claude Code неинтерактивно, и API‑ключ с бюджетом для прогонов evals.

Как это делать

1. Платформенный инженер собирает 20–50 реальных задач из недавней работы с ожидаемым/принятым результатом.

2. Каждая задача записывается как eval — промпт плюс проверки, определяющие приемлемость (тесты проходят, линт чист, поведение не изменилось, политика соблюдена).

3. Набор тестов запускается неинтерактивно в CI по расписанию и при любом изменении CLAUDE.md, skills или хуков, поскольку эта конфигурация направляет агента и заслуживает той же регрессионной проверки, что и код.

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

5. Для каждого производственного инцидента пишется свой eval, автором выступает команда, владевшая инцидентом, и он остаётся в наборе как регрессионный тест.

Как это выглядит (.github/workflows/agent‑evals.yml)

name: Agent evals
on:
  pull_request:
    paths: ['CLAUDE.md', '.claude/**']
  schedule:
    - cron: '0 2 * * *'
jobs:
  evals:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install -g @anthropic-ai/claude-code
      - name: Run eval suite
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          for eval in evals/*.json; do
            claude -p "$(jq -r '.prompt' $eval)" \
              --allowedTools "Read,Edit,Bash(make test)" \
              --output-format json > result.json
            ./evals/check.sh "$eval" result.json
          done

Управление

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

Как измерить

---

Этап 5. Деплой

Claude в цикле ревью PR

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

Фиксация артефакта в виде REVIEW.md

С чего начать

Предпосылки: обновлённый файл CLAUDE.md с Этапа 3: Разработка; skills, если проходы ревью применяют письменные политики; определённые субагенты.

Инфраструктура: репозиторий с установленной интеграцией Claude — либо управляемый сервис Code Review (research preview), включённый администратором, либо claude‑code‑action, работающий в вашем собственном CI, с вызовами модели через AWS Bedrock, Google Vertex или Microsoft Foundry там, где это нужно (варианты деплоя описаны ниже в этапе CI/CD). Стоит также настроить регламенты защиты веток, требующие одобрения от владельца кода.

Как это делать

1. Управляемый сервис Code Review — самый быстрый старт. Администратор включает его и выбирает репозитории. Запускать ревью в собственном CI через claude‑code‑action нужно, когда требуется контроль над пайплайном или вызовы API через собственное облачное соглашение.

2. Техлид пишет регламент ревью как REVIEW.md в корне репозитория, разбитую на проходы, важные для организации: баги и логические ошибки; безопасность и уязвимости; соответствие спецификации (spec.md из этапа требований), плану реализации (plan.md из режима планирования) и принципам дизайна. REVIEW.md также определяет, что считается важным, а что — Nit, и что пропускать.

3. Техлид задаёт порог участия человека. Найденные проблемы (баги) сами по себе не одобряют и не блокируют PR, защита веток по‑прежнему требует одобрения от владельца кода. Если инженер хочет блокировать слияние PR на основе найденных проблем, он может использовать количество находок по каждому уровню серьёзности — эти данные автоматически публикует проверка (check run) в PR, в формате, который можно обрабатывать программно.

4. Когда ревьюер или автор тегает @claude в комментарии ревью, Claude обрабатывает комментарий и пушит фикс. Тред PR фиксирует и запрос, и изменение. Этот цикл фиксов идёт через claude‑code‑action. В управляемом сервисе комментарий @claude review запускает новое ревью. Для PR, открытых самим Claude, можно пойти дальше и позволить Claude “нянчить” PR до слияния. Команды оборачивают этот цикл в кастомную slash‑команду, которая проходит по неразрешённым комментариям ревью и падающим проверкам PR, обрабатывает их и пушит фиксы, пока PR не станет зелёным и не будет ждать только одобрения владельца кода.

5. Найденные проблемы ревью попадают обратно в CLAUDE.md. Когда ревью отмечает одну и ту же ошибку второй раз, исправление вносится в CLAUDE.md прямо в рамках этого ревью, и поскольку ревью читает CLAUDE.md, эта ошибка ловится начиная со следующего PR. Ревью также помечает, когда изменение сделало CLAUDE.md устаревшим.

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

Как это выглядит (REVIEW.md)

# Review instructions

## Passes
Run three passes and tag each finding with its pass:
- Bugs: logic errors, broken edge cases, subtle regressions
- Security: injection risks, authentication gaps, PII in logs
- Compliance: the change matches spec.md, plan.md and our design principles

## What Important means here
Reserve Important for findings that would break behavior, leak data
or breach a policy. Style and naming are nits.

## Cap the nits
Report at most five nits per review; summarize the rest as a count.

## Do not report
Generated files under src/gen/ and anything CI already enforces.

Управление

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

О том, как эти средства контроля работают в масштабе продакшена, см. статью о защите AI‑native SDLC в Anthropic.

Как измерить

Хуки как контроль одобрения

На этапе разработки хуки использовались как защитные механизмы, разрешающие или блокирующие действия без участия человека (Этап 3: Разработка). Хук также может спрашивать инженера, приостанавливая действие до одобрения конкретным человеком — именно это нужно, чтобы релиз проходил только после одобрения.

Этот процесс относится к Этапу 5: Деплой, поскольку релизный контроль — самый наглядный случай, но хуки не привязаны только к деплою: они срабатывают везде, где действует Claude. Например, хуки могут блокировать редактирование миграций и инфраструктуры без тикета на изменение на Этапе 3: Разработка и не давать агенту редактировать тестовые файлы во время задачи‑фикса на Этапе 4: Тестирование.

С чего начать

Предпосылки: нет.

Инфраструктура: письменный список одобрений, которые требует процесс изменений.

Как это сделать

1. Менеджеры вместе с комплаенсом перечисляют точки контроля (человеческое одобрение), которые должны сохраниться, например: согласование change management, авторизация релиза и редактирование защищённых путей.

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

3. Командные хуки идут в.claude/settings.json под git, а обязательные хуки без точек контроля — в управляемые настройки, которыми владеет команда СI/CD или ИТ‑администратор, где отдельные инженеры не могут их отключить.

4. Блокировка должна объяснять себя: когда хук останавливает действие, причина и путь к одобрению должны появляться в выводе Claude.

Как это выглядит (.claude/settings.json)

{
    "hooks": {
      "PreToolUse": [
        {
          "matcher": "Bash",
          "hooks": [
            { "type": "command",
              "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/production-gate.sh" }
          ]
        }
      ]
    }
}

И сама точка контроля (.claude/hooks/production‑gate.sh):

#!/bin/bash
# Production deploys require a named release authorization
cmd=$(jq -r '.tool_input.command' < /dev/stdin)
if [[ "$cmd" == *"deploy"* && "$cmd" == *"production"* ]]; then
   if [ -z "$RELEASE_APPROVAL" ]; then
     echo "Production deploys need a release authorization." >&2
     exit 2 # exit 2 blocks the action; the message goes to Claude
   fi
fi
exit 0

Управление

Хуки — это точки контроля (барьеры, где используется одобрение человеком). Условие барьера соблюдается каждый раз, для всех. Решения разрешить или заблокировать фиксируются с меткой времени. Точка контроля также определяет, что считается одобрением — будь то одобренный тикет на изменение или подпись релиз‑менеджера.

***

ПРАКТИЧЕСКИЙ ПРИМЕР: управляемые настройки

Разворачивается командой CI/CD через MDM или консоль администратора; инженеры не могут ничего в этом редактировать или переопределять.

{
  "permissions": {
     "deny": [
        "Read(.env*)", "Read(./secrets/**)",
        "WebFetch", "Bash(curl *)", "Bash(wget *)"
     ],
     "allow": [
        "Bash(git *)", "Bash(make build)",
        "Bash(make test)", "Bash(make lint)"
     ],
     "disableBypassPermissionsMode": "disable"
  },
  "allowManagedPermissionRulesOnly": true,
  "sandbox": {
     "enabled": true,
     "failIfUnavailable": true,
     "allowUnsandboxedCommands": false,
     "network": { "allowedDomains": ["git.internal.example.com",
"registry.npmjs.org"] },
     "credentials": {
        "files": [
          { "path": "~/.ssh", "mode": "deny" },
          { "path": "~/.aws/credentials", "mode": "deny" }
        ],
        "envVars": [ { "name": "GITHUB_TOKEN", "mode": "deny" } ]
     }
  },
  "allowManagedHooksOnly": true,
  "disableSideloadFlags": true,
  "allowManagedMcpServersOnly": true,
  "strictKnownMarketplaces": [
     { "source": "github", "repo": "example-corp/approved-plugins" }
  ],
  "requiredMinimumVersion": "2.1.193"
}

Что даёт каждая строка в терминах контроля:

• permissions.deny не даёт секретам попасть в контекст агента и блокирует произвольный сетевой доступ через инструменты; permissions.allow заранее разрешает безопасный внутренний цикл, чтобы список запретов не превратился в «усталость от запретов».

• disableBypassPermissionsMode вместе с allowManagedPermissionRulesOnly означает, что ни один инженер, файл проекта или флаг командной строки не может расширить правила.

• sandbox закрывает пробел, который не может закрыть уровень прав. Запрет на уровне инструмента для WebFetch не мешает команде оболочки достучаться до сети; список разрешённых доменов на уровне ОС полностью блокирует такой выход.

• failIfUnavailable и allowUnsandboxedCommands делают песочницу настоящим барьером: Claude Code отказывается стартовать, если песочница не может инициализироваться, а команда, упавшая внутри песочницы, не может быть повторена вне её.

• credentials закрывает пробел, который оставляют правила запрета. permissions.deny управляет файловыми инструментами Claude, но команда оболочки в песочнице всё ещё могла бы по умолчанию прочитать ~/.ssh или ~/.aws/credentials; этот блок запрещает такое чтение и убирает названные секреты из окружения каждой команды в песочнице.

• allowManagedHooksOnly означает, что барьеры одобрения из этой стадии — единственные хуки, которые запускаются; ничто локальное не может добавить или заменить их.

• disableSideloadFlags и strictKnownMarketplaces означают, что каждый skill, агент, хук и MCP‑сервер на машине инженера пришёл через одобренный маркетплейс плагинов организации, а не из домашней директории.

• allowManagedMcpServersOnly делает набор инструментов агента списком разрешений, которым владеет команда CI\CD.

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

Считайте пример выше отправной точкой для настройки под себя, а не рекомендацией копировать как есть. Каждый запрет можно изменить на возможности, и правильный баланс зависит от классификации данных репозитория. Полный справочник по настройкам, включая управляемые‑только ключи, доступен по адресу: code.claude.com/docs/en/settings

Как измерить (для самих хуков)

***

Интеграция CI/CD и деплой

Запускайте Claude Code неинтерактивно внутри пайплайна CI/CD, изолируйте выполнение в песочнице, чтобы долгоживущие агенты работали безопасно, открывайте деплой через MCP‑интеграции и отрабатывайте пути отката до того, как агенту действительно понадобится ими воспользоваться.

С чего начать

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

Инфраструктура: CI‑платформа с установленным claude‑code‑action или любой раннер, способный вызывать claude ‑p; доступ к модели через API либо Bedrock, Foundry или Vertex там, где трафик должен оставаться в облачном соглашении организации; MCP‑серверы для целей деплоя; профиль песочницы для задач агента без постоянных продакшен‑учётных данных.

Как это делать

1. Инженер начинает с шагов только для чтения, требующих рассуждения человека. Используем claude ‑p в задаче пайплайна, чтобы разобрать упавшую сборку, суммировать нестабильный тест или подготовить черновик changelog.

2. Добавляем шаги записи за существующими точками контроля — для задач вроде исправления линта, обновления сгенерированной документации или обработки комментариев ревью через упоминания @claude. Всё, что пишет агент, приходит как PR через защиту веток, и у агента нет прямого пути пушить в main.

3. Выполнение изолируется в песочнице. Задачи агента запускаются в контейнерах под сетевой политикой с короткоживущими ограниченными токенами и по умолчанию не имеют продакшен‑учётных данных.

4. Деплой открывается через MCP. Деплой, статус и откат становятся инструментами, ограниченными по окружениям, поэтому возможности агента по деплою — это список разрешений, а не скрипт оболочки с учётными данными.

5. Автономность градуируется по окружениям. В development агент деплоит свободно. В production агент готовит релиз, а релиз‑менеджер его авторизует, хук обеспечивает точку контроля продакшена. Staging — где‑то посередине.

6. Откат должен быть самым отработанным путём в пайплайне — единой командой, которую агент может выполнить и которая регулярно отрабатывается на staging. Регламент замыкания цикла (Этап 6: Поддержка) вызывает именно этот откат при нарушении контрольной границы, поэтому он должен быть заранее проверен.

Как это выглядит (шаг пайплайна)

- name: Triage failed build
  if: failure()
  run: >
    claude -p "Read the build log at out/build.log. Identify the most
    likely cause, say whether the failure looks flaky or real, and write a
    three-line summary for the PR thread." >> triage.md

Управление

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

• Защита веток превращает всё, что пишет агент, в PR, без прямого пути в main.

• Хук деплоя в продакшен блокирует релиз до авторизации назначенным релиз‑менеджером. Каждый неинтерактивный запуск действует под собственной идентичностью агента, поэтому лог пайплайна отделяет действия агента от действий инженера, запустившего процесс.

• Многоуровневые права по окружениям задают, что может сделать агент на пути к точке контроля.

Как измерить

---

Этап 6. Поддержка

Поддержка и замыкание цикла

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

Например, непрерывно работающий агент мониторинга может, в ответ на заведение тикета о баге, создать intent.md и пройти через фазы требований, плана, разработки, тестирования и ревью. Этап 6: Поддержка работает в headless‑режиме, с независимой точкой контроля доверия между этапами — детерминированной проверкой или агентом‑ревьюером в состязательном режиме — который решает, продолжается ли результат предыдущего этапа или эскалируется человеку.

Замыкание цикла

Детерминированный скрипт следит за продакшеном и вызывает Claude при нарушении контрольной границы. Мониторинг такого нарушения — полезный пример паттерна для автономно работающего цикла, а раздел про Claude Tag (публичная бета) в конце этапа охватывает работу, поступающую по другим каналам.

С чего начать

Предпосылки: intent.md, дающий циклу структурированный вывод для перезапуска. Ускоренные ревью PR от Claude, хуки как граница действия, путь отката для CI/CD (который вызывает высший уровень автономности).

Инфраструктура: хранилище метрик, которое может опросить скрипт обнаружения (Prometheus, API системы CI или аналоги), доступ на чтение к репозиторию, способ запускать Claude Code неинтерактивно в CI, либо Agent SDK для сервиса, принимающего вебхуки.

Как это делать

1. Владелец сервиса или инженер СI\CD выбирает одну метрику со стабильной базовой линией — например, частоту сбоев тестов в CI, частоту 5xx после деплоя или время цикла PR.

2. Пишется скрипт обнаружения, обычно среднее и стандартное отклонение по скользящему окну с правилами (Western Electric или аналогичными), чтобы точки контроля ловили и постепенный дрейф, и всплески. Скрипт находится под контролем версий и покрыт юнит‑тестами, а само обнаружение остаётся полностью детерминированным, без участия модели.

3. Уровни реагирования определяются в конфигурации под контролем версий (bands.yaml ниже). На 1σ скрипт только логирует, на 2σ вызывает Claude в режиме только чтения для диагностики, на 3σ Claude может действовать — но только открывая PR в барьер ревью или запуская заранее одобренный runbook.

4. Слой триггера может быть запланированным workflow в GitHub или GitLab, вебхуком из уже существующего стека мониторинга или Cron Job внутри сети. Claude работает без сохранения состояния — либо как неинтерактивный шаг на раннере CI, либо как сервис на Agent SDK в изолированном контейнере (варианты деплоя и доступа к модели описаны ниже в этапе CI/CD). Поскольку запуск не сохраняет состояние и неинтерактивен, цикл может начаться и закончиться без чьего‑либо участия.

5. Агент записывает свой результат как intent.md в формате Этапа 1: Планирование, охватывая аномалию и доказательства, предлагаемые действия, затронутые системы и открытые вопросы. Дальше найденная проблема идёт по пайплайну, как и всё остальное.

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

7. Когда фикс выходит в релиз, добавляется eval для этого инцидента (процесс непрерывных evals), чтобы защититься от подобных проблем в будущем.

Как это выглядит (пример, bands.yaml для мониторинга частоты сбоев тестов в CI)

metric: ci_test_failure_rate
baseline: rolling_30d
rules: western_electric
tiers:
  1sigma: { action: log }
  2sigma: { action: diagnose,
            tools: "Read,Grep,Bash(gh run view *)" }
  3sigma: { action: propose,
            routes: [pull_request, runbook:rollback-deploy] }

Управление

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

Как измерить

Примеры

• Когда частота сбоев тестов в CI пробивает 3σ, агент либо помещает нестабильный тест в карантин, либо открывает PR на откат — а дальше решение принимает уже человек на этапе ревью.

• Когда частота 5xx после деплоя пробивает 3σ при деплое в этом окне, агент запускает существующий пайплайн отката.

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

***

Периодические сканирования кодовой базы

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

Claude Security — это облачный сервис для запланированного сканирования, который работает на инфраструктуре Anthropic. Подключите репозиторий GitHub, и сканы будут запускаться на Claude Mythos 5 в облаке Anthropic, при этом каждая найденная проблема проверяется до того, как о ней сообщат, и получает рейтинг доверия. Предлагаемые патчи ревьюятся и применяются в Claude Code на web. Организация получает найденные проблемы без необходимости прямого доступа к самой модели.

С чего начать

Предпосылки: точки контроля ревью PR и хуки как точки контроля одобрения (Этап 5: Деплой), чтобы найденные проблемы проходили через ревью, как и любое другое изменение. Формат intent.md с Этапа 1: Планирование — для найденных проблем, слишком крупных для одного PR.

Инфраструктура: Claude Security доступен организациям Claude Enterprise в публичной бете. Требуется установленное на целевые репозитории GitHub‑приложение Anthropic (облачный github.com), включённый Claude Code на web, включённый Extra Usage с установленным лимитом расходов, премиум‑места для тех, кто запускает сканы, и функция, включённая администратором в claude.ai/admin‑settings/claude‑code. Сканы тарифицируются по потреблению по ставкам Mythos 5, так что лимит расходов должен соответствовать размеру и числу репозиториев.

Как это делать

1. Специалист по безопасности подключает репозитории и организует их в проекты по репозиторию, сервису или команде, чтобы владение находками было ясно с самого начала.

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

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

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

5. Для ограниченной проблемы открыть предложенный патч в Claude Code на web, проревьювить и отправить через ревью PR, как и любое другое изменение. У агента, предложившего фикс, нет пути его самостоятельно одобрить.

6. Если проблема шире, чем можно исправить одним патчем — например, это слабое место в архитектуре системы или один и тот же паттерн ошибки повторяется в нескольких сервисах — такую находку оформляют как intent.md (в том же формате, что и на Этапе 1: Планирование), и она проходит через весь процесс заново, начиная с этапа планирования.

7. Когда фикс выходит в продакшен, добавить eval для этого класса уязвимости в набор из регламента непрерывных evals, чтобы конфигурация, направляющая агента, тестировалась на этот класс с этого момента.

8. Экспортировать найденные проблемы в CSV или Markdown, либо использовать вебхуки, чтобы существующий трекер и системы аудита организации оставались системой учёта там, где их уже ожидают аудиторы.

Управление

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

Фиксы попадают в продакшен через барьер ревью PR и защиту веток, а не напрямую из скана. Claude Security дополняет существующий статический анализ и сканирование зависимостей. Детерминированные проверки остаются в CI, а сканирование на базе модели покрывает контекстно‑зависимые уязвимости, которые эти проверки не предназначены находить.

Как измерить

***

Claude на дежурстве с Claude Tag

Инциденты также могут поступать через другие каналы, такие как рабочие мессенджеры — Slack или Teams. Инцидент может выглядеть как сообщение в Slack в 22:00 с просьбой срочно что‑то исправить в канале инцидента, и теперь на это можно отреагировать немедленно. Claude Tag (публичная бета, сейчас доступна в Slack) делает Claude участником таких каналов под собственной идентичностью, так что каждый новый инцидент получает первого респондента, а сам ответ становится частью цикла и памяти для будущих инцидентов.

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

Инциденты — не единственная работа, которую подхватывает Claude Tag. Будучи тегнутым в тикете через MCP или спрошенным в канале, Claude сортирует работу тем же образом. Небольшой, чётко ограниченный фикс приходит как PR через ревью, а всё более крупное оформляется как intent.md для Этапа 1: Планирование, и с этого момента цикл начинает обогащать сам себя. См. как Claude Tag дежурит для CI/CD

---

Заключение

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

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

Источники

Документация ниже — то, что нужно команде для настройки средств контроля, примерно в том порядке, в котором их стоит внедрять.

• Настройка Claude Code для организации — карта решений для администратора; начните отсюда: code.claude.com/docs/en/admin‑setup

• Справочник по настройкам и приоритету, включая все управляемые‑только ключи: code.claude.com/docs/en/settings

• Настройки, управляемые сервером, из консоли администратора Claude: code.claude.com/docs/en/server‑managed‑settings

• Права: code.claude.com/docs/en/permissions

• Песочница — изоляция на уровне ОС по файловой системе и сети: code.claude.com/docs/en/sandboxing

• Хуки — руководство: code.claude.com/docs/en/hooks‑guide

• Хуки — справочник: code.claude.com/docs/en/hooks

• Skills: code.claude.com/docs/en/skills

• Плагины и приватные маркетплейсы — как skills и хуки распространяются в масштабе организации: code.claude.com/docs/en/plugin‑marketplaces

• Управляемый MCP — централизованный контроль набора инструментов агента: code.claude.com/docs/en/managed‑mcp

• Обзор корпоративного деплоя — Bedrock, Vertex, Foundry: code.claude.com/docs/en/third‑party‑integrations

• Настройка корпоративной сети: code.claude.com/docs/en/network‑config

• Мониторинг (OpenTelemetry): code.claude.com/docs/en/monitoring‑usage

• Дашборд аналитики: code.claude.com/docs/en/analytics

• Compliance API — лента активности Enterprise, получение и удаление чатов: platform.claude.com/docs/en/manage‑claude/compliance‑api

• Модель безопасности: code.claude.com/docs/en/security