Действительно ли ИИ умеет программировать?

Исследование MIT о барьерах на пути к автономной разработке ПО

От переводчика: Новое исследование MIT развенчивает популярные мифы об ИИ в программировании и показывает реальные барьеры на пути к автономной разработке ПО. Оригинал статьи опубликован в MIT News ^[1].

Представьте будущее, где искусственный интеллект ^[2] молча берет на себя рутинную работу в разработке ПО: рефакторинг запутанного кода, миграцию legacy-систем и поиск состояний гонки (race conditions), позволяя инженерам-людям сосредоточиться на архитектуре, дизайне и действительно новых проблемах, которые пока недоступны машинам.

Последние достижения, казалось бы, приблизили нас к этому будущему, но новая работа исследователей из MIT Computer Science and Artificial Intelligence Laboratory (CSAIL) и нескольких партнерских институтов утверждает, что эта потенциальная реальность требует трезвого взгляда на современные вызовы.

Что показало исследование

Работа под названием “Challenges and Paths Towards AI for Software Engineering” ^[3] (“Вызовы и пути к ИИ для разработки программного обеспечения”) анализирует множество задач разработки ПО за пределами генерации кода, выявляет текущие узкие места и указывает на перспективные направления исследований для их преодоления, с целью позволить людям сосредоточиться на высокоуровневом дизайне, пока рутинную работу автоматизируют.

“Все говорят о том, что программисты больше не нужны, и теперь доступна вся эта автоматизация”, — говорит Армандо Солар-Лезама, профессор электротехники и компьютерных наук MIT, главный исследователь CSAIL и старший автор исследования. “С одной стороны, область добилась огромного прогресса. У нас есть инструменты, которые гораздо мощнее всего, что мы видели раньше. Но до полной автоматизации, которую мы ожидаем, еще очень далеко.”

Мифы против реальности: что такое настоящая разработка ПО

Солар-Лезама утверждает, что популярные нарративы часто сводят разработку ПО к “студенческой части программирования: кто-то дает вам спецификацию небольшой функции, и вы ее реализуете, или решаете задачи в стиле LeetCode на собеседованиях”.

Реальная практика гораздо шире:

Ежедневная работа разработчика включает:

Рефакторинг, который улучшает дизайн, масштабные миграции — перевод миллионов строк с COBOL на Java, меняющий целые бизнесы, непрерывное тестирование и анализ — фаззинг, property-based тестирование и другие методы для поиска багов конкурентности или исправления уязвимостей нулевого дня, а также рутину сопровождения — документирование десятилетнего кода, создание сводок истории изменений для новых коллег, ревью пулл-реквестов на стиль, производительность и безопасность.

Оптимизация кода в промышленных масштабах

Например, тонкая настройка GPU-ядер или непрерывные многоуровневые улучшения движка V8 в Chrome остается крайне сложной для оценки.

Проблема №1: Ограниченные бенчмарки

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

Де-факто стандарт области — SWE-Bench — ставит перед моделью задачу исправить баг в GitHub: это полезно, но все еще напоминает парадигму “студенческого программного упражнения”.

Ограничения SWE-Bench:

SWE-Bench касается только нескольких сотен строк кода, создает риск утечки данных из публичных репозиториев и игнорирует другие реальные контексты: ИИ-ассистированный рефакторинг, парное программирование человек-ИИ, критичные по производительности переписывания миллионов строк.

Пока бенчмарки не расширятся, чтобы захватить эти высокорискованные сценарии, измерение прогресса — и, следовательно, его ускорение — останется открытым вызовом.

Проблема №2: Слабая коммуникация человек-машина

Алекс Гу, первый автор и аспирант MIT по электротехнике и компьютерным наукам, видит сегодняшнее взаимодействие как “тонкую линию коммуникации”.

Типичная проблема:

Когда он просит систему сгенерировать код, он часто получает большой неструктурированный файл и даже набор unit-тестов, но эти тесты поверхностны.

“У меня нет особого контроля над тем, что пишет модель”, — говорит Гу. “Без канала для ИИ, чтобы раскрыть свою собственную уверенность — ‘эта часть правильная… эту часть, возможно, перепроверьте’ — разработчики рискуют слепо доверять галлюцинированной логике ^[4], которая компилируется, но рушится в продакшене.”

Критичный аспект

ИИ должен знать, когда обратиться к пользователю за уточнениями.

Проблема №3: Масштаб усугубляет сложности

Современные модели ИИ серьезно страдают при работе с большими кодовыми базами, часто охватывающими миллионы строк.

Проблема уникальности каждой компании:

Базовые модели учатся на публичном GitHub, но “кодовая база каждой компании специфична и уникальна”, говорит Гу, что делает проприетарные соглашения кодирования и требования спецификаций принципиально отличающимися от данных обучения ^[5].

Результат — код, который:

Выглядит правдоподобно, но вызывает несуществующие функции, нарушает внутренние правила стиля и не проходит пайплайны непрерывной интеграции.

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

Проблема №4: Неправильный поиск кода

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

“Стандартные техники поиска очень легко обмануть фрагментами кода, которые делают одно и то же, но выглядят по-разному”, — говорит Солар-Лезама.

Призыв к действию: что нужно сделать

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

Во-первых, нужны подробные данные, которые отражают процесс написания кода разработчиками — какой код разработчики оставляют, а какой выбрасывают, и как код рефакторится со временем.

Во-вторых, требуются общие бенчмарки для оценки, которые измеряют прогресс по качеству рефакторинга, долговечности исправления багов и корректности миграций.

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

Гу называет эту повестку “призывом к действию” для более крупных open-source коллабораций, которые ни одна лаборатория не могла бы организовать в одиночку.

Видение будущего

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

Почему это важно?

“Программное обеспечение уже лежит в основе финансов, транспорта, здравоохранения и мелочей повседневной жизни, и человеческие усилия, необходимые для безопасного построения и поддержания его, становятся узким местом. ИИ, который может взять на себя рутинную работу — и делать это без введения скрытых сбоев — освободит разработчиков для сосредоточения на креативности, стратегии и этике”, — говорит Гу.

“Но это будущее зависит от признания того, что автодополнение кода — это самая простая часть; сложная часть — это все остальное. Наша цель не заменить программистов. Наша цель — усилить их. Когда ИИ сможет справляться с утомительным и пугающим, инженеры-люди наконец смогут тратить время на то, что могут делать только люди.”

Экспертная оценка

“Учитывая множество новых исследований в области ИИ для программирования и сообщество, часто гонящееся за последними трендами, бывает сложно отступить назад и подумать о том, какие проблемы наиболее важно решать”, — говорит Батист Розьер, ученый по ИИ в Mistral AI, который не участвовал в исследовании. “Мне понравилось читать эту работу, потому что она дает четкий обзор ключевых задач и вызовов в области ИИ для разработки ПО. Она также намечает перспективные направления для будущих исследований.”

Исследовательская команда

Гу и Солар-Лезама написали статью совместно с Кушиком Сеном, профессором Калифорнийского университета в Беркли, и PhD студентами Наманом Джейном и Манишем Шетти, а также с Кевином Эллисом, доцентом Корнелльского университета, и PhD студентом Вен-Дином Ли, с Дии Ян, доцентом Стэнфордского университета, и PhD студентом Ицзя Шао, и с Зияном Ли, будущим доцентом Университета Джонса Хопкинса.