Composer супротив Opus
2026-05-30 12:43![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vakЗаконспектирую опыт программирования с Курсором и Claude Code. Вдруг кому пригодится. Я провёл несколько дней, активно кодируя симулятор i386 на микрокоде. Чисто из любопытства: если получится, его можно будет встроить в tiltti.
Но главная цель - сравнить умность двух разных моделей: от Курсора (Composer) и от Claude Code (Opus). Недавно как раз появились новые версии: Composer 2.5 и Opus 4.8.
Начал я с того, что дал Клод Коду (модель Sonnet 4.6) исходники микрокода i386 и исходники реализации z386 для FPGA. Попросил проанализировать их на предмет построения софтверного симулятора. Получил подробный план разработки из 19 шагов. По этому плану и действовал.
Создал два пустых Git-репозитория: в одном будет трудиться модель Composer 2.5 от Курсора, в другом - модель Opus 4.8 (тоже через Курсор, но сначала Sonnet 4.6 через Claude Code).
Из tiltti убрал всю суть и оставил голый скелет приложения - main() и мелочёвку. Положил в оба репозитория и скомандовал агентам: вперёд и с песней. Делаем шаг №1 по плану, покрываем тестами. Потом шаг №2, и так далее.
Композер быстро вырвался вперёд. За два дня усердной работы (с утра до вечера) все 19 шагов были выполнены. Ещё через два дня допиливания удалось пройти первые пять тысяч MOO тестов.
Соннет (под Claude Code) быстро осилил первые девять шагов, и на десятом застрял на два дня. Когда он таки добил десятый шаг, я решил, что так мы далеко не уйдём. Что-то фигово там в планировщике. Вместо Claude Code запустил тот же Курсор, но уже с моделью Opus 4.8. Тоже от Anthropic, как и Соннет, но поумнее. И дело наладилось. Через пару дней все шаги были выполнены, и отлажены первые пятьсот MOO тестов.
Какой вывод? Казалось бы, Композер однозначно победил: 5000 тестов супротив 500, и намного шустрее. Однако всё ровно наоборот. Смотрим исходники. В классе, представляющем собственно процессор, Композер нагенерил множество малопонятных переменных состояния. У Опуса же все переменные состояния однозначно связаны с потребностями микрокода. Общий размер исходников: 11205 строк против 6193. То есть почти в 2 раза больше. Много лишней логики - явный признак некачественного дизайна.
С отладкой каждого следующего MOO теста Композер имеет тенденцию добавлять новые переменные состояния. То есть он не врубается в работу процессора и ищет обходные пути. Опус же ничего такого себе не позволяет. Для каждого теста он глядит в суть и вносит мелкие изменения в существующий код.
Я пришёл к выводу, что продолжать с Композером бессмысленно. А вот с Опусом вполне можно бы довести симулятор i386 до ума. Если бы только он не жрал столько денег. Для хобби выходит недешёвое удовольствие.
Но главная цель - сравнить умность двух разных моделей: от Курсора (Composer) и от Claude Code (Opus). Недавно как раз появились новые версии: Composer 2.5 и Opus 4.8.
Начал я с того, что дал Клод Коду (модель Sonnet 4.6) исходники микрокода i386 и исходники реализации z386 для FPGA. Попросил проанализировать их на предмет построения софтверного симулятора. Получил подробный план разработки из 19 шагов. По этому плану и действовал.
Создал два пустых Git-репозитория: в одном будет трудиться модель Composer 2.5 от Курсора, в другом - модель Opus 4.8 (тоже через Курсор, но сначала Sonnet 4.6 через Claude Code).
Из tiltti убрал всю суть и оставил голый скелет приложения - main() и мелочёвку. Положил в оба репозитория и скомандовал агентам: вперёд и с песней. Делаем шаг №1 по плану, покрываем тестами. Потом шаг №2, и так далее.
Композер быстро вырвался вперёд. За два дня усердной работы (с утра до вечера) все 19 шагов были выполнены. Ещё через два дня допиливания удалось пройти первые пять тысяч MOO тестов.
Соннет (под Claude Code) быстро осилил первые девять шагов, и на десятом застрял на два дня. Когда он таки добил десятый шаг, я решил, что так мы далеко не уйдём. Что-то фигово там в планировщике. Вместо Claude Code запустил тот же Курсор, но уже с моделью Opus 4.8. Тоже от Anthropic, как и Соннет, но поумнее. И дело наладилось. Через пару дней все шаги были выполнены, и отлажены первые пятьсот MOO тестов.
Какой вывод? Казалось бы, Композер однозначно победил: 5000 тестов супротив 500, и намного шустрее. Однако всё ровно наоборот. Смотрим исходники. В классе, представляющем собственно процессор, Композер нагенерил множество малопонятных переменных состояния. У Опуса же все переменные состояния однозначно связаны с потребностями микрокода. Общий размер исходников: 11205 строк против 6193. То есть почти в 2 раза больше. Много лишней логики - явный признак некачественного дизайна.
С отладкой каждого следующего MOO теста Композер имеет тенденцию добавлять новые переменные состояния. То есть он не врубается в работу процессора и ищет обходные пути. Опус же ничего такого себе не позволяет. Для каждого теста он глядит в суть и вносит мелкие изменения в существующий код.
Я пришёл к выводу, что продолжать с Композером бессмысленно. А вот с Опусом вполне можно бы довести симулятор i386 до ума. Если бы только он не жрал столько денег. Для хобби выходит недешёвое удовольствие.
no subject
Date: 2026-05-31 00:59 (UTC)no subject
Date: 2026-05-31 02:54 (UTC)В принципе, в Курсоре есть GPT-5.5 в списке моделей на выбор. Я пробовал - работает, но не впечатляет. Медленнее чем Композер и не настолько сообразительный как Опус.
no subject
Date: 2026-05-31 05:36 (UTC)no subject
Date: 2026-06-01 02:12 (UTC)no subject
Date: 2026-05-31 06:34 (UTC)хотя впечатление такое, что мумбайские аутцорцеры так быстро не смогли бы, будь их хоть тысяча
no subject
Date: 2026-05-31 23:02 (UTC)no subject
Date: 2026-05-31 09:42 (UTC)no subject
Date: 2026-05-31 23:02 (UTC)no subject
Date: 2026-06-01 07:23 (UTC)1) насмотренность модели (pretrain) - основная база знаний и большая часть способностей модели
2) и пост-тюнинг (lora/qlora/sft ...) - следование инструкциям, качество ответов и тд
1-й этап как раз отвечает за "интеллект" и умение модели "мыслить", второй этап как выражать в конечном виде эти мысли и выводы (умения написать код на конкретном языке программирования). 1-й этап требует колоссального количества современных видеокарт которым у Китая есть трудности и реально что можно сильно заморочиться с этапом 2 что они и делают