6 этапов разработки с ИИ: собери процесс от идеи до сопровождения

Основа: статья Луиса Клакстона «The AI-native SDLC playbook», Anthropic, 21 августа 2026 года, в полном тексте.

01. Определи, где хранится решение

В примере Anthropic постановка задачи живёт в intent.md, требования в spec.md, реализация в plan.md. Но у команды уже могут быть Jira, ServiceNow, Figma и отдельная система требований. Если два документа расходятся, агенту нужен способ понять, какой из них главный.

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

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

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

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

02. Преврати идею в intent.md

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

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

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

Готово, когда: другой участник команды понимает, что требуется и почему, не читая исходный чат.

Что измерять: время от первого обсуждения до коммита intent.md; долю принятых постановок; изменения постановки после начала проектирования. Ожидаемое в статье сокращение до часов — ориентир авторов, а не обещание результата твоей команды.

03. Получи спецификацию с разрешёнными противоречиями

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

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

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

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

Что измерять: время между коммитами intent.md и spec.md; количество изменений спецификации после появления первого plan.md.

04. Разбери план до написания кода

В примере plan.md из статьи перечислены конкретные файлы панели статуса, серверного маршрута и теста. Там же указан риск: API допускает 50 запросов в секунду, поэтому панели нужно кеширование. Это характеристика учебного примера, не стандарт для твоего API.

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

• Начни сессию в режиме планирования и передай intent.md и spec.md.
• Попроси перечислить изменяемые файлы, порядок работы и проверки результата.
• Разбери с агентом, что может сломаться, какой шаг самый рискованный и какие альтернативы он отверг.
• Доработай план до состояния, в котором инженер без доступа к переписке сможет выполнить задачу.
• Зафиксируй одобренный plan.md и только после этого запускай реализацию.
• Если реализация отклоняется от плана, обновляй документ в том же коммите.

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

Что измерять: время от принятия плана до слияния; долю изменений, проходящих с первой реализации; количество переделок.

05. Запиши знания команды в CLAUDE.md и навыки

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

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

• Запусти /init и сократи результат до команд, ключевых соглашений, архитектуры и типичных ошибок.
• Проверь каждую команду сборки, тестирования и анализа кода, которую записываешь в CLAUDE.md.
• Сохрани файл в корне репозитория и включи его изменения в обычную проверку кода.
• Применяй правило из статьи: повторившуюся дважды ошибку превращай в конкретное указание в CLAUDE.md.
• Выбери правило, которое применяется непоследовательно, и оформи его в SKILL.md с условиями вызова и процедурой.
• Проверь вызов навыка на разных формулировках подходящей задачи.
• Назначь владельца навыка; обновляй и согласовывай его при изменении исходного правила.

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

Что измерять: повторение уже описанных ошибок; время обновления навыка после изменения правила; замечания проверяющих по тому же правилу.

06. Подкрепи обязательные правила техническими ограничениями

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

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

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

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

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

07. Распараллель только независимые задачи

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

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

• Разбей принятый план на задачи и проверь пересечения по файлам.
• Последовательно выполняй задачи, которые редактируют общие файлы.
• Для независимых задач создай отдельные рабочие деревья Git и ветки.
• Начни с двух или трёх сессий и проверь, успеваешь ли разбирать их результаты.
• Повторяемые узкие работы оформи как субагентов в .claude/agents/ с описанием роли и разрешённых инструментов.
• Сохрани определения в Git; проверь применение общих ограничений ко всем сессиям.

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

Что измерять: число одновременных сессий вместе с качеством проверки; слитые изменения на инженера в неделю вместе с долей переделок.

08. Замкни проверку результата и проверку самого агента

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

Отдельно проверь конфигурацию агента. Смена модели, навыка или CLAUDE.md способна изменить качество работы даже при неизменном приложении. Для этого авторы предлагают набор из 20–50 реальных задач с ожидаемыми результатами.

