⚪️ 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
👍7❤🔥2❤1
⚪️ 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
👍5❤2🔥2
⚪️ 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
❤6😱3👍1
⚪️ 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
❤16👍8🤔5🔥2
⚪️ 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
▶️ Это небольшое, но важное улучшение для тех, кто активно работает с рабочими деревьями. Фича позволяет автоматом скопировать .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
👍19🔥10
Forwarded from Семёнов Daily (AI)
Что такое AI-Pulse
У меня в день набегает тысячи сообщений в чатиках про ИИ - всё это нереально прочитать. Поэтому собрал AI-Pulse
Теперь, чтобы быть в курсе русского AI-сообщества, не нужно читать все чаты и каналы подряд: главное собрано в одном месте - открыли, пробежали глазами и уже понимаете, что обсуждают и что думают. Бесплатно и экономит время
Отличие от стандартных дайджестов
Пульс дополнительно показывает:
💬 Настроение по каждой теме: что хвалят, где скепсис, где спорят. Блок «Голоса» - за и против
🛠 Полезное из чатов - лайфхаки, гайды, рабочие решения участников
📈 Динамика - что растёт, а что выдыхается: заметить новое раньше, чем о нём заговорят все
👆 Клик на тему - вся сводка в карточке: что это, о чём спорят, полезное, переход на первоисточник
🔗 Раздел «Ссылки» - видео, курсы и находки участников в одном месте
В основе - десятки чатов и каналов, десятки тысяч сообщений в неделю. Обновление - еженедельно
👉 aipulse-weekly.ru
У меня в день набегает тысячи сообщений в чатиках про ИИ - всё это нереально прочитать. Поэтому собрал AI-Pulse
Теперь, чтобы быть в курсе русского AI-сообщества, не нужно читать все чаты и каналы подряд: главное собрано в одном месте - открыли, пробежали глазами и уже понимаете, что обсуждают и что думают. Бесплатно и экономит время
Отличие от стандартных дайджестов
Пульс дополнительно показывает:
💬 Настроение по каждой теме: что хвалят, где скепсис, где спорят. Блок «Голоса» - за и против
🛠 Полезное из чатов - лайфхаки, гайды, рабочие решения участников
📈 Динамика - что растёт, а что выдыхается: заметить новое раньше, чем о нём заговорят все
👆 Клик на тему - вся сводка в карточке: что это, о чём спорят, полезное, переход на первоисточник
🔗 Раздел «Ссылки» - видео, курсы и находки участников в одном месте
В основе - десятки чатов и каналов, десятки тысяч сообщений в неделю. Обновление - еженедельно
👉 aipulse-weekly.ru
2🔥26👍12❤5👎3🥱3
⚪️ 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
Тут Factory.ai изобрели RepoWiki из Qoder.
🔗 Блог : https://factory.ai/news/wiki
🔗 Дока: https://docs.factory.ai/cli/features/wiki/overview
Из забавного: система умеет генерировать ВИДЕО про ваш репозиторий - почти как notebookLM. Качество похуже, как мне показалось, голос занудный.
Еще умеет в ваш репо на гитхабе залить это wiki как, удивительно - да, WIKI!
Но забавная штука. Не уверен что имеет большую практическую ценность, но в свое время для своих репо я сделал wiki через qoder и с некоторым интересом его почитал!
❓ Что думаете? Упёрлось ли оно куда то?
@deksden_notes
👍8👏1
⚪️ Двойной Codex Reset
Лимиты кодекса не просто сбросили, так еще один ресет добавили в копилку!
Единственный момент: не всем ресет в копилку приехал - кому то пока не додали. Свои аккаунты пока не проверял, потом отпишусь
Nice
(ц) пляшем дальше!
——
Upd 1️⃣ : обнаружил, что сбросили даже на Free аккаунтах. Необычно!
——
Upd 2️⃣ : требуется уточнения по терминологии. Предлагаю так: ресет - это когда централизованно на сервисе вам сбросили лимиты, и начали тикать новые даты сброса.
Другой вид ресета - это то, что в хвиттере называют "bankable reset", который вам дают на аккаунт и который виден в codex.app в разделе usage, который вы сможете сами применить в удобный момент течение 30 дней.
‼️ Нужен русский термин для него! Удачного чего то не приходит на ум.
——
Upd 3️⃣ : Отложенный ресет, который мне на новый free аккаунт начислили при инвайте нового аккаунта, сохранился при переходе на Plus тариф! То есть апгрейд тарифа сохраняет ресет, что при апгрейде до Про-100/Про-200 весьма поднимает его ценность)) Хозяйке на заметку!)
Кстати - лайвхак "лесенка обновлений" тоже работает: сжигаете лимиты free - поднимаете до Плюса, получаете новые лимиты. Сжигаете все лимиты Плюса - повышаете до Про, получаете новые лимиты. Ну, вы поняли, да?)
@deksden_notes
Лимиты кодекса не просто сбросили, так еще один ресет добавили в копилку!
Единственный момент: не всем ресет в копилку приехал - кому то пока не додали. Свои аккаунты пока не проверял, потом отпишусь
Nice
(ц) пляшем дальше!
——
Upd 1️⃣ : обнаружил, что сбросили даже на Free аккаунтах. Необычно!
——
Upd 2️⃣ : требуется уточнения по терминологии. Предлагаю так: ресет - это когда централизованно на сервисе вам сбросили лимиты, и начали тикать новые даты сброса.
Другой вид ресета - это то, что в хвиттере называют "bankable reset", который вам дают на аккаунт и который виден в codex.app в разделе usage, который вы сможете сами применить в удобный момент течение 30 дней.
‼️ Нужен русский термин для него! Удачного чего то не приходит на ум.
——
Upd 3️⃣ : Отложенный ресет, который мне на новый free аккаунт начислили при инвайте нового аккаунта, сохранился при переходе на Plus тариф! То есть апгрейд тарифа сохраняет ресет, что при апгрейде до Про-100/Про-200 весьма поднимает его ценность)) Хозяйке на заметку!)
Кстати - лайвхак "лесенка обновлений" тоже работает: сжигаете лимиты free - поднимаете до Плюса, получаете новые лимиты. Сжигаете все лимиты Плюса - повышаете до Про, получаете новые лимиты. Ну, вы поняли, да?)
@deksden_notes
🔥14👍6❤4
⚪️ Очередной рыбный день! Без улова?
Сегодня четверг, который не раз становлися днем релизов. Но сегодня и вчера - в хвиттере тихо, что то не похоже.
Мне кажется, 5.6 перенесли, потому как смысла в релизе стало мало - 5.5 сейчас топовая модель и так, потому как опус 4.8 все таки будет местами попроще.
Думаю, пока ситуация с фублей не разрешится, вряд ли у клозедов есть хоть какая то логика в выпуске следующей модели: проще продолжать тренировать и улучшать свою. Может, USG свое регулирвоание сделает явным - единомоментно откатить новую модель с прода никому не интересно. А причины регулирвоания так и не ясны, как и критерии "безопасности".
К тому же гугол тоже затих с 3.5 про - хотя вроде поговаривали про месяц со дня io! Он прошел, но все тихо
Я скорее верю в sonnet 5 первым. На месте антропиков я бы ее выпусти как квант/прун от Мифоса/Фубли, но, типа - оно не такое умное и не опасное. Это даст буст продажам, а хороший кодер антропикам нужен.
❓ Что думаете?
@deksden_notes
Сегодня четверг, который не раз становлися днем релизов. Но сегодня и вчера - в хвиттере тихо, что то не похоже.
Мне кажется, 5.6 перенесли, потому как смысла в релизе стало мало - 5.5 сейчас топовая модель и так, потому как опус 4.8 все таки будет местами попроще.
Думаю, пока ситуация с фублей не разрешится, вряд ли у клозедов есть хоть какая то логика в выпуске следующей модели: проще продолжать тренировать и улучшать свою. Может, USG свое регулирвоание сделает явным - единомоментно откатить новую модель с прода никому не интересно. А причины регулирвоания так и не ясны, как и критерии "безопасности".
К тому же гугол тоже затих с 3.5 про - хотя вроде поговаривали про месяц со дня io! Он прошел, но все тихо
Я скорее верю в sonnet 5 первым. На месте антропиков я бы ее выпусти как квант/прун от Мифоса/Фубли, но, типа - оно не такое умное и не опасное. Это даст буст продажам, а хороший кодер антропикам нужен.
❓ Что думаете?
@deksden_notes
👍12🌚2💯2💅2❤1
Media is too big
VIEW IN TELEGRAM
⚪️ Покажи этому Кодексу! Record & Replay в Codex.app
Клозеды выкатывают фичу Record & Replay в Codex.app - вы показываете кодексу сеанс работы на компе с выполнением какой то задачи, а он превращает это в повторно используемый скилл.
Удобно использовать, когда показать проще чем написать словами. Стартуете скилл, обозначаете чего хотите сделать, кодекс спрашивает разрешения и начинает запись действий, вы выполняете работу, завершаете запись - и кодекс анализирует куда там вы тыкали, в какие экраны и делает драфт скилла.
потом когда хотим стартовать - просто зовем скилл с переменными параметрами (новый файл даем или чего то в этом духе).
Примерно так работает
Конечно, только macOS
Конечно, никакого доступа в Европии / UK.
Паспорт пока не требуют (ха ха - что, не смешно?)
🔗 Дока : https://developers.openai.com/codex/record-and-replay
🔗 Анонс : https://x.com/OpenAIDevs/status/2067681320281723113
(ц) не программингом единым
@deksden_notes
Клозеды выкатывают фичу Record & Replay в Codex.app - вы показываете кодексу сеанс работы на компе с выполнением какой то задачи, а он превращает это в повторно используемый скилл.
Удобно использовать, когда показать проще чем написать словами. Стартуете скилл, обозначаете чего хотите сделать, кодекс спрашивает разрешения и начинает запись действий, вы выполняете работу, завершаете запись - и кодекс анализирует куда там вы тыкали, в какие экраны и делает драфт скилла.
потом когда хотим стартовать - просто зовем скилл с переменными параметрами (новый файл даем или чего то в этом духе).
Примерно так работает
Конечно, только macOS
Конечно, никакого доступа в Европии / UK.
Паспорт пока не требуют (ха ха - что, не смешно?)
🔗 Дока : https://developers.openai.com/codex/record-and-replay
🔗 Анонс : https://x.com/OpenAIDevs/status/2067681320281723113
(ц) не программингом единым
@deksden_notes
👍12🔥7❤2😁1👻1
⚪️ Мультиплексоры сессий : tmux / Zellij / Herdr
❓Используете мельтиплексоры для cli агентов? Они позволяют сохранять сессии, даже если вы отключаетесь
Я вот думал таки заюзать Herdr, но не очень хочется отказываться от CMUX. Не уверен, что они здорово подружатся.
Ну и поверх всего этого надо бы прикрутить Moshi как мобильный теримнал, на всякий случай. Я как раз на своем квн сделал группу для своих устройств, теперь там почти аналог tailnet.
👉 Поделитесь кто на опыте, как вам такие штуки! Интересно было бы какой то опыт получить upfront, а не тыкаться самостоятельно во все грабли, особенно детские.
А я потом обзор / гайд напишу по итогам внедрения))
@deksden_notes
❓Используете мельтиплексоры для cli агентов? Они позволяют сохранять сессии, даже если вы отключаетесь
Я вот думал таки заюзать Herdr, но не очень хочется отказываться от CMUX. Не уверен, что они здорово подружатся.
Ну и поверх всего этого надо бы прикрутить Moshi как мобильный теримнал, на всякий случай. Я как раз на своем квн сделал группу для своих устройств, теперь там почти аналог tailnet.
👉 Поделитесь кто на опыте, как вам такие штуки! Интересно было бы какой то опыт получить upfront, а не тыкаться самостоятельно во все грабли, особенно детские.
А я потом обзор / гайд напишу по итогам внедрения))
@deksden_notes
👍6❤4🤔1
Forwarded from Phantom AI
⚡️ SuperGrok:
├ На ваш аккаунт 1 мес (CDK) — 959₽
└ На ваш аккаунт 2 мес (CDK) — 1 549₽😮 Gemini Pro:
└ Ссылка активация на ваш аккаунт 18 мес — 399₽🤞 ChatGpt:
├ PLUS 1 мес На ваш аккаунт (CDK) — 1 890₽
├ PRO X5 1 мес На ваш аккаунт (CDK) — 7 690₽
└ PRO X20 1 мес На ваш аккаунт (CDK) — 12 490₽😎 Claude:
├ PRO 1 мес На ваш аккаунт (CDK) — 1 890₽
├ MAX X5 1 мес На ваш аккаунт (CDK) — 6 499₽
└ MAX 20 1 мес На ваш аккаунт (CDK) — 12 990₽😵💫 Cursor:
├ PRO 1 мес Готовый аккаунт — 1 429₽
├ PRO+ 1 мес Готовый аккаунт — 3 690₽
└ ULTRA 1 мес Готовый аккаунт — 12 290₽⚡️ Perplexity:
└ PRO 1 ГОД На ваш аккаунт (CODE) — 2 690₽🤩 Antigravity:
├ ULTRA X5 На ваш аккаунт ( ИНВАЙТ) — 2 190₽
└ ULTRA X20 На ваш аккаунт ( ИНВАЙТ) — 1 490₽😿 Suno:
├ PRO 1 мес Готовый аккаунт — 890₽
└ PREMIER 1 мес Готовый аккаунт — 1990₽
DEKSDENCHATКУПИТЬ ПОДПИСКУ - https://t.me/phantomAI_shop_bot
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4😁2
⚪️ Нарезка задач
▶️ Я работаю с агентами через документ, который называю "протоколом" - это штука, которая связывает единым документом цикл от хотелки пользователя, ее проработку в некое ТЗ, планирование реализации, реализацию, мерж и проверки.
▶️ Один из этапов общего процесса - это анализ "габаритов" задачи. Тут у процесса есть тюнинг и "снизу" и "сверху". Щас поясню!
▶️ Если задача мелкая, то у меня тут две фичи имеются. Есть интерактивный режим - это когда мы с агентом работаем в режиме ИИ ассистента, когда он выполняет мелкие правки, я смотрю чего получилось. Чаще всего это доработка UI. Как мы такую сессию заканчиваем - далее по флоу идет процесс проработки изменений "по полной схеме" - с ревью изменений, рефакторингом, документированием, обновлением всякого, проверками всего на свете и то - все что свойственно "тяжелому флоу". Называется consolidation/hardening.
▶️ Далее есть упрощенный режим проработки планов, simple plan - когда доработка несложная или небольшая, то часть проработок не делается или делается в упрощенном режиме.
▶️ И есть "шейпинг" по верхнему габариту задачи. Если доработка огромная, оформляется общая спека на эту доработку, может быть даже с ADR если там решали чего, и оформляется пучок протоколов, которые эту доработку постепенно реализуют.
Режу объемы по такой логике: если это доставляемая фича продукта - то вертикальным слайсом. Но это не всегда, потому как могут быть доработки в слоях - ну там какую то подсистему докрутить. Или нужна какая то инфраструктура, контракт/ схема, миграция - тогда конечно это не слайс.
👉 Важно чтобы у каждого протокола была понятная одна цель и один сценарий для проверки. То есть чтобы можно было смело пускать goal по нему, не опасаясь дедлоков/циклов. Если это расползается, сценариев много, как и целей - верный кандидат на разделение.
❓ А вы как управляете габаритами работ в своих флоу? Шейпите? Какая логика? Поделитесь!
@deksden_notes
▶️ Я работаю с агентами через документ, который называю "протоколом" - это штука, которая связывает единым документом цикл от хотелки пользователя, ее проработку в некое ТЗ, планирование реализации, реализацию, мерж и проверки.
▶️ Один из этапов общего процесса - это анализ "габаритов" задачи. Тут у процесса есть тюнинг и "снизу" и "сверху". Щас поясню!
▶️ Если задача мелкая, то у меня тут две фичи имеются. Есть интерактивный режим - это когда мы с агентом работаем в режиме ИИ ассистента, когда он выполняет мелкие правки, я смотрю чего получилось. Чаще всего это доработка UI. Как мы такую сессию заканчиваем - далее по флоу идет процесс проработки изменений "по полной схеме" - с ревью изменений, рефакторингом, документированием, обновлением всякого, проверками всего на свете и то - все что свойственно "тяжелому флоу". Называется consolidation/hardening.
▶️ Далее есть упрощенный режим проработки планов, simple plan - когда доработка несложная или небольшая, то часть проработок не делается или делается в упрощенном режиме.
▶️ И есть "шейпинг" по верхнему габариту задачи. Если доработка огромная, оформляется общая спека на эту доработку, может быть даже с ADR если там решали чего, и оформляется пучок протоколов, которые эту доработку постепенно реализуют.
Режу объемы по такой логике: если это доставляемая фича продукта - то вертикальным слайсом. Но это не всегда, потому как могут быть доработки в слоях - ну там какую то подсистему докрутить. Или нужна какая то инфраструктура, контракт/ схема, миграция - тогда конечно это не слайс.
👉 Важно чтобы у каждого протокола была понятная одна цель и один сценарий для проверки. То есть чтобы можно было смело пускать goal по нему, не опасаясь дедлоков/циклов. Если это расползается, сценариев много, как и целей - верный кандидат на разделение.
❓ А вы как управляете габаритами работ в своих флоу? Шейпите? Какая логика? Поделитесь!
@deksden_notes
1👍11❤6🔥5
⚪️ HTTP QUERY
Не прошло и 10 лет (нет, прощло, кстати), как стандартизация HTTP Query метода почти закончета! Ну да ладно, зато все наконец то двигается.
▶️ В чем проблема? В дизайне API. Чтобы сделать запрос к апи, сейчас используют несколько вариантов. Например,
Сложность с этим в том, что прааметры запроса в URL могут иметь разный допустимый размер, ограничивающися в разных системах через который проходит запрос. Приходится кодировать данные для передачи в URL. В логах видны, что прегружает логи. Неудобно. А засунуть в body запрос нельзя, потому что нету такой принятой семантики у body для GET, не поддержвиается.
Для решения этих проблем часто используют:
Но проблема идемпотентности такого запроса - чисто серверная. Можно ли повторять запрос при сетевых сбоях? Не ясно. И кеширование тут ограничено. И, самое главное, ломается семантика. Мы хотим просто сделать запрос (не меняя объект), а метод используем, который подразумевает изменение ресурса! Оч нелогично, и это договоренность на уровне апи системы, окружающая инфраструктура (кеши, прокси, браузеры, файерволы, ...) всего этог оне понимают.
Предложено решение, берущее лучшее из обоих подходов:
Как у POST параметры в body. Как GET имеет семантику безопасного запроса на чтение. Идемпотентный, кешируемый. Сервер может вернуть Location или Content-Location, чтобы потом клиент мог обращаться к результату через обычный GET.
В общем, одни плюсы! Осталось чтобы поддержка дошла до всех систем, но со стандартом оно проще пойдет!
🔗 Почитать: https://datatracker.ietf.org/doc/rfc10008/
▶️ Зачем пишу? Для агентов любое АПИ важно, оно им удобнее и понятнее. Развитие стандартов для апи, получается, профильная тема.
(ц) хорошие говсти, в принципе!
@deksden_notes
Не прошло и 10 лет (нет, прощло, кстати), как стандартизация HTTP Query метода почти закончета! Ну да ладно, зато все наконец то двигается.
▶️ В чем проблема? В дизайне API. Чтобы сделать запрос к апи, сейчас используют несколько вариантов. Например,
GET /feed?q=foo&limit=10&sort=-published HTTP/1.1
Host: example.org
Сложность с этим в том, что прааметры запроса в URL могут иметь разный допустимый размер, ограничивающися в разных системах через который проходит запрос. Приходится кодировать данные для передачи в URL. В логах видны, что прегружает логи. Неудобно. А засунуть в body запрос нельзя, потому что нету такой принятой семантики у body для GET, не поддержвиается.
Для решения этих проблем часто используют:
POST /feed HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
q=foo&limit=10&sort=-published
Но проблема идемпотентности такого запроса - чисто серверная. Можно ли повторять запрос при сетевых сбоях? Не ясно. И кеширование тут ограничено. И, самое главное, ломается семантика. Мы хотим просто сделать запрос (не меняя объект), а метод используем, который подразумевает изменение ресурса! Оч нелогично, и это договоренность на уровне апи системы, окружающая инфраструктура (кеши, прокси, браузеры, файерволы, ...) всего этог оне понимают.
Предложено решение, берущее лучшее из обоих подходов:
QUERY /feed
Content-Type: application/x-www-form-urlencoded
q=foo&limit=10&sort=-published
Как у POST параметры в body. Как GET имеет семантику безопасного запроса на чтение. Идемпотентный, кешируемый. Сервер может вернуть Location или Content-Location, чтобы потом клиент мог обращаться к результату через обычный GET.
В общем, одни плюсы! Осталось чтобы поддержка дошла до всех систем, но со стандартом оно проще пойдет!
🔗 Почитать: https://datatracker.ietf.org/doc/rfc10008/
▶️ Зачем пишу? Для агентов любое АПИ важно, оно им удобнее и понятнее. Развитие стандартов для апи, получается, профильная тема.
(ц) хорошие говсти, в принципе!
@deksden_notes
🔥11❤4👍1
⚪️ Codex Cloud - всё
Нет, по ссылке он всё еще доступен! и даже работает
но из веб приложения chatGPT его убрали
Даже не могу понять - к чему бы это всё, но точно - неспроста
❓ что думаете?
——
Upd 1️⃣ : ярлычок вернули в приложение, но он теперь открываает рекламку. Скрины в комментах
@deksden_notes
Нет, по ссылке он всё еще доступен! и даже работает
но из веб приложения chatGPT его убрали
Даже не могу понять - к чему бы это всё, но точно - неспроста
❓ что думаете?
——
Upd 1️⃣ : ярлычок вернули в приложение, но он теперь открываает рекламку. Скрины в комментах
@deksden_notes
Forwarded from Aleksei
Полгода назад я устал смотреть, как AI-агенты перед каждой правкой читают пол-репозитория вслепую через rg/find/cat, жгут контекст и всё равно не видят, что сломается и всех зависимостей.
И тогда я сделал скилл codespaces: он строит из всей кодовой базы запрашиваемый граф .belief_map.sexp (модули, сущности, импорты, вызовы, data-flow) через tree-sitter и ast, так что вместо слепого чтения он одним запросом получает точную границу изменения, зону поражения (rdeps), слой модуля и границы архитектуры, usages и другие виды связей.
За полгода в проде это серьёзно ускорило разрабоку и улучшило по коду, сделало рефакторинг достаточно предсказуемым (насколько это возможно с помощью агента) и заметно улучшило работу агентов на больших монорепо. Решил выложить в общий доступ.
Ставится одной командой:
https://www.skills.sh/diskd-ai/codespaces
https://github.com/diskd-ai/codespaces
Вызов в одной фразе, которую стоит закрепить в инструкциях агента (AGENTS.md, CLAUDE.md):
Перед любой нетривиальной правкой кода сначала запрашивай belief map (search -> analyze -> rdeps), читай только boundary-файлы, и проверяй boundaries после изменений.
Буду рад фидбэку, звездам и тд и тп.
И тогда я сделал скилл codespaces: он строит из всей кодовой базы запрашиваемый граф .belief_map.sexp (модули, сущности, импорты, вызовы, data-flow) через tree-sitter и ast, так что вместо слепого чтения он одним запросом получает точную границу изменения, зону поражения (rdeps), слой модуля и границы архитектуры, usages и другие виды связей.
За полгода в проде это серьёзно ускорило разрабоку и улучшило по коду, сделало рефакторинг достаточно предсказуемым (насколько это возможно с помощью агента) и заметно улучшило работу агентов на больших монорепо. Решил выложить в общий доступ.
Ставится одной командой:
npx skills add diskd-ai/codespaceshttps://www.skills.sh/diskd-ai/codespaces
https://github.com/diskd-ai/codespaces
Вызов в одной фразе, которую стоит закрепить в инструкциях агента (AGENTS.md, CLAUDE.md):
Перед любой нетривиальной правкой кода сначала запрашивай belief map (search -> analyze -> rdeps), читай только boundary-файлы, и проверяй boundaries после изменений.
Буду рад фидбэку, звездам и тд и тп.
❤23🔥17👍6
Forwarded from Max Syabro and a Slop Driven Development
https://github.com/syabro/pi-web-search
Запилил себе поиск под PI.
Нашел 5 API-Search провайдеров с фри тиром, которые переключаются когда кончается лимиты
Monthly free quotas:
- Exa — 20,000 searches/month
- Brave — ~1,000 searches/month
- Tavily — 1,000 searches/month
Starter free quotas:
- Parallel — ~16,000 searches
- Serper — 2,500 searches
Думаю для личного пользования этого за глаза
PS Думаю про мсп, но мне кажется у клода,кодекса и антигрваити уже из коробки есть
Запилил себе поиск под PI.
Нашел 5 API-Search провайдеров с фри тиром, которые переключаются когда кончается лимиты
Monthly free quotas:
- Exa — 20,000 searches/month
- Brave — ~1,000 searches/month
- Tavily — 1,000 searches/month
Starter free quotas:
- Parallel — ~16,000 searches
- Serper — 2,500 searches
Думаю для личного пользования этого за глаза
PS Думаю про мсп, но мне кажется у клода,кодекса и антигрваити уже из коробки есть
2🔥12👍7❤🔥2❤1
⚪️ 5.6 - пошёл прогрев!
В твитетрах народ постит "утечки". Верный знак. Неужели завтра? Посмотрим!..
@deksden_notes
В твитетрах народ постит "утечки". Верный знак. Неужели завтра? Посмотрим!..
@deksden_notes
🔥14👍11👀3❤🔥1❤1
Forwarded from ABI
Сделал лёгкий MCP-мост для семантического поиска по коду с использованием Zvec и локальных эмбеддингов.
Он индексирует файлы проекта и позволяет искать по смыслу, а не только по ключевым словам, что особенно удобно для больших кодовых баз и быстрого поиска по похожим реализациям.
Если интересно, посмотрите проект здесь: https://github.com/ABIvan-Tech/zvec-mcp
Крайне приветствуются Issue & PR
#opensource
Он индексирует файлы проекта и позволяет искать по смыслу, а не только по ключевым словам, что особенно удобно для больших кодовых баз и быстрого поиска по похожим реализациям.
Если интересно, посмотрите проект здесь: https://github.com/ABIvan-Tech/zvec-mcp
Крайне приветствуются Issue & PR
#opensource
GitHub
GitHub - ABIvan-Tech/zvec-mcp
Contribute to ABIvan-Tech/zvec-mcp development by creating an account on GitHub.
👍10🔥5❤2👌2