Snowboard Kids для Nintendo 64 декомпилировали за 84 дня, почти в 7 раз быстрее с ИИ-агентами

Проект по декомпиляции игры Snowboard Kids для Nintendo 64 завершён на 100%: теперь для каждой функции игры есть код на C, который при компиляции даёт машинный код, полностью идентичный оригинальному. Единственное исключение, несколько фрагментов рукописного ассемблера из системных библиотек: они и в оригинале были написаны на ассемблере, а не на C, так что переписывать их в C не требовалось.

Работа заняла 84 дня, против 596 дней на предыдущем похожем проекте той же команды, декомпиляции Snowboard Kids 2, то есть почти в 7 раз быстрее. Это не только заслуга ИИ-агентов: к началу проекта у автора уже было почти два года опыта декомпиляции игр, накопленного на предыдущем проекте, а приписывать всё ускорение исключительно языковым моделям, как прямо пишет автор, было бы грубым упрощением. Часть разницы объясняется и тем, что в Snowboard Kids всего 2145 функций против 2995 в Snowboard Kids 2, то есть меньше самого объёма работы. При этом задачу усложнял компилятор: Snowboard Kids был собран проприетарным компилятором SGI IDO 5.3 (сообществу декомпиляции пришлось самостоятельно заниматься реверс-инжинирингом компилятора и статически пересобрать версии IDO 5.3 и 7.1 под современное оборудование), тогда как Snowboard Kids 2 собирали открытым GCC 2.7.2. IDO агрессивно преобразует код на нескольких проходах оптимизации, и даже небольшая правка в C может неожиданно изменить распределение регистров в итоговом машинном коде, ни автор, ни языковые модели не умеют надёжно предсказывать поведение IDO, поэтому обычный процесс выглядел так: понять смысл функции, написать приблизительный C-код, а затем донастраивать его вспомогательной утилитой permuter, которая ищет побайтовое совпадение, но она бессильна, если сама структура кода в корне неверна.

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

Заметнее всего агенты проявили себя на стандартном библиотечном коде: в Snowboard Kids нашлось больше сотни фрагментов из библиотеки Nintendo libultra и функции из аудиобиблиотеки libmus, их не нужно было декомпилировать заново, если правильно опознать и подставить существующий исходный код. Агентов пришлось отдельно и настойчиво просить не декомпилировать такие функции с нуля, а сначала искать подходящий вариант среди версий SDK, настроек компилятора и путей условной компиляции. Отдельный автоматический скрипт на основе инструмента m2c прогонялся по всем ещё не сопоставленным функциям и сам подставлял точные совпадения, он справился лишь с 17 из 1830 функций (успех 0,93%), но даже это было выгоднее, чем тратить на них токены агентов.

Обнаруженные особенности компилятора IDO агенты записывали в общий файл DECOMPILATION_LEARNINGS.md, чтобы следующие запуски агентов могли опираться на уже найденные закономерности, а не переоткрывать их заново. Ключевым диагностическим инструментом стал N64 Decomp Workbench, он классифицирует несовпадения, учитывает релокации, умеет проигрывать отдельные проходы компилятора и отличать структурную ошибку в коде от проблемы распределения регистров, тогда как обычный дифф ассемблерного кода лишь показывает сам факт расхождения. Работу распараллелили на четыре независимые копии репозитория (Git worktree): кандидаты на декомпиляцию делились между ними хешированием, каждой задаче ставился явный дедлайн (чтобы permuter не работал бесконечно и агент мог сам решать, когда сдаться и перейти к следующей функции), а полная синхронизация всех четырёх копий могла занимать больше часа. Чтобы не ждать мержа, поиск похожих уже решённых функций обновили так, чтобы он учитывал все копии сразу, новое совпадение в одной копии сразу становилось доступно агентам в других.

