AI-native SDLC: как замкнуть цикл от намерения до эксплуатации

Участники сразу отделяют жанр документа от исследования: это подробное руководство команды Claude с шаблонами и примерами, но без сравнительного эксперимента. Большинство отдельных практик уже знакомо по разработке и DevOps; ценность playbook — в том, что они собраны в единый маршрут. Его исходный тезис прост: когда агент быстро пишет код, ограничением становятся постановка задачи, проектирование, проверка, review, выпуск и эксплуатация. Локальная оптимизация Build не ускоряет delivery, если соседние этапы продолжают работать через очереди и ручные передачи.

Вместо линейной эстафеты предлагается цикл Plan, Design, Build, Test, Deploy и Maintain. На входе Plan продуктовый автор может описать проблему обычным языком или голосом, а модель задаёт уточняющие вопросы и оформляет intent.md: проблему, желаемый результат, ограничения и способ проверить успех. Design превращает намерение в spec.md. Оба документа версионируются, поэтому при неверном результате можно вернуться не только к коду, но и к ошибочной спецификации или исходному намерению. Прослеживаемость здесь нужна для исправления решений, а не ради архива документов.

Корпоративные знания подключаются к Design как CLAUDE.md, skills и политики: технологические ограничения, разрешённые API, требования безопасности, удачные примеры и уроки инцидентов. Антон подчёркивает преимущество декларативного правила перед длинной императивной инструкцией: оно меньше зависит от поведения конкретной версии модели. Но для крупной регулируемой организации рекомендательной подсказки недостаточно. Критичные требования должны дублироваться детерминированными проверками, правами и CI/CD-gates, а исключения — становиться новыми тестами и eval-сценариями.

Build начинается не с генерации кода, а с plan.md. Красиво структурированный план легко принять на веру, поэтому человек должен проверить последовательность действий до дорогой реализации: это перенос design review в точку, где исправление ещё дёшево. Затем агент использует проектные инструкции, команды, hooks, skills, подагентов и автоматический режим. Защита должна отдельно запрещать утечку секретов, обход проверок и подгонку тестов под текущую реализацию. Первые задачи могут в основном строить саму обвязку; доверие к ней появляется только из статистики принятых результатов, регрессий и инцидентов.

Test сочетает обычные тесты и security scanners с continuous evals агентного процесса. Набор проверок растёт из реальных исключений и запускается после смены модели, промпта или обвязки. Deploy в playbook во многом использует знакомые release gates, а Review становится новым узким местом: объём сгенерированных изменений растёт быстрее человеческого внимания. Hooks жёстко блокируют формальные нарушения, повторяемые вопросы можно вынести в review.md и отдать агенту, но смысловая проверка архитектуры, риска и соответствия намерению остаётся обязанностью человека.

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