Организации начали использовать ИИ для написания кода со скоростью, немыслимой год назад, однако процессы, связанные с кодом, не изменились с той же скоростью.
Многие инженерные команды по-прежнему имеют те же этапы согласования (approval gates), ревью (reviews), передачи задач (handoffs) и политики, что замедляет рост производительности, достигнутый благодаря использованию агентных решений для кодирования, таких как Claude Code.
Традиционный SDLC
Жизненный цикл разработки программного обеспечения (SDLC) — это процесс, который переводит ПО от идеи до продакшена. Большинство организаций используют ту или иную версию одних и тех же шести этапов, охватывающих планирование, проектирование, создание, тестирование, развертывание и сопровождение ПО. Традиционно каждый этап представляет собой отдельную фазу, за которую отвечает своя роль. Продакт-менеджеры пишут требования, технические архитекторы превращают их в проекты, инженеры создают эти проекты, команды QA в регулируемых предприятиях проверяют ПО, команды релизов выпускают его, а операционные команды (operations) отслеживают его работу. Работа между фазами перемещается посредством документов, тикетов и согласований (sign-offs).
Традиционный жизненный цикл разработки ПО (SDLC) является процессным и ориентирован на обеспечение подотчетности и контроля на каждом шаге. Однако традиционный SDLC был разработан для максимизации эффективности в эпоху, когда самым трудоемким и дорогостоящим этапом было написание и внедрение кода, что уже не так. Документы с требованиями к продукту (PRD), ритуалы оценки и проверки безопасности продукта (product security reviews) — все это существовало для обеспечения согласованности в течение недель, месяцев или кварталов работы по разработке.
Традиционный SDLC также включает механизмы контроля, которые предполагают, что каждый шаг выполняется людьми. Организации, создающие наибольшую ценность, перестроили свои процессы вокруг того, что теперь может делать агентный ИИ, при этом гарантируя, что люди остаются в цикле (in the loop). В этом руководстве мы рассмотрим несколько лучших практик нашей команды Applied AI по внутренней интеграции Claude на каждом этапе SDLC для ускорения разработки и оптимизации процессов, вдохновленных работой с нашими клиентами.
Когда код перестает быть узким местом
Когда код перестает быть узким местом, а фаза сборки (build phase) выполняется быстрее, чем позволяет традиционный SDLC, становятся верными три утверждения:
-
Узкое место перемещается на этапы, предшествующие и следующие за фазой сборки: в основном планирование, ревью/тестирование и развертывание, которые по-прежнему выполняются со скоростью человека.
-
Механизмы контроля перестают соответствовать реальности и становятся трудноразрешимыми. Ручное ревью каждой строки имело смысл, когда ее писал человек, но это становится невозможным, когда агенты пишут большую часть изменений (diff).
-
Затраты на управление (governance) возрастают, потому что исключения по-прежнему проходят через совещания и комитеты, которые собираются еженедельно или ежемесячно.
Узкое место сместилось: сборка (build) сокращается до скорости агента, в то время как окружающие этапы по-прежнему выполняются со скоростью человека.
Рассмотрим узкое место в безопасности в качестве примера. Команды безопасности рассчитаны на человеческую производительность, поэтому, когда агенты многократно увеличивают объем кода, либо очередь на ревью растет, либо код выпускается без должного ревью. Регулируемая организация не может принять ни один из этих исходов, поэтому ее проверки безопасности и политик должны идти в ногу с агентами.
Чтобы лучше реализовать прирост производительности и обеспечить безопасность агентного ИИ, традиционный жизненный цикл SDLC требует такого же уровня трансформации, какой претерпела фаза реализации.
Что такое AI-native SDLC?
AI-native SDLC — это переосмысленный процесс, который сочетает старые цели контроля с новыми методами их обеспечения. Вместо линейного потока процесс становится циклом, и ИИ встроен в каждую точку. AI-native SDLC способствует автоматизированной передаче (handover) и запуску последующих сценариев (plays), помогая решить проблему ручного и громоздкого характера передачи задач (handoff) между фазами традиционного SDLC.
Традиционный линейный SDLC (слева) и AI-native непрерывный цикл (справа), с людьми, расположенными над циклом, инициирующими, направляющими и управляющими.
Изменения
В таблице ниже показаны крайние точки спектра между традиционным SDLC и AI-native SDLC, поддерживаемым Claude. Большинство организаций находятся где-то между этими двумя столбцами.
| Этап | Традиционный SDLC | AI-native SDLC |
|---|---|---|
| Планирование | Требования собираются комитетом, уточняются на воркшопах и согласованиях, записываются вручную | Claude синтезирует болевые точки непосредственно из источников и фиксирует их в intent.md, который читаем человеком и машиночитаем (machine actionable) |
| Проектирование | Спецификация пишется аналитиками, разбирается дизайнерами | Требования и дизайн сжимаются в одну рабочую сессию с агентом, руководствуясь стандартами, закодированными как skills, версионируются в Git |
| Сборка | Тесты и код пишутся вручную, а документация пишется после основной разработки | Тесты и код генерируются ИИ, а институциональные знания поддерживаются как версионированные машиночитаемые файлы CLAUDE.md и skills |
| Тестирование | QA-гейты на границах этапов | Непрерывные evals, интегрированные в реализацию |
| Развертывание | Люди просматривают каждую строку кода, а управление (governance) происходит в циклах ревью, часто непоследовательно | Слои агентного ревью с человеческим ревью, зарезервированным для регулируемого и критически важного кода. Управление (governance) обеспечивается по мере действия ИИ, с хуками (hooks) в качестве этапов согласования (approval gates) |
| Сопровождение | Люди следят за продакшеном на предмет багов | Агенты отслеживают активные развертывания (live deployments). Любое нарушенное контрольное ограничение (control band) диагностируется и записывается обратно в цикл как новый intent.md |
Что объединяет столбец AI-native, так это зафиксированный артефакт (committed artifact). Каждый этап завершается записью артефакта в систему контроля версий (включая intent.md, spec.md, plan.md, diff и его тесты, PR с результатами ревью и запись об инциденте), а следующий этап начинается с его чтения. Для ранних этапов файлы .md являются преобладающим артефактом, потому что владелец продукта и агент могут читать и действовать на основе одного и того же файла. Начиная с этапа сборки (Build), артефактом является код и его записи. Цепочка коммитов также является аудиторским следом: кто что запросил, что произвел агент и кто это одобрил.
Люди остаются ответственными за каждое решение, требующее суждения. В мире агентного SDLC внимание человека смещается вместе с артефактами, которые должны быть просмотрены.
Как работают сценарии (plays)
Сценарии (plays) являются ядром плейбука и сгруппированы в шесть нелинейных этапов (Планирование, Проектирование, Сборка, Тестирование, Развертывание, Сопровождение), которые вместе охватывают полный жизненный цикл.
- Что меняется
- Начало работы
- Конкретные шаги по реализации
- Вопросы управления (governance)
- Как измерить эффективность
Сценарии (plays) являются модульными, и организации могут выбрать приоритетное преобразование различных этапов в разное время в зависимости от своих уникальных потребностей. Каждый сценарий (play) указывает свои зависимости в разделе "Предварительные условия" (Prerequisites), что дополнительно иллюстрируется графом зависимостей.
Этап завершается фиксацией артефакта, при этом коммит инициирует следующий этап. Принятый intent.md запускает прохождение требований и дизайна, одобренный spec.md запускает режим планирования, объединенный PR запускает пайплайн, а нарушенное контрольное ограничение (control band) в продакшене записывает следующий intent.md, и так цикл продолжается.
Сначала вы вручную инициируете каждый шаг, при этом конечным состоянием является цикл, в котором каждый принятый артефакт запускает следующий гейт. Внимание человека концентрируется на гейтах, просматривая то, что отметил агент, вместо того чтобы начинать каждый этап с нуля.
Граф зависимостей сценариев (plays). Сценарии (plays) в верхнем ряду не имеют предварительных условий; сплошная стрелка указывает на сценарии, которые на нем строятся, пунктирная стрелка означает, что это помогает, но не является обязательным.