AI-Driven Development. Родион Мостовой

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.me/llm_under_hood/625 И вот отличный пример Deep Research + SGR от Валеры Ковальского:https://github.com/vamplabAI/sgr-deep-research У нас в CodeAlive много всего интересного используется - и GraphRAG и агенты, интересно ли больше контента на эту тему? Или лучше что-то более прикладное про LLM/агентов в кейсах разработки?

Онлайн митап: AI Coding Talk в этот четверг Приходите в четверг на онлайн встречу, на которой мы с AI-buddies из соседних каналов про AI-кодинг будем обсуждать то, как сегодня выглядит эффективная AI-driven разработка. Ребята, как и я, глубоко погружены в…

Онлайн митап: 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. 🗓Ссылка на календарь Ставьте напоминашку и делитесь с друзьями.

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

Заставляем Claude Code думать на максимуме Готовлю доклад про Context Engineering и раскапываю на досуге разных кодовых агентов - в т. ч. Claude Code. Существует ряд сложных задач, над которыми LLM сначала надо хорошенько "подумать" прежде, чем кодить решение…

Заставляем 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 режим сравнения кишочков кодовых агентов, чтобы по вопросу пользователя показывать как та или иная фича или флоу работает в разных кодагентах (например, "как работает применение патча к файлам?") - интересно ли было бы такое?

Сэкономит 30% вашего бюджета: стартап CodeAlive упрощает работу с кодом Может ли заядлый айтишник стать предпринимателем? Опыт Родиона Мостового, фаундера стартапа CodeAlive, подтверждает, что да. В работе тимлидом он понял, что разработчики тратят много времени на то, чтобы разобраться в коде. Со временем эта боль переросла в стартап CodeAlive, который превращает весь код и документацию компании в интерактивную базу знаний. В эксклюзивном интервью для ER10 Media Родион Мостовой рассказал о взлетах, падениях и изнанке своего стартапа. ER10.KZ | IT-медиа

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

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 (уверен, ты читаешь мой канал), не отключайте ее, пожалуйста) Кейс, конечно, экзотический, но показательный - не сбрасывайте эту странную модельку со счетов. А у вас были похожие кейсы, когда большинство сильных моделей не справлялись, а какая-то "маргинальная" справилась?

AI-Driven Development. Родион Мостовой pinned a photo

🎙Митап AI Driven Development в MOST IT Hub (Алматы) Есть кто из Алматы?) Залетайте на митап 11 июля в 19:00 в MOST IT Hub опытные техлиды из Bereke Bank, QazCode и архитектор из CodeAlive поделятся своими рецептами использования AI-кодинг-агентов в решении реальных рабочих задач. Доклады будут актуальны не только для технических лидеров, но и для всех, кто интересуется AI-агентами. 🧠 В программе: 🔹Иван Луценко, техлид из Bereke Bank, покажет, как он с помощью Claude сократил анализ крашей с нескольких часов до 15 минут и выстроил единый workflow для всех проектов. 🔹Родион Мостовой, CEO и RAG-архитектор из CodeAlive, поделится своими находками в решении сложных задач с помощью LLM и расскажет, как его команда настраивала AI Code Review. 🔹 Но просто сгенерировать код недостаточно — AI-агентов нужно правильно интегрировать в команду. Павел Королев, техлид из QazCode, объяснит, как «обучить» искусственный интеллект особенностям вашего проекта и поддерживать его знания в актуальном состоянии. 📅11 июля | 19:00 📍MOST IT Hub - г. Алматы, ул. Ходжанова 2/2, БЦ Fortis, 3 этаж. ⏱ Длительность: 2,5 часа 📝Регистрация по ссылке ⚠️ Количество мест ограничено

Может ли 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-ки применяются на гране своих возможностей, мы можем собрать потом все в один пост.