A
AI-Driven Development. Родион Мостовой
10.07.2026 13:51 · 👁 1.7K
Claude Fable 5 написал GC для .NET на C#
Если точнее, модель довела до ума проект по написанию managed GC от Kevin Gosse. На некоторых бенчмарках, AI сгенерированный нейронкой GC не уступает в производительности оригинальному
neuecc с помощью Fable 5 ускорил WriteInt в MessagePack. Вместо того, чтобы просить AI ускорить код и make no mistakes применили итеративный подход. В промпт загружались C# исходник и его disassembly после JIT-компиляции + результаты бенчмарков. Модель анализировала ассемблерные инструкции и шаг за шагом подгоняла исходный C# код. Результат — ускорение в 4 раза
Anthropic купили bun — Javascript рантайм, на котором работает Claude Code. Сразу после покупки Fable 5 переписал bun с Zig на Rust за 11 дней, потратив на это $165K токенов
====
Нейронки эволюционировали и теперь успешно пишут не только веб на реакте, но и низкоуровневый код. Масштабные проекты и сложные переписывания архитектуры теперь реализуемы за пару недель. Единственное ограничение — бюджет на токены.
Языку Zig не повезло. ИИ просто исключил его из цепочки, отдав предпочтение более надежному Rust. Похожая участь досталась C# NativeAOT, когда порт компилятора TypeScript сделали на Go.
Можно считать, что ценность стека технологий == ценности проектов, которые на нём написаны. И теперь технологии без прочной экосистемы популярных продуктов будут быстро вытесняться нейросетями в пользу мейнстрима
@epeshkblog
A
AI-Driven Development. Родион Мостовой
09.07.2026 22:05 · 👁 2.6K
Мне нужен такой робот)) Кто знает где взять?)
A
AI-Driven Development. Родион Мостовой
09.07.2026 13:54 · 👁 2K
Начали доклады на AI митапе в Береке банке - присоединяйтесь!
Чуть позже появится запись.
Ссылка в комменте
A
AI-Driven Development. Родион Мостовой
08.07.2026 11:42 · 👁 1.8K
Хорошо, что я решил не спешить с перетестом GigaChat 3.5 432B, а дождался разбора (от Родиона @ai_driven) поддержки агентности этой модели, если кратенько, то я в целом чего-то подобного и ожидал, модель оказалась слабее GPT-OSS-120B.
Моё предложение для спецов из Сбера как собрать датасет чтобы сделать модель лучше:
1. обновить уже наконец линейку сберовских моделей доступных по API, а то GigaChat 2 морально устарела во всём, плюс не только ваши модели, добавьте все какие хотите дистилить, ту же gpt-oss-120b и скажем kimi k2.7
2. добавить специальный ДЕШЁВЫЙ тариф для агентов работающих через API
3. запустить рекламу про домашнего агента, скажем на примере OpenClaw, ну или скажем моего Coddy Agent ;)
4. поощрять юзеров которые пользуются агентом через ваше API плюшками, скидками на услуги, повышенной ставкой по вкладу и так далее, вы это всё умеете
5. собирать логи работы с апишкой
6. обучить уже наконец крутую агентную модель и зарелизить её в OpenSource
UPD.
7. сменить релизную политику, к моменту AI Journey в сентябре конкуренты выпустят десяток новых моделей и ваша "четвёрка" опять окажется слабее аналогов.
UPD2.
8. СРАЗУ добавлять новые модели на своё API после релиза, веса это конечно хорошо, но что толку от них если большинство не сможет попробовать модель без железа?
A
AI-Driven Development. Родион Мостовой
08.07.2026 11:42 · 👁 1.7K
Хорошие замечания от Паши
A
AI-Driven Development. Родион Мостовой
08.07.2026 09:59 · 👁 3.9K
GigaChat 3.5 - что по агентному кодингу? Terminal Bench 2.0
Пока мы все ждем релиз GPT-5.6, в каналах все чаще наблюдаю анонсы новой модели от Сбера. Очевидно, что работа была проделана немаленькая, поэтому поздравляю ребят с релизом! Там действительно получился довольно большой скачок в сравнении с их предыдущей моделью, а в пабликах часто наблюдаю как пишут, что уровень модели сопоставим, либо даже выше, чем DeepSeek V3.2. Но для нас главный вопрос - что с агентным кодингом? Поскольку мне Сбер денег не занес, придется писать правду.
И тут главная проблема в том, что из официального релиза это практически не понятно. Т. к. единственный прямой agentic coding бенчмарк, который опубликовала команда - это Terminal Bench 2 (в этом месте хочется позанудствовать, что не существует бенчмарка Terminal Bench 2, а существует Terminal Bench 2.0 и более честная его версия Terminal Bench 2.1 - догадаемся, что речь про 2.0). Причем даже в нем мы видим сравнение только с DeepSeek V3.2 и GigaChat 3.1 Ultra. Ну что ж, мы не из робкого десятка, поэтому соберем результаты других моделей по крупицам из разных источников. Например, результаты Terminal Bench 2.0/2.1 удобно смотреть здесь и здесь.
Результаты
GigaChat-3.5-Ultra: 13.48 (харнесс Terminus 2, данные от команды сбера)
GPT-OSS-120B: 18.7 (Terminus 2, данные из лидерборда tbench)
Qwen3.6-35B-A3B: 24.6 (харнесс little-coder)
DeepSeek-3.2: 39.6 (Terminus 2)
Nemotron 3 Ultra (550B-A55): 50.94 (Terminus 2, результаты из vals.ai)
Видимо, агентный кодинг пока не приоритет для команды GigaChat.
Тем не менее, на рынке РФ из отечественных моделей, похоже, что GigaChat 3.5 пока самая сильная. Но объективно сказать трудно, т. к. ни Яндекс, ни Сбер более широкого сравнения не публикуют и друг друга в бенчмарки не добавляют - а зря, ведь современные бенчмарки достаточно легко прогоняются через Harbor, нужны только токены.
Кстати, внимательный читатель мог обратить внимание на не сильно популярную модельку Nemotron 3 Ultra, которая при своем относительно небольшом размере показывает весьма впечатляющие результаты (50.94), чуть хуже Kimi K2.6 (53.56) - напомню, что это одна из самых свежих LLM от Nvidia. Любители on-prem LLM - присмотритесь.
А к колегам по цеху предложение на будущее публиковать System Card модели с техническими подробностями, как это делают OpenAI и Anthropic, а также показывать больше современных бенчмарков: хотя бы DeepSWE 1.1 и SWE-rebench 2.0.
@ai_driven
A
AI-Driven Development. Родион Мостовой
05.07.2026 07:05 · 👁 4.7K
/goal или вайб-кодинг по ключ
Тут наш друг Костя Доронин хороший кейс с /goal описал про, фактически, создание приложений "под ключ", когда агент по подробному плану может работать сутки и более: https://t.me/kdoronin_blog/1312
Но там есть пара важнейших нюансов, которые я не смог не прокоментировать, продублирую:
При всей моей любви к GPT 5.5 Pro - это вообще не панацея. Я довольно часто использую эту модель для разных задач, в т. ч. для V0 примерно как Костя описал и хочу сказать, что GPT 5.5 Pro это все еще совсем не магия. В кейсах "приложение под ключ с нуля" именно этап интервью критически важен - чем оно подробнее тем лучше результат на выходе. И в целом, такой подход довольно рискованный. Даже Pro модель часто такую дичь может напланировать, что можно вообще приложение свое не узнать после этих 26-ти часов. И, конечно, бизнесовый контекст в этом случае очень важно давать - для кого приложение, нефункциональные требования (профиль нагрузки, например), иначе может как переусложнить (часто) так и упростить не там, где надо.
Ну и UX лучше отдельно прорабатывать - а то, вроде, все красиво делает и функционально, но дико неудобно и совершенно непонятно для пользователя, который видит приложение в первый раз. Поэтому по UX прям отдельно интервью лучше провести, а по-хорошему, сначала макеты посмотреть.
Кстати, раз уж про инженерию с нуля заговорили, расскажу про свой мини-проектик новый, вайб стек называется. Короч, помимо бизнесовых требований, чтобы разработка и сопровождение шли как гладко, довольно важно еще и с технологиями оптимальными определиться - собсна, вайб стэк эту проблему и решает, давая очень оптимальные opinionated дефолты: https://github.com/CodeAlive-AI/vibe-stack/
На днях подробнее расскажу подробнее про эту штуку.
@ai_driven
A
AI-Driven Development. Родион Мостовой
01.07.2026 12:16 · 👁 2.2K
Sonnet 5 и косты
Тема костов становится все более актуальной не только для компаний, но и для индивидуалов.
Как только появилась Соннет 5, многие стали говорить о том, что это лучшая модель по соотношению цена/качество - люди смотрят на результаты модели, на raw стоимость токенов и делают выводы. Но что стоит модели достичь таких результатов? Сколько шагов ей нужно сделать и сколько токенов сжечь? Помните тот анекдот про музыканта виртуоза?
На улице недалеко друг от друга подрабатывают два гитариста - молодой и старый. Молодой музыкант показывает суперскоростную технику, "пилит" по всему грифу, сногсшибательно импровизирует, а старый скромно стоит в сторонке и извлекает вдумчиво пару-другую нот. Около молодого гитариста - никого, около старого - толпа народу.
Один слушатель не выдержал, подошел к старому музыканту и спрашивает: "Как так получается, что тот молодой музыкант быстро играет, показывает фантастическую технику, и его никто не слушает, а вы спокойно играете несколько нот и вас слушает толпа народу?" Старый музыкант подумал и ответил: "Он только еще ищет свою ноту, а я уже нашел..."
Забавно, но для LLM этот принцип часто тоже работает - более мощные и умные модели (GPT 5.5, Fable) за меньшее количество шагов достигают той же цели, сжигая в разы меньше токенов на пути. И новая Sonnet 5 как раз отличный пример такого поведения - она на столько много "ищет", что в итоге на многих задачах по цене выходит дороже Opus 4.8 и прям ощутимо дороже GPT 5.5. Не мудрая, в общем модель)
Например, из CursorBench можно увидеть, что Sonnet 5 high с результатом (57%) vs GPT 5.5 medium (59.2%) получается. То есть, даже с учетом скидки Sonnet 5 может оказаться дороже GPT 5.5. Любопытно, что ни по FrontierCode ни по CursorBench результаты не опубликовали в анонсе, они есть только в system card.
Понятно, что по API сейчас соннет дают с небольшой скидкой, что все-таки делает ее слегка дешевле, чем Opus 4.8, но каким образом Sonnet 5 будут чарджить по подписке - пока загадка.
Ждем другие бенчмарки для объективности, но по костам картина уже вырисовывается довольно объективная. И конечно, ждем новое семейство GPT 5.6 - там как раз наоборот по соотношению цена-качество ожидают куда более интересное соотношение, особенно у средней модели Terra.
Что касается меня, то я уже недели три как почти полностью пересел на GPT-5.5 (сразу после отключение Fable), и при оптимальном выборе reasoning - medium / high, в целом, лимитов на 200$ подписке стало хватать на всё. Fable, видимо, буду использовать точечно, как и писал выше в своем обзоре - и смысла теперь в Claude подписке без Fable не вижу, разве что для ревью когда нужен "независимый взгляд".
Ну и напомню, что если цель - сокращение костов и у вас большая кодовая база (1М+ строк), то хороший контекстный движок (например, CodeAlive) - это один из наиболее выгодных способов снижения костов (и существенного ускорения стадии ресерча кодовой базы заодного). Конкретно на exploration даже на небольшой кодовой базе сокращение потребления токенов получается -45% в среднем в нашем RepoQA бенчмарке.
Источники:
Твит от Artificial Analysis на эту тему.
Sonnet 5 System Card (для тех, кто любит копать глубже - похоже, что они прогоняют Main набор FrontierCode на 100 задач).
Расскажите про свои впечатления от Sonnet 5 и актуальна ли для вас вообще проблема костов/экономии токенов.
@ai_driven
A
AI-Driven Development. Родион Мостовой
29.06.2026 08:35 · 👁 3K
1М контекстное окно - прорыв или фикция?
Context Arena забенчмаркали стойкость контекста для GLM 5.2 и Opus 4.8 - значит, это хороший повод нам вспомнить про контекстную инженерию.
На бенчмарке отчетливо видна существенная просадка внимательности моделей на 512к контексте: в среднем, почти в 2 раза в сравнении с 64к контекстом и примерно в 1.5 раз в сравнении с 128к контекстом - грубо говоря, для нас с вами это означает то, что на 512к контексте агент будет терять в полтора раза больше деталей, чем на при 128к заполненности. Для открытых моделей проблема потери контекста особенно актуальна, поэтому практический вывод такой, что по-хорошему, с ними стоит держать заполненность контекстного окна не выше 128к, а лучше даже меньше - ни о каком 1М, конечно, и речи не идет, там просадка будет колоссальной. Кстати, у моделей Kimi K2.6 и, тем более, Minimax M3 дела обстоят еще хуже.
Что еще? Открыв закрытых моделей на большом контексте от открытых все еще впечатляет, хоть уже и не такой драматичный - спасибо DeepSeek за DeepSeek Sparse Attention, которую в GLM-5.2 развили через IndexShare. Кстати, о GLM 5.2 - как видно, моделька действительно на удивление успешная в т. ч. на больших контекстах. Opus 4.8 идет рядышком с GPT 5.5, но последняя все равно сильнее, особенно на совсем больших контекстах. На этом месте вспоминаем интересную деталь - в Codex App по дефолту контекстное окно для GPT 5.5 все еще 256к - то есть, по сути, точность всегда остается где-то на уровне 75%+- (по MRCRv2), а благодаря превосходному алгоритму компактизации, команде Codex удается сохранить все действительно важное так, что эти компактизации обычно и не заметны вовсе - то есть, конкретно в случае с Codex проблему контекстной инженерии ребята здорово решили на уровне модели и на уровне Harness (обвязки), в то время, как Claude Code в этом аспекте требует чуть больше ручной работы - модель на 1M контекста там включается прямо в выпадающем списке (велик соблазн ее включить), но кажется, что простой обыватель зачастую не очень понимает, что переключение на эту модель потребует от него ручного управления контекстом - как только контекст переваливает за условные 200к, начинается зона риска, в которой нужно либо переходить в новый чат, либо, хотя бы, вызывать компактизацию - что и приходилось делать. Что уж говорить, что пользователям открытых моделей за загрузкой контекста все еще стоит следить куда пристальнее. Короче, в 2026-м контекстную инженерию (в которую входит контроль % заполнения контекстного окна) пока никто не отменял - чем больше забит контекст, тем сильнее приходится надеятся на удачу.
И, конечно, не забываем про контроль AGENTS.md, скиллов, MCP, progressive disclosure и т. д. - тоже все составляющие context engineering, с открытыми моделями все это становится еще важнее.
Кстати, современная версия Context Arena прогоняет бенчмарк MRCRv2 от Google DeepMind (GDM-MRCRv2).
Paper про MRCRv2 (Michelangelo)
Датасет MRCRv2
А как вы менеджите контекст? Обращаете ли внимание на % заполнения? Наблюдаете ли просадки в качестве output модели на больших контекстах?
@ai_driven
A
AI-Driven Development. Родион Мостовой
26.06.2026 17:53 · 👁 2.6K
А кто очередь сообщений юзает в Codex App? Я прям активно использую и считаю эту фичу большим UX-преимуществом в сравнении с консольными агентами. Ну Cmd+Enter для моментальной отправки команды и, фактически, корректировки/уточнения движения агента мне тоже очень нравится, в Claude Desktop этого прям не хватает.
Так вот, оказывается, очередь сообщений в Codex App можно реранжировать - то есть, меня последовательность, в которой сообщения будут докидываться агенту надо просто за квадратик слева от сообщения перетащить его выше или ниже. Не знаю как давно так стало можно, но я нашел только сейчас - очень удобно. И быстрая навигация по сообщениям (на втором скрине) тоже тема.
А вам какие UX фичи в Codex/Claude Desktop нравятся больше всего? Особенно неочевидные.
@ai_driven