AI-Driven Development. Родион Мостовой
"Делай хорошо" или антипромптинг Sol Накипело. Помните мы раньше просили модели делать хорошо, учитывать корнер кейсы и тд? Так вот, как минимум с GPT 5.6 Sol настало время наоборот просить агента не делать лишнего и не переусложнять. Это модель, которая…
Борьба со сложностью
В продолжение темы о переусложнениях, которые полюбили делать современные модели, поделюсь своими двумя скиллами, которые помогают с этой самой сложность бороться.
Code That Fits in Your Head
Скилл-дестиллят одноименной книги Марка Симмана, название которой говорит само за себя. Цель скилла: прежде всего, выбор понятных и сопровождаемых решений и их реализации. Начинка довольно сильно адаптирована мною под агентную разработку. Этот скилл я особенно люблю применять когда нужно реализовать какую-то хитрую штуку, которая априори сложная (из моей практики сразу в голову безопасный парсер псевдо-SQL кода, который приходит от агента и преобразуется в безопасный MongoDB query). А более бытовой пример с задачей по ускорению обхода файловой системы на скринах.
—
Ubiquitous Language
Скилл занимается обслуживанием всего, что связано с языком в проекте:
1. Генерирует и поддерживает в актуальном состоянии т. н. тезаурус (docs/THESAURUS. md) - это расширенный словарь понятий с разъяснением неоднозначностей и фиксацией чем понятие является, а с чем его не стоит путать и с какими понятиями оно связано.
Кстати, помимо того, что агенты начинают лучше понимать проект, приятный бонус от тезауруса - это более точные результаты от grep'a.
2. Позволяет агенту выбирать новые имена для сущностей, сервисов и прочих артефаков с оглядкой на этот самый тезаурус и вообще агент больше думает о важности языка и нейминга.
Этот скилл тоже делался на плечах гигантов: в основу был взят блок про Ubiquitous Language из отличной книжки Влада Хононова "Изучаем DDD — предметно-ориентированное проектирование", а также блоки про язык из FPF + ISO 25964 про создание тезаурусов (все сорсы тут).
Оба скилла тем ценнее, чем больше и сложнее проекты с которыми вы работаете.
А еще, к планированию архитектуры и вообще к тому, как наиболее элегантно встроить тот или иной функционал я люблю привлекать Fable (обычно на low или medium reasoning).
И, конечно, никакой скилл не заменит понимание системы и продукта инженером. Собственно, третий этап после скиллов и Fable ревью - это фильтр через человека-инженера (на скринах как раз пример такой пирамиды из 3-х этапов как мы с агентами ищем оптимальный способ ускорить обход файловой системы: 1: анализ плана скиллами, 2: Fable, 3: инженер - это мой-вопрос финальная корректировка: заметьте, что я ее задаю в виде вопроса, давая агенту пространство для несогласия). Выбор наиболее оптимального решения из огромного пространства траекторий - это все еще сложнейшая задача для LLM. Да и для экспертов часто непростая. Почему это важно, вроде, очевидно - сложное и неоптимальное решение обычно более хрупкое - на него будет сожжено больше токенов, а в проде оно с большей вероятностью будет ломаться в разных местах (или эффектом бабочки ломать что-то смежное). Опять же, все это становится острее на масштабе: пока вайб кодишь проект на полтора пользователя, может казаться, что все и без этого прекрасно.
@ai_driven
В продолжение темы о переусложнениях, которые полюбили делать современные модели, поделюсь своими двумя скиллами, которые помогают с этой самой сложность бороться.
Code That Fits in Your Head
Скилл-дестиллят одноименной книги Марка Симмана, название которой говорит само за себя. Цель скилла: прежде всего, выбор понятных и сопровождаемых решений и их реализации. Начинка довольно сильно адаптирована мною под агентную разработку. Этот скилл я особенно люблю применять когда нужно реализовать какую-то хитрую штуку, которая априори сложная (из моей практики сразу в голову безопасный парсер псевдо-SQL кода, который приходит от агента и преобразуется в безопасный MongoDB query). А более бытовой пример с задачей по ускорению обхода файловой системы на скринах.
—
Ubiquitous Language
Скилл занимается обслуживанием всего, что связано с языком в проекте:
1. Генерирует и поддерживает в актуальном состоянии т. н. тезаурус (docs/THESAURUS. md) - это расширенный словарь понятий с разъяснением неоднозначностей и фиксацией чем понятие является, а с чем его не стоит путать и с какими понятиями оно связано.
Кстати, помимо того, что агенты начинают лучше понимать проект, приятный бонус от тезауруса - это более точные результаты от grep'a.
2. Позволяет агенту выбирать новые имена для сущностей, сервисов и прочих артефаков с оглядкой на этот самый тезаурус и вообще агент больше думает о важности языка и нейминга.
Этот скилл тоже делался на плечах гигантов: в основу был взят блок про Ubiquitous Language из отличной книжки Влада Хононова "Изучаем DDD — предметно-ориентированное проектирование", а также блоки про язык из FPF + ISO 25964 про создание тезаурусов (все сорсы тут).
Оба скилла тем ценнее, чем больше и сложнее проекты с которыми вы работаете.
А еще, к планированию архитектуры и вообще к тому, как наиболее элегантно встроить тот или иной функционал я люблю привлекать Fable (обычно на low или medium reasoning).
И, конечно, никакой скилл не заменит понимание системы и продукта инженером. Собственно, третий этап после скиллов и Fable ревью - это фильтр через человека-инженера (на скринах как раз пример такой пирамиды из 3-х этапов как мы с агентами ищем оптимальный способ ускорить обход файловой системы: 1: анализ плана скиллами, 2: Fable, 3: инженер - это мой-вопрос финальная корректировка: заметьте, что я ее задаю в виде вопроса, давая агенту пространство для несогласия). Выбор наиболее оптимального решения из огромного пространства траекторий - это все еще сложнейшая задача для LLM. Да и для экспертов часто непростая. Почему это важно, вроде, очевидно - сложное и неоптимальное решение обычно более хрупкое - на него будет сожжено больше токенов, а в проде оно с большей вероятностью будет ломаться в разных местах (или эффектом бабочки ломать что-то смежное). Опять же, все это становится острее на масштабе: пока вайб кодишь проект на полтора пользователя, может казаться, что все и без этого прекрасно.
@ai_driven
👍25❤9
Вайб-релиз Bun на Rust
На моей памяти это первый настоящий вайб релиз такого масштаба. Помните тот PR команды bun на миллион строк, который им Claude Code сгенерил. Так вот, прошло чуть более 3 месяцев и они зарелизили апдейт для всех. И результаты впечатляют - мало того, что по множеству метрикам ощутимый прирост, так ещё и +1.5к новых тестов с node.js теперь проходят и на bun (это 80.5% всех тестов node.js).
Для меня лично наиболее интересный выигрыш в возможности ускорить тесты в наших проектах на node runtime, ибо с приходом агентной разработки, количество тестов выросло кратко, а выполняться они стали неприлично долго. Попробую обязательно. А если вдруг кто-то уже успел попробовать новый bun - поделитесь в комментариях своим опытом, интересно почитать.
Браво команде bun и Антропикам, их купившим.
https://bun.com/blog/bun-v1.4
@ai_driven
На моей памяти это первый настоящий вайб релиз такого масштаба. Помните тот PR команды bun на миллион строк, который им Claude Code сгенерил. Так вот, прошло чуть более 3 месяцев и они зарелизили апдейт для всех. И результаты впечатляют - мало того, что по множеству метрикам ощутимый прирост, так ещё и +1.5к новых тестов с node.js теперь проходят и на bun (это 80.5% всех тестов node.js).
Для меня лично наиболее интересный выигрыш в возможности ускорить тесты в наших проектах на node runtime, ибо с приходом агентной разработки, количество тестов выросло кратко, а выполняться они стали неприлично долго. Попробую обязательно. А если вдруг кто-то уже успел попробовать новый bun - поделитесь в комментариях своим опытом, интересно почитать.
Браво команде bun и Антропикам, их купившим.
https://bun.com/blog/bun-v1.4
@ai_driven
Bun
Bun 1.4
Bun 1.4 rewrites Bun in Rust, ships built-in headless browser automation (Bun.WebView), Bun.Image, Bun.markdown, JSON5, JSONL, Terminal and cron APIs, Node.js 26.3.0 compatibility with 1,517 newly passing tests, parallel test and run, Windows ARM64, and an…
👍15👎2
Стрим по Jujutsu: решение проблем с git для агентов
Последний месяц я на своих проектах активно работаю с Jujutsu (JJ) - современной VCS от Google. Это довольно интересная попытка переизобрести Git и часть его особенностей довольно хорошо ложатся на агентную разработку и решают часть ее проблем.
Например:
- Конфликтные состояния допустимы - то есть, в истории реально могут лежать конфликты, которые вы с агентами сможете решить тогда, когда вам будет удобно
- Возможность легко двигать, сплитить и пересобирать коммиты
- Еще, там нет понятия unstaged - все, что агенты делают по умолчанию попадает в - это решает проблему потерянных изменений
Но есть и разные подводные камни, которые могут мешать привычной работе и их нужно заранее предусмотреть. В общем, мне решение показалось интересным, поэтому я решил рассказать о нем вам и организовать встречу. В кач-ве эксперта я позвал Федора Шереметьева - он 2 года работает с JJ, и даже сделал свой продукт VisualJJ для более наглядной работы с Jujutsu. Федор поделится своим флоу агентной разработки с jj и расскажет нам о том, как там все устроено.
Дата: сегодня в 13:00 по МСК, 11:00 по Лондону и 15:00 по Алматы.
Ссылка на стрим в YouTube.
Еще, мне удалось выловить Макса Шапошникова из DeepMind поэтому,в эту субботу проведем стрим про агентную разработку и немного про карьеру, так что следите за анонсами в канале и ставьте колокольчики. Upd: Перенесли на сентябрь, следите за анонсами.
@ai_driven
Последний месяц я на своих проектах активно работаю с Jujutsu (JJ) - современной VCS от Google. Это довольно интересная попытка переизобрести Git и часть его особенностей довольно хорошо ложатся на агентную разработку и решают часть ее проблем.
Например:
- Конфликтные состояния допустимы - то есть, в истории реально могут лежать конфликты, которые вы с агентами сможете решить тогда, когда вам будет удобно
- Возможность легко двигать, сплитить и пересобирать коммиты
- Еще, там нет понятия unstaged - все, что агенты делают по умолчанию попадает в - это решает проблему потерянных изменений
Но есть и разные подводные камни, которые могут мешать привычной работе и их нужно заранее предусмотреть. В общем, мне решение показалось интересным, поэтому я решил рассказать о нем вам и организовать встречу. В кач-ве эксперта я позвал Федора Шереметьева - он 2 года работает с JJ, и даже сделал свой продукт VisualJJ для более наглядной работы с Jujutsu. Федор поделится своим флоу агентной разработки с jj и расскажет нам о том, как там все устроено.
Дата: сегодня в 13:00 по МСК, 11:00 по Лондону и 15:00 по Алматы.
Ссылка на стрим в YouTube.
Еще, мне удалось выловить Макса Шапошникова из DeepMind поэтому,
@ai_driven
YouTube
Jujutsu: решение проблем с Git для агентов — с Фёдором Шереметьевым
Последний месяц я активно использую Jujutsu (JJ) — современную систему контроля версий от Google — в агентной разработке.
Обсудим, почему некоторые особенности JJ хорошо подходят для работы с кодовыми агентами:
• конфликтные состояния допустимы и могут…
Обсудим, почему некоторые особенности JJ хорошо подходят для работы с кодовыми агентами:
• конфликтные состояния допустимы и могут…
👍15❤5
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5
Периодически натыкаюсь на разные исследования о том, что в среднем AI не повышает эффективность разработки, что часть команд получают существенный буст, а другая часть наоборот замедляется, да и на моих консультациях это довольно распространенная проблема. Так вот, понятно, что во внедрении AI в существующие процессы и команды разработки куча нюансов и это комплексный процесс, требующий системного подхода и изучения - самостоятельного (больше шишек) либо с условным наставником, который уже успел пройти этот путь (меньше шишек, быстрее профит).
Но менее очевидно другое - при внедрении такого мощного бустера, как AI замедление на начальных этапах вполне естественно. Грубо это можно сравнить с тем, как раньше все в вашем городе передвигались на велосипедах и тут все (или не все) резко пересели на автомобили, не успев получить права - да, первое время будет много аварий, но постепенно команда учится на этих ошибках и движение на дорогах сначала нормализуется, затем ускоряется (особенно, при наличии грамотного регулировщика).
Главное только в течение этого процесса не расфигачить город (сломать продукт) и не растерять водителей от травм, не совместимых с жизнью.
А как у вас в команде обстоят дела с перфомансом после внедрения агентной разработки? И как вы этот перфоманс измеряете?
@ai_driven
Но менее очевидно другое - при внедрении такого мощного бустера, как AI замедление на начальных этапах вполне естественно. Грубо это можно сравнить с тем, как раньше все в вашем городе передвигались на велосипедах и тут все (или не все) резко пересели на автомобили, не успев получить права - да, первое время будет много аварий, но постепенно команда учится на этих ошибках и движение на дорогах сначала нормализуется, затем ускоряется (особенно, при наличии грамотного регулировщика).
Главное только в течение этого процесса не расфигачить город (сломать продукт) и не растерять водителей от травм, не совместимых с жизнью.
А как у вас в команде обстоят дела с перфомансом после внедрения агентной разработки? И как вы этот перфоманс измеряете?
@ai_driven
👍9🦄2
Нюансы Fable 5.1 в SWE задачах
В системной карточке Fable 5.1 (которая аж на 212 страниц) как обычно можно найти множество интересных инсайтов. Вот что мне показалось интересным:
* Нынче один самых важных вопросов - а какой reasoning effort оптимален? Тк мы видим из бенчей, что он напрямую влияет на цену, а значит и на то, как быстро будут уходить лимиты. Кроме того, на некоторых бенчах можно заметить, что более высокий effort ухудшает результаты моделей. Так, например, во FrontierCode (Main субсет) результаты Fable 5.1 после medium не становятся лучше. А если сравнивать medium vs max, то получим 50.9% vs 50.3%, при том, что medium почти в 5 раз дешевле max. Кроме того, в этом бенче Fable 5.1 medium даже вышел дешевле, чем Opus 5 medium, хоть и с чуть более скромным результатом (50.9 vs 53.4), что тоже слегка удивляет. А в карточке Антропик по этому поводу пишут, что на высоком ризонинге фейбл 5.1 начинает делать больше, чем ее просили. И пишут:
Напомню на всякий случай, что FrontierCode 1.1 от команды Devin - это один из немногих закрытых бенчмарков.
* Результаты Fable 5.1 в DeepSWE v1.1: 67.4%. Но есть важный нюанс:
Антропики рапортают, что Фейбл сделала часть задач даже тщательнее, чем того требовало задание, поэтому часть скрытых тестов завалились (стр. 168).
* В DRACO (это бенчмарк на диприсерч от Perplexity), опус 5 почти на всех эффортах сильнее Fable 5.1 - вот и думайте) Любопытно, кстати, что у них там Opus 4.6 в кач-ве судьи над Опусом и другими - мб в этом дело.
* И ресерчеры из METR говорят, Fable 5.1 особенно сильна, когда у задачи есть понятный фидбек. Но когда надо самому придумать, что проверять, куда копать дальше и как вообще выстроить исследование, всё заметно хуже. Вот вам и long-horzont tasks... Все равно, нужно четко критерии ставить и послеживать, чтобы не дрейфовала.
Из забавного: на моей памяти впервые Антропик замерили свои модели на бенчмарке FrontierSWE (ага, еще один фронтир - он, к слову, старее всех остальных фронтиров), это бенчмаре на ультра-большие задачи на десятки а то и сотни тысяч LoC, тем самым как бы легализовав его. Получилось вот так: Fable 5.1 (0.57), Claude Opus 5 (0.52), Claude Fable 5 (0.48), GPT-5.6 Sol (0.32). Что забавного? 1. В первой версии их бенчмарка грок 4.5 как-то оказался выше опус 4.8, при том, что грок 4.5 - модель откровенно слабая. 2. Вторая версия бенчмарка пока недоступна нигде, а ссылка из System Card показыват 404. Видимо, ребята тормозят с релизом.
И немаловажный нюанс: cutoff date Fable 5.1 июнь 2026, а Opus 5 май 2026. При этом, знания GPT 5.6 sol заканчиваются на фервале 2026. Что нам с этого? То, что всякие современные знания про разработку агентнов и агентную разработку из коробки будут актуальнее всего у Fable 5.1. А по моему опыту агенты очень плохо пишут других агентов (если они хоть немного нестандартные).
Какой я для себя делаю вывод? Для большинства задач в Claude Code, видимо, продолжу использовать Opus medium, для планирования и второго мнения Fable 5.1 medium, а для чего-то особого сложного Fable 5.1 xhigh.
@ai_driven
В системной карточке Fable 5.1 (которая аж на 212 страниц) как обычно можно найти множество интересных инсайтов. Вот что мне показалось интересным:
* Нынче один самых важных вопросов - а какой reasoning effort оптимален? Тк мы видим из бенчей, что он напрямую влияет на цену, а значит и на то, как быстро будут уходить лимиты. Кроме того, на некоторых бенчах можно заметить, что более высокий effort ухудшает результаты моделей. Так, например, во FrontierCode (Main субсет) результаты Fable 5.1 после medium не становятся лучше. А если сравнивать medium vs max, то получим 50.9% vs 50.3%, при том, что medium почти в 5 раз дешевле max. Кроме того, в этом бенче Fable 5.1 medium даже вышел дешевле, чем Opus 5 medium, хоть и с чуть более скромным результатом (50.9 vs 53.4), что тоже слегка удивляет. А в карточке Антропик по этому поводу пишут, что на высоком ризонинге фейбл 5.1 начинает делать больше, чем ее просили. И пишут:
Если дополнительно попросить модель быть лаконичнее и не добавлять лишние комментарии или документацию, она реже вносит изменения вне заданного scope. Но опубликованные benchmark-результаты получены без такой дополнительной инструкции.
Напомню на всякий случай, что FrontierCode 1.1 от команды Devin - это один из немногих закрытых бенчмарков.
* Результаты Fable 5.1 в DeepSWE v1.1: 67.4%. Но есть важный нюанс:
Антропики рапортают, что Фейбл сделала часть задач даже тщательнее, чем того требовало задание, поэтому часть скрытых тестов завалились (стр. 168).
* В DRACO (это бенчмарк на диприсерч от Perplexity), опус 5 почти на всех эффортах сильнее Fable 5.1 - вот и думайте) Любопытно, кстати, что у них там Opus 4.6 в кач-ве судьи над Опусом и другими - мб в этом дело.
* И ресерчеры из METR говорят, Fable 5.1 особенно сильна, когда у задачи есть понятный фидбек. Но когда надо самому придумать, что проверять, куда копать дальше и как вообще выстроить исследование, всё заметно хуже. Вот вам и long-horzont tasks... Все равно, нужно четко критерии ставить и послеживать, чтобы не дрейфовала.
Из забавного: на моей памяти впервые Антропик замерили свои модели на бенчмарке FrontierSWE (ага, еще один фронтир - он, к слову, старее всех остальных фронтиров), это бенчмаре на ультра-большие задачи на десятки а то и сотни тысяч LoC, тем самым как бы легализовав его. Получилось вот так: Fable 5.1 (0.57), Claude Opus 5 (0.52), Claude Fable 5 (0.48), GPT-5.6 Sol (0.32). Что забавного? 1. В первой версии их бенчмарка грок 4.5 как-то оказался выше опус 4.8, при том, что грок 4.5 - модель откровенно слабая. 2. Вторая версия бенчмарка пока недоступна нигде, а ссылка из System Card показыват 404. Видимо, ребята тормозят с релизом.
И немаловажный нюанс: cutoff date Fable 5.1 июнь 2026, а Opus 5 май 2026. При этом, знания GPT 5.6 sol заканчиваются на фервале 2026. Что нам с этого? То, что всякие современные знания про разработку агентнов и агентную разработку из коробки будут актуальнее всего у Fable 5.1. А по моему опыту агенты очень плохо пишут других агентов (если они хоть немного нестандартные).
Какой я для себя делаю вывод? Для большинства задач в Claude Code, видимо, продолжу использовать Opus medium, для планирования и второго мнения Fable 5.1 medium, а для чего-то особого сложного Fable 5.1 xhigh.
@ai_driven
1👍17❤4
Как вам Астра? Я пробую ей давать небольшие баг фиксы на минимальном ризонинге и она работает очень быстро и делает хорошо. Ловлю приятное ощущение, что теперь кучу хвостов можно позакрывать быстро и хорошо (надеюсь, ощущение не обманчиво).
Баги исправляются в одном из моих легаси проектов, который я развиваю еще с 2012 года и он ни разу не AI ready (разве что визуальный фидбек настроен). В общем, пока выглядит так, что low (light) ризонинга вполне достаточно для большинства задач, что и бенчмарки подтверждают - DeepSWE, FrontierCode.
Единственное что удручает так это быстрый расход лимитов - даже на моей 200$ подписке. С другой же стороны, когда довольно быстро получаешь ожидаемый результат, то может оно того и стоит.
Кстати, с более сложной задачей по качественному RAG по большей базе нормативов пока не справилась ни Fable 5.1 max, ни Astra pro - в очередной раз убеждаюсь насколько тяжело до сих пор заодн даже современным моделям разрабатывать сложных агентов, когда нужна предельная точность в ответах.
Upd: подписчик про интересный кейс с голосовым управлением рассказал - https://t.me/ai_driven_chat/4905
Как у вас ощущения от Астры? Согласны, что low теперь достаточен для большинства задач?
@ai_driven
Баги исправляются в одном из моих легаси проектов, который я развиваю еще с 2012 года и он ни разу не AI ready (разве что визуальный фидбек настроен). В общем, пока выглядит так, что low (light) ризонинга вполне достаточно для большинства задач, что и бенчмарки подтверждают - DeepSWE, FrontierCode.
Единственное что удручает так это быстрый расход лимитов - даже на моей 200$ подписке. С другой же стороны, когда довольно быстро получаешь ожидаемый результат, то может оно того и стоит.
Кстати, с более сложной задачей по качественному RAG по большей базе нормативов пока не справилась ни Fable 5.1 max, ни Astra pro - в очередной раз убеждаюсь насколько тяжело до сих пор заодн даже современным моделям разрабатывать сложных агентов, когда нужна предельная точность в ответах.
Upd: подписчик про интересный кейс с голосовым управлением рассказал - https://t.me/ai_driven_chat/4905
Как у вас ощущения от Астры? Согласны, что low теперь достаточен для большинства задач?
@ai_driven
Telegram
Mike in Чат AI-Driven Development
Голосовой попробуйте, песня просто. Кстати в голосовом это та же астра и он может быть теперь активирован в любом чате. Но я решил создать проект оркестратор где в одном чате с голосового хочу попробовать оркестрировать другие проекты. Он умеет передать задачу…
❤4👍2