Модели сравнивали по ходу дела и неформально, само сравнение называют «полностью ненаучным»: пробовали GPT-5.5, GPT-5.6, Claude 4.5, Fable и GLM 5.2 на меняющемся наборе сложных функций, иногда уже после того, как за них бралась другая модель. В целом Codex снова обгонял Claude, так же, как и в предыдущем проекте, а особенно эффективным, как только стал доступен, показал себя «Sol xhigh». GLM 5.2 от сервиса z.ai разочаровал: модель раньше ценили за приемлемое качество при щедрых лимитах использования, но со временем лимиты стали менее щедрыми, а задержка ответа осталась ужасной, цикл обратной связи растянулся настолько, что агенту перестали давать эту модель, а подписку в итоге отменили.

В целом лишь около 4,8% успешных коммитов потребовали вмешательства эксперта-человека. Автор отдельно благодарит троих участников сообщества декомпиляции, inspectredc, Bl00D4NGEL и queueRAM, за значимый вклад в проект и подчёркивает, что никакое количество ИИ не заменило бы их работу; ещё троих, iFuzzle, JamesBLewis и douglasjv, благодарит за то, что они одолжили проекту токены (оплаченные лимиты использования моделей). При этом стопроцентное совпадение, это узкая техническая планка: она означает, что C-код есть и компилируется идентично оригиналу для каждой функции, но не означает, что команда понимает, что каждая функция делает. Впереди ещё работа по документированию: переименование сгенерированных названий, описание неизвестных полей структур данных и больших объёмов игровых данных.

Дальше в планах, проект по рекомпиляции Snowboard Kids, чтобы игра могла запускаться нативно на современных платформах; он опирается на патчи, уже сделанные для похожего проекта Snowboard Kids 2: Recompiled. Автор также рассматривает перенос уровней и другого контента из первой игры в движок второй (объём работы пока не оценён) и в перспективе интересуется декомпиляцией Snowboard Kids Plus, эксклюзивного для Японии релиза на PlayStation с дополнительными уровнями и персонажами.

Ключевые факты

Декомпиляция игры Snowboard Kids для Nintendo 64 завершена на 100%: для всех функций есть C-код, который при компиляции даёт машинный код, идентичный оригиналу, кроме нескольких фрагментов рукописного ассемблера в системных библиотеках, изначально написанных именно на ассемблере.
Проект занял 84 дня против 596 дней на предыдущий проект той же команды (декомпиляция Snowboard Kids 2), почти в 7 раз быстрее. Но, по словам автора, приписывать разницу целиком ИИ было бы грубым упрощением: сказался и собственный, почти двухлетний опыт, накопленный на предыдущем проекте.
Из пяти опробованных моделей, GPT-5.5, GPT-5.6, Claude 4.5, Fable и GLM 5.2, агент Codex снова обгонял Claude, как и в прошлом проекте, а отдельно особенно эффективным, как только стал доступен, показал себя «Sol xhigh». GLM 5.2 от z.ai разочаровал: долгие задержки ответа и урезанные лимиты в итоге привели к отмене подписки.
Агентов запускали параллельно в четырёх независимых копиях репозитория (Git worktree), с явным дедлайном на каждую задачу и общим файлом DECOMPILATION_LEARNINGS.md, куда записывались найденные особенности компилятора для повторного использования другими агентами.
Только 4,8% успешных коммитов потребовали вмешательства эксперта-человека. При этом отдельный автоматический скрипт, пытавшийся сопоставить оставшиеся функции без участия агентов, справился лишь с 17 из 1830 (0,93%), предел полностью безагентной автоматизации.

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

История, редкий детальный отчёт о применении ИИ-агентов к большому, растянутому на месяцы инженерному проекту, а не к разовой демонстрации. Декомпиляция игры для Nintendo 64, задача, где нужно восстановить читаемый C-код по машинному коду так, чтобы он компилировался обратно в те же байты; это требует и понимания логики программы, и умения воспроизвести особенности древнего проприетарного компилятора IDO 5.3, для которого не сохранилось ни документации, ни исходников. ИИ-агенты помогли ускорить работу почти в 7 раз по сравнению с предыдущим похожим проектом той же команды, но автор честно отделяет вклад ИИ от вклада собственного опыта и человеческих экспертов, такая прозрачность в отчётах о продуктивности агентов встречается нечасто.

