Результаты внедрения AI в SDLC — риски и ошибки

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

Я несколько раз возвращал к этому вопросу Глеба Михеева, который занимается платформой агентов в Сбере, Дениса из команды безопасной разработки Яндекс SourceCraft и техлида Максима. Меня интересовал весь путь изменения: от задачи до работающего продукта и его сопровождения. Ускорение набора кода хорошо видно. Что происходит с остальной работой, выяснить сложнее.

Между личным инструментом и процессом компании

Глеб различал два состояния. В одном разработчик может спросить модель о коде, получить ответ и использовать его в работе. В другом сам процесс устроен с расчётом на агентов: им доступны необходимые сведения, понятно, какие задачи они получают, как возвращают результат и кто его принимает.

Первое состояние он называл AI-enabled, второе AI-native. Смысл различия удобнее объяснить через электронный документооборот. Новая компания обычно сразу организует его в цифровом виде. Ей не нужно сначала построить бумажный процесс, а потом пристроить к нему сканер. С агентами, по мнению Глеба, нам ещё предстоит пройти похожий путь.

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

Глеб говорил об этом без отрицания прогресса моделей. Они стали лучше работать со структурированной информацией, получили больше контекста и возможность выполнять последовательности действий. Но процессы компаний к такому участнику часто не готовы. Обещание заменить разработчиков упирается в работу, которую раньше незаметно делали сами разработчики вокруг кода.

Спецификация перед кодом, проверка после

Максим ожидал перераспределения времени. Меньше непосредственного написания кода, больше подготовки задания и проверки результата. Он связывал это с разработкой от спецификации: сначала описать, что должно получиться, затем дать агенту выполнить работу и проверить её по заранее определённым условиям.

В такой спецификации недостаточно написать «сделай форму на React». Нужны требования к поведению, удобству использования и безопасности. Архитектурные договорённости тоже должны попасть в контекст. Если они остаются только в голове команды, модель не обязана их угадать.

Проверку Максим рассматривал как самостоятельную часть процесса. В ней могут участвовать и люди, и другие агенты. Тесты помогают установить, делает ли программа то, чего от неё ждут, но сам набор проверок тоже приходится продумывать.

Глеб увидел здесь новое применение старых инженерных практик. Разработка через тестирование особенно полезна, когда человек сначала проверяет, что тест описывает нужное поведение, а затем агент доводит реализацию до прохождения этого теста. Хорошо описанная архитектура становится частью рабочего контекста, а не документом, к которому редко возвращаются.

Максим сравнил это с каскадной разработкой: сначала подробное описание, потом реализация. Только раньше между ними могли пройти месяцы, за которые требования успевали измениться. С агентами полный проход может быть гораздо короче. Глеб предположил, что мы ещё повторим знакомую историю: сначала попробуем всё заранее расписать, затем столкнёмся с ограничениями и начнём строить более гибкое взаимодействие между участниками.

Денис остановил этот оптимистичный разговор вопросом о середине процесса. С одной стороны у нас спецификация, с другой тесты. А между ними код, который будет работать в продукте. Кто отвечает за его свойства, которые в тесты не попали? Что произойдёт с безопасностью и с поддержкой этой реализации?

Какой код можно отдать агенту

Глеб предложил разделить код по последствиям решений. У системы есть архитектура, которую дорого менять, и локальные возможности, которые на неё опираются. Форма обратной связи или отображение списка товаров в корзине обычно имеют более понятные границы, чем выбор общего устройства приложения.

Локальную задачу можно описать и проверить. Архитектурные решения, ответственный код и договорённости, влияющие на долгую жизнь проекта, Глеб пока оставлял людям. Для него это была практическая граница доверия агенту в 2025 году.

В качестве более смелого примера он предложил представить набор микросервисов с сохранёнными спецификациями и тестами. Если общая архитектура остаётся прежней, реализацию отдельного сервиса можно сгенерировать заново, в том числе на другом языке. Тогда исходный код перестаёт быть единственным местом, где хранится замысел системы.

Денис возражал против формулировки «неважно, какой код». Он не был готов считать выполнение бизнес-задачи достаточным признаком качества. Глеб уточнил: ему важны измеримые характеристики. Если код запускается за допустимое время, укладывается в память и проходит нужные проверки, язык или внешний вид реализации не должны становиться самоцелью.

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

Денис с необходимостью требований не спорил. Его сомнение осталось прежним: мы ещё должны доказать, что реализация им соответствует. Хорошо написанная спецификация сама по себе этого не делает.

