ИИ-агенты уже умеют писать код, вызывать инструменты и работать внутри IDE, но это не делает их заменой команде разработки. В статье Аслан Агабубаев, главный системный аналитик GitFlic, объясняет, почему агент полезен только внутри зрелого SDLC, где есть архитектура, code review, CI/CD, контроль доступов и ответственность людей за итоговый результат.
Большая языковая модель (LLM) — это разновидность модели искусственного интеллекта, призванная заместить функции человека частично, а для некоторых задач и полностью. Ее сильная сторона — не «механизм мышления» в привычном смысле, а мощная логико-вероятностная модель, которая умеет предсказывать следующий фрагмент текста на основе колоссального корпуса текстов.
Начиная с GPT-4 (2023) эта технология стала достаточно мощной, и ее можно применять в практической работе. Модель не «понимает» задачу, а воспроизводит статистические закономерности, а значит, способна делать ошибки так же уверенно и незаметно, как и выдавать правильные ответы.
Популярность LLM обрели, когда для них создали программно-технические окружения, где они, как и профильные специалисты, начали выполнять разные задачи. Окружения и инструменты буквально выдали им «ручки», которыми те манипулируют любыми объектами в электронном виде.
Естественно искусственный
Сегодня вопрос замещения естественного интеллекта искусственным ставят ребром, и все чаще звучат аргументы в пользу второго как более компетентного исполнителя. При этом упускают главное, что при замене человека на LLM- или ИИ-агент в контуре программно-технического окружения само это окружение никуда не девается и по-прежнему требует развития. Это нормально, ведь «подкапотное» пространство базируется на фундаментальных программных и технологических решениях, а их история местами начинается с 2000-х годов, а иногда и более ранних.
В этом контексте уместно вспомнить классическую работу Ф. Брукса «Серебряной пули нет» (No Silver Bullet). По положениям из нее, сложность ПО делится на «случайную» (рутина написания и отладки кода) и «существенную» (понимание того, что и зачем строить, проектирование архитектуры, согласование требований, разрешение неоднозначностей). Инструменты, в том числе ИИ, уменьшают «случайную» сложность, но «существенную» убрать нельзя, она заложена в природе самой задачи. Иными словами, разработка софта никогда не сводилась к набору кода, а ценность инженера — к скорости печати.
ИИ ускоряет или замедляет
Сейчас ИИ-агент по простому текстовому запросу выдает вполне хорошее софтверное решение, иногда даже с избыточными «подкапотными» механизмами, и этот прогресс отрицать нельзя. Однако к ощущению «оно само все делает» стоит относиться осторожно.
В строгом рандомизированном контролируемом эксперименте организации METR опытные разработчики выполняли задачи с ИИ-инструментами на 19% дольше, хотя сами были уверены, что ускорились примерно на 20%. То есть субъективное ощущение продуктивности систематически расходится с измеримой реальностью, и принимать кадровые решения на основе впечатления опасно.
Новый мощный участник
Если же проанализировать работу ИИ-агента и выделить лучшие сценарии его использования, мы придем ровно к тем же проверенным рабочим процессам, в которых и так работают ИТ-специалисты. Сегодня лучший вариант применения агента (особенно в разработке и исследованиях) — это интеграция со средой разработки (IDE), где настроен рабочий каталог со всеми необходимыми файлами, манифестами, библиотеками, базами знаний и т. п.
В этом случае всегда актуализирован контекст по проекту, зафиксированы промежуточные и итоговые результаты в структурированном виде, а к работе могут подключаться как сторонние специалисты, так и другие ИИ-агенты.
Далее мы сталкиваемся с классическим автоматизированным циклом тестирования, сборки, доставки и развертывания. В него ИИ-агент встроился очень хорошо, поскольку знания и навыки работы с CI/CD, git, Docker, Kubernetes, Terraform и т. п. подробно описаны в интернете — именно на них агент обучался, и его компетентность ограничена тем, что хорошо представлено в доступных ему источниках.
Отсюда следует, что инструмент работает только потому, что опирается на фундаментальные технологии: git, конвейеры непрерывной интеграции и доставки (CI/CD) и контейнеры. То есть на ту самую инфраструктуру жизненного цикла разработки ПО (SDLC), что иногда предлагают сократить.
В итоге агент — это новый мощный участник, а не замена самого процесса. Более того, на уровне системы скорость написания кода. Например, исследование Google DORA показало, что с ростом внедрения ИИ стабильность поставки и пропускная способность не растут, а снижаются (примерно на 7,2% и 1,5% на каждые 25% внедрения), а почти 40% профи не доверяют сгенерированному коду. Слабое звено — доставка корректного и безопасного кода в промышленную эксплуатацию, а не его написание.
рИИски
Таким образом, ИИ-агент наиболее надежен внутри устоявшегося, хорошо документированного SDLC и резко теряет надежность за его пределами — это следствие того, как он обучается. Но даже если модели будут стремительно улучшаться, суть не в том, что агент чего-то не умеет, — контролируемый жизненный цикл разработки и управление рисками существуют по причинам, которые не исчезают при замене человека на ИИ. Система, ее сложность, ответственность и режимы отказа остаются теми же.
Куда хуже все выглядит, когда дисциплиной работы с ветками (git-flow) пренебрегают, позволяя агенту вносить изменения напрямую в рабочую ветку. Местами это приводит к самому неблагоприятному исходу — полному уничтожению базы данных без возможности восстановиться из резервной копии.
В июле 2025 года ИИ-агент платформы Replit во время «заморозки кода» и вопреки прямым многократным запретам уничтожил рабочую БД компании, а затем выдал недостоверный отчет и заявил, что откат невозможен, хотя этот откат в итоге все же сработал. Риск есть не только в разрушении, в одном контролируемом исследовании разработчики с ИИ-помощником писали заметно менее безопасный код — и при этом были более уверены в его безопасности.
Разумная стратегия
В таких случаях очевидно, что без классического контролируемого SDLC ИИ-агент, как и любой человек, может допустить ошибку, а раз такая вероятность есть, ею нужно управлять и анализировать множество факторов, как это классически решается в управлении рисками любого ИТ-проекта. Здесь работает известный парадокс автоматизации Л. Бейнбридж: «Автоматизируя бóльшую часть работы, мы не убираем людей, а оставляем им самое трудное — контроль и вмешательство в нештатных ситуациях».
Чем надежнее автоматика в обычном режиме, тем критичнее и дороже компетентное человеческое суждение в редкий, но решающий момент. К этому добавляется вопрос ответственности, ведь ее нельзя возложить на агента. Когда он уничтожит данные или внесет уязвимость, отвечать будет организация, и кто-то компетентный обязан этим риском владеть.
На основе этого разумная стратегия — не упразднять команду и процессы, а встроить агент внутрь контролируемого жизненного цикла разработки. Сохранить людей в ролях архитекторов, рецензентов кода и владельцев риска, ввести строгое разделение сред разработки и промышленной эксплуатации, обязательное рецензирование кода (code review), принцип наименьших привилегий (RBAC) и ограничения по процессам (quality gate). Тогда мы получим прирост продуктивности, не повторяя чужих ошибок.