tgindex

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

описание

Увлекательно рассказываю про AI в разработке, про построение продуктов с LLM под капотом и иногда про .NET. Связь: @rodion_m_tg Чат: @ai_driven_chat

← к каналу@ai_driven
5 314
подписчиков
Охват к подписчикам
47,9%
ERR
Реакции к просмотрам
0,68%
457 на 25 постов
Пересылки к просмотрам
1,61%
1 079
Постов в день
0,3
всего 25

Где отзываются чаще

доля реакций к просмотрам
  • 13 авг."Делай хорошо" или антипромптинг Sol Накипело. Помните мы раньше просили модели делать хорошо, учитывать корнер кейсы и тд? Так вот, как минимум с GPT 5.6 Sol настало время наоборот просить агента не делать лишнего и не переусложнять. Это модель, которая по дефолту будет учитывать и обрабатывать маргинальные корнер кейсы, вероятность которых примерно отрицательная. Она делает кучу бекапов, проб и тд, даже когда это вообще не нужно - ее тупо приходится бить по рукам (пример на скрине). Если раньше мы промптили "делай хорошо, до конца и тд", то теперь актуальнее "не переусложняй, найди элегантное решение, сейчас нам хватит MVP и тд". Промптинг в обратную сторону получается. Еще раз нам всем урок важности передачи высокоуровневого контекста агенту - что за проект, какова его ценность для пользователей, кто пользователи, сколько их вообще планируется, профиль нагрузки и тд. Дефолты Sol оказались слишком "энтепрайзными", именно поэтому она тратить условно 10 часов на то, что другие современные модели сделают за час. Зато в ревью критически важного кода, в котором действительно необходимо учесть все все все корнер кейсы она чертовски хороша (и Opus 5, кстати, тоже). В общем, теперь Sol из планера и (иногда) воркера превращается для меня в модель-консультанта по оптимизациям и код ревьюера (обязательно с перепроверкой адекватности находок через судью). А что касается поиска оптимальных решений, то это я делаю в паре с Fable. Она мне представляется как раз наиболее мудрой моделью. PS Перфекционизм страшная штука, от него я сам лечусь, а теперь еще и модели приходится лечить. @ai_driven2,44%
  • 30 июл.Агентам не нужен TDD Дядя Боб говорит, что TDD вообще-то для людей и агентам совсем не обязателен, ведь у агента дела с краткосрочной памятью обстоят куда лучше, чем у людей. А что нужно агентам по его мнению? Юнит тест, CRAP метрика и мутационное тестирование... Кто-то считает CRAP и делает мутационные тесты? Если первое ещё иногда интересно, то второе довольно спорная техника - если практикуете расскажите. TDD != тесты А по поводу TDD (его щас прям любят вайб кодеры тиражировать), то давно понятно, что классический TDD цикл (красный тест > код > зелёный тест > рефакторинг, причем мелкими итерациями) с агентами больше похож на прожигание токенов, чем на что-то полезное. Смысл имеет скорее разнообразные тест кейсы перед реализацией продумывать с агентом (включая интересные техники типа pairwise testing), сохранить их в маркдаун или (по BDD или нет - не принципиально). Ну и, конечно, одних лишь юнитов недостаточно совсем, они в принципе часто мало чего хорошего дадут проверить просто by design - идеально использовать умную связку из разных видов тестов - по пирамиде тестирования или лучше даже по трофею (статические проверки), ну или на худой конец хотя бы e2e или browser use/computer use. А когда вайб кодеры говорят про важность TDD часто просто имеют в виду, что нужно тестировать и верифицировать результат - что, конечно, бесспорно. Но Кент Бэк TDD это же не про это, это именно про красный тест > код > зелёный тест. Вот так начинают путаться классические термины с этими нашими вайб кодингами... В общем, если вы ещё используете TDD с агентами - скорее всего, он вам им не нужен. @ai_driven2,01%
  • 8 авг.Важность исследования контекста Тема заезженная, но я сейчас кодю с Opus 5 и, конечно, провожу новую фичу через research стадию и интервью. Собственно, хоть фича и совсем небольшая, даже после того, когда кажется, что все готово, я все равно прошу опуса доисследовать контекст и проработать корнер кейсы и он действительно находит что-то новое и мы учитываем дополнительные инварианты, т. е. не зря просили доисследовать. Вообще, может показаться, что с появлением новых сильных моделей и харнессов проблема исследования контекста (research фазы) решена. Тем более, я даже явно попросил агента о дополнительном исследовании. Но что в действительности? Вы помните, что у меня Grok Heavy подписка с практически бесконечными лимитами, поэтому я смело попросил опуса запустить 5 сфокусированных грок агентов поисследовать глубже все ли мы с ним учли в спеке. Результат: гроки нашли 9 релевантных пробелов, которые мы не учли в спеке. Ну, всё, куда уж дальше-то копать? Ан нет, грок-то бесконечный у нас, давайте еще один проход 5-ти субагентов запустим. Результат: еще +4 находки. Ну, теперь-то уж точно всё, сколько можно? в 2025-й что ли вернулись? Почти. Мы тут недавно CodeAlive агента перевели на GPT 5.6 Luna (кстати, невероятно цепкая и крутая в исследовании и в code review модель), хороший повод проверить новый режим глубокого анализа нашего агента (он специально запромптчен, чтобы предельно глубоко копать)... Отправил. 2 минуты поисков и вуаля, еще +6 находок и пробелов в спеке, которые Опус потом подтвердила и исправила. Ну, и финально фейблом тоже прошлись, которая дала еще 3 полезных замечания по спеке и несколько мелочей. И только теперь спека готова к реализации. Почему так сложно? Две главные причины: 1. Да, фича хоть и небольшая, но нетривиальная и идет в некоторый конфликт с существующей механикой. 2. Кодовая база уже довольная большая и непростая - за 2+ года набралось более полу миллиона строк кода в сумме, это тоже усложняет задачу агенту. Количество ручной работы при этом можно сократить, завернув всю церемонию в скилл (вы тогда на вопросы будете отвечать где-то ближе к началу и в конце, т. к. каждый новый ваш ответ может поменять траекторию и потребовать доп. проверку контекста). В целом, чем более легаси проект, тем актуальнее будут все эти долгие и упорные перепроверки и тем сложнее будет стадия планирования. Особенно если вы, как и я, хотите за one-shot получить около prod-ready результат. Теперь когда вы услышите, что агенты не работают в enterprise, вы знаете каким постом ответить. Кстати, почему не Haiku 4.5? Хайку очень слабая модель на фоне Грока и Luna, она просто видит сильно меньше и уже подводила меня, поэтому теперь не советую ее (в крайнем случае Sonnet 4.6 хотя бы если у вас только клод подписка). Расскажите как у вас теперь выглядит стадия планирования? Вот теперь думаю раз CodeAlive так здорово спеки умеет ревьюить и граундить, может, есть смысл упаковать это в отдельный MCP/skill метод и отдать агентам в пользование? Актуально это? @ai_driven1,56%
  • 6 апр. 2025 г.LiveSWEBench: Реальный бенчмарк SWE-агентов для народа Пока все пишут о новой лламе, AI-2027 и картинках в Гибли-стиле, расскажу вам про новый интересный бенчмарк, оценивающий качество AI агентов-программистов. Причем не всех в подряд, а тех, которые AI-разработчики чаще всего используют в реальности (Cursor, Windserf, aider, GitHub Copilot). В чём проблема существующих бенчмарков? Когда мы оцениваем AI-ассистентов для программирования, то выясняем, что большинство тестов либо проверяют их на изолированных задачах (HumanEval, LiveCodeBench), либо в полностью автономном режиме (SWE-Bench). Но это не совсем отражает реальность. В повседневной работе мы взаимодействуем с AI по-разному: иногда просим его полностью решить задачу, иногда — внести конкретные правки в файл, или просто используем автодополнение для ускорения написания кода. Как LiveSWEBench это исправляет? LiveSWEBench оценивает AI-ассистентов в трёх ключевых сценариях: 1️⃣ Полностью агентные задачи AI получает только описание проблемы из GitHub и должен самостоятельно решить её от начала до конца: найти нужные файлы в большой кодовой базе, разобраться в архитектуре, написать решение и протестировать его. 2️⃣ Задачи на "целевые правки" Более реалистичный сценарий: разработчик уже знает, какой файл нужно изменить, и может объяснить на высоком уровне, что требуется сделать. AI должен внести правильные изменения в указанные файлы. 3️⃣ Задачи автодополнения (tab-autocompletion) Самый "легкий" для AI случай (но внезапно не самый простой!): разработчик начал писать строку или функцию, а AI должен корректно её завершить в контексте всего проекта. В чем же фишки LiveSWEBench? 1. Реальные задачи из реальных проектов: тесты основаны на парах "проблема-решение" из крупных open-source репозиториев c GitHub, включая freeCodeCamp, PyTorch, Wagtail (Django), JUnit5 и JSON for Modern C++. Обратите внимание на мултиязычность! (в отличие от SWE-bench) 2. Защита от "загрязнения": используются только относительно свежие PR (за последний год), которые с меньшей вероятностью попали в обучающие данные AI. Бенчмарк регулярно обновляется. 3. Попытка объективной оценки: решения проверяются запуском реальных тестов из проекта. И что в итоге? В полностью агентных задачах лидируют SWE-Agent, Github Copilot (VSCode), Windsurf - почти все на базе нашей любимой Claude 3.7 Sonnet. В задачах целевых правок многие инструменты показывают заметный прирост производительности (особенно Aider). Задачи автодополнения оказались неожиданно сложными: AI часто находят правильное решение, но затем добавляют лишний код, который ломает тесты. Тут вообще интересно, у них autocompletion Копайлота (44.83) показал лучшие результаты, чем Курсор (41.38) - вот так неждан. Немного критики от меня Несмотря на все усилия по борьбе с "загрязнением" данных (использование недавних PR (до года) и регулярное обновление), фундаментальная проблема остаётся: оценка проводится на популярных публичных репозиториях, которые с высокой вероятностью уже были включены в обучающие выборки современных LLM. Даже если конкретные PR не попали в тренировочные данные, модели могли "видеть" структуру проектов, стиль кода и общую архитектуру этих репозиториев. Это даёт им неявное преимущество. Действительно показательным был бы бенчмарк на основе больших, но закрытых кодовых баз — внутренних проектов компаний, которые гарантированно не попали в обучающие данные. Такой подход позволил бы более объективно оценить способность AI-ассистентов разбираться в незнакомом коде и решать реальные, "свежие" для них задачи, с которыми сталкиваются разработчики в корпоративной среде. Но сделать такое сложно по понятным причинам. Авторы обещают, что бенчмарк будет развиваться. Надеюсь, появится возможность фильтровать результаты для конкретного ЯП (создал issue). Ну и, ждем результатов по Cline и по Roo-Code. Подробнее про бенчмарк тут: https://liveswebench.ai/details Код бенчмарка тут: https://github.com/LiveBench/liveswebench Что думаете про результаты и про сам бенчмарк? На сколько бьется с вашим опытом? #бенчмарк #LiveSWEBench1,16%
  • 24 июл.Все лимиты и ресеты для Codex 200$ закончились. Рекорд - расход 2 недельных подписки за сутки (работа над RepoContextBench v2 ведется полным ходом). А Claude медленный, да еще и с лимитированным фейблом. В итоге, взял Грока за 300$ 100$ - говорят, там лимиты почти бесконечные и все очень быстро. Грок за 30$ мне понравился как по качеству, так и по скорости. Грока я использую в качестве исполнителя внутри OpenCode (возможно, перееду теперь на его нативный харнесс Grok Build) через свой скилл agents-consilium, его вызывает Codex App или Claude как субагента, поэтому получается очень удобно. Итого, сетап теперь такой: Планирует Fable или GPT-5.6 Sol high/xhigh, а что вместе. Иногда GPT 5.6 Sol Pro. Выполняет Grok 4.5 high Ревьят: Opus 4.8, GPT 5.6 Sol, GLM 5.2 и по итогу Fable. Позже добавлю Kimi K3 в ревьюеры и посмотрим еще на возможности релизной DeepSeek V4 Pro и Qwen 3.8. Итого 4 подписки: Codex 200$, Claude 100$ (для Fable и ревью), OpenCode 10$ для ревью через китайцев (для работы практически бессмысленная, только нечастые ревью разве что). Есть еще темная лошадка SWE 1.7 от ребят из Devin - супер быстрый (на Cerebras чипах) и, судя по Frontier Code, с классными результатами. Если кто пробовал - отпишитесь. Еще, мне регулярно перестает хватать мощностей моего мака на комфортную разработку, поэтому планирую арендовать VMку и делегировать тяжелые задачи агента туда. Ах да, напоследок - лайфхак. Поскольку ручной сброс кодекс лимитов просто стартует новую неделю - получается, что выгоднее сразу после органического сброса как можно быстрее выжать лимиты, затем сделать ручной сброс, тогда вы за один и тот же помежуток времени сделаете больше работы нагенерите больше кода и, условно, в месячной подписке станет почти 6 полных недельных квот вместо 5-ти (без учета общих сбросах). Почему-то об этом никто не пишет. @ai_driven1,14%
  • 12 авг./btw на максималках или Codex side chat Продолжаем рубрику подборка лучших UX решений. Когда кодишь с агентом довольно часто возникает ситуация, когда из одного чата нужно быстро форкнуться в новый чат, чтобы исправить что-то, возникшее по пути, не прерывая работы в старом чате. Раньше мы использовали fork для этих целей, но форк довольно тяжеловесный + не из всех состояний он доступен. В общем, если выделить текст в прямо чате Codex App'а, то сверху можно увидеть всплывающее меню с разными действмия, в т. ч. Ask in side chat. Наверное, видели. Можно подумать, что это старый добрый /btw а-ля клод код. Но нет, на деле у этого сайд чата тоже есть полноценный write доступ и из него действительно можно делать небольшие правки (например, в скиллах, как на скрине) прямо по ходу основной задачи, вообще никак в нее не вмешиваясь. Не знаю как вам, но мне не хватало такой возможности - настолько, что решил и вам рассказать. Напомню, что ранее я уже рассказывал про неочевидную удобную возможность реордеринга (как это по русски подскажите в комментариях) очереди сообщений в Codex App. Если не видели - посмотрите. А еще, теперь можно попросить Codex App запустить какую-то задачу в новом диалоге и он прям из текущего чата спавнет вам новый диалог. И читать сторонние или текущий диалог Codex App теперь тоже умеет. Подробнее про то, как это работает рассказывал Тимур. И да, в Claude Code Desktop тоже есть подобный side chat, но он readonly, что не так интересно, хоть и удобно иногда что-то доспросить. @ai_driven1,12%
  • 9 авг.Luna - потрясающая модель для Code Review Собственно, похоже, что GPT 5.6 Luna max сейчас лучшая моделька для код ревью по соотношению цена-качество, да и в принципе одна из лучших моделей для ревью. Это подтверждают как наши внутренние бенчи на Code Review, так и новый бенчмарк от Vercel DeepsecBench (да да, бенч на секьюрити в принципе можно смело экстраполировать на код ревью). С учетом ее предельной дешевизны, крайне рекомендую включать ее в свои пайплайны - как для ревью, так и для исследований контекста. Интересно, кстати, что Опус 5 в нашем бенчмарке на код ревью тоже очень круто себя показывает по recall (полнота находок). А еще, там DeepSWE bench обновили изрядно модельный ряд и новая дипсик 4 флеш там уж очень хороша - практически на уровне grok 4.5/sonnet 5 (53% vs 54%) при цене более, чем в 20 раз дешевле и в 264 раза дешевле sonnet 5. Китайцы снова жгут. Если вы у себя в компании крутите локально модельки - точно стоит присмотреться. Upd: в комментариях подписчик подсказывает способ ускорения Luna в качестве субагента @ai_driven1,10%
  • 30 июл.Мой тест на AGI0,99%
  • 30 июл.Какой-то баг с реациями в ТГ случился (навайбкодили опять) и были доступны только дизлайки и сомнения, поэтому мы с дядей Бобом собрали рекордное кол-во дизайков под постом, я еще начал думать, что никто уже не читает такие "длинные" посты до конца. Короче, если вы хотели отреагировать как-то иначе - теперь можно. А еще лучше - подключайтесь к дискусси, тк дебаты разгорелись нехилые в комментариях...0,97%
  • 29 июл.Kimi K3 и ревью моделями разных семейств Ну как вам новая Kimi K3? Медленно? Если использовать ее не как основную модель, а как еще одно мнение - вполне норм, тем более, что она действительно находит интересное в дополнение к Опусу. Сейчас как раз работаю над очень сложной задачкой по улучшению комплексного и длительного воркфлоу, он должен быть устойчивым к разным сбоям, там всякие outbox'ы, умные фолбеки и другие нетривиальные штуки, в которых нейронки часто ошибаются. Предыдущие агенты полноценно не могли осисить эту задачу - постоянно что-то где-то вылетало. План делали уже по традиции Sol, Fable, Opus и даже Kimi K3 - в комплексных (или исследовательских) задачах, когда много unknown unknowns чем больше хороших и разнообразных моделей - тем лучше. Но даже самый сильный план не всегда гарантия идеального кода, поэтому в таких случаях есть смысл еще и итоговую реализацию дополнительно ревьюить (тем более, что исполнителям иногда свойственно срезать углы). Так вот, конкретно в этом кейсе ревью я прогнал через Opus 5 (medium) и Kimi K3 (max) (на DeepSWE, кстати, у обоих 69%). Результаты на скрине. Собсна, чье ревью сильнее даже не так важно в данном случае, важнее - кол-во уникальных (не пересекающихся) находок, а их 4 у Kimi и 5 у Opus - т. е. кими дополнила ревью опуса аж 4-мя находками и главное все они оказались релевантны. Однозначно беру в коллекцию ревьюеров. Будем наблюдать дальше. Кстати, в самых тяжелых случаях все еще можно отправить архив релевантных файлов на ревью в GPT 5.6 Pro. Но тут сразу важный нюанс - если у вас такая задача, что самые мощные модели 2+ раза подряд находят реальные проблемы, то это хороший повод задуматься о том, что, скорее всего, все-таки есть переусложнение, и, вероятно, на нее уже есть готовое и хорошо протестированное решение - возможно, будет дешевле поискать их получше. Ну, либо задача слишком большая и стоило бить ее на меньшие сабтаски. Про Опус 5: хоть ее все равно все еще приходится направлять и подсказывать (а вы что хотели?), мне моделька нравится - весьма понимающая и не соглашается на все в подряд. А слог ее так вообще шикарен. GPT семейство по традиции общается довольно сухо, у Opus'а же наоборот частенько проскакивают нотки гуманитария, речь богаче и живее - это приятно. Что касается практической части, то напомню, что ревью я запускаю через скилл agents-consilium - он теперь наблюдаемый и умеет стримить прогресс вызывающей стороне - стало сильно удобнее. А еще, там появилось два совершенно новых режима explore и delegate, про которые я расскажу отдельно. Итого, текущий джентельменский набор вайб-кодера agentic инженера: Опус/Фейбл/Sol/Kimi K3 - план и интервью, Grok 4.5 (ну или Terra/Luna) - исследование контекста и реализация, и все те же Опус, Фейбл, Sol, K3 код-ревью. Стадию плана лучше дополнять парочкой очень важных скиллов для борьбы со сложностью (FPF, code-that-fits-in-your-head). Kimi K3 я использую внутри OpenCode через подписку OpenCode Go за 10$/мес (моя рефка с бонусом) и еще держу резерв на Synthetic за 30$ (моя рефка тоже с бонусом). @ai_driven0,93%
  • 21 июл.без подписи0,80%
  • 20 сент. 2025 г.Митап по 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 #второй_блин0,70%