⚪️ OpenRouter Fusion
Интересную штуку сделали OpenRouter - Fusion называется. Работает так: есть "модель" openrouter/fusion который выглядит как обычная модель. Внутри вы настраиваете основную модель, которая генерирует итоговый ответ, а также "панель моделей". Рутер именно такой термин использует, а по мне он весьма смешной, "модели на панели". Но альтернативы которые я слышал - это "ансамбль" моделей (весьма отдает фрактальным промптингом), ну или "совет" моделей. Хорошего русского прижившегося термина нету. Пусть будет "панель".
В панель вы можете включить несколько моделей, по умолчагнию - три штуки, максимум - 8. Они получают задание от вашей главной модели через вызов тула openrouter:fusion, можно сделать вызов обязательным.
Тул openrouter:fusion исполняется так: fan out агентный запрос, параллельно каждая модель из панели выполняет запрос, ей выданы инструменты openrouter:web_search , openrouter:web_fetch, дан бюджет на количество ходов и вызовов тулов, установлен ризонинг и температура. Рекурсию делать нельзя.
потом делаем fan in на модель-судью. Судья НЕ ПРОСТО делает синтез ответа - он возвращает структурированный ответ: в чем модели согласились, где были спорные моменты, инсайты из ответов каждой модели и слепые зоны, которрые остались не покрыты никем. Также возвращаются полны еиндивидуальные ответы. Я бы сказал, что это ответ не судьи, а структурированный отчет.
🔗 Попробовать плейграунд: https://openrouter.ai/fusion
🔗 Почитать про fusion "модель": https://openrouter.ai/docs/guides/routing/routers/fusion-router
🔗 Серверный тул fusion : https://openrouter.ai/docs/guides/features/server-tools/fusion
Итак, опенроутер изобрел мульти-модель. Т акими темпами они еще и до мульти-семплинга дойдут, и до фокусной аспектной проработки. Но - не все сразу, да?)
Результаты: на мой взгляд, охренительно. Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro (fusion) дают результаты чуть хуже Falbe 5 solo (замеры на DRACO deep research benchmark by Perplexity) - график на картинке КДПВ.
🔗 Про бенчмарк: https://arxiv.org/abs/2602.11685
Ценник очевиден: 1 модель синтезирует ответ, 3 модели дают ответы в панели, 1 модель судит. Итого х5 цены! но при текущей разнице фронтира и китов - панель китов на 50% дешевле фубли выходила.
Мне понравилась идея прятать систему за модулью через роутер. Задумался))
(ц) оч интересно
@deksden_notes
Интересную штуку сделали OpenRouter - Fusion называется. Работает так: есть "модель" openrouter/fusion который выглядит как обычная модель. Внутри вы настраиваете основную модель, которая генерирует итоговый ответ, а также "панель моделей". Рутер именно такой термин использует, а по мне он весьма смешной, "модели на панели". Но альтернативы которые я слышал - это "ансамбль" моделей (весьма отдает фрактальным промптингом), ну или "совет" моделей. Хорошего русского прижившегося термина нету. Пусть будет "панель".
В панель вы можете включить несколько моделей, по умолчагнию - три штуки, максимум - 8. Они получают задание от вашей главной модели через вызов тула openrouter:fusion, можно сделать вызов обязательным.
Тул openrouter:fusion исполняется так: fan out агентный запрос, параллельно каждая модель из панели выполняет запрос, ей выданы инструменты openrouter:web_search , openrouter:web_fetch, дан бюджет на количество ходов и вызовов тулов, установлен ризонинг и температура. Рекурсию делать нельзя.
потом делаем fan in на модель-судью. Судья НЕ ПРОСТО делает синтез ответа - он возвращает структурированный ответ: в чем модели согласились, где были спорные моменты, инсайты из ответов каждой модели и слепые зоны, которрые остались не покрыты никем. Также возвращаются полны еиндивидуальные ответы. Я бы сказал, что это ответ не судьи, а структурированный отчет.
🔗 Попробовать плейграунд: https://openrouter.ai/fusion
🔗 Почитать про fusion "модель": https://openrouter.ai/docs/guides/routing/routers/fusion-router
🔗 Серверный тул fusion : https://openrouter.ai/docs/guides/features/server-tools/fusion
Итак, опенроутер изобрел мульти-модель. Т акими темпами они еще и до мульти-семплинга дойдут, и до фокусной аспектной проработки. Но - не все сразу, да?)
Результаты: на мой взгляд, охренительно. Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro (fusion) дают результаты чуть хуже Falbe 5 solo (замеры на DRACO deep research benchmark by Perplexity) - график на картинке КДПВ.
🔗 Про бенчмарк: https://arxiv.org/abs/2602.11685
Ценник очевиден: 1 модель синтезирует ответ, 3 модели дают ответы в панели, 1 модель судит. Итого х5 цены! но при текущей разнице фронтира и китов - панель китов на 50% дешевле фубли выходила.
Мне понравилась идея прятать систему за модулью через роутер. Задумался))
(ц) оч интересно
@deksden_notes
1🔥25👍10❤4
Forwarded from ABI
Обновление bash-скрипта для кастомизации статус-бара в Antigravity CLI. 🚀
Интерфейс там консольный (TUI), поэтому раскрасить вывод ANSI-кодами не вышло, зато получилось аккуратно вытащить через jq всю самую важную стату из JSON-плейлоада:
🤖 Текущую модель и тир подписки
🔄 Статус агента (idle, etc.)
📉 Детальный расход токенов (Контекст ↓ / Вывод ↑)
📊 Процент использования контекстного окна
Теперь перед глазами всегда понятно, сколько контекста сожрала сессия и сколько еще осталось, всё в одну компактную строку. Видно все модели и лимиты 5h/1w.
Закинул исходник в Gist, кому актуально для работы с LLM — забирайте:
https://gist.github.com/ABIvan-Tech/1c979e29a378a67b88a313dfaee18464
#opensource
Интерфейс там консольный (TUI), поэтому раскрасить вывод ANSI-кодами не вышло, зато получилось аккуратно вытащить через jq всю самую важную стату из JSON-плейлоада:
🤖 Текущую модель и тир подписки
🔄 Статус агента (idle, etc.)
📉 Детальный расход токенов (Контекст ↓ / Вывод ↑)
📊 Процент использования контекстного окна
Теперь перед глазами всегда понятно, сколько контекста сожрала сессия и сколько еще осталось, всё в одну компактную строку. Видно все модели и лимиты 5h/1w.
Закинул исходник в Gist, кому актуально для работы с LLM — забирайте:
https://gist.github.com/ABIvan-Tech/1c979e29a378a67b88a313dfaee18464
#opensource
👍14🔥2
thegod shop - магазин по продаже подписок на нейросети по самым дешевым ценам!
✨ Gemini Pro 18m. - от 99р.
⭐️ Kiro Pro+ (12k cred.) - от 500р.
🤖 Super Grok - от 200р.
💬 Chat GPT Plus - от 240р.
зачем переплачивать когда можно взять тут за копейки?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤4👀4
Media is too big
VIEW IN TELEGRAM
⚪️ Kimi Code 2.7 ⚡️HIGHSPEED⚡️
Релиз анонсирвоанной при запуске фичи - х6 скорость. На практике получается от 150 до 260 tps в зависимости от сложности / размера задачи
Доступ раскатывают участникам Kimi Beta Program, в API, и для Kimi Business. Для обычного Kimi Code Plan пока нету - записывайтесь в Beta программу.
200 tps - это, конечно, другой опыт.
Ценники на апи - в табличке в комментах ⬇️ (х2)
@deksden_notes
Релиз анонсирвоанной при запуске фичи - х6 скорость. На практике получается от 150 до 260 tps в зависимости от сложности / размера задачи
Доступ раскатывают участникам Kimi Beta Program, в API, и для Kimi Business. Для обычного Kimi Code Plan пока нету - записывайтесь в Beta программу.
200 tps - это, конечно, другой опыт.
Ценники на апи - в табличке в комментах ⬇️ (х2)
@deksden_notes
🔥19👍3⚡3❤1
⚪️ Xiaomi MiMo UltraSpeed
Тут вторая новость про высокоскоростную генерацию - вот Сяоми предлагает бэту своего высокоскоростного решения. Анонсировано 1000 tps - это прям оч быстро.
интересная тенденция!
🔗 Записть тут : https://platform.xiaomimimo.com/ultraspeed
🔗 Промик живет тут в карусели, первый слайд: https://mimo.mi.com/docs/en-US/quick-start/summary/welcome
@deksden_notes
Тут вторая новость про высокоскоростную генерацию - вот Сяоми предлагает бэту своего высокоскоростного решения. Анонсировано 1000 tps - это прям оч быстро.
интересная тенденция!
🔗 Записть тут : https://platform.xiaomimimo.com/ultraspeed
🔗 Промик живет тут в карусели, первый слайд: https://mimo.mi.com/docs/en-US/quick-start/summary/welcome
@deksden_notes
👍4
⚪️ Расценки для Claude -p / Agents SDK
Мы все помним как в мае антропики всех "обрадовали" что с 15 июня програмное использование их агента - Claude -p или Agents SDK (который поверх claude -p) будет расцениваться по апи ценам с баланса счета over usage.
Это автоматически убивает все продукты, построенные сверху SDK.
15 июня, на секундочку, настало ВЧЕРА. ТАК ВОТ! "Фраер сдал назад"!
Антропики ТИХО разослали клиентам рассылочку, что передумали, и использврание claude -p / Agents SDK по-прежнему будет идти с подписки.
Если вы клиент - посомтрите почту!
Хорошая новость, так то! Но то, что она так "тихо" анаонсирована - вызывает какие то смутные подозрения про будущее.
(ц) Посмотрим
@deksden_notes
Мы все помним как в мае антропики всех "обрадовали" что с 15 июня програмное использование их агента - Claude -p или Agents SDK (который поверх claude -p) будет расцениваться по апи ценам с баланса счета over usage.
Это автоматически убивает все продукты, построенные сверху SDK.
15 июня, на секундочку, настало ВЧЕРА. ТАК ВОТ! "Фраер сдал назад"!
Антропики ТИХО разослали клиентам рассылочку, что передумали, и использврание claude -p / Agents SDK по-прежнему будет идти с подписки.
Если вы клиент - посомтрите почту!
Хорошая новость, так то! Но то, что она так "тихо" анаонсирована - вызывает какие то смутные подозрения про будущее.
(ц) Посмотрим
@deksden_notes
👏9🔥4
Forwarded from A M
если интересно, то можно расшарить пост -
Провел небольшой A/B-тест моделей Spark, mini и 5.5-medium на реальной задаче обогащения базы своего теннисного сайта.
Зачем: у нас большой объем data scraping и обработки фактов, и хотелось понять, можно ли снизить расход токенов за счет дешевых subagents без потери качества. Как известно, у Spark отдельные лимиты и в теории выглядит очень привлекательно использовать его для простых data scraping задач.
Задача была такая: извлечь source-backed данные с официальных страниц академий: контакты, цены, лагеря/программы, затем сохранить raw JSONL для строгой проверки перед добавлением в базу.
Итог: Spark не подходит как дефолтный worker для такого workflow.
Почему:
Хрупкий в длинных тредах
Spark один раз упал на скрытом ограничении контекста/инструментов, и его пришлось перезапускать с fork_context=false. Для автономных batch-задач это риск.
Слабая дисциплина схемы
Все модели немного отклонялись от заданного формата, но Spark чаще уходил от нужной vocabulary для type/status. Его выход нельзя считать готовым к выдаче в базу.
Плохо подходит для broad discovery
Spark нормален, если есть точный URL и очень маленькая задача: например, “достань email и телефон с этой страницы”. Но он слабее, когда надо ходить по ссылкам, отличать официальный сайт от third-party, разбирать неоднозначные цены или отделять настоящие academy facts от общей информации о клубе/кортах.
Экономия токенов может исчезнуть на QA
Если main agent потом тратит много времени на исправление слабого extraction, отклонение vague facts и починку malformed JSONL, выгода от дешевой модели быстро уменьшается.
Текущий routing после теста:
Spark — только для очень маленьких exact-URL, text-only задач или bounded QA. Короткий prompt, fork_context=false.
5.5-mini — дефолтный worker для обычных небольших batch-задач, если official URLs уже известны.
5.5 medium — для сложных случаев: non-English pages, PDFs, несколько связанных официальных страниц, booking/form gates, contact repair, ambiguity.
Главный вывод: дешевые subagents должны генерировать только raw candidates. Main agent все равно делает строгую нормализацию, duplicate checks, helper dry-run и только потом promotion.
То есть Spark не бесполезен, но как general scraping/research agent он ОЧЕНЬ слабый. Это узкий инструмент для простого extraction, а не надежный enrichment worker.
Провел небольшой A/B-тест моделей Spark, mini и 5.5-medium на реальной задаче обогащения базы своего теннисного сайта.
Зачем: у нас большой объем data scraping и обработки фактов, и хотелось понять, можно ли снизить расход токенов за счет дешевых subagents без потери качества. Как известно, у Spark отдельные лимиты и в теории выглядит очень привлекательно использовать его для простых data scraping задач.
Задача была такая: извлечь source-backed данные с официальных страниц академий: контакты, цены, лагеря/программы, затем сохранить raw JSONL для строгой проверки перед добавлением в базу.
Итог: Spark не подходит как дефолтный worker для такого workflow.
Почему:
Хрупкий в длинных тредах
Spark один раз упал на скрытом ограничении контекста/инструментов, и его пришлось перезапускать с fork_context=false. Для автономных batch-задач это риск.
Слабая дисциплина схемы
Все модели немного отклонялись от заданного формата, но Spark чаще уходил от нужной vocabulary для type/status. Его выход нельзя считать готовым к выдаче в базу.
Плохо подходит для broad discovery
Spark нормален, если есть точный URL и очень маленькая задача: например, “достань email и телефон с этой страницы”. Но он слабее, когда надо ходить по ссылкам, отличать официальный сайт от third-party, разбирать неоднозначные цены или отделять настоящие academy facts от общей информации о клубе/кортах.
Экономия токенов может исчезнуть на QA
Если main agent потом тратит много времени на исправление слабого extraction, отклонение vague facts и починку malformed JSONL, выгода от дешевой модели быстро уменьшается.
Текущий routing после теста:
Spark — только для очень маленьких exact-URL, text-only задач или bounded QA. Короткий prompt, fork_context=false.
5.5-mini — дефолтный worker для обычных небольших batch-задач, если official URLs уже известны.
5.5 medium — для сложных случаев: non-English pages, PDFs, несколько связанных официальных страниц, booking/form gates, contact repair, ambiguity.
Главный вывод: дешевые subagents должны генерировать только raw candidates. Main agent все равно делает строгую нормализацию, duplicate checks, helper dry-run и только потом promotion.
То есть Spark не бесполезен, но как general scraping/research agent он ОЧЕНЬ слабый. Это узкий инструмент для простого extraction, а не надежный enrichment worker.
👍10
Forwarded from A M
В нашем тесте mini выглядит заметно эффективнее 5.5-medium для типовых extraction-задач, но не как полная замена.
Практический вывод:
mini лучше по cost/performance, когда:
известен официальный URL;
задача простая: контакты, email, phone, social, базовые pricing/program facts;
страницы на английском или простые по структуре;
не нужно много reasoning.
5.5-medium лучше, когда:
сайт неочевидный или надо искать новый официальный URL;
есть PDF, booking portal, формы, логин-гейты;
страница не на английском;
надо отличить реальную академию от клуба/кортов/мерча;
mini вернул мало, расплылся или дал сомнительные факты.
По качеству:
mini дал достаточно хорошие raw candidates, которые main agent мог проверить и нормализовать. Он намного надежнее Spark и обычно дешевле/быстрее, чем medium.
По риску:
mini все еще нельзя пускать напрямую в базу. Он может:
принять court booking price за program pricing;
не заметить, что цена устарела;
не отличить camp от generic junior page;
дать слабый status/type.
Итоговая оценка:
mini должен быть default worker для 70-80% обычного enrichment batch, а 5.5-medium надо держать как escalation model для сложных/ambiguous случаев. Это, вероятно, лучший баланс между ценой, скоростью и качеством.
Практический вывод:
mini лучше по cost/performance, когда:
известен официальный URL;
задача простая: контакты, email, phone, social, базовые pricing/program facts;
страницы на английском или простые по структуре;
не нужно много reasoning.
5.5-medium лучше, когда:
сайт неочевидный или надо искать новый официальный URL;
есть PDF, booking portal, формы, логин-гейты;
страница не на английском;
надо отличить реальную академию от клуба/кортов/мерча;
mini вернул мало, расплылся или дал сомнительные факты.
По качеству:
mini дал достаточно хорошие raw candidates, которые main agent мог проверить и нормализовать. Он намного надежнее Spark и обычно дешевле/быстрее, чем medium.
По риску:
mini все еще нельзя пускать напрямую в базу. Он может:
принять court booking price за program pricing;
не заметить, что цена устарела;
не отличить camp от generic junior page;
дать слабый status/type.
Итоговая оценка:
mini должен быть default worker для 70-80% обычного enrichment batch, а 5.5-medium надо держать как escalation model для сложных/ambiguous случаев. Это, вероятно, лучший баланс между ценой, скоростью и качеством.
Forwarded from A M
Продолжение после реального A/B-теста 5.5-low vs 5.5-medium.
Прогнали обе модели на одинаковом sample из 8 академий, без promotion в базу. Цель была не “кто написал больше строк”, а кто дает больше реально полезных source-backed candidates при меньшей нагрузке на QA.
Короткий итог: 5.5-low полезна, но не как замена mini и не как замена medium.
Она занимает узкую middle-tier позицию.
Что показал тест:
5.5-low
- лучше держится на простых exact-URL задачах;
- дает более чистые contact/program rows;
- меньше расползается в лишние рассуждения;
- выглядит дешевле по QA для простых страниц;
- но пропускает более сложные источники: PDFs, linked pages, padel/pricing details, неоднозначные программы.
То есть 5.5-low хороша, когда надо быстро извлечь очевидные факты с уже известной официальной страницы.
5.5-medium
- нашла больше materially useful facts;
- лучше справилась с pricing, PDF, padel и более сложными linked sources;
- полезнее там, где нужна интерпретация;
- но output был менее promotion-ready;
- требовала больше нормализации и main-agent QA.
То есть medium лучше как reasoning/research модель, но ее нельзя использовать как “просто дешевый extractor”: она может дать больше ценности, но и больше шума.
Главный вывод по workflow
5.5-low не заменяет mini, потому что mini все еще остается default для массового простого extraction, если official URL уже известен.
Но 5.5-low можно добавить как промежуточный слой:
- mini — обычный default worker для простых known-URL batches;
- 5.5-low — когда задача чуть сложнее mini, но еще не требует полноценного reasoning;
- 5.5-medium — когда есть PDF, non-English, booking gates, pricing ambiguity, multiple official pages, contact repair или слабый результат от mini/low.
Практическое правило после теста:
Использовать 5.5-low для:
- exact official URL;
- contact + simple program extraction;
- простых англоязычных страниц;
- bounded QA;
- случаев, где Spark слишком слабый, а medium избыточна.
Не использовать 5.5-low для:
- broad discovery;
- dead URL / rebrand repair;
- pricing через booking portals;
- PDF-heavy pages;
- non-English pages;
- финального решения по ambiguous facts.
И важное: ни 5.5-low, ни 5.5-medium нельзя считать promotion-ready. Обе модели должны писать только raw JSONL candidates. Main agent дальше делает strict normalization, duplicate checks, pricing filters и helper dry-run.
Финальная рекомендация:
5.5-low стоит добавить в routing, но как narrow middle tier. Она экономит QA на простых задачах, но medium все еще нужен для сложных случаев, где low просто не достает часть ценных фактов.
Прогнали обе модели на одинаковом sample из 8 академий, без promotion в базу. Цель была не “кто написал больше строк”, а кто дает больше реально полезных source-backed candidates при меньшей нагрузке на QA.
Короткий итог: 5.5-low полезна, но не как замена mini и не как замена medium.
Она занимает узкую middle-tier позицию.
Что показал тест:
5.5-low
- лучше держится на простых exact-URL задачах;
- дает более чистые contact/program rows;
- меньше расползается в лишние рассуждения;
- выглядит дешевле по QA для простых страниц;
- но пропускает более сложные источники: PDFs, linked pages, padel/pricing details, неоднозначные программы.
То есть 5.5-low хороша, когда надо быстро извлечь очевидные факты с уже известной официальной страницы.
5.5-medium
- нашла больше materially useful facts;
- лучше справилась с pricing, PDF, padel и более сложными linked sources;
- полезнее там, где нужна интерпретация;
- но output был менее promotion-ready;
- требовала больше нормализации и main-agent QA.
То есть medium лучше как reasoning/research модель, но ее нельзя использовать как “просто дешевый extractor”: она может дать больше ценности, но и больше шума.
Главный вывод по workflow
5.5-low не заменяет mini, потому что mini все еще остается default для массового простого extraction, если official URL уже известен.
Но 5.5-low можно добавить как промежуточный слой:
- mini — обычный default worker для простых known-URL batches;
- 5.5-low — когда задача чуть сложнее mini, но еще не требует полноценного reasoning;
- 5.5-medium — когда есть PDF, non-English, booking gates, pricing ambiguity, multiple official pages, contact repair или слабый результат от mini/low.
Практическое правило после теста:
Использовать 5.5-low для:
- exact official URL;
- contact + simple program extraction;
- простых англоязычных страниц;
- bounded QA;
- случаев, где Spark слишком слабый, а medium избыточна.
Не использовать 5.5-low для:
- broad discovery;
- dead URL / rebrand repair;
- pricing через booking portals;
- PDF-heavy pages;
- non-English pages;
- финального решения по ambiguous facts.
И важное: ни 5.5-low, ни 5.5-medium нельзя считать promotion-ready. Обе модели должны писать только raw JSONL candidates. Main agent дальше делает strict normalization, duplicate checks, pricing filters и helper dry-run.
Финальная рекомендация:
5.5-low стоит добавить в routing, но как narrow middle tier. Она экономит QA на простых задачах, но medium все еще нужен для сложных случаев, где low просто не достает часть ценных фактов.
🔥7👍4❤1
⚪️ Software Factory
Тут Factory.ai (авторы droid, довольно крутого агента) разродился интро-постом о том, что мы переходим от индивидуальных агентов к автоматизации полного SDLC через Software Factories. Предлагает услуги их построить!
Это ровно то, о чем мы на одном из созвонов говорили - про полный SDLC, и что это сильно отличается от ИИ-разработки. Разработка - это все таки часть бизнеса, еще может оказаться, что и не самая большая! Автоматизация только ее - это формирвоание бутылочных горлышек по цепочке дальше.
▶️ Фэктори правильно все этапы пишет:
• signal in: хотелка пользователя
• triage: проработка хотелки, снятие неопределенностей, устранение Gaps
• plan: делаем подробный план реализации
• code: реализация
• test: тестируем (я сценариями прежде всего тетсирую)
• review: почему после тестов? нелогично; я делаю тесты ДО ревью, чтобы код корректный был, и ревью по цепочке с тестами бегает; а вот сценарии фичи - после смотрим, чтобы типа окончательный вариант;
• ship: у меня тут разделено - есть отдельно release (это выпуск версии, то есть паковка определенного набора фич в версию) и deploy (деплой - это выпуск некоего артефакта на определенный Stage, или в репозиторий, или в магаз); есть совмещенный флоу publish - это когда разделить не получается выпуск версии и делой на stage;
• monitor, automate: я хз как именно они за деплоями следят - у меня это индивидуально в паре проектов автоматизировано (в квн моем, например) через агента-администратора системы, он мне отчеты шлет как оно там поживает;
• software out: ну - концептуально тоже мне не понятно; оно у меня out когда я деплой сделал;
В общем, тема знакомая)) концепция не новая - мы про такое еще со времен Code Machine отслеживаем, всякие такие гравицапы (Auto Claude, например). Просто лишний раз убеждаешься, что тенденция усмотрена верно, жизнь туда и развивается.
Мне понравилось как сделана визуализация дашборда на их фабрике! Скрин в комменты кину для понимания. ⬇️
▶️ Надо будет упереь для своего dd-flow. Я как раз все свои этапы снабдил html-отчетами, и щас вот дашборд надо красивый вкрутить)) Спасибо за inspiration
🔗 Пост в бложик : https://factory.ai/news/software-factory
❓ Вы что то подобное делаете?
@deksden_notes
Тут Factory.ai (авторы droid, довольно крутого агента) разродился интро-постом о том, что мы переходим от индивидуальных агентов к автоматизации полного SDLC через Software Factories. Предлагает услуги их построить!
Это ровно то, о чем мы на одном из созвонов говорили - про полный SDLC, и что это сильно отличается от ИИ-разработки. Разработка - это все таки часть бизнеса, еще может оказаться, что и не самая большая! Автоматизация только ее - это формирвоание бутылочных горлышек по цепочке дальше.
▶️ Фэктори правильно все этапы пишет:
• signal in: хотелка пользователя
• triage: проработка хотелки, снятие неопределенностей, устранение Gaps
• plan: делаем подробный план реализации
• code: реализация
• test: тестируем (я сценариями прежде всего тетсирую)
• review: почему после тестов? нелогично; я делаю тесты ДО ревью, чтобы код корректный был, и ревью по цепочке с тестами бегает; а вот сценарии фичи - после смотрим, чтобы типа окончательный вариант;
• ship: у меня тут разделено - есть отдельно release (это выпуск версии, то есть паковка определенного набора фич в версию) и deploy (деплой - это выпуск некоего артефакта на определенный Stage, или в репозиторий, или в магаз); есть совмещенный флоу publish - это когда разделить не получается выпуск версии и делой на stage;
• monitor, automate: я хз как именно они за деплоями следят - у меня это индивидуально в паре проектов автоматизировано (в квн моем, например) через агента-администратора системы, он мне отчеты шлет как оно там поживает;
• software out: ну - концептуально тоже мне не понятно; оно у меня out когда я деплой сделал;
В общем, тема знакомая)) концепция не новая - мы про такое еще со времен Code Machine отслеживаем, всякие такие гравицапы (Auto Claude, например). Просто лишний раз убеждаешься, что тенденция усмотрена верно, жизнь туда и развивается.
Мне понравилось как сделана визуализация дашборда на их фабрике! Скрин в комменты кину для понимания. ⬇️
▶️ Надо будет упереь для своего dd-flow. Я как раз все свои этапы снабдил html-отчетами, и щас вот дашборд надо красивый вкрутить)) Спасибо за inspiration
🔗 Пост в бложик : https://factory.ai/news/software-factory
❓ Вы что то подобное делаете?
@deksden_notes
🔥11❤6
⚪️ Codex Referal Reset
Как вы знаете, Кодекс ввел систему рефералок, - если по вашей ссылке регистрируется пользователь, вам и ему дают ресет.
▶️ Так как у меня много аккаунтов, я решил не брать плюс подписку на очередной аккаунт "из старых", а сделать новый аккаунт, благо доменов то у меня много! )) Аккаунты я делаю на свои домены, но вместо почты завожу алиас на simplelogin.io (там у меня премиум) куда у меня эти домены подключены.
Зарегавшись в chatgpt.com, я вернулся в кодекс.апп и оттуда на этот новый аккаунт отправил рефералку.
▶️ Не забываем на chagpt.com для новых аккаунтов включить для аккаунта passkey / 2fa. Я забыл, и у меня просила авторизацию через телефон (благо у меня этих ваших esim с номерами верификации щас полно). Надо будет еще раз попробовать - но уже со включенным 2fa/passkey, есть мнение, что в этом случае может НЕ просить верификацию, но не факт, надо проверять.
Тут надо сделать выход из своего аккаунта в кодекс.апп. На всякий случай взял с почты реферальную ссылку, и по ней перешел - она открывает кодекс.апп. Там вошел в новый аккаунт, и в чате поздоровался с кодексом. В этот момент ресет пришел)
▶️ В общем, для нового аккаунта все сработало: ресет дали и моему аккаунту, с которого я реферал делал, и новому (даже free) аккаунту! Понятно, что тратить ресет на free аккаунте довольно неразумно, надо будет его апнуть до Плюса.
▶️ Не на всех аккаунтах включилась возможность отправлять инвайты. Наверное, это только честно купленные аккаунты - но я не отслеживал закономерность. Имейте ввиду.
——
Upd 1️⃣ : проверил - нет, для новых аккаунтов 2fa/passkey не спасает от требования верификации - скорее всего, это защита от фрода.
И еще наблюдение: логин и логаут из кодекс.апп инвалидирует сессии в CPA / web.
@deksden_notes
Как вы знаете, Кодекс ввел систему рефералок, - если по вашей ссылке регистрируется пользователь, вам и ему дают ресет.
▶️ Так как у меня много аккаунтов, я решил не брать плюс подписку на очередной аккаунт "из старых", а сделать новый аккаунт, благо доменов то у меня много! )) Аккаунты я делаю на свои домены, но вместо почты завожу алиас на simplelogin.io (там у меня премиум) куда у меня эти домены подключены.
Зарегавшись в chatgpt.com, я вернулся в кодекс.апп и оттуда на этот новый аккаунт отправил рефералку.
▶️ Не забываем на chagpt.com для новых аккаунтов включить для аккаунта passkey / 2fa. Я забыл, и у меня просила авторизацию через телефон (благо у меня этих ваших esim с номерами верификации щас полно). Надо будет еще раз попробовать - но уже со включенным 2fa/passkey, есть мнение, что в этом случае может НЕ просить верификацию, но не факт, надо проверять.
Тут надо сделать выход из своего аккаунта в кодекс.апп. На всякий случай взял с почты реферальную ссылку, и по ней перешел - она открывает кодекс.апп. Там вошел в новый аккаунт, и в чате поздоровался с кодексом. В этот момент ресет пришел)
▶️ В общем, для нового аккаунта все сработало: ресет дали и моему аккаунту, с которого я реферал делал, и новому (даже free) аккаунту! Понятно, что тратить ресет на free аккаунте довольно неразумно, надо будет его апнуть до Плюса.
▶️ Не на всех аккаунтах включилась возможность отправлять инвайты. Наверное, это только честно купленные аккаунты - но я не отслеживал закономерность. Имейте ввиду.
——
Upd 1️⃣ : проверил - нет, для новых аккаунтов 2fa/passkey не спасает от требования верификации - скорее всего, это защита от фрода.
И еще наблюдение: логин и логаут из кодекс.апп инвалидирует сессии в CPA / web.
@deksden_notes
1🔥8❤3
⚪️ HTML отчеты - небольшой апдейт
Я уже говорил про тему с HTML отчетами
🔗 Вот оригинальный пост про подход: https://t.me/deksden_notes/837
Я их использую на каждый этап своих флоу, стараюсь что то важное показать, и, желательно, как то посимпатичнее, графиком там разбавить, или табличками.
▶️ Делаю просто: есть html шаблон, данные он берет из json, а этап флоу должен только сформировать этот json - не нужно каждый раз агенту упражняться с html, да и формат выходит консистентнее. Шаблоны - в доп материалах промпта (скилла)
▶️ Еще момент: агент, конечно, напишет в своем заключении по этапу что сделал такой то отчет. Но это надо кликнуть - а ведь еще удобнее, когда отчет просто сразу видно. Я сделал блок в промпт, чтобы оно работало почти везде - я использую CMUX сейчас, в нем есть скилл Cmux Browser: если он доступен, отчет откроется в CMUX. Если нет - использую скилл Agents Browser.
Вы можете аналогичным образом прописывать браузер вашей ADE, встроенные браузеры сейчас почти у всех - от кодекс апп, до курсора.
❓ Пользуете такое для UX разработки? Или только отладку фронта?
@deksden_notes
Я уже говорил про тему с HTML отчетами
🔗 Вот оригинальный пост про подход: https://t.me/deksden_notes/837
Я их использую на каждый этап своих флоу, стараюсь что то важное показать, и, желательно, как то посимпатичнее, графиком там разбавить, или табличками.
▶️ Делаю просто: есть html шаблон, данные он берет из json, а этап флоу должен только сформировать этот json - не нужно каждый раз агенту упражняться с html, да и формат выходит консистентнее. Шаблоны - в доп материалах промпта (скилла)
▶️ Еще момент: агент, конечно, напишет в своем заключении по этапу что сделал такой то отчет. Но это надо кликнуть - а ведь еще удобнее, когда отчет просто сразу видно. Я сделал блок в промпт, чтобы оно работало почти везде - я использую CMUX сейчас, в нем есть скилл Cmux Browser: если он доступен, отчет откроется в CMUX. Если нет - использую скилл Agents Browser.
Вы можете аналогичным образом прописывать браузер вашей ADE, встроенные браузеры сейчас почти у всех - от кодекс апп, до курсора.
❓ Пользуете такое для UX разработки? Или только отладку фронта?
@deksden_notes
Telegram
DEKSDEN notes
⚪️ Агентные флоу - отчеты
▶️ У меня в работе часто используются агентные флоу. Это именно то, что запускают оркестраторы, да.
И по результатам работы этих флоу агенты, как водится, отчитываются.
▶️ Мне категорически не нравится как отчитывается кодекс:…
▶️ У меня в работе часто используются агентные флоу. Это именно то, что запускают оркестраторы, да.
И по результатам работы этих флоу агенты, как водится, отчитываются.
▶️ Мне категорически не нравится как отчитывается кодекс:…
1❤6👍3✍2
Forwarded from Alexey Demochko
Привет :) Обещал упаковать красиво плагин для Фигмы
🧩 Figma AI Bridge — опенсорсный мост между Figma Desktop и ИИ-агентами.
В чем боль? Скармливать LLM сырой JSON из Figma — гиблое дело. Он гигантский, шумный и мгновенно сжирает контекст модели. А настраивать ради банальной верстки одного экрана Figma API, Dev Mode MCP, токены и всю эту инфру — откровенный оверкилл.
Figma AI Bridge решает это элегантно и полностью локально:
🔹 Плагин в Figma собирает только суть: макеты, тексты, структуру, стили и превью.
🔹 Локальный сервер упаковывает это в аккуратный handoff-бандл в папке out/.
🔹 Ваш ИИ-агент (Codex, Cursor и др.) читает не мусорный дамп на сотни тысяч строк, а понятный набор: prompt.md, page-map.md, preview.png и design-context.json.
🔹 Никаких REST API, платного Dev Mode и возни с access-токенами.
Внутри коробки: режимы Page Extract, Links Batch и Selection, плюс готовые CLI-команды для валидации, саммари и нарезки задач для агентов.
Суть: дать ИИ ровно то, что нужно для реализации интерфейса, не забивая ему мозги мусором. Меньше шума и ручной подготовки = больше шансов получить верстку, которая реально похожа на макет. ⚙️
Если автоматизируете фронтенд через агентов, этот репозиторий закрывает огромную дыру в пайплайне.
Github: https://github.com/Kacep91/figma-ai-bridge
#opensource #figma #codex #frontend #design
🧩 Figma AI Bridge — опенсорсный мост между Figma Desktop и ИИ-агентами.
В чем боль? Скармливать LLM сырой JSON из Figma — гиблое дело. Он гигантский, шумный и мгновенно сжирает контекст модели. А настраивать ради банальной верстки одного экрана Figma API, Dev Mode MCP, токены и всю эту инфру — откровенный оверкилл.
Figma AI Bridge решает это элегантно и полностью локально:
🔹 Плагин в Figma собирает только суть: макеты, тексты, структуру, стили и превью.
🔹 Локальный сервер упаковывает это в аккуратный handoff-бандл в папке out/.
🔹 Ваш ИИ-агент (Codex, Cursor и др.) читает не мусорный дамп на сотни тысяч строк, а понятный набор: prompt.md, page-map.md, preview.png и design-context.json.
🔹 Никаких REST API, платного Dev Mode и возни с access-токенами.
Внутри коробки: режимы Page Extract, Links Batch и Selection, плюс готовые CLI-команды для валидации, саммари и нарезки задач для агентов.
Суть: дать ИИ ровно то, что нужно для реализации интерфейса, не забивая ему мозги мусором. Меньше шума и ручной подготовки = больше шансов получить верстку, которая реально похожа на макет. ⚙️
Если автоматизируете фронтенд через агентов, этот репозиторий закрывает огромную дыру в пайплайне.
Github: https://github.com/Kacep91/figma-ai-bridge
#opensource #figma #codex #frontend #design
GitHub
GitHub - Kacep91/figma-ai-bridge: Local Figma Desktop plugin and localhost bridge for AI-ready design handoff bundles, without…
Local Figma Desktop plugin and localhost bridge for AI-ready design handoff bundles, without Figma API, Dev Mode MCP, or access tokens. - Kacep91/figma-ai-bridge
2❤12🔥7
⚪️ Swarm-Forge, большой обзор (часть 1)
Боб Мартин, известный как Дядя Боб (Uncle Bob), создатель весьма культовой книжки Clean Code, выпустил свой оркестратор - Swarm Forge.
🔗 Гитхаб: https://github.com/unclebob/swarm-forge
Дядя весьма хардкорный с методологической точки зрения, посмотреть на его оркестратор - весьма интересно. Приступим!
Сразу отметил: необычен способ дистрибуции. Проект лежит на гитхабе и распределен ПО РАЗНЫМ веткам, и в них находится ОДИН продукт. Дефолтная ветка main содержит документацию и главные файлы проекта, а другие ветки содержат конфиги встроенного флоу, и как раз предназначены для работы с проектами - мы вернемся к этой штуке чуть попозже.
▶️ Оркестратор сделан системой на базе tmux и детерминированных скриптов оркестрации + не совсем шаблонное использование git worktrees + файловая агентная почта. Написано на смеси closure / sh и использует кложурный babashka интерпретатор для скриптов. Также в проекте использована куча специфического (TDD?) инструментария - Gherkin, DRY структурные анализаторы, CRAP метрики кода, APS (Acceptance-Pipeline-Specification), gherkin-parser, gherkin-mutator.
▶️ В оркестраторе предусмотрены роли для агентов: specifier, architect, coder, cleaner, hardender, qa. Можно добавить свои. Каждая роль будет отдельным агентом, который работает в своем изолированном рабочем дереве, со своей отдельной tmux сессией (к которой вы можете подключиться и смотреть за работой). На каком агентном движке - настраивается. Дефолтом идет codex, поддерживается claude, copilot (omfg, Дядя Боб!) grok. Где, блин pi? Где opencode? Ну или droid? бардак. Про китов молчу.
Задачи агентам выдаются через специальную агентную почту на базе типизированных файлов. Агент кладет сообщение в специальном формате в исходящую почту, а демон в составе оркестратора обрабатывает и маршрутизирует ее получателю, делает короткое уведомление о новой почте. Задачи с одинаковым приоритетом объединяются для обработки в пачки (batch).
Обратите внимание: рабочие ветки созданы не под задачу/фичу, а под роли агентов в проекте! Оригинально.
В итоге систему оркестрации в проекте можно описать как настраиваемый конвеер обработки последовательной передачи заданий через систему агентной почты между разными исполнителыми. Для отдельных этапов предусмотрена пакетная обработка задач.
(продолжение далее ...)
@deksden_notes
Боб Мартин, известный как Дядя Боб (Uncle Bob), создатель весьма культовой книжки Clean Code, выпустил свой оркестратор - Swarm Forge.
🔗 Гитхаб: https://github.com/unclebob/swarm-forge
Дядя весьма хардкорный с методологической точки зрения, посмотреть на его оркестратор - весьма интересно. Приступим!
Сразу отметил: необычен способ дистрибуции. Проект лежит на гитхабе и распределен ПО РАЗНЫМ веткам, и в них находится ОДИН продукт. Дефолтная ветка main содержит документацию и главные файлы проекта, а другие ветки содержат конфиги встроенного флоу, и как раз предназначены для работы с проектами - мы вернемся к этой штуке чуть попозже.
▶️ Оркестратор сделан системой на базе tmux и детерминированных скриптов оркестрации + не совсем шаблонное использование git worktrees + файловая агентная почта. Написано на смеси closure / sh и использует кложурный babashka интерпретатор для скриптов. Также в проекте использована куча специфического (TDD?) инструментария - Gherkin, DRY структурные анализаторы, CRAP метрики кода, APS (Acceptance-Pipeline-Specification), gherkin-parser, gherkin-mutator.
▶️ В оркестраторе предусмотрены роли для агентов: specifier, architect, coder, cleaner, hardender, qa. Можно добавить свои. Каждая роль будет отдельным агентом, который работает в своем изолированном рабочем дереве, со своей отдельной tmux сессией (к которой вы можете подключиться и смотреть за работой). На каком агентном движке - настраивается. Дефолтом идет codex, поддерживается claude, copilot (omfg, Дядя Боб!) grok. Где, блин pi? Где opencode? Ну или droid? бардак. Про китов молчу.
Задачи агентам выдаются через специальную агентную почту на базе типизированных файлов. Агент кладет сообщение в специальном формате в исходящую почту, а демон в составе оркестратора обрабатывает и маршрутизирует ее получателю, делает короткое уведомление о новой почте. Задачи с одинаковым приоритетом объединяются для обработки в пачки (batch).
Обратите внимание: рабочие ветки созданы не под задачу/фичу, а под роли агентов в проекте! Оригинально.
В итоге систему оркестрации в проекте можно описать как настраиваемый конвеер обработки последовательной передачи заданий через систему агентной почты между разными исполнителыми. Для отдельных этапов предусмотрена пакетная обработка задач.
(продолжение далее ...)
@deksden_notes
GitHub
GitHub - unclebob/swarm-forge: A simple tool for coordinating several AI agents.
A simple tool for coordinating several AI agents. Contribute to unclebob/swarm-forge development by creating an account on GitHub.
❤2🔥1
⚪️ Swarm-Forge, большой обзор (часть 2)
(первая часть ранее ...)
▶️ Теперь к флоу: система содержит три конфига встроенного флоу. На 2 агента, на 4 агента, и полный флоу на 6 агентов. Как раз эти флоу лежат в бранчах two-pack, four-pack, six-pack на гитхабе. Мы вибираем для проекта тот конфиг флоу, который нам подходит, по степени глубины проработки.
Полный граф 6-pack:
-> specifier
-> coder
-> cleaner
-> architect
-> hardender (batch)
-> QA
-> specifier
Более простой 4-pack:
-> specifier
-> coder
-> refactorer
-> architect (batch)
-> specifier
И самый просто two-pack:
-> coder
-> cleaner (batch)
-> coder
Напоминаю, что пачки (batch) - это когда агент за раз может обработать пачку однотипных входящих задач. Для рефакторинга обрабатывать более полную картину изменений - это даже плюс.
Давайте детально разберем роли из полного набора six-pack.
1️⃣ specifier
Владеет: внешним поведением, acceptance criteria, Gherkin-спецификациями, примерами, end-to-end QA procedure.
Что делает:
- уточняет неоднозначность у пользователя;
- превращает intent в тестируемую спецификацию;
- пишет Gherkin по APS;
- чистит Gherkin через ir-dry-checker;
- пишет UI-level QA suite/procedures;
- не лезет в реализацию.
Передает дальше: specifier -> coder
Условие передачи: только после явного approval от пользователя. После approval он commit-ит specification changes, придумывает короткий task: name и
отправляет git_handoff coder-у.
В конце флоу: QA -> specifier
Когда QA сообщает, что работа завершена, specifier merge-ит изменения и спрашивает пользователя про следующую feature.
(продолжение далее...)
@deksden_notes
(первая часть ранее ...)
▶️ Теперь к флоу: система содержит три конфига встроенного флоу. На 2 агента, на 4 агента, и полный флоу на 6 агентов. Как раз эти флоу лежат в бранчах two-pack, four-pack, six-pack на гитхабе. Мы вибираем для проекта тот конфиг флоу, который нам подходит, по степени глубины проработки.
Полный граф 6-pack:
-> specifier
-> coder
-> cleaner
-> architect
-> hardender (batch)
-> QA
-> specifier
Более простой 4-pack:
-> specifier
-> coder
-> refactorer
-> architect (batch)
-> specifier
И самый просто two-pack:
-> coder
-> cleaner (batch)
-> coder
Напоминаю, что пачки (batch) - это когда агент за раз может обработать пачку однотипных входящих задач. Для рефакторинга обрабатывать более полную картину изменений - это даже плюс.
Давайте детально разберем роли из полного набора six-pack.
1️⃣ specifier
Владеет: внешним поведением, acceptance criteria, Gherkin-спецификациями, примерами, end-to-end QA procedure.
Что делает:
- уточняет неоднозначность у пользователя;
- превращает intent в тестируемую спецификацию;
- пишет Gherkin по APS;
- чистит Gherkin через ir-dry-checker;
- пишет UI-level QA suite/procedures;
- не лезет в реализацию.
Передает дальше: specifier -> coder
Условие передачи: только после явного approval от пользователя. После approval он commit-ит specification changes, придумывает короткий task: name и
отправляет git_handoff coder-у.
В конце флоу: QA -> specifier
Когда QA сообщает, что работа завершена, specifier merge-ит изменения и спрашивает пользователя про следующую feature.
(продолжение далее...)
@deksden_notes
⚪️ Swarm-Forge, большой обзор (часть 3)
(вторая часть ранее ...)
2️⃣ coder
Владеет: реализацией approved behavior slices, то есть куски функционала умеет делать.
Что делает:
- берет принятую спецификацию;
- ставит normal acceptance pipeline из Acceptance-Pipeline-Specification;
- использует gherkin-parser;
- строит project-specific acceptance entrypoint generator, runtime, step handlers;
- пишет unit tests через TDD;
- пишет production code только под тесты;
- гоняет unit + acceptance tests.
Не делает:
- не занимается CRAP/DRY/mutation;
- не делает Gherkin mutation;
- не поддерживает QA suite от specifier.
Передает дальше: coder -> cleaner
Условие: acceptance и unit tests проходят, изменения закоммичены.
3️⃣ cleaner
Владеет: локальной чисткой без изменения поведения.
Что делает:
- улучшает имена, cohesion, локальную связность;
- убирает duplication;
- чистит тесты, fixtures, helpers;
- делает error paths явными;
- выносит поведение из environment-heavy модулей в testable modules, если это можно сделать без смены поведения;
- запускает coverage;
- ставит и запускает CRAP/DRY tools;
- использует mutation tool только в scan/count mode, не полноценные mutation tests;
- если файл имеет больше 100 mutation sites, разумно split-ит его до handoff.
Не делает:
- не вводит новое поведение;
- не запускает mutation tests;
- не запускает Gherkin mutation;
- не занимается end-to-end QA suite.
Передает дальше: cleaner -> architect
Условие: refactor small enough, acceptance + unit tests проходят, изменения закоммичены.
4️⃣ architect
Владеет: архитектурой, границами модулей, dependency direction, property-test support.
Что делает:
- проверяет UI/core separation;
- следит, чтобы high-level policy не зависела от IO/UI/framework/db/network;
- исправляет dependency direction violations;
- убирает framework leakage, low-level DTO leakage, accidental public APIs;
- вводит narrow interfaces, owned by high-level modules;
- может добавить lightweight architecture checks;
- оценивает property-test coverage и добавляет property tests там, где полезны инварианты, round trips, ordering, parsing/formatting stability и
т.п.
Не делает:
- не занимается QA suite от specifier.
Передает дальше: architect -> hardender
Условие: если handoff содержит реальные изменения. Если изменений нет, не надо гонять дальше пустую работу. Перед handoff запускает relevant local test suite / verification.
(продолжение далее...)
@deksden_notes
(вторая часть ранее ...)
2️⃣ coder
Владеет: реализацией approved behavior slices, то есть куски функционала умеет делать.
Что делает:
- берет принятую спецификацию;
- ставит normal acceptance pipeline из Acceptance-Pipeline-Specification;
- использует gherkin-parser;
- строит project-specific acceptance entrypoint generator, runtime, step handlers;
- пишет unit tests через TDD;
- пишет production code только под тесты;
- гоняет unit + acceptance tests.
Не делает:
- не занимается CRAP/DRY/mutation;
- не делает Gherkin mutation;
- не поддерживает QA suite от specifier.
Передает дальше: coder -> cleaner
Условие: acceptance и unit tests проходят, изменения закоммичены.
3️⃣ cleaner
Владеет: локальной чисткой без изменения поведения.
Что делает:
- улучшает имена, cohesion, локальную связность;
- убирает duplication;
- чистит тесты, fixtures, helpers;
- делает error paths явными;
- выносит поведение из environment-heavy модулей в testable modules, если это можно сделать без смены поведения;
- запускает coverage;
- ставит и запускает CRAP/DRY tools;
- использует mutation tool только в scan/count mode, не полноценные mutation tests;
- если файл имеет больше 100 mutation sites, разумно split-ит его до handoff.
Не делает:
- не вводит новое поведение;
- не запускает mutation tests;
- не запускает Gherkin mutation;
- не занимается end-to-end QA suite.
Передает дальше: cleaner -> architect
Условие: refactor small enough, acceptance + unit tests проходят, изменения закоммичены.
4️⃣ architect
Владеет: архитектурой, границами модулей, dependency direction, property-test support.
Что делает:
- проверяет UI/core separation;
- следит, чтобы high-level policy не зависела от IO/UI/framework/db/network;
- исправляет dependency direction violations;
- убирает framework leakage, low-level DTO leakage, accidental public APIs;
- вводит narrow interfaces, owned by high-level modules;
- может добавить lightweight architecture checks;
- оценивает property-test coverage и добавляет property tests там, где полезны инварианты, round trips, ordering, parsing/formatting stability и
т.п.
Не делает:
- не занимается QA suite от specifier.
Передает дальше: architect -> hardender
Условие: если handoff содержит реальные изменения. Если изменений нет, не надо гонять дальше пустую работу. Перед handoff запускает relevant local test suite / verification.
(продолжение далее...)
@deksden_notes
⚪️ Swarm-Forge, большой обзор (часть 4)
(третья часть ранее ...)
5️⃣ hardender (batch)
Владеет: mutation hardening после архитектурного review. Тут надо немного быть в теме всего этого APS, gherkin и прочего mutation подходов.
Это единственный batch-агент в six-pack.
Что batch объединяет: несколько architect -> hardender handoff-ов с одинаковым priority которые уже лежат в hardender inbox/new
Что делает:
- принимает TASK или BATCH;
- если BATCH, обрабатывает все BATCH_ITEM в helper-delivered order как один hardening batch;
- ставит language mutation, CRAP, DRY tools;
- ставит APS gherkin-parser и gherkin-mutator;
- строит runner adapter для gherkin-mutator;
- запускает language mutation по одному файлу за раз;
- использует differential mutation against manifest;
- запускает soft Gherkin acceptance mutation;
- затем CRAP;
- затем DRY;
- чинит survivors/issues.
Не делает:
- не поддерживает end-to-end QA suite от specifier.
Передает дальше: hardender -> QA
Условие передачи: текущий architect task или batch architect tasks полностью hardened, изменения закоммичены.
6️⃣ QA
Владеет: финальной независимой проверкой.
Что делает:
- проверяет accepted specification;
- проверяет generated acceptance tests;
- превращает specifier QA procedures в executable QA scripts;
- гоняет end-to-end QA через пользовательский интерфейс, не через project API;
- проверяет unit tests, property tests при наличии, architecture-sensitive workflows, release checks;
- чинит найденные QA/final verification bugs минимально;
- если QA suite конфликтует с Gherkin или unit tests, останавливается и спрашивает clarification;
- проверяет, что handoff commits, manifests и audit files консистентны;
- перед финалом запускает CRAP и DRY.
Не делает:
- не запускает language mutation и Gherkin mutation, если явно не попросили.
Передает дальше: completion broadcast с priority: 00.
QA -> specifier
QA -> coder
QA -> cleaner
QA -> architect
QA -> hardender
Смысл broadcast: все роли получают “QA complete”. Но локальное правило six-pack говорит, что QA handoff не прерывает текущую работу. Если агент занят, он игнорирует wake-up, а после done_with_current.sh очередь сама выдаст следующий item.
(продолжение далее...)
@deksden_notes
(третья часть ранее ...)
5️⃣ hardender (batch)
Владеет: mutation hardening после архитектурного review. Тут надо немного быть в теме всего этого APS, gherkin и прочего mutation подходов.
Это единственный batch-агент в six-pack.
Что batch объединяет: несколько architect -> hardender handoff-ов с одинаковым priority которые уже лежат в hardender inbox/new
Что делает:
- принимает TASK или BATCH;
- если BATCH, обрабатывает все BATCH_ITEM в helper-delivered order как один hardening batch;
- ставит language mutation, CRAP, DRY tools;
- ставит APS gherkin-parser и gherkin-mutator;
- строит runner adapter для gherkin-mutator;
- запускает language mutation по одному файлу за раз;
- использует differential mutation against manifest;
- запускает soft Gherkin acceptance mutation;
- затем CRAP;
- затем DRY;
- чинит survivors/issues.
Не делает:
- не поддерживает end-to-end QA suite от specifier.
Передает дальше: hardender -> QA
Условие передачи: текущий architect task или batch architect tasks полностью hardened, изменения закоммичены.
6️⃣ QA
Владеет: финальной независимой проверкой.
Что делает:
- проверяет accepted specification;
- проверяет generated acceptance tests;
- превращает specifier QA procedures в executable QA scripts;
- гоняет end-to-end QA через пользовательский интерфейс, не через project API;
- проверяет unit tests, property tests при наличии, architecture-sensitive workflows, release checks;
- чинит найденные QA/final verification bugs минимально;
- если QA suite конфликтует с Gherkin или unit tests, останавливается и спрашивает clarification;
- проверяет, что handoff commits, manifests и audit files консистентны;
- перед финалом запускает CRAP и DRY.
Не делает:
- не запускает language mutation и Gherkin mutation, если явно не попросили.
Передает дальше: completion broadcast с priority: 00.
QA -> specifier
QA -> coder
QA -> cleaner
QA -> architect
QA -> hardender
Смысл broadcast: все роли получают “QA complete”. Но локальное правило six-pack говорит, что QA handoff не прерывает текущую работу. Если агент занят, он игнорирует wake-up, а после done_with_current.sh очередь сама выдаст следующий item.
(продолжение далее...)
@deksden_notes
⚪️ Swarm-Forge, большой обзор (часть 5, последняя)
(вы удивитесь, но часть 4 - ранее ...)
▶️ Какие наборы проверок и инструментов встроены в флоу:
- APS / gherkin-parser проверяет: правильно ли описано внешнее поведение
- normal acceptance tests: система делает то, что описано
- Gherkin mutation: acceptance-примеры реально что-то значат и проверяют
- CRAP (Change Risk Anti-Pattern) : где сложный и плохо покрытый код
- DRY : где подозрительная структурная дубликация (юзаем проекты типа dry4ts, dry4go)
- language mutation : на самом деле ловят ли unit/acceptance tests сломанный код
Некоторые эти штуки требуют отдельного обзора про методики тестирования - немного выходит за рамки оркестратора.
▶️ Подход к обеспечению качества кода комплексный, и довольно интересен:
- Поведение фиксируется: specifier описывает фичи через Gherkin/acceptance criteria.
- Реализация идет через классический TDD: coder пишет unit тесты до кода, и прогоняет acceptance tests.
- Чистка отделена от реализации: cleaner улучшает имена, дублирование, локальную сложность и тестируемость, не добавляя нового поведения. Важно что это отдельная стадия.
- Архитектура проверяется отдельно: architect смотрит границы модулей, dependency direction, isolation от IO/UI/framework.
- Сила тестов проверяется мутационно: hardender мутирует код и Gherkin-примеры, чтобы найти слабые тесты и пустые acceptance checks. Это сильный подход к тестам.
- Финальная проверка независима: QA проверяет через пользовательский интерфейс и сверяет спецификацию, тесты, manifests и handoff-аудит. Лишний раз видим что агенту обязательно добавлять обратную связь о фиче.
▶️ Вот такой получился оркестратор и флоу - агентный Clean Code и инженерные TDD практики качественного кода от Дяди Боба! На мой взгляд - подход довольно оригинальный, сочетает в себе умеренную сложность и функциональную насыщенность. Нетиповые решения, насыщенный набор инструментов качества - мне в целом понравились набор подходов к тестированию / качеству кода. Буду чего то перенимать себе, однозначно.
Респект Дяде Бобу за интересный релиз!
@deksden_notes
(вы удивитесь, но часть 4 - ранее ...)
▶️ Какие наборы проверок и инструментов встроены в флоу:
- APS / gherkin-parser проверяет: правильно ли описано внешнее поведение
- normal acceptance tests: система делает то, что описано
- Gherkin mutation: acceptance-примеры реально что-то значат и проверяют
- CRAP (Change Risk Anti-Pattern) : где сложный и плохо покрытый код
- DRY : где подозрительная структурная дубликация (юзаем проекты типа dry4ts, dry4go)
- language mutation : на самом деле ловят ли unit/acceptance tests сломанный код
Некоторые эти штуки требуют отдельного обзора про методики тестирования - немного выходит за рамки оркестратора.
▶️ Подход к обеспечению качества кода комплексный, и довольно интересен:
- Поведение фиксируется: specifier описывает фичи через Gherkin/acceptance criteria.
- Реализация идет через классический TDD: coder пишет unit тесты до кода, и прогоняет acceptance tests.
- Чистка отделена от реализации: cleaner улучшает имена, дублирование, локальную сложность и тестируемость, не добавляя нового поведения. Важно что это отдельная стадия.
- Архитектура проверяется отдельно: architect смотрит границы модулей, dependency direction, isolation от IO/UI/framework.
- Сила тестов проверяется мутационно: hardender мутирует код и Gherkin-примеры, чтобы найти слабые тесты и пустые acceptance checks. Это сильный подход к тестам.
- Финальная проверка независима: QA проверяет через пользовательский интерфейс и сверяет спецификацию, тесты, manifests и handoff-аудит. Лишний раз видим что агенту обязательно добавлять обратную связь о фиче.
▶️ Вот такой получился оркестратор и флоу - агентный Clean Code и инженерные TDD практики качественного кода от Дяди Боба! На мой взгляд - подход довольно оригинальный, сочетает в себе умеренную сложность и функциональную насыщенность. Нетиповые решения, насыщенный набор инструментов качества - мне в целом понравились набор подходов к тестированию / качеству кода. Буду чего то перенимать себе, однозначно.
Респект Дяде Бобу за интересный релиз!
@deksden_notes
❤6👍1🤔1