AI-Driven Development. Родион Мостовой
Агентам не нужен TDD Дядя Боб говорит, что TDD вообще-то для людей и агентам совсем не обязателен, ведь у агента дела с краткосрочной памятью обстоят куда лучше, чем у людей. А что нужно агентам по его мнению? Юнит тест, CRAP метрика и мутационное тестирование...…
Какой-то баг с реациями в ТГ случился (навайбкодили опять) и были доступны только дизлайки и сомнения, поэтому мы с дядей Бобом собрали рекордное кол-во дизайков под постом, я еще начал думать, что никто уже не читает такие "длинные" посты до конца. Короче, если вы хотели отреагировать как-то иначе - теперь можно. А еще лучше - подключайтесь к дискусси, тк дебаты разгорелись нехилые в комментариях...
😁21🎉3👍2🤔2🤯1
Важность исследования контекста
Тема заезженная, но я сейчас кодю с 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_driven
Тема заезженная, но я сейчас кодю с 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_driven
👍26🤯5👎3❤1
Не все мне нравится в UX десктопной версии Claude Code, но надо отдать им должное - фича просмотра прототипов прямо в диалоге Claude Code просто бомбическая.
Раньше для этого требовалось просить сгенерить HTML, и отдельно открывать ее в браузере - не очень удобно.
Напомню, что прототип - это супер крутой и быстрый способ еще до того, как агент написал хоть строку кода, посмотреть как будет выглядит результат и направить . С точки зрения UI/UX важнейшая штука.
Там же можно по нажатию на три точки скопировать прототип сразу в виде картинки.
Еще можно прямо в вариантах прототипа просить агента оценивать объем работы, потенциальный blast radius и риски по каждому варианту.
На скрине CC очень быстро воспроизвел UI чата CodeAlive и отобразил его в виде виджета прямо в диалоге с агентом.
Upd: В комментариях подписчик подсказал, что Codex теперь тоже такое умеет - тригерится через скилл visualize. Будем юзать. Из интересного: можно прототип сразу в виде live сайта опубликовать или скопировать в виде изображения.
@ai_driven
Раньше для этого требовалось просить сгенерить HTML, и отдельно открывать ее в браузере - не очень удобно.
Напомню, что прототип - это супер крутой и быстрый способ еще до того, как агент написал хоть строку кода, посмотреть как будет выглядит результат и направить . С точки зрения UI/UX важнейшая штука.
Там же можно по нажатию на три точки скопировать прототип сразу в виде картинки.
Еще можно прямо в вариантах прототипа просить агента оценивать объем работы, потенциальный blast radius и риски по каждому варианту.
На скрине CC очень быстро воспроизвел UI чата CodeAlive и отобразил его в виде виджета прямо в диалоге с агентом.
Upd: В комментариях подписчик подсказал, что Codex теперь тоже такое умеет - тригерится через скилл visualize. Будем юзать. Из интересного: можно прототип сразу в виде live сайта опубликовать или скопировать в виде изображения.
@ai_driven
👍12
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_driven
Собственно, похоже, что 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_driven
1👍16❤10🎉2
/btw на максималках или Codex side chat
Продолжаем рубрику подборка лучших UX решений.
Когда кодишь с агентом довольно часто возникает ситуация, когда из одного чата нужно быстро форкнуться в новый чат, чтобы исправить что-то, возникшее по пути, не прерывая работы в старом чате. Раньше мы использовали fork для этих целей, но форк довольно тяжеловесный + не из всех состояний он доступен. В общем, если выделить текст в прямо чате Codex App'а, то сверху можно увидеть всплывающее меню с разными действмия, в т. ч. Ask in side chat. Наверное, видели. Можно подумать, что это старый добрый
Напомню, что ранее я уже рассказывал про неочевидную удобную возможность реордеринга (как это по русски подскажите в комментариях) очереди сообщений в Codex App. Если не видели - посмотрите.
А еще, теперь можно попросить Codex App запустить какую-то задачу в новом диалоге и он прям из текущего чата спавнет вам новый диалог. И читать сторонние или текущий диалог Codex App теперь тоже умеет. Подробнее про то, как это работает рассказывал Тимур.
И да, в Claude Code Desktop тоже есть подобный side chat, но он readonly, что не так интересно, хоть и удобно иногда что-то доспросить.
@ai_driven
Продолжаем рубрику подборка лучших UX решений.
Когда кодишь с агентом довольно часто возникает ситуация, когда из одного чата нужно быстро форкнуться в новый чат, чтобы исправить что-то, возникшее по пути, не прерывая работы в старом чате. Раньше мы использовали fork для этих целей, но форк довольно тяжеловесный + не из всех состояний он доступен. В общем, если выделить текст в прямо чате Codex App'а, то сверху можно увидеть всплывающее меню с разными действмия, в т. ч. Ask in side chat. Наверное, видели. Можно подумать, что это старый добрый
/btw а-ля клод код. Но нет, на деле у этого сайд чата тоже есть полноценный write доступ и из него действительно можно делать небольшие правки (например, в скиллах, как на скрине) прямо по ходу основной задачи, вообще никак в нее не вмешиваясь. Не знаю как вам, но мне не хватало такой возможности - настолько, что решил и вам рассказать.Напомню, что ранее я уже рассказывал про неочевидную удобную возможность реордеринга (как это по русски подскажите в комментариях) очереди сообщений в Codex App. Если не видели - посмотрите.
А еще, теперь можно попросить Codex App запустить какую-то задачу в новом диалоге и он прям из текущего чата спавнет вам новый диалог. И читать сторонние или текущий диалог Codex App теперь тоже умеет. Подробнее про то, как это работает рассказывал Тимур.
И да, в Claude Code Desktop тоже есть подобный side chat, но он readonly, что не так интересно, хоть и удобно иногда что-то доспросить.
@ai_driven
1👍14❤5
"Делай хорошо" или антипромптинг Sol
Накипело.
Помните мы раньше просили модели делать хорошо, учитывать корнер кейсы и тд?
Так вот, как минимум с GPT 5.6 Sol настало время наоборот просить агента не делать лишнего и не переусложнять. Это модель, которая по дефолту будет учитывать и обрабатывать маргинальные корнер кейсы, вероятность которых примерно отрицательная. Она делает кучу бекапов, проб и тд, даже когда это вообще не нужно - ее тупо приходится бить по рукам (пример на скрине).
Если раньше мы промптили "делай хорошо, до конца и тд", то теперь актуальнее "не переусложняй, найди элегантное решение, сейчас нам хватит MVP и тд". Промптинг в обратную сторону получается.
Еще раз нам всем урок важности передачи высокоуровневого контекста агенту - что за проект, какова его ценность для пользователей, кто пользователи, сколько их вообще планируется, профиль нагрузки и тд. Дефолты Sol оказались слишком "энтепрайзными", именно поэтому она тратить условно 10 часов на то, что другие современные модели сделают за час. Зато в ревью критически важного кода, в котором действительно необходимо учесть все все все корнер кейсы она чертовски хороша (и Opus 5, кстати, тоже).
В общем, теперь Sol из планера и (иногда) воркера превращается для меня в модель-консультанта по оптимизациям и код ревьюера (обязательно с перепроверкой адекватности находок через судью).
А что касается поиска оптимальных решений, то это я делаю в паре с Fable. Она мне представляется как раз наиболее мудрой моделью.
PS Перфекционизм страшная штука, от него я сам лечусь, а теперь еще и модели приходится лечить.
@ai_driven
Накипело.
Помните мы раньше просили модели делать хорошо, учитывать корнер кейсы и тд?
Так вот, как минимум с GPT 5.6 Sol настало время наоборот просить агента не делать лишнего и не переусложнять. Это модель, которая по дефолту будет учитывать и обрабатывать маргинальные корнер кейсы, вероятность которых примерно отрицательная. Она делает кучу бекапов, проб и тд, даже когда это вообще не нужно - ее тупо приходится бить по рукам (пример на скрине).
Если раньше мы промптили "делай хорошо, до конца и тд", то теперь актуальнее "не переусложняй, найди элегантное решение, сейчас нам хватит MVP и тд". Промптинг в обратную сторону получается.
Еще раз нам всем урок важности передачи высокоуровневого контекста агенту - что за проект, какова его ценность для пользователей, кто пользователи, сколько их вообще планируется, профиль нагрузки и тд. Дефолты Sol оказались слишком "энтепрайзными", именно поэтому она тратить условно 10 часов на то, что другие современные модели сделают за час. Зато в ревью критически важного кода, в котором действительно необходимо учесть все все все корнер кейсы она чертовски хороша (и Opus 5, кстати, тоже).
В общем, теперь Sol из планера и (иногда) воркера превращается для меня в модель-консультанта по оптимизациям и код ревьюера (обязательно с перепроверкой адекватности находок через судью).
А что касается поиска оптимальных решений, то это я делаю в паре с Fable. Она мне представляется как раз наиболее мудрой моделью.
PS Перфекционизм страшная штука, от него я сам лечусь, а теперь еще и модели приходится лечить.
@ai_driven
👍21💯10❤5🤔2
Друзья нашего канала в компании с Андреем Бреславом сейчас будут обсуждать как писать код с агентами - такое смотрим с удовольствием
Forwarded from Константин Доронин
Мы начинаем наш стрим "Как писать код с AI-агентами?"
Подключайтесь по ссылке: https://youtube.com/live/x0j1kcagoXg
Подключайтесь по ссылке: https://youtube.com/live/x0j1kcagoXg
YouTube
Как писать код с AI-агентами?
Страница донатов: https://www.donationalerts.com/r/kdoronin
Подписывайтесь на TG-каналы участников эфира:
Валерий Ковальский – https://t.me/neuraldeep
Максим Ключников – https://t.me/etechlead
Константин Доронин – https://t.me/kdoronin_blog
Подписывайтесь на TG-каналы участников эфира:
Валерий Ковальский – https://t.me/neuraldeep
Максим Ключников – https://t.me/etechlead
Константин Доронин – https://t.me/kdoronin_blog
👍6❤2
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
👍23❤8