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

Полный перевод статьи из блога Claude на русский. Оригинал — по ссылке.

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

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

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

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

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

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

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

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

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

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

Что такое жизненный цикл разработки программного обеспечения, изначально ориентированный на искусственный интеллект?

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

Сдвиги

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

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

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

Сценарии

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

Каждый сценарий охватывает:

• Что меняется;
• Начало работы;
• Конкретные шаги для реализации;
• Соображения по управлению; и
• Как Вы измеряете, сработало ли это.

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

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

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

Зафиксировать как intent.md

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

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

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

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

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

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

Как это выполнить

1. Инициатор описывает проблему Claude своими словами. Инициатор может описать, что он не может сделать сегодня, кого затрагивает идея, как выглядит улучшение или что выходит за рамки. Формальный язык не требуется.
2. Проводите мозговой штурм, пока идея не станет конкретной. Claude задаёт вопросы, которые задал бы аналитик: область охвата, пользователи, ограничения и как выглядит успех.
3. Попросите Claude записать результат как intent.md с использованием шаблона организации, который может быть закодирован как навык, настроенный техническим членом команды и утвержденный руководителем. Он может охватывать проблему, предлагаемый результат, затронутых пользователей и системы, ограничения и открытые вопросы.
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: Проектирование, записывается как слияние или закрывающая проверка.

Требования и проектирование

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

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

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

Как это выполнить

1. Владелец продукта открывает сеанс с доступными навыками организации и прикрепляет intent.md.
2. Подсказка для владельцев продукта указывает на intent.md, называет ограничения и требует отмечать проблемы. Сначала выполните ее вручную, затем оформите ее как слеш-команду уровня организации. После этого сделайте принятие intent.md в домашнем разделе намерения триггером, с неинтерактивным заданием, которое запускается при слиянии, выполните проход с загруженными навыками организации и зафиксируйте spec.md как запрос на включение изменений (схема непрерывной интеграции и непрерывной доставки/развертывания на этапе 5: «Развертывание» охватывает подключение). С этого момента первое участие владельца продукта — это проверка.
3. Тот же владелец продукта проверяет спецификацию относительно идеи. Решает ли спецификация заявленную проблему, и отвечены ли открытые вопросы из intent.md или перенесены дальше?
4. Сначала проработайте отмеченные проблемы, поскольку это те моменты, которые аналитик передал бы на эскалацию. Владелец продукта решает каждую из них с ее владельцем политики до того, как инженерная команда увидит спецификацию.
5. Зафиксируйте spec.md вместе с intent.md. Эта пара файлов фиксирует, что было запрошено и что было решено.
6. Владелец продукта решает, переходят ли спецификация и замысел к разработке, консультируясь с техническим руководителем по всему, что организация относит к более высокому риску. Это решение всегда принимает человек из команды, а принятие спецификации запускает сценарий режима планирования на этапе 3: разработка.

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

Read the attached intent.md and produce a requirements and design spec for integrating it into our existing codebase. Apply the skills available to you so the plan conforms to our brand guidelines, security policies and UX standards. Document the spec fully as spec.md, ready to hand to the engineering team. Describe clearly any areas of concern, especially where you cannot satisfy contradicting policies.

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

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

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

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

Как это выполнить

1. Инженер начинает сеанс в режиме планирования с Claude.
2. Инженер передаёт Claude файлы intent.md и spec.md и просит подготовить план реализации, в котором названы изменяемые файлы, порядок работы и тесты, подтверждающие результат.
3. Проверьте план, спросив, что может сломать это изменение, какой шаг является самым рискованным и какие другие варианты Claude решил не использовать.
4. Повторяйте итерации, пока инженер, который никогда не видел переписку, не сможет реализовать изменение, опираясь только на план.
5. Зафиксируйте утверждённый план как plan.md. План становится частью аудиторского следа, а сценарий проверки запроса на слияние (этап 5: развёртывание) сверяет итоговые различия с ним.
6. Примите план и позвольте Claude выполнить реализацию. При надёжном плане реализация часто выполняется за один проход.
7. Когда реализация отклоняется от плана, обновите plan.md в том же коммите. Рассмотрите возможность использования перехватчика, чтобы обеспечить синхронизацию между ними.

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

