⚪️ 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

⚪️ Codex Referal Reset


Как вы знаете, Кодекс ввел систему рефералок, - если по вашей ссылке регистрируется пользователь, вам и ему дают ресет.

▶️ Так как у меня много аккаунтов, я решил не брать плюс подписку на очередной аккаунт "из старых", а сделать новый аккаунт, благо доменов то у меня много! )) Аккаунты я делаю на свои домены, но вместо почты завожу алиас на simplelogin.io (там у меня премиум) куда у меня эти домены подключены.

Зарегавшись в chatgpt.com, я вернулся в кодекс.апп и оттуда на этот новый аккаунт отправил рефералку.

▶️ Не забываем на chagpt.com для новых аккаунтов включить для аккаунта passkey / 2fa. Я забыл, и у меня просила авторизацию через телефон (благо у меня этих ваших esim с номерами верификации щас полно). Надо будет еще раз попробовать - но уже со включенным 2fa/passkey, есть мнение, что в этом случае может НЕ просить верификацию, но не факт, надо проверять.

Тут надо сделать выход из своего аккаунта в кодекс.апп. На всякий случай взял с почты реферальную ссылку, и по ней перешел - она открывает кодекс.апп. Там вошел в новый аккаунт, и в чате поздоровался с кодексом. В этот момент ресет пришел)

▶️ В общем, для нового аккаунта все сработало: ресет дали и моему аккаунту, с которого я реферал делал, и новому (даже free) аккаунту! Понятно, что тратить ресет на free аккаунте довольно неразумно, надо будет его апнуть до Плюса.

▶️ Не на всех аккаунтах включилась возможность отправлять инвайты. Наверное, это только честно купленные аккаунты - но я не отслеживал закономерность. Имейте ввиду.

——
Upd 1️⃣ : проверил - нет, для новых аккаунтов 2fa/passkey не спасает от требования верификации - скорее всего, это защита от фрода.

И еще наблюдение: логин и логаут из кодекс.апп инвалидирует сессии в CPA / web.


@deksden_notes

⚪️ HTML отчеты - небольшой апдейт


Я уже говорил про тему с HTML отчетами

🔗 Вот оригинальный пост про подход: https://t.me/deksden_notes/837

Я их использую на каждый этап своих флоу, стараюсь что то важное показать, и, желательно, как то посимпатичнее, графиком там разбавить, или табличками.

▶️ Делаю просто: есть html шаблон, данные он берет из json, а этап флоу должен только сформировать этот json - не нужно каждый раз агенту упражняться с html, да и формат выходит консистентнее. Шаблоны - в доп материалах промпта (скилла)

▶️ Еще момент: агент, конечно, напишет в своем заключении по этапу что сделал такой то отчет. Но это надо кликнуть - а ведь еще удобнее, когда отчет просто сразу видно. Я сделал блок в промпт, чтобы оно работало почти везде - я использую CMUX сейчас, в нем есть скилл Cmux Browser: если он доступен, отчет откроется в CMUX. Если нет - использую скилл Agents Browser.

Вы можете аналогичным образом прописывать браузер вашей ADE, встроенные браузеры сейчас почти у всех - от кодекс апп, до курсора.

❓ Пользуете такое для UX разработки? Или только отладку фронта?

@deksden_notes

Привет :) Обещал упаковать красиво плагин для Фигмы



🧩 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

⚪️ 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

⚪️ 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

⚪️ 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

⚪️ 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

⚪️ 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

⚪️ Codex : добавили поддержку .worktreeinclude

▶️ Это небольшое, но важное улучшение для тех, кто активно работает с рабочими деревьями. Фича позволяет автоматом скопировать .env секреты и подобные файлы в рабочее дерево, чтобы агент не занимался этим сам, что рождает риск утечки секретов. Можно смело банить тулы агента от возможности даже читать подобные файлы!

Фича повторяет синтаксис .gitignore и срабатывает только для тех файлов, которые в .gitignore.

Хорошая добавка как к удобству, так и безопасности.

▶️ К слову - это почти стандарт становится: СС также поддержвиает такой файлик, как и некоторые сторонние инструменты.


🔗 Дока у кодекса: https://developers.openai.com/codex/app/worktrees#copy-ignored-local-files-into-managed-worktrees

🔗 Аналогичная фича у Антропиков: https://code.claude.com/docs/en/worktrees#copy-gitignored-files-into-worktrees

🔗 Аналогичная фича Conductor (для примера): https://www.conductor.build/docs/reference/worktreeinclude

🔗 WorkTrunk поддержка: https://worktrunk.dev/step/#wt-step-copy-ignored


(ц) мелочь, а приятно!

@deksden_notes

Что такое AI-Pulse

У меня в день набегает тысячи сообщений в чатиках про ИИ - всё это нереально прочитать. Поэтому собрал AI-Pulse

Теперь, чтобы быть в курсе русского AI-сообщества, не нужно читать все чаты и каналы подряд: главное собрано в одном месте - открыли, пробежали глазами и уже понимаете, что обсуждают и что думают. Бесплатно и экономит время

Отличие от стандартных дайджестов
Пульс дополнительно показывает:

💬 Настроение по каждой теме: что хвалят, где скепсис, где спорят. Блок «Голоса» - за и против

🛠 Полезное из чатов - лайфхаки, гайды, рабочие решения участников

📈 Динамика - что растёт, а что выдыхается: заметить новое раньше, чем о нём заговорят все

👆 Клик на тему - вся сводка в карточке: что это, о чём спорят, полезное, переход на первоисточник

🔗 Раздел «Ссылки» - видео, курсы и находки участников в одном месте

В основе - десятки чатов и каналов, десятки тысяч сообщений в неделю. Обновление - еженедельно

👉 aipulse-weekly.ru

⚪️ Factory AutoWiki


Тут Factory.ai изобрели RepoWiki из Qoder.

🔗 Блог : https://factory.ai/news/wiki

🔗 Дока: https://docs.factory.ai/cli/features/wiki/overview

Из забавного: система умеет генерировать ВИДЕО про ваш репозиторий - почти как notebookLM. Качество похуже, как мне показалось, голос занудный.

Еще умеет в ваш репо на гитхабе залить это wiki как, удивительно - да, WIKI!

Но забавная штука. Не уверен что имеет большую практическую ценность, но в свое время для своих репо я сделал wiki через qoder и с некоторым интересом его почитал!

❓ Что думаете? Упёрлось ли оно куда то?

@deksden_notes