Весьма показательная история. Справедливости ради только отмечу, что для совсем не инженеров, которые очень хотят быстрый MVP, все-таки больше подходят такие решения, как lovable.dev и bolt.new - во всяком случае, они хоть как-то пытаются проблемы c секьюрити решать.
Ну, и, конечно, всегда стоит помнить о возможности хотя бы взять часовую консультацию у эксперта-разработчика на том же getmentor.dev (некоммерческий проект) - всяко дешевле выйдет, чем потенциальные потери от утечки ваших ключей.

Может ли AI находить сложные ошибки в коде целых проектов?

У меня в канале много дотнетчиков (спасибо Жене @epeshkblog, Саше @dotnetmore, Кириллу @csharp_gepard и Леше @itbeard) и многие из вас наверняка помнят популярный вопрос с собеседований про GetHashCode) Следующий кейс как об этом.

Есть расхожее заблуждение о том, что LLM все еще слишком глупы для того, чтобы находить ошибки в коде проектов. Особенно когда речь идет о больших и сложных кодовых базах.
В действительности же нейросети развиваются каждый день, и чтобы GenAI тулинг смог находить даже сложные ошибки в коде, в сущности, необходимы всего 2 составляющие:
1. Мощная LLM с возможностью размышлений (reasoning, thinking). Например, наши внутренние бенчмарки показывают, что самыми внимательными к багам являются модели Gemini 2.5 Pro и OpenAI o3.
2. Релевантный контекст. Важно находить золотую середину между избыточным контекстом и недостаточным контекстом. В случае если в LLM поступает лишний контекст, она просто с большей вероятностью в нем запутается и качество ревью упадет драматически. С другой стороны, если контекста недостаточно, то нейросеть просто не сможет "понять" как то или иное изменение кода повлияет на проект в целом, упустив таким образом важные потенциальные проблемы. Простой пример - код, предназначенный для однопоточного выполнения, в многопоточной среде, как правило, будет выполняться с ошибками.
Например, мы CodeAlive предварительно индексируем кодовую базу, выстраивая граф вызовов, иерархию типов и другие связи - именно этот шаг помогает максимально эффективно работать с контекстом нашему AI Code Review.
Поделюсь таким кейсом:
Недавно мы заметили баг, из-за которого в системе дублировались артефакты Identifier артефакта - это композиция из fileName, className, funcName). Но самое интересное то, что в коде мы уже обрабатывали дубликаты через HashSet и этой ошибки не должно было быть вовсе:

        HashSet<ArtifactAggregate> artifactsToSave = new();
        void TryAddArtifact(ArtifactAggregate artifact)
        {
            if (artifactsToSave.Add(artifact) == false)
            {
                // log error
            }   
        }

При этом, GetHashCode, на первый взгляд даже корректный, уже был реализован ранее (но я честно о нем даже и не вспомнил тогда).
И тут и возникла та самая ситуация, когда даже разработчику непонятно, в чем дело (ведь мы же уже защитились!).
Почесав репу, я подумал, почему бы не попросить CodeAlive поискать корень проблемы:

почему у нас дублируются Identifier артефактов в базе? мы же вроде защищены от этого в TryAddArtifact

Ответ прилагаю на скрине. Но он мне настолько понравился, что я продублировал его в текст. Здесь важно отменить, что весь контекст AI-агент собрал сам - все, что я дал ему на входе это вопрос выше.
Проблема действительно оказалась именно в некорректных св-вах в Equals и GetHashCode.
Кстати, многие хотят попробовать CodeAlive сразу на больших проектах, без регистрации и смс, теперь это стало возможным. Мы проиндексировали опенсорс проекты (ASP.NET Core, Java Spring, laravel, GORM, VSCode, etc.) и теперь каждый может задать по ним свои вопросы: https://www.codealive.ai/#public-chats

У меня есть еще отдельный флоу для решения сложных coding проблем через LLM, если такое интересно, то ваши реакции - лучшая мотивация для нового поста) И поделитесь своими кейсами и флоу, в которых LLM-ки применяются на гране своих возможностей, мы можем собрать потом все в один пост.

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://news.1rj.ru/str/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://news.1rj.ru/str/llm_under_hood/625
И вот отличный пример Deep Research + SGR от Валеры Ковальского: https://github.com/vamplabAI/sgr-deep-research

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

Мой доклад на Kolesa Conf’25 + конкурс

