Сейчас мы можем создавать новые строки кода с невероятной скоростью, но большая часть этого сгенерированного искусcтвенным интеллектом кода не работает в производственной среде. О том, как мы можем решить эту проблему, на портале The New Stack рассказывает Анимеш Коратана, генеральный директор и основатель PlayerZero.

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

Вице-президент Google по инженерным вопросам недавно сказал: «Люди были бы шокированы, если бы знали, как мало кода из больших языковых моделей (LLM) на самом деле попадает в производство». Несмотря на впечатляющие демонстрации и миллиарды долларов финансирования, между прототипами, созданными с помощью ИИ, и готовыми к производству системами существует огромный разрыв. Но почему? Причина кроется в трех основных проблемах:

  1. Разработки «с нуля» vs. существующие технологические стеки. ИИ превосходен в создании прототипов без ограничений, но испытывает трудности с интеграцией в существующие системы. Кроме того, работа в производственных средах накладывает жесткие ограничения, которые делают прототипы хрупкими.
  2. Проблема Дори. ИИ с трудом отлаживает свой собственный код, потому что ему не хватает настойчивого понимания. Он не может учиться на прошлых ошибках и не имеет достаточного контекста для устранения неполадок в системах.
  3. Неодинаковая зрелость инструментов. Хотя инструменты генерации кода на основе ИИ быстро развиваются, функции развертывания, обслуживания, проверки кода, обеспечения качества и поддержки клиентов по-прежнему работают со скоростью, характерной для до-ИИ эпохи.

Разработки «с нуля» vs. существующие технологические стеки

LLM может быстро создать новый микросервис в вакууме, который будет хорошо работать в изоляции. Но работа в производственной среде требует интеграции с непредсказуемыми реалиями: унаследованным кодом, границами сервисов, контрактами на данные, промежуточным ПО для авторизации, схемами протокола буферов, конвейерами CI/CD, стеками наблюдаемости, целевыми показателями качества сервисов (SLO), наборами ограничений по ключевым метрикам производительности... И это еще не все. И все это до того, как непредсказуемые пользователи начнут взаимодействовать с ПО.

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

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

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

Проблема Дори

Мы установили, что современные LLM с трудом пишут код, который будет работать за пределами контролируемых сред новых проектов. Но почему мы не можем использовать ИИ для устранения неполадок и отладки этого кода?

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

К сожалению, большинство LLM работают очень похоже на персонажа Дори из мультфильма «В поисках Немо»: у них нет единого контекста для нескольких запросов, и у них очень короткая память.

Многие компании используют кодовые базы, накопленные за 20, 30 или 40 лет. Эти системы имеют непредсказуемое поведение, скрытые зависимости и исторические обходные пути — сложные проценты по их техническому долгу. Без широкого понимания всей архитектуры системы, взаимосвязей между несколькими репозиториями кода, прошлых решений и развертываний практически невозможно устранить сложные проблемы.

Неодинаковая зрелость инструментов

Последней причиной, по которой код ИИ испытывает трудности в производстве, является то, что инструменты ИИ для поддержки жизненного цикла доставки ПО (SDLC) не все созрели в одинаковой степени. Возьмем, к примеру, эволюцию цифровых камер. Первые цифровые камеры очень напоминали свои аналоговые аналоги — мы не могли представить другой способ применения этой технологии. Но вскоре мы поняли, что камеры можно встраивать везде: от ноутбуков до телефонов, от дверных звонков до автомобилей. Камеры больше не служат только для съемки фотографий; они также могут помочь нам добраться из точки А в точку Б.

Несмотря на то что прошло всего несколько лет, ИИ-инструменты генерации кода уже претерпели быструю трансформацию. Наши первые попытки интегрировать ИИ в наш SDLC очень напоминали вставку ИИ в нашу IDE — эквивалент цифровой зеркальной камеры. Первоначальная версия GitHub Copilot была по сути усовершенствованным автозаполнением IDE.

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

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

Путь вперед

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

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

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

А пока следует ожидать появления впечатляющих прототипов и разочаровывающих производственных опытов. Когнитивное несоответствие никуда не исчезнет — оно является фундаментальным для работы этих систем.