Каждый день я вижу новую демонстрацию, которая выглядит примерно так: Одно приглашение создает законченное приложение. Несколько строк естественного языка и та-да: получается отполированный продукт. Тем не менее, несмотря на вирусные тенденции, сохраняется сбивающий с толку факт: мы не наблюдаем увеличения количества поставляемой продукции или ожидаемых темпов инноваций.
Недавно процитировали слова вице-президента по разработке Google: «Люди были бы шокированы, если бы знали, как мало кода, полученного в рамках LLM, на самом деле доходит до производства». Несмотря на впечатляющие демонстрации и миллиарды финансирования, существует огромный разрыв между прототипами, созданными с помощью ИИ, и готовыми к производству системами. Но почему? Истина заключается в этих трех фундаментальных проблемах:
Гринфилд против существующих технологических стеков
Большие языковые модели (LLM) позволяют быстро разработать новый микросервис в вакууме, который будет хорошо работать изолированно. Но работа в производстве требует интеграции с запутанной реальностью: унаследованный код, границы сервисов, контракты данных, промежуточное программное обеспечение авторизации, схемы protobuf, конвейеры CI/CD, стеки наблюдаемости, цели уровня обслуживания (SLO), бюджеты производительности… Я мог бы продолжать. И все это до того, как непредсказуемые пользователи начнут взаимодействовать с программным обеспечением.
Когда вы создаете новое программное обеспечение, вы участвуете в так называемом художественном процессе. Вы начинаете с представления ожидаемого поведения: данные должны передаваться из этого начального состояния в это конечное состояние, преобразованные определенным образом через определенный поток управления. Вы рисуете с возможностью, создавая что-то из ничего.
Вот почему помощники по программированию с использованием искусственного интеллекта создают такие впечатляющие прототипы. Они феноменальны в этом дальновидном, неограниченном творческом поколении. Но для эффективной работы высококачественного программного обеспечения увеличение количества кода не является решением. Вам нужен код, который может работать с очень специфическим набором параметров. Проблема заключается в том, что передача этих многочисленных и тонких параметров LLM — непростая задача.
Поскольку LLM прекрасно общаются с нами на нашем естественном языке, мы переоцениваем их способность писать качественное программное обеспечение. Но хотя язык гибок и прощает ошибки, код — нет. Код является исполняемым и композиционным: корректность зависит от точных контрактов между файлами/сервисами. Компилятор и среда выполнения не прощают ошибок; небольшие ошибки вызывают каскадные сбои, дыры в безопасности или снижение производительности.
Проблема Дори
Мы установили, что нынешние LLM с трудом пишут код, который будет работать за пределами контролируемых сред с нуля. Но почему мы не можем использовать ИИ для устранения неполадок и отладки этого кода?
Для правильной отладки вам необходимо разобраться во всей архитектуре. Вам необходимо понимать, как данные на самом деле проходят через систему, а не только то, как они должны проходить. Вам нужна способность перепроектировать систему, начиная с дефекта. Вам нужны модели, которые могут использовать массивные и сложные архитектуры, созданные десятилетиями, и понимать, почему они ведут себя именно так. Вам необходимо понимание того, что уже существует, что было раньше, непройденных путей.
К сожалению, большинство LLM действуют во многом подобно персонажу Дори из «В поисках Немо»: у них нет контекста от одного запроса к другому, и у них чрезвычайно короткая память.
Многие компании используют кодовые базы, накопленные за 20, 30 или 40 лет. Эти системы имеют эмерджентное поведение, неявные зависимости и исторические обходные пути — сложные проценты по их техническому долгу. Без широкого понимания всей архитектуры системы, взаимосвязей нескольких репозиториев кода, прошлых решений и развертываний практически невозможно устранять сложные проблемы.
Непостоянная зрелость инструмента
Последняя причина, по которой код ИИ испытывает трудности в производстве, заключается в том, что не все инструменты ИИ для поддержки жизненного цикла доставки программного обеспечения (SDLC) развиваются с одинаковой скоростью. Возьмем, к примеру, эволюцию цифровой камеры. Первые цифровые камеры были очень похожи на свои аналоговые аналоги — мы не могли представить другого способа применения этой технологии. Но вскоре мы узнали, что камеры можно вставлять повсюду: от ноутбуков до телефонов, от дверных звонков до автомобилей. Камеры больше не предназначены только для фотографирования; они также могут помочь нам добраться из точки А в точку Б.
Хотя прошло всего несколько лет, инструменты генерации кода ИИ уже претерпели быструю трансформацию. Наши первые попытки интегрировать ИИ в наш SDLC во многом напоминали внедрение ИИ в нашу IDE — эквивалент цифровой зеркальной камеры. Первоначальная версия GitHub Copilot по существу представляла собой улучшенное автозаполнение IDE.
Но за последние несколько лет такие инструменты, как Cursor, Windsurf и Claude Code, взяли верх с совершенно другим подходом. Они представили совершенно новый рабочий процесс, в котором вы вообще не пишете код. Вместо работы в редакторе кода вы работаете в окне чата, выражая свои намерения, и изменения в коде происходят естественным образом.
Сегодняшний стандарт генерации кода ИИ — это продукт второго поколения, который изменил весь рабочий процесс. Но когда мы смотрим за пределы генерации кода на остальную часть SDLC, мы все еще находимся в первом поколении этих продуктов. Если мы действительно хотим повысить скорость разработки, нам нужно выйти за рамки генерации кода. Нам нужны инструменты, которые помогут нам переосмыслить и управлять полным комплексным SDLC с помощью ИИ.
Путь вперед
Существует множество инструментов, которые справляются с современными операциями с кодом, но они рассматривают каждый этап процесса изолированно. Они создают очень эффективные цифровые камеры, но им не хватает воображения, чтобы переосмыслить все процессы с нуля.
Вы можете получить дополнительную выгоду от более совершенной системы проверки кода на базе искусственного интеллекта или от агента-инженера по надежности сайта, но наибольший прогресс принесет инструменты, которые переосмысливают весь процесс эксплуатации программного обеспечения, а не просто улучшают существующий процесс.
Инструменты ИИ, которые помогут управлять производственной средой, будут теми, которые смогут выполнять реверс-инжиниринг сложных систем, систематически подсчитывать состояния и помогать разработчикам определять конкретные условия, вызывающие неожиданное поведение. Они должны быть не просто творческими строителями — они также должны быть научными исследователями. И они будут рассматривать проблему комплексно, а не изолированно.
А пока ожидайте увидеть впечатляющие прототипы и разочаровывающий опыт производства. Когнитивное несоответствие не исчезнет — оно имеет фундаментальное значение для работы этих систем.
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Анимеш Коратана с юных лет занимался стартапами программного обеспечения, занимаясь технической поддержкой, контролем качества и тестированием в компаниях своего отца. Позже, во время работы в Стэнфордской лаборатории DAWN, он имел возможность взглянуть изнутри на… Читать далее от Animesh Koratana
