GPT 4.5 лучше, чем Claude Opus 4, o3 Pro и Gemini 2.5 Pro?! И причем тут Mermaid?

GPT 4.5 от OpenAI - одна из наиболее странных и специфичных моделей. Она стоит в разы больше, чем GPT-4o/GPT 4.1/o4-mini, но на большинстве задач на программирование показывает сопоставимые или худшие результаты. Как только появилась эта модель, у меня в канале был пост о том, что GPT 4.5 гумманитарий, а не технарь, в котором она имитировала рассказы Пелевина.

Собственно, до сегодняшнего дня я использовал GPT 4.5 только для написания красивых текстов или переводов (и то я уже не уверен, что она здесь выигрывает у Sonnet 4).

Так вот, у нас в CodeAive чатик в своих ответах умеет генерировать Mermaid диаграммы любой сложности - и добиться около 100% корректности этих диаграмм было большим челленджем, по итогу которого мы реализовали целый пайплайн-фиксер, частью которого являются старые добрые проверки через регулярки (regular expressions).
Только проблема в том, что регулярками там надо проверять довольно много разных кейсов (36 тестов в сумме), поэтому паттерны там получились настолько сложные, что их легче просто протестить на разнообразных кейсах и забыть о них. Просто как пример:

$@"(\b[a-zA-Z0-9_]+(?:<br\s*\/?>[a-zA-Z0-9_]+)*)\s*$begin:math:text$\\((.*?)$end:math:text$\)(?=\s*(?:@"(?:x--x)(?:\|.*?\|)?|$))"

В общем, есть один хак, про который подробнее я расскажу чуть позже, он позволяет моделям типа o3 быстрее генерировать сложный рабочий код через итеративное тестирование, но работает это пока только с Python. Я, конечно, воспользовался этим подходом и в итоге, у LLMки получился идеальный метод, который успешно проходил все тесты. Но настоящим челленджем по итогу оказалось корректно конвертировать этот метод обратно в C#. Ни одна сильная reasoning модель с этой задачей не справлялась и половина тестов просто не проходила. Какие модели я пробовал: o3, o3 Pro, o4-mini-hight, Claude 4 Opus Thinking, Grok 3 Thinking, Gemini 2.5 Pro (max thinking budget). Никакой итеративный подход, конечно, тоже не спасал (когда мы несем тексты ошибок обратно в чат и просим их исправить). Больше того, я даже нашел вот такой интересный список отличий регулярок в разных ЯП и скармливал LLMкам этот список (дистиллированный под Python vs C#) - результат тот же... полный фейл.