Друзья, 11 октября в Алматы я буду выступать с докладом про Context Engineering на Kolesa Conf. Расскажу про Spec-Driven Development и о том, как сейчас устроена работа с контекстом в современных кодагентах и в CodeAlive - будет жарко!
Ссылка на сайт конференции (билеты пока доступны): https://kolesa-conf.kz/?utm_source=tg&utm_medium=aidriven#up

И хорошая новость только для подписчиков моего канала - совместно с организаторами мы проводим конкурс: в комментариях к этому посту расскажите о самой необычной задаче, которую вам помог решить кодовый агент и победителю с наиболее интересным кейсом достанется билет на Kolesa Conf'25 и месяц подписки на CodeAlive. Победителя выберу я через неделю в четверг 18-го сентября.

P. S. Почти год прошел с момента моего предыдущего доклада про LLM для разработки на DotNext и вот организаторы выложили выступление в общий доступ - надо признать, что за год столько всего изменилось, что доклад интересен разве что с целью погрузиться в картину и инструменты годовалой давности и еще раз осознать насколько все быстро развивается в нашей сфере, либо если вы только вкатываетесь в тему AI для разработки. То ли дело доклады моего приятеля Жени Пешкова, вот они-то остаются актуальны годами! Вот, кстати, его доклад про async/await c того же Дотнекста.
А для тех, кто дочитал до конца бонус - мой недавний и очень актуальный доклад про подход к решению сложных задач с LLM, а также про AI Code Review. (совершенно не выспался и дико устал в тот день, поэтому надеюсь вы мне простите мои бесконечные междометия))

Онлайн: Разбираемся с Gemini CLI, Claude Code и Codex CLI на продвинутом уровне вместе с экспертами

Сегодня, в среду, в 17:00 по МСК, 16:00 по CEST и в 19:00 по Алматы встречаемся с Александром Колотовым, чтобы разобраться в том, как эффективно использовать Gemini CLI в повседневных задачах программиста. Помимо разных фишек Gemini CLI так же увидим как CodeAlive MCP может усилить Gemini CLI. Александр - разработчик с 20-ти летним стажем, сейчас кодит преимущественно на Elixir в компании Blockscout.

Добавляйте в календарь встречу "Раскрываем потенциал Gemini CLI + MCPs", чтобы не пропустить: (встреча прошла)

—

А в этот четверг, 16:00 МСК, 15:00 CEST и 18:00 по Алматы пройдет встреча с Максимом, автором замечательного Telegram-канала Этихлид. Из всех моих знакомых Максим наиболее глубоко и широко погружен в тему кодовых агентов - регулярно пробует и обозревает разные решения и (что важно) не зацикливается на каком-то одном агенте. Цель встречи - на реальной задаче посмотреть как эффективно использовать Claude Code со всякими продвинутыми фишками типа субагентов, а также разберемся в каких случаях может пригодится Codex CLI. Помимо глубокой погруженности в тему, у Максима так же опыт разработки почти 20 лет.

Добавляйте встречу "Claude Code vs Codex. А не пора ли нам обновить воркфлоу?" в календарь, чтобы не пропустить: (встреча прошла)

Обе встречи будут записаны, но у тех, кто подключится Live будет возможность задать свои вопросы экспертам.

Митап по Claude Code, Codex и их контекст v2

Суббота 27 сентября 17:00 МСК, 16:00 CEST и 19:00 Алматы.
Вы просили, мы сделали! Уж очень хорошая получилась встреча с @etechlead - Максиму удается подавать материал очень просто и структурированно, поэтому % удержания аудитории на встрече был близок к 100 от начала до конца. Мы вам обещали запись, но мы не осилили Zoom по техническим причинам нормально записать встречу не получилось, поэтому мы решили ещё лучше подготовиться во всех смыслах и повторить митап с хорошей записью для YouTube.

Вообще, я бы очень рекомендовал эту встречу не только программистам, но и руководителям для лучшего понимания того, что сейчас происходит в области AI- assisted разработки и как это все работает.

В программе:
● Анатомия кодингового агента
● Контекст и внимание
● Цикл работы агента
● Возможности Claude Code (команды, субагенты, модели, режимы работы, контекст)
● Codex и его сравнение с Claude Code

Ссылка на встречу: https://calendar.app.google/gtcTeQAeUxiVmtF5A

#workshop #agents #второй_блин