Я занимаюсь работой с экспериментальными AI-first командами и исследую гипотезу о том, что Т2М снижается если полностью внедрить Agentic Engineering.

В феврале вышла статья Boris Tane: SDLC мертв, агенты его убили. С этим постом не согласен — SDLC меняется, но по-разному, в зависимости от контекста. Поэтому попробуем порассуждать и разобрать,

• как AI меняет цикл разработки в Greenfield, Brownfield и highly regulated проектах — и на какие метрики обращать внимание;

• в чем теперь фокус взаимодействия между членами команды, какие этапы становятся неактуальными. 

Внимание: пост — призыв к дискуссии, нежели утверждение.

Как AI влияет на SDLC

Стоимость изменений кода падает

Раньше мы инвестировали в согласование дизайна насколько возможно заранее, потому что переписывать дорого. Даже в Agile мы старались не фиксировать архитекуру, но всё равно опирались на то, насколько дорого будет вносить радикальные изменения. С AI изменения становятся ощутимо быстрее и дешевле*:

• Переписать модуль часто можно в рамках одного дня,

• Сгенерировать три варианта архитектуры и сравнить — пара-тройка дней,

• Проработать гипотезу через прототип вместо документа — ощутимо быстрее, чем обсуждать

*написать код теперь быстро, но чтобы он нормально работал надо еще вложиться в спецификации, корректно настроить окружения, убедиться что вы продумали работу с тестами и валидацию результата

Это означает что нам нужен другой тип планирования:

• Еще меньше детальных спецификаций по реализации заранее (потому что проще переписать)

• Больше четких constraints (ограничений): масштабируемость, безопасность, разрешённые библиотеки, критерии приемки

• Гипотезы проверяются прототипами, собранными с помощью агентов. Не документами (как раньше) или не написанным человеком кодом

Взаимодействие изменяется

С AI некоторые аспекты коллаборации меняются:

• Переделка дешевле → цена ошибки ниже → можно меньше согласовывать наперёд и просто пробовать реализовать (в том числе и в одиночку)

• Один человек с AI может потенциально сделать то, что раньше требовало команды — написать код, покрыть тестами, проверить на типовые уязвимости (конечно, со всеми ограничениями — контекст, специфика технической реализации, знание доменной области и другое)

Это снижает два типа потерь:

• Ожидание в очереди. Раньше задача простаивала, пока какой-нибудь архитектор баз данных или инженер-безопасник освободится. С AI часть этой работы делается сразу.

• Зависимость от ключевого специалиста (bus factor). Единственный, кто знает модуль — в отпуске? AI даёт контекст любому члену команды, чтобы продолжить работу (опять же при условии что он сам имеет изначальный контекст). Это спорный аргумент и палка о двух концах: команды становятся меньше -> один-два человека делают всё -> кто-то из них уходит и bus-factor опять растет

Раньше контекст задачи делился между участниками команды — каждому свой кусочек, а дальше на синках выравнивались. Теперь один человек + AI делает фичу целиком, и ему нужен полный e2e контекст. Когнитивная нагрузка на одного человека растёт.

Большую часть работы с ИИ-агентом теперь может выполнять один человек-оркестратор. При этом ценность парного программирования и моббинга не исчезает: команде по-прежнему важно распределять знания (снижая bus factor) и совместно проверять качество решений. 

Поэтому взаимодействие в команде смещается к совместной валидации результата, проектированию ограничений для агента и формированию качественного контекста

Декомпозиция становится критичной

AI-агенты работают лучше всего с маленькими, чётко сформулированными задачами — как если бы мы объясняли задачу джуниору:

• Конкретная цель с ясными границами

• Один проверяемый результат

• Контекст умещается в голове (или в контекстное окно агента). Не нужно смотреть что у нас окно в миллион токенов, ведь чем больше токенов — тем меньше их вес.

На практике это означает: если раньше senior мог взять размытую задачу и сам её декомпозировать, то теперь декомпозиция до атомарного уровня — это часть подготовки работы для агента. Тот, кто умеет хорошо формулировать задачи «как для джуна», получает лучшие результаты от AI.

Чем крупнее задача → тем больше агент «галлюцинирует» или теряет фокус. Важна атомарность задачи для агента.

Ловушка: соблазн воспроизвести waterfall — “сначала всё распланируй, напиши спеки,
потом отдай агенту”. Это не работает. Работа с AI — это те же итерации и мелкие батчи,
просто быстрее. Агент — парный партнёр для коротких циклов, а не исполнитель большого ТЗ (что бы вам не говорили про оркестраторов). Поэтому и декомпозиция должна быть от ценности, а не разделенная по компонентам.

Code Review становится узким местом

Код генерируется быстрее, чем люди успевают его проверять. По данным CodeRabbit, PR от AI-ассистентов получают в среднем 10.8 замечаний против 6.4 у человеческого кода — review занимает больше времени.

Три сценария: как SDLC сворачивается по-разному

Нет универсального “нового SDLC”. Мне кажется, в реальности будет спектр сценариев. В каждом из этих сценариев есть то, что меняется. А также метрики, на которые, как я считаю, нужно обращать внимание чтобы следить за “успехом”

Сценарий 1: Greenfield / MVP / Internal Tools

Контекст: Новый проект, нет пользователей, цена ошибки низкая, скорость критична. Это, кажется, самый близкий вариант к полному agentic-engineering (в терминах товарища Карпатый) и видению в статье SDLC is dead.

Что меняется:

• Code Review в зависимости от тирности: security-critical код (e.g. авторизация) — 100% человеческое code review; остальное — автоматизированные и выборочные проверки