• Сделай запуск подходящих проверок однокомандным, с ненулевым кодом завершения при неудаче.
• Запиши команды и признаки успешного результата в CLAUDE.md.
• Для исправления ошибки сначала воспроизведи её тестом и проверь причину падения.
• Зафиксируй тест до исправления; обеспечь запрет его ослабления в рамках этой задачи.
• После исправления выполни проверки и приложи фактический вывод.
• Для интерфейса пройди цикл «реализация → снимок → сравнение → исправление» и проверь поведение.
• Собери 20–50 реальных задач для оценочного набора: запрос, ожидаемый результат и независимые проверки приемлемости.
• Запускай этот набор при изменении конфигурации агента и по выбранному расписанию; оцени затраты на вызовы модели.
• Добавляй каждый разобранный инцидент в набор как регрессионный случай.

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

Что измерять: успешность первого запуска CI; долю успешных оценочных проверок; время превращения инцидента в постоянную проверку; регрессии, найденные до и после выпуска.

09. Настрой проверку изменений в обе стороны

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

Автор изменений не получает права сам одобрить результат. Защита ветки сохраняет решение за владельцем кода. Учти различие интеграций: в управляемом Code Review команда @claude review запрашивает новую проверку, а цикл исправления комментариев описан через claude-code-action.

• Выбери подходящую интеграцию проверки и включи её для пилотного репозитория.
• Создай REVIEW.md с проходами по ошибкам, безопасности и соответствию spec.md и plan.md.
• Определи существенные замечания через нарушение поведения, утечку данных или нарушение правила.
• Ограничь мелкие замечания; пример статьи допускает не более пяти за проверку.
• Исключи сгенерированные файлы и замечания, которые уже надёжно проверяет CI.
• Настрой обязательное одобрение владельца кода и проверь отсутствие обхода у автора-агента.
• Возвращай повторяющиеся замечания в CLAUDE.md; раз в месяц пересматривай качество проверки.

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

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

10. Доведи изменения до выпуска с проверенным откатом

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

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

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

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

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

11. Замкни сопровождение на новую постановку

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

Для мониторинга статья приводит пример уровней 1σ, 2σ и 3σ: записать, диагностировать, предложить действие по разрешённому маршруту. Эти пороги иллюстрируют схему; они не заменяют настройку детектора под конкретную метрику.

• Выбери метрику со стабильным скользящим базовым уровнем и доступным источником данных.
• Реализуй детерминированное обнаружение отклонений; сохрани скрипт в Git и проверь его тестами.
• Раздели реакции в версионируемой конфигурации: запись, диагностика только на чтение, запрос на слияние или заранее одобренная процедура.
• Настрой автоматический запуск через расписание или событие; задай разрешения для каждого уровня.
• Поручи агенту сохранять диагноз в intent.md с доказательствами, системами, предполагаемым результатом и вопросами.
• Назначь разбор очереди: исправить, запланировать или отклонить с причиной; используй отклонения для настройки детектора.
• Для регулярного сканирования безопасности назначь владельцев репозиториев, расписание и бюджет; сохраняй оценку уверенности и причины отклонения находок.
• Ограниченную находку направляй в запрос на слияние, архитектурную проблему — в intent.md; сохраняй существующие проверки безопасности в CI.
• Если инциденты обрабатываются в рабочем канале, сохраняй там запрос, диагноз, разрешение и результат; извлечённые уроки записывай в версионируемый документ.
• После выпуска исправления добавляй случай в оценочный набор и проверяй повторные инциденты того же класса.

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

Что измерять: время от сигнала до постановки; долю находок, превратившихся в слитые исправления; повторные инциденты; время от находки сканирования до запроса на слияние.

12. Сними противоречия до расширения автономности

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

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

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

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

13. Возьми одну задачу и проведи её через весь маршрут

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

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

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

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

Задания для первого прохода

Это редакционные шаблоны для применения чек-листа. Они не являются дословными цитатами из статьи.

Подготовить постановку

Подготовить спецификацию и план

Проверить готовность изменения

Источник и редакционные границы

Первоисточник: The AI-native SDLC playbook — Anthropic, 21 августа 2026 года.