⚪️ 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👍4✍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❤14🔥11👍1
⚪️ 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.
🔥9❤8🤮1👻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
👍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