# 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 не может редактировать файлы, пока инженер не примет план. План и его редакции протоколируются вместе с тем, кто его принял. Рутинные изменения утверждаются инженером, а всё, что организация относит к более высокому риску, передаётся техническому руководителю или архитектору.

Claude Code в автоматическом режиме

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

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

Файл CLAUDE.md

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

Как это выполнить

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.

Навыки как институциональные знания

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

Как это выполнить

1. Выберите одну область знаний, которая сегодня применяется непоследовательно. Это может быть стандарт безопасности, соглашение о проектировании API или правило бренда.
2. Оформите ее как навык — папку, содержащую SKILL.md, в frontmatter которого указано, когда он срабатывает, а в теле — что делать. Инженер пишет его на основе «источника истины» владельца политики, используя Claude для помощи.
3. Поместите навык в репозиторий по пути .claude/skills//, чтобы он поставлялся вместе с кодом, или распространите его на уровне всей организации через плагин.
4. Проверьте, что навык срабатывает. Попросите Claude выполнить соответствующую задачу разными способами и убедитесь, что навык загружается каждый раз.
5. Когда политика меняется, измените навык и получите подтверждение изменения от владельца политики.
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.

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

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

Хуки как ограничители на этапе сборки

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

Хуки этапа сборки могут:

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

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

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

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

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

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

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

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

Как это выполнить

1. Инженер делит работу на задачи, которые затрагивают разные файлы, используя план из сценария режима планирования («Этап 3: разработка»), чтобы увидеть, где работа независима. Задачи, которые используют общие файлы, выполняются в одной сессии, одна за другой.
2. Каждая параллельная задача получает собственное рабочее дерево, например claude --worktree feature-auth в одном терминале и claude --worktree fix-rate-limit в другом. Рабочее дерево — это отдельная рабочая копия на собственной ветке, которая не даёт сессиям конфликтовать из-за файлов.
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.

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

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

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

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

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

Как это выполнить

1. Если проверка работы сегодня требует последовательности команд и некоторого знания окружения, оберните её в одну цель, такую как «make test» или «npm test», которая завершается с ненулевым кодом при сбое.
2. В разделе «Commands» файла CLAUDE.md перечислите каждую команду с примером корректного вывода.
3. Укажите цель и сделайте её количественно измеримой, чтобы Claude мог проверить работу, не спрашивая Вас, например: «Все тесты в test_status.py проходят», «снимок экрана соответствует приложенному макету» или «конечная точка возвращает 200 с новым полем».
4. При исправлении ошибок сначала пишите падающий тест. Попросите Claude воспроизвести ошибку в виде теста, запустить его и подтвердить, что он падает по той причине, которую Вы ожидаете. Зафиксируйте этот тест в коммите. Только после этого попросите Claude сделать так, чтобы тест проходил, не редактируя сам тест; хук для тестового файла из финального шага обеспечит соблюдение этого ограничения. Тест, который существовал до исправления и который агент не мог переписать, — доказательство того, что ошибка устранена.
5. При работе над пользовательским интерфейсом замыкайте цикл визуальной проверкой. Дайте 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.

Непрерывные оценки в CI

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

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

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

Как это выполнить

1. Инженер платформы собирает от 20 до 50 реальных задач из недавней работы вместе с ожидаемым или принятым результатом для каждой из них.
2. Оформите каждую задачу как оценочную проверку, то есть запрос плюс проверки, которые определяют приемлемость: тесты проходят, статический анализ кода не выявляет нарушений, поведение не изменилось, политика соблюдена.
3. Набор проверок запускается без интерактивного участия в системе непрерывной интеграции по расписанию и при любом изменении CLAUDE.md, навыков или перехватчиков, поскольку эта конфигурация направляет агента и заслуживает такого же регрессионного тестирования, какое получает код.
4. Пропускайте изменения конфигурации через контроль на основе результатов. Изменение навыка, которое снижает долю успешных прохождений, проверяется до слияния.
5. Каждый производственный инцидент получает оценку, написанную командой, которая отвечала за инцидент, и остается в наборе как регрессионный тест.