В общем, бросил я эту задачу, понадеявшись на грядущий Grok 4, а потом вдруг вспомнил, что у нас еще есть GPT 4.5 в арсенале. Ну и что бы вы думали? С одного простого промпта с первой же попытки GPT-4.5 нагенерила абсолютно корректный метод (Python - > C#), который успешно прошел все 36 тестов. Так что, sama (уверен, ты читаешь мой канал), не отключайте ее, пожалуйста)

Кейс, конечно, экзотический, но показательный - не сбрасывайте эту странную модельку со счетов.

А у вас были похожие кейсы, когда большинство сильных моделей не справлялись, а какая-то "маргинальная" справилась?

Я стал редко постить что-то новое в свой канал, т. к. на него совершенно не остается времени из-за загрузки в CodeAlive - мы с мощной командой сделали инструмент, который позволяет разработчикам, аналитикам и тестировщикам быстрее разбираться в огромных кодовых базах, давая быстрые, точные и глубокие ответы на вопросы по коду всего проекта, а также умеет делать AI Code Review с учетом контекста проекта.
В общем, недавно я дал интервью Шахизе Менг из казахстанского издания er10, в котором много всего рассказал не только о пути нашего проекта, но и его технической составляющей. Если вам интересно как развивается KZ-EU AI DevTool стартап в 2025, то милости прошу. Немного позже я расскажу подробнее о том как у нас все работает. А сейчас, спасибо er10, и приятного чтива!

Сэкономит 30% вашего бюджета: стартап CodeAlive упрощает работу с кодом

Может ли заядлый айтишник стать предпринимателем?
Опыт Родиона Мостового, фаундера стартапа CodeAlive, подтверждает, что да. В работе тимлидом он понял, что разработчики тратят много времени на то, чтобы разобраться в коде.

Со временем эта боль переросла в стартап CodeAlive, который превращает весь код и документацию компании в интерактивную базу знаний.

В эксклюзивном интервью для ER10 Media Родион Мостовой рассказал о взлетах, падениях и изнанке своего стартапа.

ER10.KZ | IT-медиа

Заставляем Claude Code думать на максимуме

Готовлю доклад про Context Engineering и раскапываю на досуге разных кодовых агентов - в т. ч. Claude Code.
Существует ряд сложных задач, над которыми LLM сначала надо хорошенько "подумать" прежде, чем кодить решение (а точнее, сжечь reasoning токены) - так вот, Claude Sonnet 4 и Claude Opus 4/4.1 тоже этим навыком владеют. И многие знают, что заставить СС подумать можно просто добавив в постановку задачи текст "think deep". Но немногие знают, что на самом деле у клода таких думающих режимов несколько, а именно:

        HIGHEST: 31999,
        MIDDLE: 10000,
        BASIC: 4000

Справа от названия режима объем мыслетоплева thinking budget tokens для LLM.
И теперь самое интересное - список ключевых слов, активирующих каждый из режимов (да, они прям захардкожены):

            HIGHEST: [{
                pattern: "think harder",
            }, {
                pattern: "think intensely",
            }, {
                pattern: "think longer",
            }, {
                pattern: "think really hard",
            }, {
                pattern: "think super hard",
            }, {
                pattern: "think very hard",
            }, {
                pattern: "ultrathink",
            }],
            MIDDLE: [{
                pattern: "think about it",
            }, {
                pattern: "think a lot",
            }, {
                pattern: "think deeply",
            }, {
                pattern: "think hard",
            }, {
                pattern: "think more",
            }, {
                pattern: "megathink",
            }],
            BASIC: [{
                pattern: "think",
            }]

В общем, достаточно запомнить ultrathink и будем вам "самый умный режим". Осторожно, возможно непредвиденное обжорство токенами.

Кстати, вот еще лайфхак как новый Codex на базе GPT-5 перевести в максимально "думающий" режим: codex --config model_reasoning_effort="high".

—

А что еще вам было бы интересно про подкапотную составляющую кодовых агентов? (в т. ч. Claude Code). Есть идея добавить в наш CodeAlive режим сравнения кишочков кодовых агентов, чтобы по вопросу пользователя показывать как та или иная фича или флоу работает в разных кодагентах (например, "как работает применение патча к файлам?") - интересно ли было бы такое?

Claude Code vs Codex vs Codex CLI vs Aider

В последнее время я активно использую Claude Code, Aider, Gemini CLI, Codex и Codex CLI. И если с первым для большинства все понятно - CC сейчас стал эдаким индустриальным стандартом для AI-кодинга, который плавно заменяет Cursor, то кейсы для остальных тулов уже не так очевидны. Поэтому поделюсь своим форкфлоу:

Aider
aider (на базе Gemini 2.5 Pro) я люблю использовать в случаях когда четко знаю какие именно файлы нужны для решения задачи - тогда я просто загоняю их в контекст эйдера и точно знаю, что LLMка будет учитывать контекст всех этих файлов (другие кодагенты часто грешат частичным считыванием файлов). Ну и еще один кейс с эйдер - это применение плана изменений из CodeAlive - aider очень хорошо умеет применять патчи к указанным файлам по указанному плану изменений.

Codex CLI
Похоже, что как кодовый агент Codex CLI до сих пор довольно сырой (во всяком случае уступает Claude Code), зато поскольку он теперь работает на базе GPT-5, есть смысл применять его точечно в самых сложных местах: например, когда нужно пофиксить какой-то лютый баг, который Claude Sonnet/Opus даже в режиме ultrathink не осиливают. Ну или для реализации какого-нибудь запутанного алгоритма с кучей corner cases.
Пример из практики: у нас в CodeAlive возникла простенькая задачка по улучшению UX - когда пользователь при добавлении репозитория в систему вставляет ссылку на него, автоматически вытаскивать имя репозитория прямо из вставленной ссылки и подставлять его в поле Name (чтобы поберечь пальцы пользователей от лишних действий). Скажите ведь, что задача на 30 сек? Так вот, мы в CodeAlive для фронта используем Nuxt и, вероятно, по этой причине ни Claude Code, ни Gemini CLI, ни Junie не смогла осилить эту, на первый взгляд, совсем элементарную задачу (в реальности я хз почему, т. к. сам совсем не фронтэндщик, но это и неважно в данном случае). Больше того, даже Claude Opus 4.1 в режиме ultrathink так и не смогла найти причину бага и исправить его, выжрав при этом аж 10$!
В итоге, странную проблему смог пофиксить только Codex CLI в режиме high reasoning effort: codex --config model_reasoning_effort="high". Промпт был простой:

`Name` auto-fill logic is not working - it's extremely complicated problem, since even a Senior dev couldn't solve it. So, think hard to find the root cause and fix it. You can even come up with an alternative approach.

Теперь вы знаете что делать если CC и остальные агенты встали в ступор. Кстати, хорошая новость в том, что с недавних пор Codex CLI работает и по подписке ChatGPT Plus, а не только через API ключ.

Codex (web)
Что касается Codex, который облачный в веб интерфейсе, то я теперь использую его для решения каких-то сложных проблем в тех случаях, когда даже непонятно где вообще искать - например, поиск возможной причины OOM. Плюс Кодекса в вебе в том, что он умеет генерировать до 4-х вариантов (траекторий) решения и далее позволяет выбрать наиболее адекватное.

CodeAlive
CodeAlive я использую для кейсов когда необходимо быстро разобраться как что-то работает в кодовой базе на 50к и более строк кода или когда нужно что-то красиво визуализировать (мы очень много работали, чтобы диаграммы всегда были корректными). CodeAlive отдает точный и глубокий ответ на вопрос за несколько секунд, в отличие от кодагентов, которые по несколько минут могут собирать контекст даже на простые вопросы.

А в каких задачах вы используете что-то кроме Claude Code?

Аудит кодовой базы на ошибки и уязвимости через LLM

Те, кто внимательно следит за моим каналом знают, что у нас в CodeAlive уже давно есть фича Code Review через AI, который учитывает контекст проекта, а не только смотрит diff. Дело в том, что этот AI-ревьюер встраивается в пайплайн разработки, и проверяет тот код, который разработчики отправляют в PR/MR. Это работает отлично, но мы все чаще получаем запрос от наших пользователей на то, чтобы CodeAlive сделал для них ревью (фактически аудит) всей кодовой базы целиком. И мы сейчас работаем именно над этой фичей. Так что если для вас актуальна задача проверки всего кода вашего пет или даже рабочего проекта - напишите мне и мы бесплатно проведем такой аудит, а с вас фидбек по результатам :)
И если среди нас есть специалисты, которые профессионально занимались аудитом кодовых баз - тоже напишите мне, нам было бы интересно с вами пообщаться.

