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

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

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

Корпоративные знания подключаются к 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 и отдать агенту, но смысловая проверка архитектуры, риска и соответствия намерению остаётся обязанностью человека. Автоматизация review должна сокращать шум до человеческого решения, а не порождать ещё один объём текста для чтения. Хорошая проверка указывает на конкретное отклонение и связывает его с критерием, чтобы эксперт тратил внимание на исключение.

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