Перевод статьи Boris Tane: SDLC is Dead (ссылка в шапке). Пост автора ангажированный и местами кликбейтный. Но автор рассуждает в очень правильном направлении.
AI-агенты не ускорили жизненный цикл разработки. Они его убили.
Я часто слышу что люди утверждают: “AI — это инструмент разработки, ускоряющий работу в 10 раз”. Сама суть фразы некорректная. Она предполагает что процесс разработки остается такой же, только скорость повышается. На самом деле происходит другое. Весь жизненный цикл, вокруг которого мы строили свои карьеры, тот который создал миллиардные индустрии инструментов вокруг себя, разваливается.
И большинство людей этого еще не заметили.
SDLC который вы изучали — пережиток прошлого
Перед вами классический SDLC, которому нас учили.
У каждого этапа свои собственные инструменты, ритуалы, собственная экосистема и кустарное производство. Jira для требований. Figma для дизайна. VS Code для реализации. Jest для тестирования. GitHub для code review. AWS для деплоймента. Datadog для мониторинга.
Каждый этап дискретный, последовательный, везде передача работы из рук в руки.
А вот что происходит, когда инженер работает с кодинговым агентом:
Этапы развалились. Они не стали быстрее, они слились. Агент не знает на каком он шаге, потому что шагов больше нет! Только заданный 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 в менеджменте можно увидеть в моем канале.
Комментарии (20)
karrakoliko
23.03.2026 06:42я уверен что этап оптимистического промпт-гэмблинга в индустрии быстро закончится, на этапе накопления проектами тонн необслуживаемых никаким образом (включая ai) слопов.
идет естественный отбор бизнесов. видимо, каждый отдельно взятый бизнес сам хочет прийти в эту точку.
Jira создавалась чтобы трекать работу по этапам, которых больше нет.
собственно, бизнесы, которые заменяют Процессы на Гэмблинг, ожидает эта самая точка. как они из нее будут разворачиваться и будет определять выживут они или нет
Eskimo Автор
23.03.2026 06:42ну мы как будто по Амазону и еще паре отечественных компаний начинаем видеть масштаб аварий из-за ai генерированного кода.
RTFM13
23.03.2026 06:42Ну либо аи научится в оптимизацию (что маловероятно), либо будет (уже есть?) откат по мере накопления гигабайтов нейрослопа.
Я так понимаю, они пытаются решить проблему количественно, но это только оттягивает мучительный конец.
Eskimo Автор
23.03.2026 06:42но базово в статейке все таки здравая мысля - прокачивай observability и будет уже получше
karrakoliko
23.03.2026 06:42мы видим, менеджмент тоже.
им нужно дать время убедиться что это не вопрос кривых рук, не локальная история, а системная проблема подхода
akakoychenko
23.03.2026 06:42Как будто бы, гемблинга не было ранее. Или проблемы с боигом не было. Как серьёзные люди в дорогих пиджаках с МВА ранее не имели ни малейшего понятия, как работает система, ибо что-то написано индусами, что-то пакистанцами, что-то субподрядчиком подрядчика, так и сейчас не будут понимать. Да, была иллюзия контроля за счёт гор планов и отчётов, сделанных специалистами по работе в корпорациях, но иишка точно так же может все это нагенерировать.
karrakoliko
23.03.2026 06:42иишка точно так же может все это нагенерировать.
нагенерит, да.
в менеджменте эйфория, в разработке лэйоффы.
а с обслуживанием и правками после у них проблемы.
в этом и пикантность ситуации.
менеджмент, приученный смотреть не дальше спринта, столкнется с последствиями: кодовая база стала неуправляемой, агенты не могут внести правку которая не ломает что-то еще, требования не понимает никто, что-то сломалось, деньги теряем сейчас.
и что делать?
систему характеризует не ошибка, а реакция на ошибку
Да, была иллюзия контроля за счёт гор планов и отчётов
нет так, контроль был за счет контроля требований менеджментом и контроля реализации разработкой. это делегируется иишке, над которой нужной степени контроля нет ни у кого.
akakoychenko
23.03.2026 06:42Точно так же, как и ранее, когда индусировали целые департаменты, сокращая людей, создавших систему в дорогой локации. Сила достаточно крупного бизнеса, который уже мыслит такой категорией, как layoff, в том, что он это все отлично выдерживает. Ну не выполнит условный American Express или SAP свой план по разработке на квартал, и что? Так даже, если за год ни одной строчки кода не напишут, то что изменится?
karrakoliko
23.03.2026 06:42я перестал понимать что вы хотите доказать.
если за год ни одной строчки кода не напишут, то что изменится?
если не надо код писать потому что от этого компания не зависит - то рассуждения на тему процессов написания кода, который не нужен, бессмысленны.
мы же говорим про компании в которых услуга, за которую компания получает деньги, все-таки зависит от кода, который работает.
если код нужен - есть ии и есть спецы, выбор за бизнесом. с людьми далеко, с ии быстро и с высокими рисками оказаться в точке невозврата
akakoychenko
23.03.2026 06:42Я хочу донести мысль, что в корпорациях всегда царило невежество в плане написания и поддержки кода. И, что руководство всегда превращало разработку в гемблинг (и имело возможность так делать за счёт запаса жира), жертвуя качеством и пониманием системы ради возможности сократить in-house разработчиков, заменив это на волшебный blackbox. А вот, что внутри чёрного ящика, да, меняется. Ранее это были подрядчики из Индии. Сейчас это ИИ. Но, принципиально, суть та же. Подрядчик с офисом на 400 индусов не имеет принципиальных отличий для заказчика от подписки на ИИ агенты
karrakoliko
23.03.2026 06:42Подрядчик с офисом на 400 индусов не имеет принципиальных отличий для заказчика от подписки на ИИ агенты
всё-таки имеет
мой поинт:
контроль был за счет контроля требований менеджментом и контроля реализации разработкой. это делегируется иишке, над которой нужной степени контроля нет ни у кого
контролировать разработчиков трудно, но можно. контролировать блэкбокс иишку невозможно
rdo
23.03.2026 06:42Можно даже сократить команду разработки. Оставить только Продукт Овнера, который непрерывно общается агентами и пишет что тому делать)
Eskimo Автор
23.03.2026 06:42вопрос, как быстро потом придем к авариям как в Амазоне https://www.ft.com/content/7cab4ec7-4712-4137-b602-119a44f771de?syn-25a6b1a6=1
aborouhin
23.03.2026 06:42Ну а то, что в AI разработке прямо сейчас как грибы после дождя растут SDD-фреймворки, agent teams со специализированными скиллами и т.п., которые ровно то и делают, что эмулируют традиционную команду разработки с раздельными ролями и этапами, - этого мы, конечно, замечать не будем :)
Kahelman
23.03.2026 06:42Не знают что такое DevOps или SRE. Не потому что они плохие инженеры — им просто он никогда не был нужен. Они никогда не сидели на планировании спринта, оценивали в story points, ждали по три дня чтобы им проверили PR.
Они просто делают работу.
неужто вернулись старые добрые времена когда дев ОПС себе я ещё не продал и не на создавал сам себе проблем?
По поводу отсутствия код- ревью: так вы его делает когда смотрите что вам агент накопил или нет?
DenSigma
23.03.2026 06:42Всегда считал, что code review - это чушь и вред. Если при работе в ИИ pr - вред, то и при работе с хуманами, это точно такой-же вред, просто не настолько очевидный.
Eskimo Автор
23.03.2026 06:42а как качество обеспечивать и отлавливать?
DenSigma
23.03.2026 06:42Давать работу исполнителю с нужным уровнем компетенции.
Давать ему в работу однозначно полный для реализации проект. Чертеж.
Контролировать результат работы на соответствие проекту (функциональным и нефункциональным требованиям, в том числе корпоративным стандартам оформления).
Ключевое замечание - контроль должен проводить специально обученный человек - фунциональные требования тестирует тестировщик. На соответствие корпоративным стандартам должен проверять что-то типа нормоконтроль (Айтишники до этого еще не доросли).
Выпускать работу в тестирование должен непосредственный руководитель (тимлид, в промышленности это начальник техбюро), он же и требует выполнения определенного технического уровня. То есть лицо, а) в непосредственном подчинении которого находится исполнитель, б) несет ответственность за сроки выполнения работ и техническое качество изделия.
Но извините, чтобы твою работу проверял (ревьювил) какой-то Вася, которому ты не подчиняешься, который не несет никакой ответственности ни за твой результат, ни за сроки, ни за процесс разработки, который не следует стандартам предприятия, а руководствуется в своих придирках исключительно своими личными предпочтениями, убеждениями и чувством прекрасного и при этом может докапываться как хочет, на козе не подъедешь - это просто п...ц. Хуже систему, имхо, сложно придумать.
Ну и тесты писать.
panzerfaust
29 комментов. Из них большая часть какие-то приторные бессмысленные расшаркивания в стиле линкедин. Где срач-то?