ИИ переписывает научный код: почему совпадения старых и новых ответов недостаточно

Что показали описанные проекты

The Decoder 1 августа 2026 года разобрал полевой отчёт OpenAI и академических партнёров. В нём представлены работы с агентами Codex и Claude Code: обновление сборки, оптимизация и перенос исследовательских программ на другие языки или вычислительные платформы.

Один пример касается библиотеки cyvcf2 и модернизации установки. Другой, MHCflurry, связан с переносом из TensorFlow в PyTorch. Такой диапазон важен: успешное исправление упаковки не доказывает способность безошибочно переписать статистический метод, даже если оба результата называют модернизацией.

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

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

Старый код не всегда является эталоном

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

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

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

Отделить автора от проверяющего

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

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

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

Быстрая перепись создаёт новую обязанность

В статье есть показательный эпизод с FastQC: автор исходного инструмента не заменил его Rust-переписью, а полезные улучшения перенесли в существующую Java-версию. Это напоминает, что отдельный новый проект не всегда лучший итог технического эксперимента.

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

Принимать результат следует вместе с планом сопровождения. Кто воспроизведёт спорный расчёт через год, ответит на сообщение об ошибке и обновит зависимости? Ускорение полезно только в программе, результатам которой команда умеет доверять по конкретным проверкам, а не по убедительности объяснений агента.