Автоматизация и внедрение ИИ-инструментов в процессы разработки — уже не просто тренд, а реальность большинства технологических команд. Однако остается открытым вопрос, позволят ли в ближайшем будущем технологии нанимать драматически меньше специалистов — например, сократить штат в два раза. Как сегодня обстоят дела с внедрением ИИ в ИТ и как это повлияет на размер команд, рассказывает Станислав Пятецкий, генеральный директор ИТ-интегратора AWG.
ИИ как ускоритель
На практике искусственный интеллект сегодня не заменяет специалистов, а усиливает их продуктивность. В первую очередь — за счет автоматизации рутинных операций: генерации кода по шаблону, автодополнения, синтаксического анализа, генерации технической документации, резюмирования встреч, транскрибации интервью и визуализации бизнес-процессов.
Например, в популярных средах разработки, таких как VDE и PHPStorm, уже есть функции, позволяющие переиспользовать код и генерировать достаточно большие его части автоматически. Однако эти инструменты пока не способны полностью заменить человека в создании сложной архитектуры — в проектировании сервисной или микросервисной архитектуры, продумывании интеграций и разработке бизнес-логики, которая далее должна быть реализована в коде.
Современные инструменты, такие как GitHub Copilot, CodeWhisperer или встроенные нейросетевые ассистенты в IDE, действительно позволяют повысить скорость разработки на 20–50% в типовых задачах. При этом эти показатели не эквивалентны кратному снижению потребности в кадрах, и говорить о сокращении команды вдвое пока рано.
Автоматизация не равна исключению человека — скорее, это перераспределение функций внутри команды.
Водитель с автопилотом
В автомобильной классификации существует шесть уровней автономности по шкале SAE, от 0 до 5, и они легко и наглядно сопоставляются с развитием ИИ-инструментов в разработке.
На нулевом уровне водитель контролирует все: руление, газ и тормоз, на первом система может управлять одной функцией — например, круиз-контроль или автоматическое торможение, но не обоими одновременно.
На уровне 2 машина уже может управлять рулем и ускорением/торможением, но водитель должен постоянно следить за дорогой и быть готовым вмешаться. Именно здесь находится большинство современных ИИ-инструментов: на уровне «автопилота с водителем».
Генераторы кода могут предложить полноценные блоки логики, структуры функций, даже черновики тестов. ИИ ускоряет процессы, но все же не понимает бизнес-контекста. Ответственность остается на человеке: разработчик обязан проверять, интерпретировать и корректировать код вручную.
Главная проблема в том, что ИИ-инструменты все еще склонны к ошибкам. Они могут пять раз предложить качественное решение, а на шестой — сгенерировать абсурдный или критически неверный результат. Это делает полное доверие невозможным. Так называемые «галлюцинации», непоследовательность, снижение точности при усложнении задачи — все это еще типично для ИИ и требует постоянной верификации человеком.
Исключение человека — нет, сокращение звеньев — да
Поэтому в текущей практике разработку нельзя просто взять и автоматизировать полностью, уволив живых людей. Однако существует гораздо более перспективный путь: начать с оптимизации отдельных звеньев, например, аналитической части.
Сегодня аналитики формализуют бизнес-процессы — описывают, как работает система, строят схемы, выявляют логические связи. Все это можно представить в виде визуальной модели, которую современные инструменты уже способны обрабатывать.
Если систему научить правильно интерпретировать такие модели, она сможет автоматически генерировать нужную бизнес-логику, подстраиваясь под формализованный процесс.
Тем не менее традиционный путь создания ПО остается довольно сложным и фрагментированным. Обычно процесс начинается с разработки версии продукта, затем подключается публика и заказчики, затем идет стадия проектирования, после чего начинается реализация. Проблема в том, что пока проходит вся эта цепочка, требования часто меняются, и процесс становится хаотичным. Особенно это характерно для крупных организаций и публичных проектов.
В российских реалиях сегодня активно закупаются no-code и low-code платформы, предназначенные для того, чтобы бизнес-пользователи могли сами моделировать и реализовывать процессы без участия программистов. Однако на практике эти инструменты используются не до конца, и автоматический переход от схемы к работающему процессу пока так и не случается.
Но сократить путь от идеи до реализации все же возможно. Если из цепочки исключить этапы проектирования и промежуточного согласования, а аналитику предоставить инструменты, которые позволяют сразу воплощать замысел в рабочем процессе, нагрузка на разработчиков значительно уменьшится.
В идеале это может выглядеть так: аналитик рисует схему бизнес-процесса, а система сразу реализует ее, предоставляя обратную связь: вносишь изменения — и тут же видишь, как они отразились на поведении системы. Однако до такой модели пока далеко — как с точки зрения зрелости инструментов, так и с точки зрения готовности к их внедрению в корпоративную практику.
AWG известно о практике одной крупной компании, где была внедрена платформа, основное преимущество которой заключалось в простоте взаимодействия: аналитики могли легко получать результаты своей работы и передавать их дальше по цепочке. Система позволяла сократить путь от аналитики до реализации, и в течение нескольких лет проект дошел до топ-менеджеров — то есть, получил одобрение на высоком уровне.
Однако на практике, как только бизнес-процесс попадал к разработчикам, возникали сложности. Им могли передать очень запутанные и плохо структурированные процессы, и это приводило к тому, что при любом неосторожном вмешательстве система могла выйти из строя или перестать корректно функционировать.
В результате возникла хаотичная и нестабильная архитектура, несмотря на то что скорость разработки и time-to-market на первом этапе была высокой. Это показывает, что даже при наличии удобных инструментов и хорошей динамике на старте, на текущем уровне развития технологий красивая идея может столкнуться с суровой реальностью.
Границы автоматизации
Свои перспективы и границы есть в каждой области — например, DevOps. На сегодняшний день ИИ здесь применяется пока не так широко. В тестировании есть потенциал для его использования, особенно если на входе имеются четко описанные тест-кейсы и понятные сценарии — тогда ИИ может обучаться и выполнять тесты автоматически.
Автотесты значительно ускоряют и оптимизируют процесс разработки, экономя огромное количество времени по сравнению с ручным тестированием. Однако есть и ограничения: большая часть процесса — тестирование интерфейсов (UI), и те тесты, которые проверяют опыт и взаимодействие реального пользователя с системой, ИИ пока заменить не может.
Кроме того, часто после модификаций приходится переписывать и сами автотесты, чтобы они адекватно отражали новые требования и поведение системы при изменении интерфейсов и бизнес-логики.
Иногда компании просто перестают их поддерживать, чтобы не тратить ресурсы на их постоянное обновление. Поддержка тестовой инфраструктуры становится самостоятельной задачей, которую ИИ на текущем уровне не способен устойчиво решать без участия человека.
Поэтому сейчас в DevOps-практиках ИИ ограничен рамками шаблонных задач: генерация Dockerfile, конфигураций CI/CD, YAML-манифестов. Сложные сценарии, включая секьюрити-аналитику, наблюдаемость и управление инцидентами, пока требуют высокой вовлеченности людей.
Ключ — в зрелости процессов
И все же самым важным фактором успешного внедрения ИИ в производственный процесс остаются не сами технологии, а зрелость организации.
Там, где существуют четко формализованные процессы, архитектурные стандарты и цифровые модели бизнес-логики, внедрение ИИ уже успешно позволяет ускорить цикл разработки и сократить транзакционные издержки. А там, где работа опирается на устные договоренности и личные практики сотрудников, ИИ всегда будет использоваться локально, но не глобально.
Кроме того, эффективность использования ИИ в компании также определяет культурная зрелость команды. Специалисты, активно применяющие инструменты автоматизации, дают кратный прирост производительности по сравнению с теми, кто продолжает работать традиционно.
Консерватизм мышления у многих специалистов все еще наблюдается: привычка и недоверие к новому мешают адаптироваться, однако их будущее выглядит неопределенно — они рискуют быстро «выйти в тираж».
Например, в AWG на собеседованиях кандидатов всегда спрашивают, какие именно ИИ-решения они применяют в своей работе и как это влияет на их эффективность. Причем это началось давно: еще в тот период, когда оптимизация разработки с помощью ИИ воспринималась как нечто экспериментальное, компания приглашала специалистов, способных предложить реальные улучшения: например, автоматизацию подготовки документации, сбор корпоративной базы знаний, ускорение аналитики.
Сегодня это уже не эксперименты, а часть устойчивой инженерной практики, и способность специалиста ориентироваться в этой новой реальности становится важнейшим показателем его профессиональной зрелости.
Когда можно будет сократить команду вдвое
Гипотетическое сокращение команды наполовину — задача не фантастическая, но требующая строгого соблюдения определенных условий. Прежде всего — зрелость процессов: стандартизированные требования, наличие архитектурных паттернов, качественная документация и развитая тестовая инфраструктура.
Второй критически важный фактор — цифровая зрелость самой команды, включая навыки работы с ИИ и гибкость в переосмыслении рабочих ролей. И, наконец, — при текущем развитии технологий — ограниченность сценариев и стабильность требований: именно это позволяет ИИ справляться с задачами без чрезмерной нагрузки.
Конкретные сроки реализации назвать невозможно: процесс может затянуться на десятилетия а может, напротив, ускориться из-за технологических прорывов и сдвигов парадигм.
Полная же замена человека в ИТ — пока что скорее футуристический сценарий. Возможно, когда-нибудь в будущем появятся полностью автономные цифровые предприятия, в которых все процессы — от аналитики до обслуживания — выполняются без участия людей, и даже при поломке робота направляется другой робот для его починки. Но в текущей реальности мы далеки от этого.
Живые, гибкие, плохо формализованные процессы, которые невозможно загнать в строгие схемы, по-прежнему требуют участия человека. Пока в системах остается хотя бы один неавтоматизированный участок, ИИ будет не заменой, а помощником. Иными словами, мы по-прежнему на стадии, когда автопилот включается, но руки все еще на руле.