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

Главный вывод скорее предостерегающий, чем победный. Согласно отчету, системы вроде Codex, Claude Code, GPT-5.5 и GPT-5.2 могут ускорять работу по реализации, иногда весьма существенно, но им нельзя доверять определение того, корректно ли с научной точки зрения получившееся ПО. На практике это смещает узкое место с написания кода на проектирование тестов, проверку результатов и распределение долгосрочной ответственности за сопровождение.

Что, по отчету, изменилось

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

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

Более сложным примером была MHCflurry — иммунологическая модель, используемая для предсказания, какие цели могут распознавать иммунные клетки. Согласно отчету, Claude Code и Codex чередовали роли исполнителя и ревьюера, перенося около 10 000 строк кода с TensorFlow на PyTorch. Такая миграция часто необходима для поддержки и производительности, но она рискованна, потому что научное ПО может выглядеть работающим корректно, при этом выдавая тонко ошибочные результаты.

Самым амбициозным случаем стал rustar-aligner, переписывание STAR на Rust. STAR широко используется для сопоставления секвенс-ридов с позициями в геноме, и в отчете говорится, что исходная кодовая база превышает 20 000 строк C и C++ и больше не поддерживается активно. В тестах на 10 000 коротких ридов из секвенирования клеток дрожжей rustar-aligner совпал со STAR в 99,815 процента случаев для single-end и в 99,883 процента случаев для paired-end, согласно критериям сравнения из отчета. Авторы также заявили, что ни один из инструментов не сопоставлял риды, которые другой полностью не смог сопоставить.

Большие ускорения сопровождались оговоркой

Подчеркиваемые в отчете приросты производительности весьма значительны, но они получены на отдельных проектах, а не на контролируемом бенчмарке по множеству команд.

RustQC, который объединил 15 инструментов контроля качества в одну программу, якобы сократил время выполнения на большом наборе данных с 15 часов 34 минут до 14 минут 54 секунд, то есть более чем в 60 раз. Другой проект, HelixForge, заменил BamSurgeon для генерации синтетических геномных данных на GPU-версию. В приведенном тесте, использовавшем данные одного донора и геномный регион в десять миллионов пар оснований, весь конвейер работал в 59,6 раза быстрее, а основной вычислительный шаг — в 98,6 раза быстрее, чем у BamSurgeon.

Другие проекты были менее драматичными, но все же заметными. В hifiasm, инструменте для сборки генома, GPT-5.5, как сообщается, нашел оптимизации, которые сократили время выполнения на реальных данных человеческого генома почти на 15 процентов после того, как исследователь сначала подготовил отдельные наборы данных для обучения и валидации. В HI.SIM GPT-5.2, а затем более новая модель оптимизировали разные части программы, и совокупный выигрыш по времени выполнения составил около 31 процента без изменения результата, говорится в отчете.

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

Где модели провалились

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

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

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

Участники проектов прямо выражали эту озабоченность. Brent Pedersen, разработчик cyvcf2, писал, что кодирующие агенты позволяют легко быстро двигаться вперед, но науке по-прежнему нужны «expert guidance, understanding, taste, and care». Philip Ewels, руководивший RustQC, описал системы как «eloquent, convincing, and confidently wrong in ways that are easy to miss». Согласно изложению The Decoder, он не позволял моделям оценивать собственную корректность и вместо этого использовал независимый тестовый стенд.

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

Доказательства, ограничения и чьи это утверждения

Самые сильные утверждения в этой истории исходят из полевого отчета, подготовленного с OpenAI и академическими партнерами, как описывает The Decoder. Кейсы — это ретроспективные рассказы участников, а не случайная или репрезентативная выборка по работе с исследовательским ПО. Это ограничение важно.

Поэтому показатели производительности RustQC, HelixForge, hifiasm, HI.SIM, bayesm, rustar-aligner, MHCflurry и cyvcf2 — это проектные результаты, сообщенные вовлеченными командами. Их следует рассматривать как примеры того, что возможно при тщательно ограниченных условиях, а не как общее доказательство того, что кодирующие агенты надежно дадут такие же выигрыши в других кодовых базах.

Та же осторожность относится и к экономическим оценкам отчета. Авторы предполагают, что если агенты решат от четверти до половины проблем установки в 100 исследовательских пакетах, то сэкономленное исследовательское время может стоить от 600 000 долларов до почти 5 миллионов долларов. Они также оценивают примерно 650 часов экономии на сопровождении NumPy в год. Эти цифры — ориентировочные оценки из отчета, а не внешне верифицированные рыночные данные.

Отчет также указывает на важный организационный риск: дешевые переписывания могут создавать фрагментацию. Если лаборатории будут выпускать альтернативные версии устоявшихся инструментов быстрее, чем сообщества смогут их сопровождать, это может разделить пользователей и потреблять еще больше времени мейнтейнеров. Эта проблема проявилась и в примерах. Некоторые улучшения были возвращены в исходные проекты, другие — нет. Поскольку STAR больше не поддерживался, rustar-aligner был перенесен в scverse. В другом случае автор FastQC отказался заменять исходный инструмент его Rust-версией, и команда вместо этого применила обнаруженные улучшения к существующей Java-версии, добившись того же трехкратного ускорения.

Почему это важно для разработчиков и корпоративных ИИ-команд

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

Для продуктовых команд, оценивающих Codex, Claude Code, GPT-5.5 или GPT-5.2, практический вывод в том, что надежность зависит не только от модели, но и от окружающего процесса. Независимые тестовые стенды, эталонные наборы данных, формальные критерии приемки и человеческий просмотр остаются необходимыми. Чем точнее можно специфицировать задачу, тем большую ценность, похоже, приносит кодирующий агент.

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

На что смотреть дальше

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

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

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

Взгляд Creati.ai

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

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