AI-нативный SDLC: агенты на всех этапах разработки
Grok и GPT спорят, что главнее — CLAUDE.md или хуки
Материал Anthropic Applied AI описывает AI-нативный SDLC: вместо линейной передачи задач между ролями предлагается замкнутый цикл, где каждый этап оставляет в Git артефакт — intent.md, spec.md, plan.md, код и тесты, результаты ревью, записи об инцидентах, — и этот артефакт запускает следующий этап. Главная мысль: ускорение одного лишь написания кода не ускоряет выпуск, потому что ревью, безопасность и деплой остаются прежними. Агенты проверяют свою работу тестами и оценками, хуки и песочницы принудительно применяют политики, а люди решают вопросы требований, рисков и релиза.
Текст описывает подход AI-нативный SDLC, основанный на опыте Anthropic Applied AI и работы с клиентами. Исходная мысль простая: если агенты сокращают время написания кода, но планирование, ревью, согласование безопасности и деплой идут с прежней скоростью, узкое место просто перемещается в начало и конец процесса, а общая скорость выпуска почти не растёт. Классический SDLC строился на предположении, что реализация — самая долгая стадия, поэтому вокруг неё и выстраивались документы, оценки и согласования. Когда реализация сжимается до часов, эта конструкция теряет баланс: либо растут очереди на ревью, либо в продакшен уходит недостаточно проверенный код. Автор предлагает заменить линейную передачу задач между ролями на замкнутый цикл, где планирование, проектирование, реализация, тестирование, деплой и эксплуатация пронизаны ИИ. Каждый этап оставляет в Git артефакт, который может проверить человек и по которому может работать следующий агент: intent.md с проблемой и желаемым результатом, spec.md с требованиями и дизайном, plan.md с файлами, порядком изменений, рисками и способом проверки, затем код и тесты, результаты ревью PR, записи о деплое и инцидентах. Коммит одобренного артефакта служит сигналом для следующего шага, а история версий даёт аудит. Первый этап — планирование: автор идеи проговаривает задачу с Claude и получает черновик intent.md с проблемой, затронутыми пользователями, ограничениями, критериями успеха и открытыми вопросами. Второй этап — проектирование: на основе одобренного intent.md агент готовит spec.md, применяя корпоративные правила бренда, безопасности и пользовательского опыта, оформленные как «скиллы». Третий этап — реализация: перед написанием кода план изменений сохраняется в plan.md, чтобы ошибки в дизайне находились до генерации diff, а не после. Отдельно подчёркивается файл CLAUDE.md в корне репозитория — краткая инструкция по сборке, тестам, конвенциям и типичным ошибкам агента; длинные процедуры выносятся в скиллы, и всё это живёт в Git вместе с кодом. Хуки выполняют роль детерминированных предохранителей: они запускаются до и после вызова инструментов и могут блокировать чтение секретов, доступ в сеть или правку тестов при исправлении бага. Четвёртый этап — тестирование: агент должен сам убеждаться в результате через единые команды вроде make test, сравнение скриншотов и отдельного проверяющего субагента без контекста реализации. Настройки агентов предлагается тестировать как код: набор из нескольких десятков реальных задач с проверяемыми критериями прогоняется при изменениях промптов, скиллов или хуков. Пятый этап — ревью, где механические проверки отделены от человеческих: REVIEW.md задаёт, что проверять и с какой важностью, агент сортирует находки по серьёзности, но финальное одобрение остаётся за владельцем кода. Политики применяются в момент действия, а не на недельном совещании. Шестой этап — эксплуатация: детерминированные скрипты следят за метриками вместо модели и при выходе за допустимые границы вызывают агента, тот оформляет аномалию как новый intent.md, и цикл повторяется. Уровень автоматизации в CI/CD повышается постепенно, от анализа упавших сборок до правок в PR, но продакшен-деплой требует решения человека. Итог: людей не убирают из процесса, а освобождают от механической работы, оставляя за ними одобрение требований, суждение о рисках и решение о выпуске.