Ощущение скорости и время по часам

Денис привёл исследование METR с участием 16 опытных разработчиков. До эксперимента участники ожидали ускорения от инструментов ИИ. После работы им тоже казалось, что они справились быстрее, хотя измеренное время, по приведённым Денисом данным, выросло примерно на пятую часть.

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

Денис оговорил небольшую выборку. Он не предлагал распространить результат на всю разработку. Скорее, это был довод в пользу измерений: после первого интереса к технологии пора смотреть на конкретные задачи и считать, что получилось.

Позже Максим оспорил такую интерпретацию. Он считал существенным опыт участников с инструментом: знакомство с Cursor и практикой разработки с ИИ, по его прочтению результатов, влияло на итог. Средняя величина могла скрывать разные результаты у разных людей. Для Максима исследование не доказывало, что освоенный инструмент бесполезен. Он видел в этом ещё и цену его освоения.

На этом они не пришли к общему выводу о величине ускорения. И я бы не заменял их спор одной удобной цифрой. Денис требовал сравнивать обещания с измеренным временем, Максим — учитывать, чему успели научиться участники и какой именно способ работы проверяли.

Я вернулся к тому же вопросу с другой стороны. Если мы меньше времени пишем код, но больше готовим спецификации и проверяем результат, не переложили ли мы работу из одной корзины в другую? Максим отвечал, что выигрыш может проявляться в качестве и в последующих итерациях, когда новый инструмент уже освоен. Это ожидание ещё нужно проверять на полном процессе.

Агенту необязательно работать одному

Когда разговор дошёл до остальных этапов разработки, я спросил, где участники уже не готовы отдавать работу агенту. Сбор требований, реализация, публикация и сопровождение предъявляют разные требования к самостоятельности.

Максим предложил сначала оценить сложность задачи, необходимый объём контекста и знакомство модели с предметной областью. Иногда задача слишком велика и её нужно разбить. Иногда она кажется обычной, но внутри есть специфические знания, которых у модели нет. Это приходится учитывать до передачи работы.

Глеб описал два режима. В автономном задача переходит агенту из трекера, тот выполняет её и приносит изменение на проверку. Человек оставляет замечания, после чего агент продолжает. В парном режиме человек остаётся рядом и управляет ходом работы: просит предложить варианты, дополняет условия, уточняет смысл.

Например, при подготовке требований помощник может заметить, что в документе вообще ничего не сказано о нагрузке или безопасности. Он предлагает дополнения с опорой на архитектурное руководство компании, а человек решает, подходят ли они. Это полезная работа, хотя агент здесь ничего не делает самостоятельно от начала до конца.

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

Глеб сравнил выбор с делегированием людям: одну задачу можно дать джуну, другую более опытному разработчику, а над третьей лучше посидеть вместе. Новая часть работы инженера состоит в том, чтобы сделать этот выбор, объяснить ожидаемый результат и затем принять его. Ответственность от такого делегирования не исчезает.

Специализация и понимание целого

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

Глеб сослался на подкаст с Кентом Беком о меняющейся ценности навыков. Для него в этом был важен рост ценности анализа и декомпозиции, а также способности управлять ходом работы. Инженерная база при этом остаётся необходимой: без неё трудно понять, какое решение получилось.

Из этого не следовало, что один человек немедленно заменит все специальности. Денис напомнил о существующих ролях в процессе разработки. Специалист по безопасности знает, какие угрозы искать и как от них защищаться. Автоматизация его работы не означает, что эти знания стали ненужными.

Максим тоже сомневался в популярном образе огромной компании из одного человека. Ему казалась более реалистичной небольшая команда опытных специалистов, каждый из которых умеет усиливать свою работу ИИ. У людей сохраняются разные области экспертизы, но они могут выполнять больше работы. Подобные команды, по его мнению, полезно создавать и внутри крупных компаний, чтобы вырабатывать практики.

Глеб опасался другой крайности: слишком узкой специализации, за которой теряется понимание продукта. Фронтендер отправил запрос, получил ошибку и считает всё остальное чужой проблемой. Разработчик написал код, у него на компьютере работает, дальше пусть разбираются другие. При работе с агентами такая граница становится особенно неудобной: чтобы поручить более крупную задачу, приходится понимать, как связаны её части.

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

Глеб считал, что доступность объяснений во многом компенсирует новые требования. Раньше нужную книгу приходилось искать и ждать, теперь можно задать вопрос модели и попросить объяснить прототипное наследование через знакомый пример. Я напомнил, что сложность программных продуктов тоже выросла. На этом мы поспорили: отдельные задачи стали гораздо удобнее, но всё приложение от этого не обязательно проще понять.

