Блогер: ИИ-агенты удешевили оптимизацию кода в тысячи раз
Автор технического блога (пост опубликован без подписи, на danluu.com) продолжает разбирать тему из предыдущего поста: стоимость работы по оптимизации производительности, которая раньше требовала редких и дорогих специалистов, упала на порядки благодаря ИИ-агентам вроде Codex и Claude. По его оценке, время, нужное человеку, чтобы проверить, что хитрая оптимизация действительно работает, сократилось в 1000, 10000, а иногда и в 1000000 раз; в пересчёте на деньги (сравнивая стоимость токенов по счётчику с зарплатой инженера, который писал JIT-компиляторы для поискового индекса Bing) выигрыш, примерно в 1000 раз. Из-за этого резко выросло число оптимизаций, которые вообще имеет смысл делать.
Автор приводит несколько своих экспериментов. Для собственного regex-движка FRE и утилиты ripgrep он поручил агенту добавить компиляцию запроса в нативный машинный код (AOT) в фоновом потоке с переключением на него, когда компиляция завершится: на длинных простых запросах это дало ускорение в 2, 4 раза, а на репрезентативных отложенных (holdout) запросах, где такое переключение уместно, около 7%. Сам FRE в процессе разработки переобучился под бенчмарк-набор rebar и стал работать хуже на новых запросах, пока агенту не сообщили о существовании отложенного набора, после этого он обобщил оптимизации.
Отдельно автор описывает, как построил, по его словам, сильнейший в мире ИИ для настольной игры Azul: многопоточный, обученный на его личном ноутбуке, а не на кластере, и, судя по прочитанной им диссертации о второй по силе программе для Azul, потребовавший примерно на два порядка меньше времени, чем академический проект-конкурент. По его наблюдению, каждое удвоение скорости перебора даёт примерно 100 очков Эло; добавление многопоточности само по себе уже выводит программу далеко вперёд, а если наложить ещё 10, 20 оптимизаций, которые большинству людей делать вручную «слишком муторно», написанный вручную ИИ-соперник перестаёт быть конкурентоспособным.
Ещё один пример, инженер по производительности Джейми Брэндон (Jamie Brandon), готовясь к собеседованиям, пробовал публичное тестовое задание Anthropic на оптимизацию производительности. Дойдя до предела, он передал задачу Claude, и тот довёл решение дальше: часть найденных оптимизаций Брэндон, по его словам, и сам держал в уме, но не успел реализовать, а часть назвал «сумасшедшими вещами», на которые сам решился бы, только потратив на задачу недели. Автор поста отмечает, что не пробовал задание сам, но подозревает, что тоже уступил бы модели при сопоставимом лимите времени.
В посте также приведены реакции читателей на предыдущую запись автора. Марк Брукер (Marc Brooker) согласился с выводом о том, что будущее, за динамическим ПО, «заточенным» под конкретную рабочую нагрузку, а не под класс нагрузок, и сравнил это с техниками демосцены. Майкл Малис (Michael Malis) из проекта pgrust возразил на мем «код никогда не был сложной частью»: по его мнению, для JIT-компиляторов и баз данных сложной частью как раз было написание кода, а LLM снизили порог входа настолько, что теперь можно замахиваться на более амбициозные программы.
Автор оговаривается, что нынешние публичные топовые модели всё ещё плохо справляются с планированием экспериментов (ему пришлось самому выстраивать методику проверки, помогает ли оптимизация в игре Azul на самом деле), и что смена алгоритма многопоточности, выбранного моделью по её собственным (ошибочным) рассуждениям, несколько раз приводила к переписыванию кода заново.
Ключевые факты
- По оценке автора, с ноября 2025 года время, нужное человеку на проверку хитрой оптимизации, упало в 1000, 1000000 раз, а в пересчёте на деньги (токены против зарплаты инженера), примерно в 1000 раз
- Для regex-движка FRE и ripgrep агент добавил компиляцию запроса в нативный код в фоновом потоке: 2, 4 раза ускорения на длинных простых запросах и около 7% на отложенном (holdout) наборе; сам FRE по пути переобучился под бенчмарк, пока агенту не сообщили о существовании holdout-набора
- Автор построил многопоточный ИИ для игры Azul, который называет сильнейшим в мире: по его оценке, у него ушло примерно на два порядка меньше времени, чем на академический проект второй по силе программы, а каждое удвоение скорости перебора даёт около 100 очков Эло
- Инженер Джейми Брэндон, застряв на публичном тестовом задании Anthropic по оптимизации, передал его Claude, модель нашла решения, которые он сам назвал «сумасшедшими» и на которые решился бы только потратив недели
- Майкл Малис (pgrust) и Марк Брукер в комментариях к предыдущему посту автора сходятся в том, что LLM снизили порог входа в сложную инженерию производительности (JIT-компиляторы, базы данных) и что будущее, за ПО, динамически заточенным под конкретную нагрузку
Почему это важно
Автор формулирует тезис: работа по оптимизации производительности, которая раньше требовала редких и дорогих специалистов (написание JIT-компиляторов, специализированных индексов, многопоточных алгоритмов), теперь по силам любому, кто может сформулировать задачу агенту в несколько предложений. Порог входа в такую инженерию резко упал, а вместе с ним, и порог, при котором оптимизация вообще имеет смысл: раньше многие улучшения отбрасывались как «не стоящие N человеко-дней на проверку», теперь это N меньше в сотни и тысячи раз.
Кому это важно
В первую очередь, разработчикам и инженерам по производительности, которым приходится решать, вкладываться ли в дорогую оптимизацию: экономика расчёта резко меняется. Также, командам, строящим требовательное к скорости ПО (поисковые индексы, базы данных, игровые ИИ, инструменты вроде ripgrep), и людям, готовящимся к техническим собеседованиям по производительности вроде описанного в посте задания Anthropic.
Как это применить
Автор описывает практический приём: сформулировать агенту (в его примерах, Codex, в примере Джейми Брэндона, Claude) желаемую оптимизацию в нескольких предложениях и дать ему реализовать код, который вручную стал бы заметным объёмом работы, например, компиляцию горячего пути в нативный код в фоновом потоке с переключением после готовности. Для защиты от переобучения под конкретный бенчмарк-набор он рекомендует держать агента в цикле с отложенным (holdout) набором тестов и явно предупреждать о его существовании. Для отладки недетерминированной многопоточности, реализовать воспроизведение по логам и добавлять логирование там, где повтор не сходится идеально.
Можно ли доверять
Материал, личное эссе с разборами собственных экспериментов автора (FRE/ripgrep, ИИ для Azul) и одного стороннего случая (Джейми Брэндон и задание Anthropic), без независимой проверки третьей стороной; численные оценки (ускорения, множители снижения стоимости, прирост Эло), собственные измерения и прикидки автора, а не результат контролируемого исследования. Имя автора поста в тексте не указано. Сам автор честно отмечает ограничение текущих моделей: по его словам, публичные топовые модели всё ещё плохо справляются с планированием экспериментов, и методику проверки, работает ли оптимизация, ему пришлось выстраивать самому.
Риски и подводные камни
Оптимизация может незаметно переобучиться под конкретный тестовый набор, так и случилось с FRE, пока агенту не указали на существование отложенного набора запросов. Компиляция в фоновом потоке ускоряет длинные запросы, но за счёт короткого запроса, у которого «отбирают» поток на компиляцию, то есть выигрыш не бесплатный. При выборе алгоритма многопоточности агент по собственным (ошибочным) рассуждениям несколько раз уводил реализацию не туда, и код приходилось переписывать заново. Наконец, по случаю с игрой Azul автор отмечает: когда оптимизация меняет не только скорость, но и сам результат вычисления, дёшево и однозначно оценить, стал ли итог лучше или хуже, получается не всегда.
«Ходит мем, что ИИ не помогает, потому что «код никогда не был сложной частью». Думаю, это верно для одних областей, но не для других, там писать код и правда было самым сложным. JIT-компиляторы, хороший пример: они бы сильно ускорили многие программы, но были редкостью именно из-за сложности реализации. LLM снизили порог входа и сильно упростили написание JIT-компилятора, на этом строится идея pgrust. Базы данных исторически были самым сложным ПО для разработки, и это их ограничивало. Теперь, с ИИ, можно замахиваться на более амбициозные программы.»
— Майкл Малис (проект pgrust)