Онлайн митап: AI Coding Talk в этот четверг

Приходите в четверг на онлайн встречу, на которой мы с AI-buddies из соседних каналов про AI-кодинг будем обсуждать то, как сегодня выглядит эффективная AI-driven разработка. Ребята, как и я, глубоко погружены в тему AI-assisted разработки, а кто-то даже свои тулы для этого делает. Я поделюсь своим текущим воркфлоу, а также расскажу про наш опыт Context Engineering в CodeAlive.

Вместе со мной участвуют следующие достопочтенные граждане:

- "The AI Architect | AI Coding", Тимур Хахалев
- AI и грабли, Николай Шейко
- Константин Доронин
- Глеб про AI, Глеб Кудрявцев

Начнём в четверг, 28 августа, в 16:30 по МСК, 18:30 по Алматы и в 15:30 CEST.

🗓 Ссылка на календарь

Ставьте напоминашку и делитесь с друзьями.

Напоминаю, наш скромный митапчик уже через 9 минут.

Добавляться через бота https://t.iss.one/group_sub_check_bot?start=68b04c36e5b9f465c329b7e6

По-умолчанию ютуб, но потом еще выложим на другие платформы.

SGR + AI Test-Driven Development + Metaprompting

Уровень 1: AI-TDD
Когда разрабатываешь тот или иной функционал с ллмками, очень круто работает подход, когда сначала пишешь хорошие тесты (часто можно нагенерить прямо через какую-нибудь мощную ллмку типа GPT-5 high), потом просто просишь кодагента итеративно запускать тесты и улучшать код в соответствии с фидбеком до тех пор, пока тесты не пройдут. Давайте назовем этот подход AI-TDD. Это довольно рисковый подход, я бы сказал на гране, т. к. некоторые ллмки и агенты могут начать просто подгонять код под тесты, тупо вставляя заглушки - Sonnet модельки таким грешат, а вот GPT-5 ведет себя честнее. Еще, может показаться, что такой подход слегка противоречит популярными нынче Spec-Driven Development (о котором мы поговорим позже). Но на самом деле нет, т. к. AI-TDD - это скорее про подход к решению более сложных и запутанных задач, в которых как ты спеку ни пиши, ллмки все равно ошибутся в итоговом коде, ну либо спеку можно вывести только из итогового кода (в случае с CodeAlive мы такой финт ушами делали, например, в задаче на парсинг кода).

