SDLC мертв. AI-агенты его убили

AI-агенты не ускорили жизненный цикл разработки. Они его убили.

Я часто слышу что люди утверждают: “AI — это инструмент разработки, ускоряющий работу в 10 раз”. Сама суть фразы некорректная. Она предполагает что процесс разработки остается такой же, только скорость повышается. На самом деле происходит другое. Весь жизненный цикл, вокруг которого мы строили свои карьеры, тот который создал миллиардные индустрии инструментов вокруг себя, разваливается.
И большинство людей этого еще не заметили.

SDLC который вы изучали — пережиток прошлого

Перед вами классический SDLC, которому нас учили.

Каждый этап дискретный, последовательный, везде передача работы из рук в руки.

А вот что происходит, когда инженер работает с кодинговым агентом:

Этапы развалились. Они не стали быстрее, они слились. Агент не знает на каком он шаге, потому что шагов больше нет! Только заданный intent, контекст, итерация.

AI-native инженеры не знают что такое SDLC

Я потратил много времени общаясь с инженерами, которые начали свою карьеру после того как запустился Cursor. Они не знают что такое жизненный цикл разработки ПО. Не знают что такое DevOps или SRE. Не потому что они плохие инженеры — им просто он никогда не был нужен. Они никогда не сидели на планировании спринта, оценивали в story points, ждали по три дня чтобы им проверили PR.

Они просто делают работу.

Ты описываешь что тебе нужно, агент пишет код. Ты смотришь на результат, итерируешь и выпускаешь. Все работает одновременно.

Эти инженеры не стали хуже оттого что пропустили очередную церемонию. Им не нужно тратить на нее время. Планирование спринта, процесс code review, релизные поезда, ритуалы по оценке. Ни-че-го. Они перепрыгнули через всё традиционное и сразу пошли в реализацию.

И если честно, я завидую.

Каждый этап схлопывается

Давайте пройдемся по SDLC и посмотрим, что же от него осталось.

Сбор требований: гибкий, не жестко детерминированный

Требования раньше спускались сверху. Product Manager пишет PRD (product requirements document), инженеры оценивают его, спека фиксируется до того как код начнет писаться. Мы делали так, потому что разработка была дорогая. Когда каждая фича занимала недели, надо было определиться заранее.

Теперь, когда агент генерирует фичу за минуты, тебе не нужно продумывать каждую деталь заранее. Ты просто задаешь направление. Смотришь на первую версию, корректируешь ее и выбираешь лучший из десятка вариантов. Требования больше не фаза — они становятся побочным продуктом итерации.

Jira создавалась чтобы трекать работу по этапам, которых больше нет. И аудитория сменилась с людей на агентов. Если твои требования — это просто контекст для ИИ, то тикетная система превращается из инструмента управления в довольно паршивое хранилище контекста.

System Design: нащупывается, а не диктуется

Проектирование систем всё еще важно. Но пропасть между архитектурой на маркерной доске и рабочим кодом стремительно исчезает. Дизайн становится тем, что ты нащупываешь в процессе работы, а не тем, что диктуешь заранее. Модель видела больше паттернов и архитектур, чем любой отдельно взятый инженер.

Ты описываешь проблему, и агент предлагает архитектуры, которые часто лучше твоих собственных идей. Проектирование превращается в диалог в реальном времени, а результатом становится рабочий код. Да, тебе всё еще нужно отлавливать оверинжиниринг, но теперь вы именно сотрудничаете над дизайном.

Реализация: теперь это работа агента

Тут всё очевидно: агент пишет код. Он создает целые фичи с обработкой ошибок, типами и пограничными случаями (edge cases). Я лично не знаю никого, кто до сих пор сам печатает строки кода. Мы ревьюим работу агентов, скармливаем им контекст и фокусируемся на тех проблемах, где действительно нужно человеческое мышление.

Тестирование: одновременно, а не последовательно

Агенты пишут тесты вместе с кодом. Они становятся неотъемлемой частью генерации, а не каким-то отдельным этапом. TDD — это больше не методология, а просто дефолтный принцип работы агентов. Вся функция QA исчезла. Код и тесты генерируются и проверяются вместе, больше нет никакого «перекидывания через стену в QA».

Code review: пора отказаться

Code Review пул-риквестов должен умереть. В мире агентов он стал просто пережитком прошлого и кризисом инженерной идентичности. Агент может сгенерировать 500 PR в день, а команда осилит посмотреть от силы 10. Мы создаем фейковое узкое горлышко, просто навязывая человеческие ритуалы машинному процессу.

Эта диаграмма не должна существовать. Процесс ревью обязан стать частью самой генерации кода или выполняться состязательными (adversarial) агентами.
Вот как выглядит мир без PR: агенты коммитят прямо в main. Автоматические проверки валидируют изменения. Если всё ок — код деплоится. Человек вмешивается (human-in-the-loop) только тогда, когда система сталкивается с чем-то принципиально новым.

Тратить время на вычитывание диффов, которые машина проверяет за секунды — это не контроль качества. Это луддизм.

Деплоймент: непрерывный и независимый

Агенты уже пишут сложные пайплайны с feature flags, canary releases и постепенными раскатками. Это естественно отделяет деплоймент от релиза. Код деплоится непрерывно: любое проверенное изменение создает артефакт, который попадает в прод, но скрыт за гейтом. А сам релиз управляется правилами маршрутизации трафика.

В будущем агенты будут управлять всем циклом релиза: мониторить раскатку, корректировать трафик по error rates и откатываться при скачках latency. «Этап» деплоя превращается в саморегулирующийся процесс, который никогда по-настоящему не заканчивается.

Мониторинг: последний выживший этап

Мониторинг — единственный выживший этап SDLC. Теперь он становится фундаментом и главной линией обороны для всего схлопнувшегося жизненного цикла.
Но текущие платформы observability созданы для людей. Если ИИ выкатывает сотни изменений в день, ручное расследование алертов просто переносит узкое место на реагирование на инциденты (incident response).

Будущее observability — это замкнутые системы (closed-loop systems). Телеметрия становится контекстом для агента, чтобы он сам находил и чинил регрессии. Слой observability становится механизмом обратной связи, который управляет всем циклом

Команды, которые первыми настроят observability для питания агентов, а не пейджеров дежурных инженеров, будут шиппить быстрее всех. Пока остальные будут тонуть в алертах.

Новый жизненный цикл — это узкая петля

SDLC был широкой петлей, полной линейных ожиданий и передачи задач из рук в руки. Новый жизненный цикл — это узкая петля.

Intent (Намерение). Build (Создание). Observe (Наблюдение). И повторить.
Никаких тикетов, спринтов, story points, очередей PR или релизных поездов. Только человек со своим намерением и агент, который это выполняет.

Так что же осталось?

Контекст. Вот и всё.

Качество того, что ты создаешь с помощью агентов, прямо пропорционально качеству контекста, который ты им даешь. А не процессам или ритуалам.
SDLC мертв. Новым ключевым навыком становится context engineering, а новой страховочной сеткой — observability. А бóльшая часть индустрии до сих пор настраивает дашборды в Datadog, на которые никто никогда не посмотрит.

От переводчика: статья ангажированная, местами кликбейтная, в комментах адский срач (советую почитать). Но автор рассуждает в очень правильном направлении. Больше подобной аналитики, обзоров и кейсов AI в менеджменте можно увидеть в моем канале.