Для Глеба показательным примером была старая вёрстка скруглённых окон с тенями: нарезанные картинки и таблицы сменились CSS-свойствами. Для меня важнее было, сколько разных частей современного приложения теперь приходится держать в голове. Оба изменения происходят одновременно.

Неудачная первая попытка ещё мало что говорит

Я спросил, насколько часто агент вообще справляется со сложной задачей с первого раза. Максим напомнил, что такая работа не обязана укладываться в один запрос. Результат вероятностный, следующая попытка может отличаться, а короткая итерация иногда стоит сравнительно мало.

Глеб предлагал смотреть и на движение возможностей моделей. Увеличение рабочего контекста позволяет учитывать больше кода и связей. При этом большую задачу можно дополнительно разделить. Он считал преждевременным делать окончательные выводы по текущему пределу сложности.

Максим сослался на другую работу METR: оценку длительности задач по времени, которое на них требуется человеку, и вероятности, с которой модель справляется с такими задачами. В его аргументе важна именно вероятность. Способность выполнить более длинную задачу примерно в половине попыток отличается от гарантии, что агент надёжно выполнит любую такую задачу в продукте.

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

Проверять раньше, чем код передали через забор

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

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

Такой подход часто называют guardrails. Например, требования к безопасности должны влиять на то, как агент выполняет задачу, а проверки должны возвращать результат во время работы. Поиск уязвимости моделью сокращает цикл, но разработчик по-прежнему должен понять, что ему принесли и как это исправить.

Для Дениса здесь была основная проблема внедрения. Если процесс плохо устроен, более сильная модель начинает быстрее производить тот же неподходящий результат. Автоматизация отдельных ролей ещё не исправляет взаимодействие между ними.

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

Поддержка агента тоже стоит денег

Глеб отдельно остановился на работе после первого удачного запуска. Агенту нужно определить критерии качества, подобрать метрики и научиться их измерять. Затем собрать случаи, на которых его можно проверять, и регулярно убеждаться, что изменения не ухудшили результат.

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

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

Глеб описывал постоянное сопровождение: команды ищут места, где агент ошибается, улучшают контекст и снова проверяют. Поэтому он не обещал мгновенной финансовой выгоды. В 2025 году он считал многие такие внедрения дорогими и связывал будущую экономию с большей автономностью и зрелостью практик.

Максим соглашался с тем, что работы не становится мало. Она перемещается выше непосредственного написания кода. Человек всё ещё решает, что должно быть сделано и как понять, что результат подходит. Для него это требовало не меньшего внимания, чем программирование вручную.

Кто заметит, что всё сломалось

Мой вопрос о чае был всё-таки про поведение людей. Можно сколько угодно говорить, что код нужно проверять. Но если результат появляется без усилий, человеку легко перестать в него вникать. Как не потерять критическое мышление вместе с привычкой писать каждую строку самостоятельно?

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

Ему близок подход, при котором команда сопровождает то, что сама создала. Инструменты доставки и эксплуатации помогают разработчику видеть, как работает его код. После передачи изменения нельзя перекладывать ответственность на эти инструменты.

Я возражал, что последствия неумелого делегирования могут затронуть тысячи пользователей, а не только самого разработчика. Глеб настаивал: человек отвечает за результат делегирования при любом инструменте. Если организация разрешила генерировать код, почему она не организовала проверку и не описала архитектурные требования?

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

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

Глеб поставил под вопрос и привычные критерии качества кода. Мы избегаем запутанной структуры и копирования, потому что людям дорого читать и менять такую реализацию. Насколько те же ограничения важны для моделей, он оставлял открытым вопросом.

Максим предложил искать инженерную красоту выше самого кода — в спецификациях и процессе работы. Глеб согласился: ясные требования, работающие проверки и хорошие показатели продукта могут приносить не меньше удовольствия, чем удачно написанная программа.

Что останется после ажиотажа

В конце я предложил противоположный сценарий: мы ещё пару лет помучаемся и вернёмся к привычной разработке. Максим в это не верил. По его оценке, даже существующие модели уже дают достаточно возможностей, чтобы продолжать менять работу без ожидания очередного прорыва.

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

Глеб допускал и экономические последствия спада интереса: расходы будут пересматривать, неудачные направления закрывать. При этом полезные применения останутся. Он также связывал дальнейшее развитие со способностью моделей удерживать больший контекст и работать с ним без неприемлемого роста стоимости.