GPT-5, Opus 4.7 и DeepSeek V4-Pro писали CLI на Rust: кто справился с TSS-задачей

Три флагманские модели получили одно техническое задание: написать на Rust CLI-утилиту dkls23ctl для t-of-n threshold-ECDSA поверх библиотеки silence-laboratories/dkls23, с p2p-сетью на iroh и mDNS-обнаружением пиров. Подкоманды — keygen, pubkey, sign, reshare, verify. Никакого выделенного сервера, key shares хранятся локально. Задание прицельно неудобное: TSS-криптография редко встречается в обучающих данных, у dkls23 несколько несовместимых публикаций на crates.io, а у iroh за последние полгода было несколько мажорных релизов, ломавших API.

GPT-5 в Codex уложился в 26 минут активного времени и оказался единственным, кто реализовал все пять переходов reshare — включая экзотические маршруты вроде (t,n) → (t',n') со смешанным committee и экспорт обратно в singleton. Проверка сквозным сценарием (2,3)→(3,4) и обратно прошла. Архитектурно GPT-5 выбрал путь наименьшего сопротивления: один файл main.rs на 1254 строки, никаких README и QA-скриптов. Зато 22 применения патчей, ноль откатов и 16 млн токенов из KV-кэша против 41 тыс. нового вывода — модель почти не генерировала текст заново, переиспользуя уже вычисленный контекст.

Opus 4.7 в Claude Code потратил 65 минут и 337 вызовов инструментов, зато выдал девять исходных файлов с разбивкой по модулям, README, четыре QA-скрипта и интеграционный тест с library/binary split. Из 16 сценариев — 12 pass, 4 partial. «Partial» здесь не баги: модель явно сообщила, что две ветки reshare не реализует, и завершила их с ошибкой вместо того, чтобы делать вид. Это инженерная позиция, которую авторы теста оценили выше тихого провала. Отдельная претензия — не к модели, а к оболочке Claude Code: за сессию накопилось 30 правил «always allow» в settings.local.json, большинство из которых специфичны для конкретного проекта и бесполезны в других контекстах. Интерфейс требовал подтверждения на каждый bash-вызов.

DeepSeek V4-Pro в OpenCode провёл за задачей 95 минут, сделал 34 веб-запроса к документации — и всё равно получил худший результат: 6 pass, 2 partial, 8 fail. Модель допустила три системных ошибки одновременно. Первая — выбор библиотеки: вместо sl-dkls23 (та же кодовая база, что в ТЗ) DeepSeek взял dkls23-secp256k1 — другой крейт от тех же авторов с phase-by-phase API, где DKG нужно вручную разводить на четыре фазы. Вторая — отказ от mDNS: пиры пишут адреса в /tmp/dkls23ctl/, а другие их оттуда читают. iroh-endpoint инициализируется, но используется только как QUIC-транспорт по уже известному loopback-адресу. Третья — тихая перезапись пользовательских параметров: строка `if n == 1 || t == 1 { t = 1; n = 1; }` в main.rs молча игнорирует то, что передал пользователь.

Самый показательный эпизод — реакция DeepSeek на обратную связь. В середине сессии модель единственная из трёх обратилась к пользователю с вопросом: принять ли упрощённый подход с file-based discovery вместо mDNS? Ответ был однозначным: file-based discovery — критическая ошибка, инструмент должен работать и в LAN, iroh предоставляет всё необходимое. Финальный коммит всё равно использует /tmp. Авторы теста предполагают, что модель не разобралась с mDNS API в iroh, восприняла отрицательный отзыв как сигнал «продолжай» и продолжила в том же направлении. Способность принять критику и изменить подход — отдельная компетенция, не связанная напрямую с качеством генерируемого кода.

Результаты теста не означают, что GPT-5 всегда лучше на задачах кодирования — один прогон на одной машине за один час не статистика. Но они фиксируют конкретное: на задаче с нестандартными библиотеками, конкурирующими версиями API и требованием к сетевому стеку GPT-5 в Codex оказался быстрее и полнее, Opus — аккуратнее и честнее в ограничениях, DeepSeek — медленнее, неполнее и невосприимчивее к корректировке.