В последнее время в интернете набирают популярность заявления о том, что AI-агенты убили SDLC. Инфлюенсеры утверждают: скрам, тестирование, DevOps — всё это больше не нужно. В эпоху ИИ классический жизненный цикл разработки программного обеспечения (SDLC) якобы устарел.
Несмотря на хайп, очевидно: индустрия действительно переживает фундаментальный сдвиг. Мы прошли путь от Waterfall к гибким методологиям (Scrum, Kanban, Lean). Теперь, с приходом AI-агентов, SDLC в очередной раз подвергается пересмотру.
Разберёмся:
- как ИИ меняет разработку в Greenfield-, Brownfield- и регулируемых проектах, и на какие метрики стоит обращать внимание;
- как меняется взаимодействие в командах и какие этапы теряют актуальность.
Важно: это не утверждение, а призыв к дискуссии.
Как AI влияет на SDLC
Стоимость изменений кода падает
Раньше мы старались согласовать архитектуру заранее — переписывать было дорого. Даже в Agile мы избегали радикальных изменений из-за высокой цены. С появлением ИИ вносить правки стало заметно быстрее и дешевле:
- Переписать модуль — за день;
- Сгенерировать и сравнить три архитектурных решения — за пару-тройку дней;
- Проверить гипотезу через прототип — быстрее, чем обсуждать её в документах.
Правда, написать код — не значит, что он заработает. Нужны качественные спецификации, настроенные окружения, тесты и валидация результата.
Это меняет подход к планированию:
- Меньше детальных спецификаций по реализации — переписать проще;
- Больше чётких ограничений: безопасность, масштабируемость, разрешённые библиотеки, критерии приёмки;
- Гипотезы проверяются прототипами, созданными агентами, а не документами или ручным кодом.
Взаимодействие изменяется
AI меняет динамику командной работы:
- Переделка дешевле → цена ошибки ниже → можно меньше согласовывать и просто пробовать;
- Один человек с ИИ может сделать то, что раньше требовало команды: написать код, покрыть тестами, проверить уязвимости (с оговорками: контекст, доменная экспертиза, технические нюансы).
Это снижает два типа потерь из Lean:
- Ожидание в очереди. Раньше задача ждала архитектора или специалиста по безопасности. Теперь часть работы делает ИИ.
- Зависимость от ключевого специалиста (bus factor). Единственный, кто знает модуль, ушёл в отпуск? ИИ помогает передать контекст. Но это двусторонний меч: команды могут уменьшаться, и при уходе одного человека bus factor снова растёт.
Раньше контекст делили между собой. Теперь один человек + ИИ реализует фичу целиком — и ему нужен полный e2e-контекст. Когнитивная нагрузка растёт.
Большую часть задач может выполнять один человек-оркестратор. Однако ценность парного программирования и моббинга остаётся: важно распределять знания и совместно проверять решения.
Теперь взаимодействие в команде сместилось к совместной валидации результата, проектированию ограничений для агента и формированию качественного контекста.
Декомпозиция становится критичной
AI-агенты лучше всего работают с маленькими, чётко сформулированными задачами — как если бы вы объясняли задание джуниору:
- Конкретная цель с ясными границами;
- Один проверяемый результат;
- Контекст умещается в голове (или в контекстное окно агента). Даже с миллионом токенов — чем больше контекст, тем слабее его вес.
Если раньше senior сам декомпозировал размытую задачу, то теперь подготовка для агента требует атомарной декомпозиции. Умение формулировать задачи «как для джуна» — ключ к эффективности с ИИ.
Чем крупнее задача — тем выше риск, что агент «галлюцинирует» или теряет фокус. Атомарность важна.
Ловушка: соблазн воспроизвести Waterfall — «сначала всё распланируй, напиши спеки, потом отдай агенту». Это не работает. Работа с ИИ — это те же итерации и мелкие батчи, только быстрее. Агент — партнёр для коротких циклов, а не исполнитель большого ТЗ. Декомпозиция должна идти от ценности, а не по компонентам.
Code Review становится узким местом
Код генерируется быстрее, чем люди успевают его проверять. По данным CodeRabbit, PR от AI-ассистентов получают в среднем 10,8 замечаний против 6,4 у человеческого кода — ревью занимает больше времени.
Три сценария: как SDLC сворачивается по-разному
Нет единого «нового SDLC». Будет спектр сценариев — каждый со своими изменениями и метриками успеха.
Сценарий 1: Greenfield / MVP / Internal Tools
Контекст: Новый проект, нет пользователей, низкая цена ошибки, критична скорость. Это ближе всего к видению «SDLC умер» и концепции agentic-engineering.
Что меняется:
- Code Review по тирам: security-critical код (например, авторизация) — 100% ручной ревью; остальное — автоматизированные и выборочные проверки;
- Основной контур защиты — Observability (канареечные релизы, автоматические откаты). Но он требует фундамента: многоуровневое тестирование, низкая связность, чистый дизайн, типизация;
- Итерации с результатами — за кратно меньшее время.
Важно: даже в greenfield AI-код содержит на 1,7 раза больше проблем, чем человеческий (CodeRabbit, 2025). Полностью отказываться от ревью рискованно.
Метрики успеха:
- Lead Time ≤ 1 день;
- Deployment Frequency > 1 раз в день;
- Change Failure Rate не превышает порог «Good» по DORA (0–15%), отслеживается через Observability.
Сценарий 2: Brownfield / Существующий продукт
Контекст: Есть пользователи, репутация, технический долг. Ошибка стоит денег.
Что меняется:
Нужен tiered-подход к ревью по уровню риска:
- Security, критичный код: 100% ревью senior-специалистами (авторизация, платежи, персональные данные, криптография);
- Бизнес-логика: 30–40% peer review (фичи, API, потоки данных);
- Утилиты и инструменты: агентное/автоматизированное ревью + выборочные проверки (тесты, документация, конфиги).
По данным LinearB (2026), AI-PR мержатся в 32,7% случаев против 84,5% у человеческого кода — большинство требуют доработки.
- Человек отвечает за валидацию, особенно для кода с высоким радиусом поражения;
- Даже при умеренной цене ошибки — валидация остаётся критичной;
- Обязательна поэтапная выкатка через QA и stage-среды + надёжная observability-обвязка с авто-роллбеком.
Метрики успеха:
- Code Review Time не растёт (несмотря на рост числа PR);
- Defect Rate стабилен или снижается;
- SLA/SLO не падают;
- Developer Satisfaction не снижается — важно, чтобы инструменты на ИИ были удобны в использовании.
Сценарий 3: Регулируемая индустрия (финтех, медтех, страхование)
Контекст: То же, что Brownfield, но с толстым compliance-слоем. Есть требования к аудиту и человеческой ответственности.
Регуляторы в США (2025) установили правила:
«AI-системы должны быть развернуты так, чтобы действия агентов были залогированы и замониторены, а человек оставался ответственным за них» — PCI Security Standards Council, ноябрь 2025.
- 100% audit trail для всего AI-кода: кто запросил, что сгенерировано, кто утвердил;
- AI ускоряет этапы, но решения принимает человек — требование FDA, PCI-DSS, HIPAA;
- Этапы могут объединяться, но не исчезают — их артефакты нужны для аудита.
Что меняется:
- AI сокращает waste, ускоряя отдельные этапы, но решения остаются за человеком;
- Этапы объединяются (например, Compliance + Requirements), но не упраздняются;
- Обязательно ведение audit trail: кто сгенерировал, кто утвердил, что изменилось.
Метрики успеха:
- Change Failure Rate не растёт;
- Постепенно сокращается время на проверку соответствия регуляторным требованиям;
- Скорость разработки растёт, и при этом продукты остаются compliant.
Парадокс продуктивности
По данным DORA (2025), 80% разработчиков считают, что ИИ повысил их продуктивность. При этом стабильность доставки продолжает падать.
Исследование METR (июль 2025) на опытных open-source разработчиках показало: они думали, что стали на 20% быстрее. Объективно — замедлились на 19%.
Почему? ИИ ускоряет набор кода (на 30–50% в контролируемых условиях), но создаёт узкие места:
- Code Review — больше PR, а команда та же;
- Качество — больше уязвимостей, баги сложнее заметить;
- Дебаг — AI-баги часто неочевидные;
- Сбор контекста — кажется, что с ИИ можно взять большую задачу, но на её описание уходит больше времени, чем ожидалось.
Время перетекает из написания кода в его подготовку и валидацию.
Вывода нет, есть вектор движения
SDLC скукоживается — но по-разному в разных контекстах.
Для Greenfield: этапы сжимаются в «Идея → Агент → Проверка результата → Следующая итерация». Минимум контроля человеком, но критична Observability для быстрого отката.
Для Brownfield: ИИ генерирует код в рамках чёткой идеи, человек валидирует. Контроль строже — по внутренним стандартам продукта.
Для regulated: ИИ ускоряет разработку, но вся ответственность остаётся на людях — ради аудита и compliance.