• Основным контуром защиты прода выступает Observability (канареечные релизы и автоматические откаты). Но этот механизм должен опираться на фундаментальные инженерные практики: многоуровневое тестирование, грамотную архитектуру с низкой связностью модулей, чистый дизайн и разработку на основе типов.

• Итерации с результатами теперь за кратно меньшее количество времени

Важно: даже в greenfield AI-код содержит 1.7x больше issues чем человеческий (CodeRabbit, 2025). Полностью отказываться от review рискованно.

Метрики успеха:

• Время от принятия обязательств до поставки: Lead Time <= 1 день

• Deployment Frequency > 1/день и чаще

• Change Failure Rate отслеживается через хорошо настроенный observability и не превышает порог “Good” по DORA (0-15%)

Сценарий 2: Brownfield / Существующий продукт

Контекст: У нас уже есть пользователи, есть какая-то репутация, мы накопили некий технический долг. Цена ошибки для нас выражается в реальных деньгах.

Что меняется:

По код-ривью нужен tiered подход по риску:

По данным LinearB 2026 Benchmarks, AI PR мержатся в 32.7% случаев против 84.5% у человеческого кода — большая часть требует доработки.

• Короче говоря: человек ответственен за валидацию, особенно для кода с высоким радиусом поражения

• Человек ответственен за валидацию, хоть цена ошибки не очень высока, в сравнении с индустриями с высокими compliance-требованиями

• Обязательная поэтапная выкатка через qa>stage средами + надежная observability-обвязка, которая проактивно следит за метриками и делает авто-роллбек в случае чего

Метрики успеха:

• Code Review Time не растёт (несмотря на больше PR)

• Defect Rate стабилен или падает

• SLA/SLO не снижаются

• Developer Satisfaction не падает (потому что нам важно чтобы AI-инструменты удовлетворяли стандартам разработчиков и им не было больно этим пользоваться)

Сценарий 3: Регулируемая индустрия (финтех, медтех, страхование)

• Это по сути тот же Brownfield + толстый Compliance-слой сверху.

• FYI: Brownfield уже подразумевает что есть легаси.

Контекст: Compliance требует человеческой ответственности. Audit trail (залоггированная последовательность действий с ответственным лицом) обязателен.

Регуляторы в США (в 2025) выпустили требования к стандартам применения ИИ в регулируемых индустриях:

«AI-системы должны быть развернуты так, чтобы выполненные агентами действия были заллоггированы и замониторены, а человек должен быть ответственным за эти действия»
— PCI Security Standards Council, Ноябрь 2025

• 100% audit trail для всего AI-сгенерированного кода: кто запросил, что сгенерировано, кто заапрувил

• Решения все равно принимаются человеком — это требование регуляторов (FDA, PCI-DSS, HIPAA)

• Этапы могут объединяться, но исчезнуть они не могут — их артефакты нужны для аудита

Что меняется:

• AI ускоряет отдельные этапы или связку этапов — это частично сокращает простои, но решения так же принимаются человеком

• Этапы могут объединяться (например, Compliance + Requirements, Security + Audit), но мы не можем их выбросить/сократить потому что должны следовать стандартам

• Audit trail: обязательно трекать кто сгенерировал, кто заапрувил, что изменилось

Метрики успеха:

• Change Failure Rate не растет

• Постепенно сокращается время на проверку соответствия решения регуляторке (на соответствующих этапах)

• Скорость разработки растёт, при этом продукты и сервисы продолжают соответствовать регуляторке

Большой дисклеймер: мы много спорили с коллегами не похож ли флоу в компаниях с кучей регуляторки больше на Brownfield-пример. Ревью требований по комплаенсу выглядит как работа для ИИ — потому что сопоставить соответствие неумолимой букве закона — хорошая задачка для ИИ-шки. С точки зрения безопасности — сейчас есть энтерпрайз и не только модели, которые хорошо сканируют системы на предмет уязвимостей. 

Напишите в комментах, как с вашей точки зрения: история с регулируемыми индустриями больше похожа на Brownfield из предыдущего примера, на текущий пример, или на что-то совсем другое!

Парадокс продуктивности

По данным DORA 2025, 80% разработчиков считают, что AI повысил их продуктивность. При этом стабильность доставки продолжает падать.

Исследование METR (июль 2025) на опытных open-source (да, я понимаю что это не enterprise-сотрудники) разработчиках показало: они верили, что стали на 20% быстрее. Объективные измерения — замедление на 19%.

Почему? AI ускоряет набор кода (30-50% в контролируемых условиях). Но создаёт bottleneck на:

• Code Review — больше PR, а команда та же

• Качестве — больше уязвимостей, сложнее заметить баги

• Дебаге — AI-баги часто неочевидные

• Context gathering — кажется, что с AI можно взять задачу побольше, но на сбор и описание контекста уходит больше времени, чем ожидалось

Затрачиваемое время перетекает из написания кода в подготовку и валидацию.

Вывода нет, есть вектор движения

SDLC скукоживается — но по-разному в разных контекстах.

Для greenfield: этапы сжимаются в “Идея → Агент → Проверка результата → след. итерация”. Минимум контроля человеком, но важно выстроить процесс Observability, чтобы сразу отлавливать ошибки и иметь возможность быстрого роллбека.

Для brownfield: AI генерирует результат в рамках достаточно сформулированной идеи в уже существующем продукте, а человек валидирует. Валидация строже, в соответствии с внутренними стандартами существующего продукта или сервиса.

Для regulated: AI ускоряет разработку, вся ответственность полностью остается на людях (так как это важно для аудита и соответствию регуляторке).

Больше подобной аналитики, обзоров и кейсов AI в менеджменте можно увидеть в моем канале.