Я занимаюсь работой с экспериментальными AI-first командами и исследую гипотезу о том, что Lead Time снижается если внедрить Agentic Engineering. Наш опыт, а также примеры из индустрии показывают - в Greenfield-проектах (с нуля) время от написания требований до выкатки на прод сокращается.
Но время реализации сокращается по-разному, в зависимости от контекста. Я попробовал систематизировать свой опыт и порассуждать:
как AI меняет цикл разработки в Greenfield, Brownfield и highly regulated проектах - и на какие метрики обращать внимание;
в чем теперь фокус взаимодействия между членами команды, какие этапы становятся неактуальными.
Внимание: пост - призыв к дискуссии, нежели утверждение.
Три сценария: как SDLC сворачивается по-разному
Нет универсального “нового SDLC” где только агенты и 0 человек. В реальности будет спектр сценариев. В каждом сценарии есть изменения, а также метрики, за которыми надо следить, чтобы не стало хуже.
Сценарий 1: Greenfield-проект
В этом сценарии у нас нет никакой старой кодовой базы, пользоваталей. Цена ошибки низкая, скорость критична. Это, кажется, самый близкий вариант к полному agentic-engineering (в терминах товарища Карпатый) и видению в статье SDLC is dead.
Что меняется:
Security-critical код (например, авторизация) — 100% code review делается человеком; остальное — автоматизированные и выборочные проверки
Основным контуром защиты прода выступает Observability (канареечные релизы и автоматические откаты). Но этот механизм должен опираться на фундаментальные инженерные практики: многоуровневое тестирование, грамотную архитектуру с низкой связностью модулей, чистый дизайн и разработку на основе типов.
Итерации с результатами теперь за кратно меньшее количество времени
Время реализации снижается радикально.
Как убедиться что мы не сделали хуже:
Lead Time <= 1 день
Deployment Frequency > 1/день и чаще
Change Failure Rate <= “Хорошо” по DORA (0-15%)
Сценарий 2: Brownfield (Существующий продукт)
Разберем ситуацию, когда у нас уже есть пользователи, есть технический долг. Цена ошибки для нас выражается в реальных деньгах.
Что меняется:
По код-ривью нужен трехуровневый подход по риску:
Тип кода | % Code Review, выполняемый человеком | Примеры |
Безопасность, Критичный код | 100% review старшими-специалистами | Auth, payment gateways, персональная информация, крипта |
Бизнес-логика | 30-40% ревью живыми коллегами | Фичи, API, потоки данных |
Утилиты и прикладные инструменты | Агентский/Автоматизированный code reivew + выборочные проверки | Тесты, доки, конфиги |
По данным LinearB 2026 Benchmarks, AI PR мержатся в 32.7% случаев против 84.5% у человеческого кода — большая часть требует доработки.
Человек ответственен за валидацию, особенно для кода с высоким радиусом поражения
Обязательная поэтапная выкатка через препрод-среды + надежная observability-обвязка (проактивный мониторинг и автоматический откат).
Время реализации снижается значительно.
Как убедиться что мы не сделали хуже чем было:
Время на Code Review не растёт (несмотря на больше PR)
Количество дефектов стабильно или не растет
SLA/SLO не снижаются
Удовлетворенность разработчиков не падает
Сценарий 3: Регулируемая индустрия (финтех, медтех, страхование)
Это по сути тот же Brownfield + толстый регуляторный слой сверху.
FYI: Brownfield уже подразумевает что есть легаси.
В этом сценарии Compliance-отдел и аудиторы требуют человеческой ответственности и истории изменений.
Что меняется в процессе разработки:
AI ускоряет отдельные этапы или связку этапов. Это частично сокращает простои, но решения так же принимаются человеком (должен быть ответственный).
Этапы могут объединяться (например, Compliance + Требования, Безопасность и Аудит решений). Но выбросить окончательно их не получится: нужно оставлять следы для аудита (обязательно трекать кто сгенерировал, кто заапрувил, что изменилось).
Радикального снижения времени реализации мы уже не добиваемся.
Как убедиться что мы не сделали хуже чем было:
Change Failure Rate не растет
Постепенно сокращается время на проверку соответствия решения регуляторке (на соответствующих этапах)
Скорость разработки растёт, при этом продукты и сервисы продолжают соответствовать регуляторке
Большой дисклеймер: мы много спорили с коллегами не похож ли флоу в компаниях с кучей регуляторки больше на Brownfield-пример. Ревью требований по комплаенсу выглядит как работа для ИИ - потому что сопоставить соответствие неумолимой букве закона - хорошая задачка для ИИ-шки. С точки зрения безопасности - сейчас есть энтерпрайз и не только модели, которые хорошо сканируют системы на предмет уязвимостей.
Напишите в комментах, как с вашей точки зрения: история с регулируемыми индустриями больше похожа на Brownfield из предыдущего примера, на текущий пример, или на что-то совсем другое!
Больше подобной аналитики, обзоров и кейсов AI в менеджменте можно увидеть в моем канале.
