Agent Driven SDLC: как меняется разработка | МЛечный путь 2026 | Конференция Selectel

Добрый день. Немножко расскажу о себе. Я занял год назад позицию технического директора по управлению искусственным интеллектом в компании. Для чего? Мы начали собирать команды и выстраивать новые процессы, разбираться, как они меняются, когда мы разрабатываем системы с искусственным интеллектом. И сегодня я хотел с вами поделиться тем опытом, теми болями, которые столкнулся. Возможно, многие из вас уже тоже с этим знакомы и как-то с этим справляются. И посмотрим немножко, как сейчас мир справляется с тем, что происходит в мире разработки с искусственным интеллектом. Немножко поговорим именно, как помогает искусственный интеллект как Cloud Code Code в классической постановке задачи, в том плане, что мы разрабатываем какие-то сервисы. И еще поразмышляем, как меняется сам процесс, когда мы начинаем разрабатывать, в первую очередь, агентную систему. То есть вроде бы та же самая разработка, но есть отличия. Ну и немножко пофантазируем, как это могло бы выглядеть в будущем. Мы на самом деле в компании с Иишкой достаточно давно и сейчас занимаемся трансформацией бизнеса, смотрим, как это в клиентах еще происходит. Где-то помогаем, где-то учимся у наших клиентов. Наверное, сегодня хотелось сконцентрироваться на такой теме, как где наши те обещания ускорения в 10x. которые нам говорили примерно год назад, что все, разработка, будет ускорение. Думаю, те, кто вас мерят, вы понимаете, что на самом деле 10-кратного роста не случилось. Если у кого-то случилось, можете поделиться. Рынок столкнулся со многими проблемами. Я размышлял, что нам помешало достичь. Ну и CloudCode будет мне помогать с картинками, чтобы нам не было грустно. Я специально разделил SDLC на две. Два подхода, так сказать. Сейчас рассмотрим разработку классических систем без искусственного интеллекта, но с применением его именно как помощников. Первое. У меня был опыт. Мы для своих команд где-то летом прям собрали команду, начали разрабатывать и всем купили там подписку, курсор, чтобы все начали кодить. Вопрос вот к вам. Как вы думаете, какая была самая популярная модель использования? Сделайте свои предположения. Стандартно еще что? Летом. Этим летом курсор как раз вышел, стал популярен. Кодекс, опус, композ еще, кстати, хороший. У них она называлась авто. Честно. То есть большинство пользователей не пытались внутрь разобраться более подробно, что там происходит разработчиков, и использовали стандартные настройки по умолчанию. И с ним работали. Отсюда выводы, с которыми мы столкнулись, что просто одного инструмента недостаточно. Сейчас уже существуют подходы, как правильно настраивать агента. Это SDD-подходы, plan-act-подходы. Мы должны понимать, что такое агента, потому что, чтобы хорошо он работал, его надо настроить. То есть мы должны понимать, как он с MCP-шками дружит, какие есть хорошие скиллы, навыки подключать с фронта. Нас этому все благодаря учат. Ну и последнее. Надо понимать, что если у вас есть разработчики, которые только сегодня сели писать с искусственным интеллектом, несмотря на все, что у нас здесь есть информации, мы там внедряем, им все равно нужно время, чтобы это освоить. От 3 до 6 месяцев, в зависимости от того, насколько они готовы в это погружаться. Я знаю кейсы в одних международных компаниях, когда шли разговоры о том, чтобы запретить разработчикам использовать IDE, чтобы они переключились на это и начали изучать. Потому что большое сопротивление. И вот такие эксперименты, по крайней мере, предлагалось. Не знаю, провели или нет, но предлагалось. Естественно, самый простой путь — это обучение. Спасибо ребятам из Антропедки, из Упунаи. У них огромное количество материала, которое позволяет учить. Мы внутри компании также целый курс поагентной сделали. И сейчас помогаем каждому сотруднику осваивать новые технологии. Но сопротивление остается. Сразу предупреждаю. Следующее, с чем мы столкнулись, почему сопротивление? Дело в том, что цена кода опустилась ниже уровня. Сейчас строчка кода ничего не стоит. Она и так все время падала, падала, падала, и она сейчас резко упала. Но разработчики, которые занимаются системами, достаточно яростно смотрят, что там происходит. У нас есть такое понятие, как чистая архитектура. Мы разбиваем код на компоненты, мы смотрим, чтобы жены не залезали куда-то в лишнее. Все время смотрим в код. А с эрой кодовых агентов это стало невозможно. Я не представляю сейчас, как можно наблюдать за тем, что там происходит строчка за строчкой, особенно когда мы смотрим, как он генерирует бесконечные куски кода, их исправляет и тому подобное. И отсюда появляются паттерны. Первое, мы выходим на уровень менеджмента. все ребята, которые хорошо понимают, что там под капотом происходит, начинают менеджерить агентами. Здесь, конечно, есть маленький кейс. То есть я, например, не совсем понимаю, как здесь жить джунам. Потому что менеджерская позиция — это все-таки позиция такого зрелого. Ты понимаешь, что там происходит под капотом, ты можешь выйти на уровень, чтобы другим раздавать команды. Как молодым разработчикам ходить в эту разработку, когда… надо бы инжирить агентами, они там непонятно что творят, остается открытым. И хочешь не хочешь, единственный выход на сегодняшний день все-таки это обучать, что мы занимаемся определенными точками контроля, с которыми мы занимаемся. То есть это все, что связано с изменением контрактов, API, с изменением базы данных. То есть это тот фундамент, на котором все держится. Вокруг него… Код может плясать влево-вправо. Не так это страшно. Но страшно, чтобы вот эти вот свои, за которыми мы зону ответственности наблюдаем, они оставались под нашим контролем. То есть на сегодняшний день я не могу доверить это агентам. У меня есть такой жизненный пример, почему, но я о нем расскажу попозже. Следующее. Представим себе менеджера, перед которым стоит теперь задача, к которой мы говорим. Тим лид, тех лид, да, у вас там черный ящик. Остальные разработчики что-то пилят с этими агентами, разрабатывают, разрабатывают. А что происходит? Как контролировать, что там происходит? Самая, с моей стороны, ошибка размышлять о том, что мы начинаем делать новое ограничение. Самый такой яркий пример, который я встречал, это мы все ICD запихнем агента, который будет ревьюить. всех наших разработчиков, которые с помощью агента пишут код. Это прям классика. Недавно Авито выступал, они там написали. В чем недостаток этого подхода? Можно чуть-чуть подумать, поразмышлять. Это же классно, он там проверяет, начинает комментарии накидывать нам, чтобы мы ходили, читали эти комментарии. Это не нужно, потому что у нас код пишет агент. Если агент проверяет, то он должен передавать эту информацию не людям, а самим кодовым агентам. Поэтому мы в какой-то момент должны прийти к такой парадигме, и сейчас потихоньку мы туда идем, когда реально все, что происходит внутри, с приложением, где работают агенты, все ложится на роль агента. Человек стоит и в зне, он говорит, вот мои требования, что я хочу получить, и смотрит на результаты, либо наборов юнит-тестов, либо еще что-то. А уже внутри агент… Проверяет, и как UI выглядит, и как код написан, и как в BD что-то происходит. На него это все ложится. Здесь хотел немножко про обратную связь рассказать. Если присмотреться, у меня просто был опыт в инженерии. Я немножко занимался системами летательными аппаратами. Там есть такое понятие системы обратной связи. Она заключается в том, что когда самолет летит, он все время сбивается с курса, его надо все время поправлять. Да, и у нас есть некие механизмы, системы, которые собирают эту обратную связь. Но чтобы их сделать хорошо, там стоят очень дорогие приборы, гироскопы, акселерометры. И если мы хотим, чтобы он автономно летел в космосе, мы ставим дорогие системы. Но, грубо говоря, с помощью GPS, то есть внешнего источника, здесь как раз человек — это внешний источник, машина может двигаться. на очень дешевых приборах, потому что внешне все время его подкорректирует. И вот мы сейчас находимся в ситуации, когда у нас обратная связь реализуется, и наша задача понять, насколько мы там активно участвуем в этом корректировке. Есть такой жизненный пример, который мы с GPT сделали. У каждого есть теплый пол, если у кого-то есть. Вы же знаете, что он регулируется. Мы говорим, выставь 20 градусов, все комфортно, все замечательно. Представьте, что вы пришли только что с пробежки. Те же самые 20 градусов для вас это жарко. Вы хотите сделать похолоднее. И вот агент, он не знает, ему нужна информация от внешнего мира. И здесь вот именно человек выступает. Я просто пытаюсь вас туда сфокусировать, что без человека нельзя. Но мы должны достаточно большую автономию дать агентам. Следующее, что прям вот ярко сейчас выстрелило, много раз я прям спотыкался об этом. Классический agile котовут. который должен был ускорять нас, он замедляет на сегодня. Вот эти вот передачи, представьте, у нас есть аналитики, разработчики, продуктованеры, каждый работает с агентом, абсолютно каждый. Каждый начинает теперь в разы быстрее работать, сокращает время. Разработчик за два часа справился, аналитик за полчаса справился с аналитикой. Но передача ответственности по этому классическому процессу занимает время, время ожидания. передачи ответственности. И второй элемент, когда мы столкнулись на реальном кейсе, решили жить по agile, собирать агентов, столкнулся с тем, что если ребята плохо понимают, что такое агент, это новая тема, с которой надо работать, им проще сделать то, что они знают. Человеку это всегда проще сделать то, что он знает. И он начинает заводить задачи в жир, писать требования, но не писать агентов. И вот этот процесс хорошо помогает делать все, что угодно, но не то, что нужно. По крайней мере, там, где мы не понимаем, как двигаться дальше. И на смену на сегодняшний день пришла такая эра продукт-инженеров. Очень много ребята сейчас выстреливают, которые берут на себя весь процесс разработки. От придумывания идеи до реализации. И с ними скорости неимоверны. То есть у нас в компании мы постоянно сталкиваемся, что классическая команда может… за месяц ни одной строчке кода не написать, увлечься всякими другими вещами. Хороший продукт-инженер за пару дней собирает и мобильные приложения, и сайты, и может с этим жить и дальше продолжать. Это бешеный разрыв. Но таких продукт-инженеров достаточно мало, а как-то надо жить. Мир сейчас пришел к такой теме, как тишейпность. очень многие крупные компании пришли к тому, что они сокращают agile команды до каких-то двух-трех человек, которые между собой делят определенные роли. Да, но захватывает больше, чем было раньше. Это выход на сегодняшний день из ситуации, когда действительно надо двигаться быстро и жить в какой-то неопределенности. Но все равно не могу сказать, что это прям идеальный пока вариант, но он работает. И вот при разработке... систем, используя искусственный интеллект, по факту можно резюмировать, мы столкнулись с неготовностью людей работать с этими новыми инструментами, пытаться жить по ставим правилам. И не знаю, как вы, а я периодически сталкивался с командами, которые считали, что юнит-тесты — это необязательно. И мало того, что это и сейчас нонсенс, но с агентами это превращается в то, что невозможно жить. Агент без обратной связи не способен существовать. Ему нужно все время проверять, как выполняется код, как там происходит в браузере, что на сервере, какие ошибки прилетают от пользователей. Если мы все это предоставляем в обратную связь, он начинает хорошо понимать, как работает наша система и может без нас ее корректировать. Давайте немножко перейдем теперь к вероятностным системам. Я, наверное, здесь сконцентрируюсь больше на агентных системах. Мы просто и так, и так сделали. Как думаете, кто должен разрабатывать агентов? Ну честно, наши классические роли. Можете поразмышлять, подумать, вспомнить, кто у вас там в командах. Потому что, ну вот как, бэкендерам дать. Они начинают фреймворки писать. Вот честно, мы несколько раз задавали баконервную задачу, они пилить свои фреймворки, они не хотят брать вот эти неготовые OpenAI, еще что-то, они пилить свои фреймворки несколько месяцев, и ничего не получается. Ну, хороший вариант, да. Мы пытались, прям у нас есть AI-инженеры, ну, потому что они же агенты, AI, ML, там все нормально, все прекрасно. Я в одну команду зашел, там был как раз менеджер, продукт менеджер, и NLP-инженер. посмотрел на бэклог авторизация интеграция работа с базой данных я спрашиваю агент да то есть и но пинженер занималась вот этого в бяской и менеджер не понимал почему он не может справиться этой задачи на же у него агент есть кодовый инженер все ну и по факту мы столкнулись с тем что во многих компаниях либо пытаются классические команды вот у них уже есть хорошая agile команда, давайте им дадим по инерции, пускай пишут. Либо у нас есть энтузиасты, которые пытаются самостоятельно как-то это все продвинять. Здесь я хотел вам сконцентрироваться. Если глубоко разбираться, кто такой агент и что из него состоит, то он состоит из двух частей. Первый — это инженерный подход. У него есть интеграция, он должен понимать, что такое MCP, какие там есть... Сейчас становится большой вопрос, как правами доступа распределяться. Потому что появился третий актор. Мы знаем, как пользователь системой пользуется, а как агент, какие у него должны права. Каждый начинает немножко выдумывать. Это задачи, которые обычно вложатся на руки бэкэнтер-разработчиков и девопсеров, чтобы инфраструктуру, где его разворачивать агенты еще. Но агент же это вероятностная система. И по факту у него еще есть другой момент. Мы должны собирать датасеты вопросов, которые ему задаем, бетчмарки настраивать, метрики мерить, разрабатывать методологии измерения этих бизнес-метрик. А это исследовательская работа. Бэкендер не знает, как с этим жить. Здесь как раз. И по факту, на сегодняшний день, если так размышлять, одной роли недостаточно, чтобы делать агентов. Нужны две роли. Если они есть у одного человека... вы получаете суперчеловек, который может этих агентов пилить без проблем. Если такого человека нет, вам надо двух, чтобы они могли разделить между собой. Следующий, это прям боль, с которой я столкнулся. Кто-нибудь пытался описать с точки зрения аналитики, что такое агент, как он должен, как интегрироваться. Не знаю, как у вас. Я просто видел бедные глаза аналитиков, когда они пытались классически всему, чему они научились. описывать агентов. Их не понимает ни бизнес, ни команда. Все начинают теряться. Обычно там такие задачи, давайте сделаем агента-аналитика. О чем будет делать? Он же аналитик, давайте подумаем. И вот эти вот идеи начинаются между командами, каждый начинает выдумывать по-своему. И мы внутри, когда разбирали… Здесь стрелочки, поехали. Честно скажу, не обращайте внимания. Но здесь надо на четыре части разбирать. Агенты каждый по-своему рисуют. Я его разделял на две части. Что у нас есть точки контроля, которые позволяют управлять агентом. Это промты, скиллы, его луп, то есть агентственный цикл, который позволяет ему существовать. Обычно это реактор, либо его аналоги. И есть интеграция, связанная с внешним миром. Это и самая лендка, память. сам агент и тому подобное. И мы понимаем, что есть что-то на вход, есть что-то на выход. Это очень хорошо ложится на такую идеологию, как методология DEV0 в бизнес-анализе, которая говорит, что описывает, что такое бизнес-функция. И когда мы начинаем разговаривать с аналитиками, а давай говорить не про агентов, а про бизнес-функции, которые мы хотим автоматизировать у клиентов, становится намного проще общаться с клиентом. Он знает, что такое бизнес-процессы, он знает, что такое бизнес-функции. Становится легко общаться с командой. Тут достаточно простые старые идеи, которые приложены, мы с ними давно живем. У меня на моем опыте мы действительно с нуля сдвигали команды. То есть команда приходит ко мне и говорит, мы не знаем, с чего начать. Вот хотя тут агент-аналитик или СРЕ-агент. Типа, что делать? Я говорю, а давай распишем на бизнес-функции, которые есть. И вот немножко поразмышляем, что у него должны быть, какие интеграции, какие задачи. И это сдвигает команды с мёртвой точки. Второй кейс. Мы приходили к одному агенту, который был 100 туллов, ещё что-то. Он что-то мощный, он всё умел, всё просто, но ничего хорошо не делал. Это вот Open Cloud, они похожие. И когда мы начали разбирать на те функции, которые он должен делать, мы понимали, сколько лишнего на него навалили. И мы могли прямо отрезать спокойно и говорить, что это нам не надо, и упрощать идеологию. Есть описание методологии, можно ознакомиться. Ну, если интересно, я подожду. Следующая боль, которую я испытал, когда мы жили в agile процессе и разрабатывали агентов. Это определенный челлендж, я вам скажу. Менеджеры такие, ура, агент есть, он работает. Ну, его быстро написать. На самом деле агента много ума не требуется. Давай в прот. Потом смотрим, какие-то вопросы пользователи задают, агент не справляется. И к ней такой, надо исправлять. И начинает в Jira писать эти ошибки. Вот это запрос плохой, это запрос плохой, это запрос плохой. И команда стопорится. То есть инженеры, исследователи не понимают, как с этим быть, с этими багами в Jira, как по одному их кодить, еще что-то. Менеджеры считают, что все это нормально. Просто инженеры что-то не справились. Но по факту в классическом процессе разработки, здесь серенький выделен, появился исследовательский процесс. Мы про него уже говорили немножко. То есть разрабатывая агентов по классической схеме, внутри еще появляется цикл экспериментов с этим самым агентом, чтобы довести его до каких-то метрик. И по факту ошибки агента — это сбор данных для того, чтобы улучшать его оценку. Батчмарки соберем, еще что-то. И к этому многие менеджеры оказались не готовы, которые привыкли к классической разработке. Что у них теперь появляется? Они раньше думали, ну вот спринт 10 фичей, отлично, делаем. А теперь у нас спринт не только 10 фичей, но и 10 экспериментов или 10 гипотез. Как перед клиентом 10 гипотез доказывать, что получилось, не получилось? Это целая эпопея. Но, грубо говоря, команда, которая разрабатывает агентные системы или системы, связанные с... ЛМ и тому подобное, они стали тем, что у них вот это появилось. Как с этим жить? Ну, понятное дело, что это надо вводить и измерять. Мы должны с бизнесом понимать, какие у него задачи стоят, бизнес-метрики, научиться их измерять. У нас должна быть платформа для измерения этих метрик. И научиться общаться с клиентом на языке именно гипотез. Ребята, мы проверим столько-то гипотез, посмотрим, что-то сработает, что-то не сработает. Нам очень сильно в том году помог такой инструмент, как ML System Design Doc. Это те, кто ML занимается, его хорошо понимают, знают. Мы его применили как раз в наших процессах исследовательских. Самое полезное, что там было, то что мы можем все наши эксперименты туда записывать. И клиент, с которым мы работаем, видит всю нашу работу. Мы понимаем, почему мы это согласились делать, почему не согласились это делать. Очень полезный, но требует определенной культуры вести этот документ. У нас получилось. Последнее, о чем хотелось поговорить ими в точке зрения SDLC, мы привыкли с вами разрабатывать системы для людей. Мы даже агентов делаем сейчас для людей, сервисы, еще что-то. Но если посмотреть повнимательнее, агент это новый актор. подключается к сервисам, подключается к другим агентам, подключается к нашему миру по каким-то татуам. И наши сервисы на самом деле очень сильно не готовы к нему. Мы сейчас размышляем и вас призываю тоже поразмышлять, что это значит для ваших сервисов, с которыми вы работаете. Вот появился агент, это новый актор, для него нужны новые точки входа. Он должен по-другому взаимодействовать. Как он взаимодействует с пользователем? Какая безопасность? Вот мы говорили про OpenClaw. Мы сейчас размышляли просто. Представим, у человека есть OpenClaw, который ходит по магазинам. Сейчас вкус его MCP выпустил. Говорит, покупайте у нас в магазине. А что, если он скомпрометирован этот агент? Как от него защититься? Как помочь пользователю от того, что у него агент скомпрометирован? Это новые задачи, которые сейчас появляются. Их надо только решать, размышлять об этом. либо не давать агенту пользователю. Ну, как будто не вариант. Джарвиса все хотят. Пока у меня нет правильных ответов. Ребята большие из OpenAI, про Harness очень много говорят. Это вот как раз туда тему в автоматизацию всего для агентов. То есть сейчас появляется потихоньку вот эта идея, что агент — это новое существо, и для него надо делать не для человека, а для агента делать сервисы. Есть наши выводы, на чем хотелось бы сконцентрироваться очень точно. Самое важное, если мы говорим про агентов, у него есть такой дуализм, я выразился, он сразу инженерный, там задачи надо решать, и исследовательский. В разработке из-за этого появляется исследовательский цикл, агентов надо как-то описывать, и для них надо на самом деле разрабатывать. И в процессе производства на самом деле все это то же самое. Jira удобный инструмент для человека, а для агента он не очень удобен. То есть там приходится приседания определенные делать. И вот смотря на все, что это происходит, куда мы катимся, можно немножко поразмышлять, какой будет процесс производства в будущем. У нас есть тезис. Агент это стал новый компонент, с которым мы должны дружить. У нас сметился роль человека. Он отвечает за... исследования границ. Мы перестаем смотреть за строчками кода. Нам уже не интересно, что там происходит с этим строчками кода. Это как с ассемблером. У нас есть код, в ассемблере приходят. Никто из нас уже не смотрит, там есть байтики. Нам это не интересно. Мы начинаем быть немножко исследователями. Уже недостаточно быть просто инженером. Мы должны немножко уже исследовать, развиваться в это направление. Немножко мы не затронули, но мы начинаем теперь работать вокруг контекста. Это все. Это наша боль. Любой агент становится умным только от того контекста, с которым он работает. И вот размышляет об этом одна из идей, которая у меня есть, что все-таки люди останутся только для того, чтобы поддерживать агентный слой, который разрабатывается. То есть у нас есть продукт-оунеры, они кидают идеи в агентный слой, который разрабатывает фичи. Скорее всего, в конце QA будет все-таки за качество отвечать. Основная задача людей будет поддерживать этот агентный слой. То есть они будут там UI-киты разрабатывать для того, чтобы целостная картина была. Скиллы какие-то определенные, следить за инфраструктурой в какой-то степени. Смотреть, чтобы база данных не разрослась, чтобы не кушали слишком много, не съел. А то был кейс у нас OpenClaw. Продуктованно развенул OpenClaw. Все прекрасно, с ним играется, экспериментирует. Там место закончилось. Но он же умный, он самостоятельно почистил, все скиллы удалил, всю память свою почистил. За этим надо следить, это помогает, и вот для этого нужна команда. По факту всю разработку и все эксперименты можно делать уже в автоматическом режиме. Осталось только везде чуть-чуть докрутить, и мы это получим. Поэтому мы сегодня начали про ускорение 10x. Наверное, самый главный вывод, что единственный, кто мешает этому ускорению, это человек. Ему надо найти свое новое место в этом процессе разработки. Потому что агенты уже справляются достаточно хорошо. Спасибо. Свои мысли, другие я делюсь в своем канале. Можете подписаться. Там все материалы уже должны быть опубликованы.

Владислав Шевченко, CTO red_mad_robot, рассказал про кризис SDLC и почему нельзя просто написать код и ждать результата. В докладе разобрали анатомию ИИ-агентов и критерии готовности компании к работе с ними.

Гибкая и производительная IT-инфраструктура для ИИ-задач: https://slc.tl/1em1h

Подписывайтесь на Selectel в социальных сетях: 
Telegram — https://slc.tl/4pkff
VK — https://vk.com/selectel 

Подписывайтесь на блоги Selectel: 
Хабр — https://habr.com/ru/company/selectel/ 
Академия Selectel — https://slc.tl/nxjp7

Не пропускайте мероприятия, которые Selectel проводит сам и вместе с партнерами: https://slc.tl/khiyk