Уровень 2: AI-TDD + Metaprompting
Так вот, если вдруг у вас есть продукты с LLM под капотом или вы что-то такое планируете, то возьмите на заметку еще один паттерн - AI-TDD + метапромтинг. Что это за зверь? В целом метапроптинг - довольно простая техника, когда промпт для LLM генерирует другая LLM (обычно более мощная), мы регулярно такое практикуем. Ну а соединив метапромтинг с AI-TDD, мы получим кейс, в котором кодагент итеративно улучшает промпт. Здесь важно отметить, что промтингом обязательно должна заниматься рассуждающая модель - я использую GPT-5 high через Codex CLI (codex --config model_reasoning_effort="high"). Давайте для простоты назовем такого агента-метапромптера супервайзером.
Кстати, про сам этот термин "метапромптинг" я узнал еще в прошлом году из давнего курса OpenAI про использование модели o1, там они использовали o1 для улучшения политик (это часть промпта) для 4o-mini. Тогда меня очень впечатлил этот подход и, кажется, что тогда он как-то остался незамеченным.

Уровень 3: AI-TDD + Metaprompting + SGR (SO + CoT)
Хорошо, погружаемся еще глубже. То, что описано выше уже может неплохо работать, но отлаживать такое (а значит, и улучшать) может быть проблематично, т. к. все, что происходит внутри LLM - черный ящик. Было бы неплохо прикрутить к ответу LLM какую-нибудь "отладочную" информацию - тогда супервайзеру будет легче понять причину проблемы и внести более точные правки в промпт. И здесь можно взять старый добрый CoT (Chain Of Thoughts) - это когда мы просим модельку подумать "шаг за шагом" перед тем, как ответить. Но CoT не всегда подходит, т. к. чаще всего в продуктах с LLM под капотом мы получаем от нейронки ответы в структурированном виде (Structured Output) и вот здесь к нам на помощь приходит подход SO + CoT или, как его нынче называют, SGR - Scheme Guided Reasoning (за термин спасибо Ринату из канала LLM под капотом). Базово, идея в том, чтобы каждый шаг, каждое свое решение LLMка сопровождала рассуждениями и свидетельствами. Если совсем упрощенно, то если раньше мы получали ответ в формате { "result": 42 }, то теперь мы получаем ответ в формате { "reasoning_steps": "...тут шаги с 'мыслями' LLM о том, как именно она пришла к ответу...", "result": 42 }. В итоге, мы, во-первых, получаем ту самую "отладочную информацию", а во вторых, еще сразу повышаем точность ответов, т. к. добавление рассуждений в output non-reasoning модели обычно уже само по себе делает модельку умнее. Ну вот и все, теперь запускаем наш пайплайн метапромтинга по TDD на новом уровне. А кому интересно еще глубже нырнуть в SGR, добро пожаловать в канал Рината: https://t.iss.one/llm_under_hood/625

У нас в CodeAlive много всего интересного используется - и GraphRAG и агенты, интересно ли больше контента на эту тему? Или лучше что-то более прикладное про LLM/агентов в кейсах разработки?