Кому это важно

В первую очередь, сообществу декомпиляции и ретро-моддинга Nintendo 64: спидраннерам Snowboard Kids, которым рабочий исходный код поможет разобраться в путях перемещения соперников и факторах, влияющих на скорость игрока, и разработчикам, которые готовят рекомпиляцию игры для современных платформ. Во вторую, инженерным командам и техлидам, которые оценивают, где именно ИИ-агенты реально ускоряют долгую работу с легаси-кодом и незадокументированными форматами, а где всё ещё нужен человек: статья даёт конкретные цифры (84 дня против 596, 4,8% коммитов с ручным вмешательством) вместо общих обещаний.

Как это применить

Из процесса можно вынести несколько приёмов для собственных агентных пайплайнов: держать общий файл-журнал (в проекте, DECOMPILATION_LEARNINGS.md), куда агенты записывают обнаруженные закономерности, чтобы следующие запуски не находили их заново; распараллеливать работу через несколько независимых копий репозитория (Git worktree) с явным разбиением задач и поиском совпадений сразу по всем копиям, не дожидаясь общего мержа; ставить агентам явный дедлайн на задачу, а не позволять вспомогательным инструментам вроде permuter крутиться до бесконечности; отдельно поощрять агентов искать и переиспользовать готовый библиотечный код (в проекте, библиотеки libultra и libmus) вместо повторной декомпиляции с нуля; и выбирать модель под конкретную задачу по собственному, пусть и неформальному, сравнению, в этом проекте Codex и «Sol xhigh» обошли Claude и особенно GLM 5.2.

Можно ли доверять

Источник, личный технический отчёт автора проекта на собственном блоге; это позиция инсайдера, а не независимого наблюдателя, но именно поэтому в тексте много конкретных, проверяемых цифр (84 и 596 дней, 4,8%, 17 из 1830), а не общих формулировок. Автор ограничивает собственные выводы: прямо называет сравнение моделей «полностью ненаучным» и отказывается приписывать всё ускорение ИИ, называя это грубым упрощением, такая самокритичность обычно повышает доверие к техническому отчёту. У истории на Hacker News заметный отклик, 207 очков и 130 комментариев, то есть текст уже прошёл проверку технически подкованной аудиторией, знакомой с декомпиляцией. Слабое место, сам факт стопроцентного совпадения и приведённые сроки не подтверждены здесь независимым источником: доверять приходится словам автора, а не результату стороннего аудита.

Риски и подводные камни

Главный риск, обобщить частный результат («почти в 7 раз быстрее») на весь класс задач с легаси-кодом: автор предупреждает, что это было бы грубым упрощением, поскольку на срок сильно повлиял и собственный двухлетний опыт автора, а не только ИИ-агенты. «Стопроцентное совпадение», узкая техническая планка: код компилируется в те же байты, что и оригинал, но это не значит, что команда понимает, что делает каждая функция, работа по документированию (переименование сгенерированных названий, описание структур данных) ещё впереди. Полностью безагентная автоматизация показала свои пределы: скрипт, пытавшийся сопоставлять оставшиеся функции без участия агентов, справился лишь с 0,93% из них. Наконец, эффективность моделей оказалась нестабильной от проекта к проекту: GLM 5.2, который раньше ценили за щедрые лимиты, со временем стал невыгоден из-за урезанных лимитов и плохой задержки ответа, удобная сегодня модель может перестать быть таковой уже завтра.

«Сейчас 2026 год, так что ответ, как минимум отчасти ИИ. Но приписывать всю разницу исключительно языковым моделям было бы грубым упрощением.»

— автор проекта декомпиляции