Как это выглядит (.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

Аспекты управления

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

Искусственный интеллект в цикле проверки запросов на слияние

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

Как это выполнить

1. Управляемая служба проверки кода — самый быстрый старт. Администратор включает ее и выбирает репозитории. Запускайте проверку в собственной непрерывной интеграции с помощью claude-code-action, когда Вам нужен контроль над конвейером или Вы хотите, чтобы вызовы программного интерфейса приложения маршрутизировались через Ваше собственное облачное соглашение (материал о непрерывной интеграции и непрерывной доставке охватывает эту связующую инфраструктуру).
2. Технический руководитель описывает политику проверки в REVIEW.md в корне репозитория, разделённую на проходы, которые важны для организации: ошибки и логические ошибки; безопасность и уязвимости; соответствие спецификации (spec.md из сценария требований), плану реализации (plan.md из сценария режима планирования) и принципам проектирования. REVIEW.md также определяет, что считается «Важным», в отличие от «Мелочи», и что следует пропускать.
3. Технический руководитель устанавливает порог участия человека. Находки сами по себе не одобряют и не блокируют запрос на включение изменений, а защита ветки по-прежнему требует одобрения от владельца кода. Инженер платформы, который хочет ограничивать слияния на основании находок, может считывать количество по уровням серьёзности, которое проверочный запуск публикует как машиночитаемую сводку.
4. Когда ревьюер или автор отмечает @claude в комментарии к ревью, Claude отвечает на комментарий и отправляет исправление. Ветка обсуждения PR фиксирует и запрос, и изменение. Этот цикл исправлений выполняется через claude-code-action. В управляемом сервисе комментарий @claude review вместо этого запрашивает новое ревью. Для PR, открытых Claude, идите дальше и позвольте Claude присматривать за PR до слияния. Команды оборачивают цикл в пользовательскую слеш-команду, которая проходит по неразрешённым комментариям ревью и неуспешным проверкам в 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 применяется ко всем запросам на включение изменений, а обнаруженные проблемы, исправления, оценки и утверждения регистрируются в истории запроса на включение изменений, поэтому запрос на включение изменений является аудиторской записью. Утверждение поступает от человека через защиту ветки с учетом обнаруженных проблем.

Хуки как контрольные точки утверждения

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

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

Как это выполнить

1. Руководство инженерного подразделения совместно с управлением изменениями и комплаенсом перечисляет контрольные точки утверждения человеком, которые должны сохраниться, такие как согласование управления изменениями, разрешение на выпуск и изменения защищенных путей.
2. Платформенный инженер выражает каждый шлюз как хук — скрипт, который выполняется до того, как Claude начнёт действовать, и может разрешить, запросить подтверждение или заблокировать действие.
3. Командные хуки размещаются в .claude/settings.json в git, а не подлежащие обсуждению хуки размещаются в управляемых настройках, принадлежащих платформе или ИТ-администратору, где отдельные инженеры не могут их отключить.
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 и развёртывание

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

Как это выполнить

1. Инженер платформы начинает с шагов оценки только для чтения. Используйте claude -p в задании конвейера, чтобы провести первичный анализ неудачной сборки, обобщить нестабильный тест или подготовить черновик журнала изменений.
2. Добавьте шаги записи за существующими шлюзами для заданий вроде исправления линтинга, обновления сгенерированной документации или обработки комментариев к ревью через упоминания @claude. Всё, что записывает агент, поступает как PR через защиту ветки, и у агента нет способа отправить изменения в main.
3. Выполнение изолировано в песочнице. Задания агента выполняются в контейнерах в рамках сетевой политики с краткосрочными токенами с ограниченной областью действия и по умолчанию не имеют производственных учетных данных.
4. Откройте развертывание через MCP. Развертывание, статус и откат становятся инструментами, ограниченными по средам, поэтому полномочия агента по развертыванию — это список разрешений, а не shell-скрипт с учетными данными.
5. Разделите автономность по средам на уровни. В среде разработки агент выполняет развертывание свободно. В производственной среде агент подготавливает релиз, а менеджер релиза авторизует его, и хук обеспечивает соблюдение производственного шлюза. Промежуточная среда находится где-то посередине.
6. Откат должен быть самым отработанным путем в конвейере — одной командой, которую агент может выполнить и которая регулярно проверяется в промежуточной среде. Сценарий замыкания цикла (этап 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

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

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

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

Сопровождение и замыкание цикла

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

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

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

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

Как это выполнить

1. Владелец сервиса или платформенный инженер выбирает одну метрику со стабильной скользящей базовой линией, например долю сбоев тестов непрерывной интеграции, долю ошибок 5xx после развёртывания или время цикла запроса на включение изменений.
2. Они пишут скрипт обнаружения, обычно используя среднее значение и стандартное отклонение по скользящему окну с правилами (Western Electric или аналогичными), чтобы полосы выявляли как медленный дрейф, так и всплески. Скрипт находится под управлением версий и покрыт модульными тестами, а обнаружение остается полностью детерминированным, без участия модели.
3. Уровни реагирования определены в конфигурации под управлением версий (bands.yaml ниже). При 1σ скрипт только ведет журнал, при 2σ он вызывает Claude в режиме только для чтения для диагностики, а при 3σ Claude может действовать, но только открывая запрос на слияние в контрольный этап проверки или запуская заранее утвержденный регламент.
4. Слоем запуска может быть запланированный рабочий процесс в GitHub или GitLab, веб-перехватчик из существующего стека мониторинга или задание Cron внутри сети. Claude работает без сохранения состояния, либо как неинтерактивный шаг на средстве выполнения непрерывной интеграции, либо как сервис Agent SDK в изолированном контейнере, а сценарий непрерывной интеграции и непрерывной доставки охватывает варианты развертывания и доступа к модели. Поскольку запуск выполняется без сохранения состояния и неинтерактивно, цикл может начаться и завершиться без того, чтобы кто-либо его запускал.
5. Агент записывает свой диагноз как intent.md в формате «Этап 1: План», охватывая аномалию и подтверждающие её данные, предлагаемый результат, затронутые системы и любые открытые вопросы. После этого обнаруженная проблема проходит через конвейер, как и всё остальное.
6. Владелец сервиса или дежурный инженер выполняет сортировку очереди, направляя обнаруженные проблемы, затрагивающие продукт, владельцу продукта. Исправить сейчас, запланировать или отклонить. Отклонения настраивают диапазоны и помогают снизить уровень шума.
7. Когда исправление выпускается, добавьте оценку для инцидента (практика непрерывных оценок), чтобы обеспечить защиту от таких проблем в дальнейшем.

Как это выглядит (например, bands.yaml, отслеживающий частоту сбоев тестов непрерывной интеграции)

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] }

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

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

Примеры

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

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

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

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

Инциденты — не единственная работа, которую Claude Tag берёт в работу. Если Claude отмечают в задаче через MCP или просят в канале, он сортирует работу таким же образом. Небольшое, чётко ограниченное исправление поступает в виде запроса на слияние через этап проверки, а всё более крупное оформляется как intent.md для этапа 1: «План», после чего цикл начинает подпитывать сам себя.

Заключительные мысли

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

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

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

Ресурсы и благодарности

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

Спасибо Джиму Блэкхерсту, Уиллу Стюку и Джамалу Арифу за их вклад в это руководство, которое было вдохновлено и построено на основе значительной части их предыдущей работы.