Локальные ИИ-модели и ИИ-агенты приходят в команды разработки. IT-World разбирался, что это дает и где без тестирования и метрик нельзя обойтись.
Еще недавно было непонятно, останется ли он игрушкой для демонстраций или станет рабочим инструментом. Теперь сомнений меньше, мы видим как ИИ встраивается в процессы и ускоряет их, но одновременно повышает цену ошибок и важность проверок.
Меня зовут Кирилл Филенков, я директор по качеству в Bell Integrator. Давайте разберемся, что именно он меняет и как это отражается на качестве.
Существует множество подходов к оценке влияния ИИ. Кто-то начинает с применения ИИ в тестировании, кто-то — в аналитике или поддержке. Я же предлагаю пойти другим, на мой взгляд, наиболее логичным путем: посмотреть, где ИИ применяется уже сейчас, и какие последствия это влечет за собой.
Разработка ПО
Первая область, где ИИ уже применяется повсеместно, — это разработка. Да-да, даже если ваш сотрудник утверждает, что пишет код полностью самостоятельно, с высокой долей вероятности он использует ИИ-инструменты.
Плохо ли это? Конечно нет. Запрещать использовать ИИ — все равно что запрещать пользоваться интернетом или искать готовые решения. Это не читерство, а инструмент повышения эффективности.
Почему я начинаю именно с разработки? Все просто: именно здесь последствия применения ИИ наиболее заметны и масштабны.
Утверждение первое: «ИИ может галлюцинировать»
Да, это правда. ИИ действительно может генерировать код, который делает не совсем то, что требуется. Но давайте будем честны: ответственность за результат все равно лежит на специалисте.
В своей повседневной работе я практически не использую ИИ как единый универсальный инструмент. Гораздо эффективнее рассматривать его как набор специализированных ролей.
Обычно мой рабочий процесс выглядит так: в первом чате я описываю бизнес-контекст задачи и прошу сгенерировать базовую реализацию. Во втором — прошу выступить в роли строгого ревьюера и найти потенциальные дефекты, архитектурные проблемы и нарушения принятых подходов. Здесь очень важно указать необходимость объективно оценки, т.к. большинство ИИ моделей склонны хвалить и соглашаться с автором, что бы он не написал. Третий чат используется для финальной оптимизации и упрощения логики. Отдельно я применяю ИИ для генерации unit-тестов, с применением различных техник тест-дизайна, таких как граничные значения и негативные сценарии.
Такой подход позволяет значительно снизить количество ошибок еще до этапа ручного тестирования. В итоге мы получаем не просто рабочий код, а код с меньшим количеством функциональных дефектов, чем при классической ручной разработке.
Можно возразить, что такой подход требует дисциплины и компетенций. И это правда. Но если специалист не способен грамотно использовать ИИ, то и без него он, скорее всего, напишет код сомнительного качества — без паттернов, архитектуры и тестов. В лучшем случае это будет фрагмент с GitHub, который «каким-то чудом работает».
Следствие первое: использование ИИ в разработке приводит к снижению количества функциональных дефектов в продукте.
При этом важно отметить: ИИ не является магическим решением. Я неоднократно сталкивался с ситуациями, когда размытая или противоречивая постановка задачи приводила к тому, что ИИ быстро генерировал формально корректный, но абсолютно бесполезный код. В этом смысле он ведет себя ровно так же, как и человек-разработчик, только значительно быстрее. Качество результата по-прежнему напрямую зависит от качества входных требований.
Утверждение второе: скорость разработки кратно возрастает
И это тоже факт. С помощью ИИ можно за несколько часов реализовать то, на что раньше уходили недели.
Из личной практики могу отметить, что основной выигрыш от использования ИИ — это даже не скорость написания кода, хотя и она безусловно ускоряется, а сокращение длительности принятия инженерных решений. В одном из проектов типовой сервисный слой с DTO, маппингами и базовыми проверками ранее занимал несколько рабочих дней. С использованием ИИ базовая версия была собрана за несколько часов, а основное время ушло на уточнение требований и проверку итогового решения.
По сути, ИИ смещает фокус разработчика с «писать код» на «думать и проверять». Важно понимать нюанс: максимальный эффект достигается в проектах, которые изначально проектируются с учетом использования ИИ. В легаси-системах прирост скорости менее выражен, но он все равно остается значительным.
Следствие второе: рост скорости разработки неизбежно требует ускорения процессов тестирования. На первый план выходит автоматизация тестирования и пересмотр QA-процессов в целом.
Утверждение третье: «Системы становятся менее устойчивыми к нагрузке»
Аргумент звучит так: ИИ в первую очередь реализует функциональность, а не думает о производительности. Частично с этим можно согласиться. Однако стоит признать, что ровно так же ведут себя и многие разработчики-люди.
ИИ можно обучить проектированию высоконагруженных систем, если в промтах и обучающих данных заложены соответствующие требования и примеры.
Тем не менее, рост скорости разработки приводит к тому, что нагрузочное тестирование и performance-инженерия должны развиваться значительно быстрее, чем раньше.
На практике мы столкнулись с тем, что ускорение разработки за счет ИИ достаточно быстро упирается в ограниченные возможности нагрузочного тестирования. Дело в том, что одна из особенностей нагрузочного тестирования заключается в необходимости эмуляции нагрузки эквивалентной продуктовой. Следовательно, нельзя просто так взять и за минуту проверить производительность, необходимо тратить часы на постепенное увеличение частоты операций. И это без учетов тестирования стабильности. Тесты данного типа длятся от 8 часов и более. Без этого определить максимум системы невозможно. Это заставляет пересматривать сами подходы к нагрузочному тестированию и активнее автоматизировать не только тесты, но и подготовку тестовых данных.
Следствие третье: возникает необходимость расширения команд нагрузочного тестирования и переработки подходов к обеспечению качества с упором на скорость и масштабируемость.
Что происходит уже сейчас
Многие крупные компании уже сегодня разрабатывают и внедряют локальные ИИ-модели. И на это есть как минимум две причины.
Во-первых, безопасность. Передавать проприетарный код и архитектурные решения внешним сервисам — риск, на который готовы идти далеко не все.
Во-вторых, качество. Открытые модели обучались на данных из интернета — в том числе на плохом, неэффективном и устаревшем коде. Гораздо эффективнее разворачивать ИИ локально и обучать его на собственных кодовых базах, стандартах и лучших практиках. Ведь при внутреннем обучении ИИ агентов можно контролировать поток входных данных, отсеивая некорректные и спорные решения.
Многие компании идут еще дальше и формируют целые команды ИИ-агентов под конкретные проекты:
- ИИ-аналитик, обученный предметной области;
- ИИ-разработчик, знающий архитектуру, паттерны и код-стайл проекта;
- ИИ-тестировщики, автоматизаторы и специалисты по нагрузочному тестированию.
Что нас ждет
На протяжении более чем 70 лет языки программирования делились на два типа: низкоуровневые и высокоуровневые. Эта концепция практически не менялась.
Впервые за десятилетия мы стоим на пороге появления принципиально нового типа языков программирования — и он уже существует. Это язык промтов.
Когда-то программисты писали на машинном коде. С появлением высокоуровневых языков звучали те же самые страхи: «Программисты станут не нужны», «Они перестанут понимать, как работает машина», «Код станет медленным и неоптимизированным». Были ли эти опасения обоснованы? Частично — да. Но вместе с этим вычислительные мощности выросли в тысячи раз, а скорость разработки — еще больше.
Да, код на ассемблере может быть быстрее, чем на Java. Но готовы ли мы выпускать релизы раз в год ради выигрыша в одну миллисекунду? Очевидно, нет. Мы просто перешли на другой уровень абстракции.
Сейчас происходит ровно то же самое. Появляется новое поколение специалистов — программистов на языке промтов. И они будут востребованы. Важно понимать: это не низкоквалифицированные специалисты. Напротив, требования к ним зачастую выше, чем к классическим разработчикам. Чтобы получить качественный результат от ИИ, нужно уметь формулировать задачи профессионально.
Хорошая аналогия — генерация визуального контента. Промт «Сделай человека, идущего по городу, фотореалистично» даст посредственный результат. А использование терминов вроде фокусного расстояния, диафрагмы, ISO, типов объективов и переходов — позволяет получить изображение или видео, неотличимое от реальности.
В программировании все точно так же. Останутся джуны, мидлы и сеньоры. Останутся тестировщики, аналитики и архитекторы. Но их компетенции изменятся — и именно способность эффективно работать с ИИ станет ключевым навыком ближайших лет.
Наблюдая за внедрением ИИ в реальных проектах, я все меньше воспринимаю его как угрозу профессии и все больше — как просто инструмент, который меняет нашу работу, но не заменяет нас. Рутинные действия уходят, а требования к инженерному мышлению, архитектуре и ответственности за результат становятся выше. И это, на мой взгляд, ключевое изменение, которое уже происходит в IT.
Находиться на острие технологического прогресса и внедрять передовые решения — один из ключевых принципов работы нашей компании. Последовательное применение современных ИИ-инструментов, а также развитие собственных внутренних решений позволили нам в 2025 году увеличить производительность труда на 23%. И это не предел, мы продолжаем оптимизацию.