Исследование MIT о барьерах на пути к автономной разработке ПО
От переводчика: Новое исследование MIT развенчивает популярные мифы об ИИ в программировании и показывает реальные барьеры на пути к автономной разработке ПО. Оригинал статьи опубликован в MIT News.
Представьте будущее, где искусственный интеллект молча берет на себя рутинную работу в разработке ПО: рефакторинг запутанного кода, миграцию legacy-систем и поиск состояний гонки (race conditions), позволяя инженерам-людям сосредоточиться на архитектуре, дизайне и действительно новых проблемах, которые пока недоступны машинам.
Последние достижения, казалось бы, приблизили нас к этому будущему, но новая работа исследователей из MIT Computer Science and Artificial Intelligence Laboratory (CSAIL) и нескольких партнерских институтов утверждает, что эта потенциальная реальность требует трезвого взгляда на современные вызовы.
Что показало исследование
Работа под названием "Challenges and Paths Towards AI for Software Engineering" ("Вызовы и пути к ИИ для разработки программного обеспечения") анализирует множество задач разработки ПО за пределами генерации кода, выявляет текущие узкие места и указывает на перспективные направления исследований для их преодоления, с целью позволить людям сосредоточиться на высокоуровневом дизайне, пока рутинную работу автоматизируют.
"Все говорят о том, что программисты больше не нужны, и теперь доступна вся эта автоматизация", — говорит Армандо Солар-Лезама, профессор электротехники и компьютерных наук MIT, главный исследователь CSAIL и старший автор исследования. "С одной стороны, область добилась огромного прогресса. У нас есть инструменты, которые гораздо мощнее всего, что мы видели раньше. Но до полной автоматизации, которую мы ожидаем, еще очень далеко."
Мифы против реальности: что такое настоящая разработка ПО
Солар-Лезама утверждает, что популярные нарративы часто сводят разработку ПО к "студенческой части программирования: кто-то дает вам спецификацию небольшой функции, и вы ее реализуете, или решаете задачи в стиле LeetCode на собеседованиях".
Реальная практика гораздо шире:
Ежедневная работа разработчика включает:
Рефакторинг, который улучшает дизайн, масштабные миграции — перевод миллионов строк с COBOL на Java, меняющий целые бизнесы, непрерывное тестирование и анализ — фаззинг, property-based тестирование и другие методы для поиска багов конкурентности или исправления уязвимостей нулевого дня, а также рутину сопровождения — документирование десятилетнего кода, создание сводок истории изменений для новых коллег, ревью пулл-реквестов на стиль, производительность и безопасность.
Оптимизация кода в промышленных масштабах
Например, тонкая настройка GPU-ядер или непрерывные многоуровневые улучшения движка V8 в Chrome остается крайне сложной для оценки.
Проблема №1: Ограниченные бенчмарки
Современные метрики производительности были разработаны для коротких, самодостаточных задач. Хотя тесты множественного выбора до сих пор доминируют в исследованиях естественного языка, они никогда не были нормой в области ИИ для кода.
Де-факто стандарт области — SWE-Bench — ставит перед моделью задачу исправить баг в GitHub: это полезно, но все еще напоминает парадигму "студенческого программного упражнения".
Ограничения SWE-Bench:
SWE-Bench касается только нескольких сотен строк кода, создает риск утечки данных из публичных репозиториев и игнорирует другие реальные контексты: ИИ-ассистированный рефакторинг, парное программирование человек-ИИ, критичные по производительности переписывания миллионов строк.
Пока бенчмарки не расширятся, чтобы захватить эти высокорискованные сценарии, измерение прогресса — и, следовательно, его ускорение — останется открытым вызовом.
Проблема №2: Слабая коммуникация человек-машина
Алекс Гу, первый автор и аспирант MIT по электротехнике и компьютерным наукам, видит сегодняшнее взаимодействие как "тонкую линию коммуникации".
Типичная проблема:
Когда он просит систему сгенерировать код, он часто получает большой неструктурированный файл и даже набор unit-тестов, но эти тесты поверхностны.
"У меня нет особого контроля над тем, что пишет модель", — говорит Гу. "Без канала для ИИ, чтобы раскрыть свою собственную уверенность — 'эта часть правильная... эту часть, возможно, перепроверьте' — разработчики рискуют слепо доверять галлюцинированной логике, которая компилируется, но рушится в продакшене."
Критичный аспект
ИИ должен знать, когда обратиться к пользователю за уточнениями.
Проблема №3: Масштаб усугубляет сложности
Современные модели ИИ серьезно страдают при работе с большими кодовыми базами, часто охватывающими миллионы строк.
Проблема уникальности каждой компании:
Базовые модели учатся на публичном GitHub, но "кодовая база каждой компании специфична и уникальна", говорит Гу, что делает проприетарные соглашения кодирования и требования спецификаций принципиально отличающимися от данных обучения.
Результат — код, который:
Выглядит правдоподобно, но вызывает несуществующие функции, нарушает внутренние правила стиля и не проходит пайплайны непрерывной интеграции.
Это часто приводит к тому, что ИИ-сгенерированный код "галлюцинирует" — создает контент, который выглядит правдоподобно, но не соответствует специфическим внутренним соглашениям, вспомогательным функциям или архитектурным шаблонам данной компании.
Проблема №4: Неправильный поиск кода
Модели часто ошибочно извлекают информацию, потому что ищут код с похожим названием (синтаксис), а не функциональностью и логикой, что действительно нужно модели, чтобы знать, как написать функцию.
"Стандартные техники поиска очень легко обмануть фрагментами кода, которые делают одно и то же, но выглядят по-разному", — говорит Солар-Лезама.
Призыв к действию: что нужно сделать
Поскольку нет универсального решения для этих проблем, авторы призывают к объединению усилий всего сообщества.
Во-первых, нужны подробные данные, которые отражают процесс написания кода разработчиками — какой код разработчики оставляют, а какой выбрасывают, и как код рефакторится со временем.
Во-вторых, требуются общие бенчмарки для оценки, которые измеряют прогресс по качеству рефакторинга, долговечности исправления багов и корректности миграций.
В-третьих, необходимы прозрачные инструменты, которые позволяют моделям раскрывать неуверенность и приглашать к человеческому руководству, а не к пассивному принятию.
Гу называет эту повестку "призывом к действию" для более крупных open-source коллабораций, которые ни одна лаборатория не могла бы организовать в одиночку.
Видение будущего
Солар-Лезама представляет пошаговые улучшения — "исследовательские результаты, которые по частям решают каждый из этих вызовов" — которые затем внедряются в коммерческие инструменты и постепенно превращают ИИ из помощника-автодополнения в настоящего инженерного партнера.
Почему это важно?
"Программное обеспечение уже лежит в основе финансов, транспорта, здравоохранения и мелочей повседневной жизни, и человеческие усилия, необходимые для безопасного построения и поддержания его, становятся узким местом. ИИ, который может взять на себя рутинную работу — и делать это без введения скрытых сбоев — освободит разработчиков для сосредоточения на креативности, стратегии и этике", — говорит Гу.
"Но это будущее зависит от признания того, что автодополнение кода — это самая простая часть; сложная часть — это все остальное. Наша цель не заменить программистов. Наша цель — усилить их. Когда ИИ сможет справляться с утомительным и пугающим, инженеры-люди наконец смогут тратить время на то, что могут делать только люди."
Экспертная оценка
"Учитывая множество новых исследований в области ИИ для программирования и сообщество, часто гонящееся за последними трендами, бывает сложно отступить назад и подумать о том, какие проблемы наиболее важно решать", — говорит Батист Розьер, ученый по ИИ в Mistral AI, который не участвовал в исследовании. "Мне понравилось читать эту работу, потому что она дает четкий обзор ключевых задач и вызовов в области ИИ для разработки ПО. Она также намечает перспективные направления для будущих исследований."
Исследовательская команда
Гу и Солар-Лезама написали статью совместно с Кушиком Сеном, профессором Калифорнийского университета в Беркли, и PhD студентами Наманом Джейном и Манишем Шетти, а также с Кевином Эллисом, доцентом Корнелльского университета, и PhD студентом Вен-Дином Ли, с Дии Ян, доцентом Стэнфордского университета, и PhD студентом Ицзя Шао, и с Зияном Ли, будущим доцентом Университета Джонса Хопкинса.