Как ИИ меняет разработку. Рассказываем, что работает уже сейчас

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

Кому и как помогают ИИ-агенты

ИИ-агенты уже реально меняют разработку, но совсем не так, как это часто продают маркетологи. Сильная сторона нейросетей — не «самостоятельно сделать продукт вместо команды», а быстро помогать в отдельных хорошо описанных задачах.

Агенты хорошо справляются и с другими задачами, у которых есть чёткая структура и понятный критерий проверки:

• Юнит-тесты для хорошо изолированных функций.

• Документация. JSDoc, README, описание эндпоинтов — агент справляется быстро, и проверить результат легко.

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

• Рефакторинг по чёткому условию. Переименовать, привести к стилю проекта, вынести повторяющийся фрагмент.

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

Выгоды от внедрения уже описаны в цифрах. Например, в исследовании GitHub/Microsoft Research разработчики выполняли часть операций заметно быстрее: время снижалось примерно с 2 часов 41 минуты до 1 часа 11 минут, а процент успешного завершения вырос с 70% до 78%. В других исследованиях и опросах тоже видно, что ежедневное использование ИИ-инструментов даёт экономию времени. Исследователи отмечают, что эффект не появляется сразу — по некоторым данным, реальная польза возникает только после нескольких недель регулярного использования.

Разработчик, используя ИИ, должен сначала научиться ставить задачи, проверять результат и понимать ограничения конкретной модели. Поэтому тезис «ИИ заменит разработчиков» слишком грубый. Скорее, ИИ усиливает разницу между теми, кто понимает, что делает, и теми, кто просто принимает сгенерированный ответ.

Ошибки и галлюцинации

Модели постоянно совершенствуются, но проблема пока не исчезла. ИИ всё ещё может предложить несуществующую библиотеку, придумать API, которого нет, или сгенерировать код с уязвимостью. Причина не только в «глупости модели», а в самой природе разработки: экосистема меняется быстрее, чем обновляются обучающие данные. Пакеты выходят, устаревают, меняют интерфейсы, ломают совместимость, а модель уверенно рассказывает о снимке мира, который уже немного стал другим. Для человека это выглядит особенно коварно: ответ написан уверенно, структура приличная, код похож на рабочий. Но похожий на рабочий код — это не рабочий код.

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

Всё это не значит, что ИИ-агенты бесполезны. Но они работают только там, где задача хорошо описана, повторяема и допускает понятную проверку результата.

ИИ — это синтез, а не поиск по кэшу

Один из распространённых страхов вокруг использования нейросетей в разработке: модели учились на Stack Overflow и GitHub. Сейчас Stack Overflow пустеет, GitHub заполняется ИИ-кодом — получается петля деградации. Страх понятен, но в его основе лежит неточное представление о том, как работает языковая модель.

Модель — не поисковый индекс. Во время обучения тексты не складываются внутрь как файлы в архив, а превращаются в «веса».

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

Опасения о деградации источников обоснованы. Но неправильно думать, что ИИ «закончится», потому что у него больше не будет свежего Stack Overflow. Во-первых, модели обучаются не только на вопросах и ответах. Есть документация, книги, статьи, спецификации, production-код, синтетические данные, обратная связь от пользователей, результаты запуска кода, статический анализ и другие способы проверки качества. Во-вторых, ценность модели не только в знании конкретной версии конкретной библиотеки, а в способности работать с контекстом. Если дать ей документацию, код проекта, ошибку, логи и ограничения задачи, она может применить свои общие паттерны к свежей информации. То есть проблема с актуальностью данных частично решается не только новым обучением, но и связкой модели с инструментами: поиском, документацией, репозиторием, тестами, линтерами, логами и исправлением сгенерированного кода самим разработчиком. Широкое применение контекста — это то, что поможет ИИ и работающим с ними специалистам решить проблему устаревания данных в открытых источниках и снижения их качества. Этот подход реален и уже применяется в практической разработке.

Не просто автоматизация, а смена парадигмы

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

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

Переходы раньше длились годами или десятилетиями. Появлялись книги, курсы, паттерны, школы мышления. Сообщество спорило, ошибалось, вырабатывало общий язык. Сейчас новые модели, IDE и агенты появляются настолько часто, что мышление не успевает стабилизироваться. Разработчик только начал понимать, как эффективно использовать один инструмент, а рынок уже принёс следующий. Главная сложность — в том, чтобы успевать за этой скоростью.

Текущее состояние разработки с использованием ИИ-агентов — переходное. Сейчас нет окончательно сложившихся best practices. Нет единого ответа, как правильно встраивать агентов в процесс, где должна проходить граница их автономности, как организовывать ревью ИИ-кода. Разработчику приходится тратить много когнитивного ресурса на то, чтобы самому тестировать гипотезы и осваивать новый инструмент в своей личной практике.

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

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

Вот почему следующим шагом в программировании, вероятно, станет появление принципиально нового класса инструментов — не компилятора, не DSL с синтаксическим сахаром поверх Python, а чего-то, что позволит описывать намерение и поведение системы, а не пошаговую инструкцию.

Первые признаки такого подхода уже есть. В 2023 году команда исследователей из Стэнфорда опубликовала DSPy — фреймворк, который предлагает относиться к работе с языковой моделью как к программированию поведения. Разработка следующей эпохи будет устроена похоже: не «напиши функцию, которая обрабатывает заказ», а «система должна принимать заказы при наличии товара, списывать остатки и уведомлять склад». Схемы вызова инструментов у современных языковых моделей тоже можно рассматривать как ранний, пока ещё грубый язык договорённостей между моделью, программой и человеком.

Как встраивать агентов без потери качества

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

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

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

Экономика внедрения

Стоимость — параметр, который не стоит недооценивать. На витрине ИИ-инструменты выглядят недорогими: $10, $20, $200 в месяц. Но агентные сценарии быстро превращают цену в переменную. Чем больше контекста, файлов, итераций и автоматических действий, тем выше расход токенов и кредитов. Некоторые инструменты используют в разы больше токенов на одну и ту же задачу, а в корпоративном использовании это уже отдельная строка бюджета. При этом расходы могут быть непрозрачными: разработчик думает, что просто запускает агента, а потом кто-то в финансовом отделе открывает счёт и тихо знакомится с новой формой боли.

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

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