Way back context
О технике промптинга
Интересно, как быстро вендоры додумаются до сворачивания истории «прыжком в прошлое»?
Чтобы контекст экономить.
Типа, модель что то делала-делала, и у нее наконец получилось (или не получилось) - и мы режем историю, возвращаемся в момент когда это все только начиналось и рассказываем модели чем все кончилось (успех или неуспех). Как в «назад в будущее».
Результат? Экономия контекста, эффективные «хождения кругами», без траты контекста, cache friendly к слову!
Пока я это иногда делаю руками для своих сообщений в кодексе с esc esc - типа обсудил что то детальное, уяснил, вернулся к старту обсуждения и продолжил по первоначальной теме разговор.
Но это будет дико полезно для любой агентной работы!
О технике промптинга
Интересно, как быстро вендоры додумаются до сворачивания истории «прыжком в прошлое»?
Чтобы контекст экономить.
Типа, модель что то делала-делала, и у нее наконец получилось (или не получилось) - и мы режем историю, возвращаемся в момент когда это все только начиналось и рассказываем модели чем все кончилось (успех или неуспех). Как в «назад в будущее».
Результат? Экономия контекста, эффективные «хождения кругами», без траты контекста, cache friendly к слову!
Пока я это иногда делаю руками для своих сообщений в кодексе с esc esc - типа обсудил что то детальное, уяснил, вернулся к старту обсуждения и продолжил по первоначальной теме разговор.
Но это будет дико полезно для любой агентной работы!
1🔥10💯4👍1👻1
Экономическое
Уже и грок сравнивает во сколько раз он дешевле антропиков!
https://x.com/xfreeze/status/1993328493359215054?s=46
Сомнительное реноме на рынке.
#post
@deksden_notes
Уже и грок сравнивает во сколько раз он дешевле антропиков!
https://x.com/xfreeze/status/1993328493359215054?s=46
Сомнительное реноме на рынке.
#post
@deksden_notes
X (formerly Twitter)
X Freeze (@XFreeze) on X
Grok 4.1 Fast ranks #1 𝜏²-Bench for Telecom Agentic Tool Use - with 93% accuracy outperforming Claude Opus 4.5 & Gemini 3 Pro
Tool calling is where the whole game is for AI agents, and this is where Grok 4.1 Fast takes over
While costing up-to 50x less…
Tool calling is where the whole game is for AI agents, and this is where Grok 4.1 Fast takes over
While costing up-to 50x less…
Agents по антропиковски
Анты тут бросили интересную статейку прочитать
Effective harnesses for long-running agents
🔗 https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
Замечу - опять harness вместо scaffold. Ну - упряжка, так упряжка. "Запрягайте, братцы конев!" ))
🟢 Статейка годная, откровений не содержит, но из категории обязательных к прочтению про AI SWE. Посему чувствую моральную обязанность чиркнуть "разбор".
Глянул код. Забавно - прога примера на питоне, использует Agents SDK чтобы сделать прогу на JS )) Причем, через АПИ ключ, они не могли по-другому! (тут вставляем мем "Платно!" с гослингом).
▶️ Спека в .txt, но внутри все структурировано XML-like тегами с легким md форматированием. Хозяйке на заметку - теги никто не отменял. В мой список приемов контекст-инжиниринга, конечно тоже входит.
Разделы спеки: техстек - фрон/бэк, настройка Dev окружения, список фич приложения, схема БД, спека ручек апи, схема UI морды, отдельно - дизайн система, отдельно - ключевые взаимодействия в UI, мастер план создания приложения по шагам с задачами каждого шага, список критериев успеха (ACs, gates).
Спека вроде бы достаточно краткая, тезисная, но содержит впечатляющего разнообразия набор разделов, есть о чем сделать вывод для своих спеков.
▶️ Даже в промпте первой стадии инициализации указано чтобы файл списка фич он не трогал. Капсом. Значит они знают как агент любит "срезать углы" - делали фичи, устали, удалили половину фич, и сказали что все уже сделали))
Также сохранение контекста - через файловую систему, но инструкции довольно примитивные. По мне так очень не очень.
▶️ Кодинговый агент - идентично моему протоколу, есть фаза проверок. Не рабоатем, если проверки падают.
Понятно, что агент работает ТОЛЬКО с верификацией: пишем код, проверяем через тесты.
Также много заборов в промпте чтобы углы не срезал. Какие? Протестировать только бэк без взаимодействия с фронтом, нет контроля визуала, использовать JS эвалы вместо UI взаимодействия, отметить тесты проходящими без верификации.
С учетом, что промпт - это пример, даже в нем столько заборов. Для реальной системы их должно быть еще больше. Думаю, даже фокусная сессия отдельного агента на чистом контексте с фокусной задачей верификации на каждый аспект - видимо, иначе нынче никак. Вот вам откуда 6-8 часов работы у кодомашины! Мои флоу тоже часами бегают, пока как быстрее я не знаю.
Также используют файл статуса (как мой context.md), но у них claude-progress.txt - более семантическое имя, к слову.
Также отмечу: много раз указано что времени у агента unlimited, типа - спешить не стоит! Видимо, не только у кодекса агенты вечно куда то опаздывают и спешат. Что RL с нейросетями делает, нервные и задерганные они все какие нынче.
...
Анты тут бросили интересную статейку прочитать
Effective harnesses for long-running agents
🔗 https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
Замечу - опять harness вместо scaffold. Ну - упряжка, так упряжка. "Запрягайте, братцы конев!" ))
🟢 Статейка годная, откровений не содержит, но из категории обязательных к прочтению про AI SWE. Посему чувствую моральную обязанность чиркнуть "разбор".
Глянул код. Забавно - прога примера на питоне, использует Agents SDK чтобы сделать прогу на JS )) Причем, через АПИ ключ, они не могли по-другому! (тут вставляем мем "Платно!" с гослингом).
▶️ Спека в .txt, но внутри все структурировано XML-like тегами с легким md форматированием. Хозяйке на заметку - теги никто не отменял. В мой список приемов контекст-инжиниринга, конечно тоже входит.
Разделы спеки: техстек - фрон/бэк, настройка Dev окружения, список фич приложения, схема БД, спека ручек апи, схема UI морды, отдельно - дизайн система, отдельно - ключевые взаимодействия в UI, мастер план создания приложения по шагам с задачами каждого шага, список критериев успеха (ACs, gates).
Спека вроде бы достаточно краткая, тезисная, но содержит впечатляющего разнообразия набор разделов, есть о чем сделать вывод для своих спеков.
▶️ Даже в промпте первой стадии инициализации указано чтобы файл списка фич он не трогал. Капсом. Значит они знают как агент любит "срезать углы" - делали фичи, устали, удалили половину фич, и сказали что все уже сделали))
Также сохранение контекста - через файловую систему, но инструкции довольно примитивные. По мне так очень не очень.
▶️ Кодинговый агент - идентично моему протоколу, есть фаза проверок. Не рабоатем, если проверки падают.
Понятно, что агент работает ТОЛЬКО с верификацией: пишем код, проверяем через тесты.
Также много заборов в промпте чтобы углы не срезал. Какие? Протестировать только бэк без взаимодействия с фронтом, нет контроля визуала, использовать JS эвалы вместо UI взаимодействия, отметить тесты проходящими без верификации.
С учетом, что промпт - это пример, даже в нем столько заборов. Для реальной системы их должно быть еще больше. Думаю, даже фокусная сессия отдельного агента на чистом контексте с фокусной задачей верификации на каждый аспект - видимо, иначе нынче никак. Вот вам откуда 6-8 часов работы у кодомашины! Мои флоу тоже часами бегают, пока как быстрее я не знаю.
Также используют файл статуса (как мой context.md), но у них claude-progress.txt - более семантическое имя, к слову.
Также отмечу: много раз указано что времени у агента unlimited, типа - спешить не стоит! Видимо, не только у кодекса агенты вечно куда то опаздывают и спешат. Что RL с нейросетями делает, нервные и задерганные они все какие нынче.
...
Anthropic
Effective harnesses for long-running agents
Anthropic is an AI safety and research company that's working to build reliable, interpretable, and steerable AI systems.
👍8🔥5❤2
Agents по антропиковски, ч2
...
Продолжим с разбором самой статейки.
▶️ Вначале рассказывают почему ваншоты сложных штук не взлетают, спотыкаясь о контекст. Впрочем, это довольно очевидно.
Проблема компакта разделена на два аспекта:
- забытые точные инструкции посередине реализации;
- новый контекст агента неправильно считывает статус выполнения задачи, поверхностно - что ведет к отметке выполненными недоделанных задач;
Как они порешали для поставленной задачи проблему:
- сделали сначала описание всей задачи,
- разбили задачу на более мелкие подзадачи
- работают с подзадачей в "оборудованном" окружении
- подзадача начинается в понятном состоянии проекта
- работаем с верификацией
- фиксируем статус работы в файл, передача статуса через контекст не срабатывает (компакты беспощадны)
- рабоатем многими контекстами
Да, кто смотрел #DeksdenFlow - все именно так и заведено. Те же шаги на итерацию, также сохраняемся в файл. Да, у меня чуть более навороченно - но это и понятно, у меня то "настоящий" flow, а не пример к статье.
Также шаг 0 заключается в инициализации всего процесса и подготовки окружения.
▶️ Для длительной работы анты аналогично пришли к системе - делаем коммит в гит, записываем статус процесса в файл. Они отметили важным что каждая итерация должна оставить систему в относительно консистентном состоянии - проверки проходят, коммит сделан, репо чистое.
▶️ Далее в статье особо отмечено что агент любит привирать и метить фичи сделанными без надлежащего тестирования. Промпты примера пытаются оградить от такого поведения:
- помимо необходимости тестов, особо отмечено необходимость e2e тестирования!
👉 Надо, видимо, написать про тестирование, видимо это неочевидно что e2e нужно обязательно, и как раз без других видов тестирвоания можно обойтись, но не без этого. Причем, многие то его руками делают, протыкивая типичный флоу с приложухой.
Анты делают вывод что если у агента появляется обратная связь от работы веб приложения - то это улучшает качество. Некоторое капитанство, но это правда от и до. Без демонстрации модели в браузере чего она там наворотила я не понимаю как можно что то работающее получить. Может, новые модели ваншотят кое что без ошибок, но я бы в более менее реальных приложениях такого бы не ждал - только верификация.
▶️ Также как и в моем протоколе - анты опираются на изучение лога гита для ориентировки агента. Это логично и работает.
▶️ Там есть даже зачатки некоего меморибанка, где агент в init.sh скрипте читает как работать с проектом, как чего делать. Думаю, меморибанк точно нужен, но грамотно скомпонованный - впрочем, это отдельная большая тема для дискуссий!
▶️ Далее говорится что если делать специализированных агентов на каждый класс задач, то можно улучшить качество. Типа, агент тестирования, агент QA, агент code cleanup, ... Ну а кто спорит? Фокусная работа, как я это называю, дает свои результаты! Спасибо антропик, за верификацию подхода))
🟢 В общем, прикольно было верифицировать некоторые подходы мнением фронтирной топовой лабы!
(ц) Такое мы читаем
#post
@deksden_notes
...
Продолжим с разбором самой статейки.
▶️ Вначале рассказывают почему ваншоты сложных штук не взлетают, спотыкаясь о контекст. Впрочем, это довольно очевидно.
Проблема компакта разделена на два аспекта:
- забытые точные инструкции посередине реализации;
- новый контекст агента неправильно считывает статус выполнения задачи, поверхностно - что ведет к отметке выполненными недоделанных задач;
Как они порешали для поставленной задачи проблему:
- сделали сначала описание всей задачи,
- разбили задачу на более мелкие подзадачи
- работают с подзадачей в "оборудованном" окружении
- подзадача начинается в понятном состоянии проекта
- работаем с верификацией
- фиксируем статус работы в файл, передача статуса через контекст не срабатывает (компакты беспощадны)
- рабоатем многими контекстами
Да, кто смотрел #DeksdenFlow - все именно так и заведено. Те же шаги на итерацию, также сохраняемся в файл. Да, у меня чуть более навороченно - но это и понятно, у меня то "настоящий" flow, а не пример к статье.
Также шаг 0 заключается в инициализации всего процесса и подготовки окружения.
▶️ Для длительной работы анты аналогично пришли к системе - делаем коммит в гит, записываем статус процесса в файл. Они отметили важным что каждая итерация должна оставить систему в относительно консистентном состоянии - проверки проходят, коммит сделан, репо чистое.
▶️ Далее в статье особо отмечено что агент любит привирать и метить фичи сделанными без надлежащего тестирования. Промпты примера пытаются оградить от такого поведения:
- помимо необходимости тестов, особо отмечено необходимость e2e тестирования!
👉 Надо, видимо, написать про тестирование, видимо это неочевидно что e2e нужно обязательно, и как раз без других видов тестирвоания можно обойтись, но не без этого. Причем, многие то его руками делают, протыкивая типичный флоу с приложухой.
Анты делают вывод что если у агента появляется обратная связь от работы веб приложения - то это улучшает качество. Некоторое капитанство, но это правда от и до. Без демонстрации модели в браузере чего она там наворотила я не понимаю как можно что то работающее получить. Может, новые модели ваншотят кое что без ошибок, но я бы в более менее реальных приложениях такого бы не ждал - только верификация.
▶️ Также как и в моем протоколе - анты опираются на изучение лога гита для ориентировки агента. Это логично и работает.
▶️ Там есть даже зачатки некоего меморибанка, где агент в init.sh скрипте читает как работать с проектом, как чего делать. Думаю, меморибанк точно нужен, но грамотно скомпонованный - впрочем, это отдельная большая тема для дискуссий!
▶️ Далее говорится что если делать специализированных агентов на каждый класс задач, то можно улучшить качество. Типа, агент тестирования, агент QA, агент code cleanup, ... Ну а кто спорит? Фокусная работа, как я это называю, дает свои результаты! Спасибо антропик, за верификацию подхода))
🟢 В общем, прикольно было верифицировать некоторые подходы мнением фронтирной топовой лабы!
(ц) Такое мы читаем
#post
@deksden_notes
🔥11❤2👍1
Тестирование в эпоху AI агентов ч1/3
Попробую изложить имеющиеся соображения по тестированию и подходов к нему в некотором преломлении к агентам. Может быть покапитанствую местами - но куда ж без этого)
Сначала о термине "тестирование". Это огромная тема, весьма многогранная, посему вначале нужно выровниться (как говаривает кодекс) по терминологии. Я буду про тестирование, которое автоматические тесты, которые мы запускаем через какой то раннер, и которые чего то ожидают (Expectations), чего то делают, чего там в итоге проверяют как оно вышло (Assertions). Методики типа TDD нам выходят ортогонально - из этой же темы, но другое направление, и их мы пропустим.
▶️ Тесты я поделю так:
- юнит тесты
- полу- и интеграционные тесты, бизнес-процессы
- специализированные тесты: ui, компонентные
- ну и хватит, этого уже достаточно
1️⃣ Юнит тесты: самые простые тесты для кусочков кода. Они тестируют базовые алгоритмы в коде и делаются изолированно - если в алгоритме используем внешние зависимости, то всегда их мокаем - делаем имитацию внешней зависимости с предопределенным поведением.
2️⃣ Все варианты e2e тестов (e2e = end-to-end, интеграционные тесты): это когда наши зависимости уже не мокаются (тогда интеграционные), или не полностью мокаются (может стаб используем для части тестов, или мок - но часть зависимостей "боевая"). Когда несколько кусков вашего кода взаимодействуют мы можем проверить как оно работает вместе.
Бизнес-процессы- это такие "сквозные" интеграционные тесты, которые используют фичи приложения в приближенной к "боевой" среде, представляя собой некий сценарий использования системы пользователем, проверяя как система в целом работает.
3️⃣ Специализированные тесты: тут можно тестировать какой то интерфейс, дергая его через инструменты наподобие Playwright / Selenium - причем как алгоритмически так и агентами через соответственный MCP.
В эту же группу запишем компонентные тесты, когда у нас дергается специфический сложный компонент и проверяется как он себя ведет в разных режимах.
▶️ Пару слов о раннерах - это софт, который позволяет описать тесты и запускать их, учитывая чего там у нас упало, брать логи и прочее. Примеры: Vitest, Jest, Playwright Test, всякие xUnit, и еще миллион разныш штук для разных языков / стеков / технологий.
...
Попробую изложить имеющиеся соображения по тестированию и подходов к нему в некотором преломлении к агентам. Может быть покапитанствую местами - но куда ж без этого)
Сначала о термине "тестирование". Это огромная тема, весьма многогранная, посему вначале нужно выровниться (как говаривает кодекс) по терминологии. Я буду про тестирование, которое автоматические тесты, которые мы запускаем через какой то раннер, и которые чего то ожидают (Expectations), чего то делают, чего там в итоге проверяют как оно вышло (Assertions). Методики типа TDD нам выходят ортогонально - из этой же темы, но другое направление, и их мы пропустим.
▶️ Тесты я поделю так:
- юнит тесты
- полу- и интеграционные тесты, бизнес-процессы
- специализированные тесты: ui, компонентные
- ну и хватит, этого уже достаточно
1️⃣ Юнит тесты: самые простые тесты для кусочков кода. Они тестируют базовые алгоритмы в коде и делаются изолированно - если в алгоритме используем внешние зависимости, то всегда их мокаем - делаем имитацию внешней зависимости с предопределенным поведением.
2️⃣ Все варианты e2e тестов (e2e = end-to-end, интеграционные тесты): это когда наши зависимости уже не мокаются (тогда интеграционные), или не полностью мокаются (может стаб используем для части тестов, или мок - но часть зависимостей "боевая"). Когда несколько кусков вашего кода взаимодействуют мы можем проверить как оно работает вместе.
Бизнес-процессы- это такие "сквозные" интеграционные тесты, которые используют фичи приложения в приближенной к "боевой" среде, представляя собой некий сценарий использования системы пользователем, проверяя как система в целом работает.
3️⃣ Специализированные тесты: тут можно тестировать какой то интерфейс, дергая его через инструменты наподобие Playwright / Selenium - причем как алгоритмически так и агентами через соответственный MCP.
В эту же группу запишем компонентные тесты, когда у нас дергается специфический сложный компонент и проверяется как он себя ведет в разных режимах.
▶️ Пару слов о раннерах - это софт, который позволяет описать тесты и запускать их, учитывая чего там у нас упало, брать логи и прочее. Примеры: Vitest, Jest, Playwright Test, всякие xUnit, и еще миллион разныш штук для разных языков / стеков / технологий.
...
🔥6❤🔥2👍1
Тестирование в эпоху AI агентов ч2/3
...
Теперь к некоторым техникам.
Хочу поделится парой моментов.
‼️ Эфемерная БД: сейчас модно и молодежно использовать в проектах штуки типа Neon / Supabase. Это postgres но с сервисами. Гонять облачную БД для тестов - немного неспешно.
Возможное решение: эфемерной локальная БД. Мы поднимаем локальную БД докером, делаем для нее volume в оперативной памяти, и гоняем тесты в этой базе. Почему такой термин - эфемерная? Потому что как только отключим том или гасим докер, то база просто пропадает. Для тестов - самое оно. Раз в 8-10 быстрее бегает, чем с облачной БД. Рекомендую.
‼️ World ID. Задача: для каждого теста хотим свой набор данных, чтобы реализовывать задуманный сценарий с детерминированным состоянием БД. Хотим чтобы тесты выполнялись параллельно. Как обеспечить?
Предлагаю такое решение: небольшое "Начало" / мультиверс, а если без художественных аналогий, то "мягкое шардирование".
Мы добавляем в каждую табличку БД поле world-id, идентификатор "мира". И индексы PK каждой таблички переделываем на использование world-id + id. Для чтения используем WHERE world-id = нужный нам мир.
Суть в том, чтобы получить возможность параллельно хранить в БД разные наборы данных. Чтобы для каждого теста мочь быстро создать такой набор данных.
🟢 Плюсы такого подхода:
- создать мир ничего не стоит - просто новый ключ для world-id.
- нет заморочек с миграциями - используем одну БД;
- нет проблем с коннектами; используем основной коннект;
🔴 Минусы:
- в каждый запрос добавляем world-id;
- я обычно добавляю такую штуку в слой доступа к данным (repository pattern), чтобы это было автоматом и прозрачно; тогда использовать очень просто;
- можно использовать RLS (row level security) для автоматизации на уровне БД :
- ALTER TABLE users ENABLE ROW LEVEL SECURITY;
- CREATE POLICY isolate_worlds ON users USING (world_id = current_setting('app.current_world_id')::uuid);
- SET app.current_world_id = 'uuid-вашего-мира';
- ключи обязательно включают world-id, но я использую UUID как ключи - поэтому все проще;
- чистить БД чуть дольше, но эфемерную БД после тестов можно просто погасить, без очистки;
▶️ Альтернативные варианты:
* делать отдельные БД для каждого теста: жирновато и медленно - делаем БД, накатываем схему, накатываем сид; просто чистить - дропаем базу;
* делать отдельную схему для каждого теста - SCHEMAS (Namespaces); почти так же муторно как создавать БД, та же проблема с миграциями; зато для очистки простой DROP SCHEMA;
* транзакции - сложность с кодом, который использует транзакции, потому что вложенные транзакции это немного больно и надо переходить на SAVEPOINTS (и переделать все хуки если они имеются - по мне так рефакторинг немаленький); мне не очень подходит чтобы переделывать транзакции; сложность с обработкой запросов в разных подключениях, например в интеграционных тестах апи;
В общем, если важно быстро сделать новый мир - тогда world-id. В проде world-id всегда null.
...
...
Теперь к некоторым техникам.
Хочу поделится парой моментов.
‼️ Эфемерная БД: сейчас модно и молодежно использовать в проектах штуки типа Neon / Supabase. Это postgres но с сервисами. Гонять облачную БД для тестов - немного неспешно.
Возможное решение: эфемерной локальная БД. Мы поднимаем локальную БД докером, делаем для нее volume в оперативной памяти, и гоняем тесты в этой базе. Почему такой термин - эфемерная? Потому что как только отключим том или гасим докер, то база просто пропадает. Для тестов - самое оно. Раз в 8-10 быстрее бегает, чем с облачной БД. Рекомендую.
‼️ World ID. Задача: для каждого теста хотим свой набор данных, чтобы реализовывать задуманный сценарий с детерминированным состоянием БД. Хотим чтобы тесты выполнялись параллельно. Как обеспечить?
Предлагаю такое решение: небольшое "Начало" / мультиверс, а если без художественных аналогий, то "мягкое шардирование".
Мы добавляем в каждую табличку БД поле world-id, идентификатор "мира". И индексы PK каждой таблички переделываем на использование world-id + id. Для чтения используем WHERE world-id = нужный нам мир.
Суть в том, чтобы получить возможность параллельно хранить в БД разные наборы данных. Чтобы для каждого теста мочь быстро создать такой набор данных.
🟢 Плюсы такого подхода:
- создать мир ничего не стоит - просто новый ключ для world-id.
- нет заморочек с миграциями - используем одну БД;
- нет проблем с коннектами; используем основной коннект;
🔴 Минусы:
- в каждый запрос добавляем world-id;
- я обычно добавляю такую штуку в слой доступа к данным (repository pattern), чтобы это было автоматом и прозрачно; тогда использовать очень просто;
- можно использовать RLS (row level security) для автоматизации на уровне БД :
- ALTER TABLE users ENABLE ROW LEVEL SECURITY;
- CREATE POLICY isolate_worlds ON users USING (world_id = current_setting('app.current_world_id')::uuid);
- SET app.current_world_id = 'uuid-вашего-мира';
- ключи обязательно включают world-id, но я использую UUID как ключи - поэтому все проще;
- чистить БД чуть дольше, но эфемерную БД после тестов можно просто погасить, без очистки;
▶️ Альтернативные варианты:
* делать отдельные БД для каждого теста: жирновато и медленно - делаем БД, накатываем схему, накатываем сид; просто чистить - дропаем базу;
* делать отдельную схему для каждого теста - SCHEMAS (Namespaces); почти так же муторно как создавать БД, та же проблема с миграциями; зато для очистки простой DROP SCHEMA;
* транзакции - сложность с кодом, который использует транзакции, потому что вложенные транзакции это немного больно и надо переходить на SAVEPOINTS (и переделать все хуки если они имеются - по мне так рефакторинг немаленький); мне не очень подходит чтобы переделывать транзакции; сложность с обработкой запросов в разных подключениях, например в интеграционных тестах апи;
В общем, если важно быстро сделать новый мир - тогда world-id. В проде world-id всегда null.
...
❤🔥2🔥2👍1
Тестирование в эпоху AI агентов ч3/3
...
‼️ Агентный раннер. Всегда гоняю тесты "под агентом". Чем сложнее тесты, тем выгоднее гонять агентами. Если юнит тесты - это просто часть проверок в protocol из #deksdenFlow, то гонять сложные интеграционные тесты идеально агентами. По мне так чем сложнее тест, тем правильнее гонять его агентами.
Я делаю примерно так:
- пишу инструкцию по запуску теста: технически, что надо сделать чтобы запустить тест; в том числе - как поднять систему, как посмотреть что система корректно поднялась;
- обозначаю контрольные точки тестов в документе;
- агент запускает тесты, контролирует систему, решает мелкие проблемы с работой теста;
- агент контролирует прохождение теста; падение интеграционного теста - всегда повод для фиксов или рефакторинга;
- интеграционные тесты - самые хрупкие, так как очень много всего в них задействовано, агент помогает решать возникающие сложности, что надежнее чем просто детерминированный тест без агента;
- самая важная часть агента как раннера тестов - провести расследование отклонений в тесте: чтобы понять суть бага нужно грамотно и полно собрать информацию - агент это делает самостоятельно, особенно если его промптить именно на это;
- отчет агента об обнаруженных отклонениях с итогами проведенного расследования - это отличное начало для фикса бага.
▶️ Такие приемчики.
Остался еще один неописанный, но имеющийся блок - работа с UI тестами через штуки типа Playwright, но это отдельная большая тема.
В ближайшее время выберусь из бэкэнда и обновлю методику. Надо внимательно погонять разные MCP для контроля браузера, посмотреть как там data-testid поживает, сравнить с браузером в антигравити, посмотреть на новые мультимодальные модели. В общем, тема требует проработанного апдейта - поэтому в свое время.
(ц) вот такое мы практикуем!
#post
@deksden_notes
...
‼️ Агентный раннер. Всегда гоняю тесты "под агентом". Чем сложнее тесты, тем выгоднее гонять агентами. Если юнит тесты - это просто часть проверок в protocol из #deksdenFlow, то гонять сложные интеграционные тесты идеально агентами. По мне так чем сложнее тест, тем правильнее гонять его агентами.
Я делаю примерно так:
- пишу инструкцию по запуску теста: технически, что надо сделать чтобы запустить тест; в том числе - как поднять систему, как посмотреть что система корректно поднялась;
- обозначаю контрольные точки тестов в документе;
- агент запускает тесты, контролирует систему, решает мелкие проблемы с работой теста;
- агент контролирует прохождение теста; падение интеграционного теста - всегда повод для фиксов или рефакторинга;
- интеграционные тесты - самые хрупкие, так как очень много всего в них задействовано, агент помогает решать возникающие сложности, что надежнее чем просто детерминированный тест без агента;
- самая важная часть агента как раннера тестов - провести расследование отклонений в тесте: чтобы понять суть бага нужно грамотно и полно собрать информацию - агент это делает самостоятельно, особенно если его промптить именно на это;
- отчет агента об обнаруженных отклонениях с итогами проведенного расследования - это отличное начало для фикса бага.
▶️ Такие приемчики.
Остался еще один неописанный, но имеющийся блок - работа с UI тестами через штуки типа Playwright, но это отдельная большая тема.
В ближайшее время выберусь из бэкэнда и обновлю методику. Надо внимательно погонять разные MCP для контроля браузера, посмотреть как там data-testid поживает, сравнить с браузером в антигравити, посмотреть на новые мультимодальные модели. В общем, тема требует проработанного апдейта - поэтому в свое время.
(ц) вот такое мы практикуем!
#post
@deksden_notes
👍5🔥5❤🔥2
Ну и тут такой Z.ai выбегает со своим AI Slides - и такой: я тоже в теме!
Вот пруф: https://chat.z.ai/space/n093jap4utt0-ppt
Вот пруф: https://chat.z.ai/space/n093jap4utt0-ppt
👍1😁1
Jules теперь - свободный агент!
Omfg. Они отвязали агента от репо, и теперь с жульесом можно просто чатится! А там, напомню, снова Гемини 3 про.
Любопытно! Это получается тут под боком есть свободный агент, с vm впридачу, и без требования подключить репо... Это в очередной раз заставляет меня задуматься - а как бы его в оркестратор включить, как удаленную ноду! Масштабирование тогда дешевое и на чужих мощностях - круто же!
Ух.. Надо думать
https://jules.google/docs/changelog/#start-from-scratchinstantly
Omfg. Они отвязали агента от репо, и теперь с жульесом можно просто чатится! А там, напомню, снова Гемини 3 про.
Любопытно! Это получается тут под боком есть свободный агент, с vm впридачу, и без требования подключить репо... Это в очередной раз заставляет меня задуматься - а как бы его в оркестратор включить, как удаленную ноду! Масштабирование тогда дешевое и на чужих мощностях - круто же!
Ух.. Надо думать
https://jules.google/docs/changelog/#start-from-scratchinstantly
❤5🔥5
Background process manager proposal
▶️ Запускаю щас всякие процессы в разных LLM. Вообще жесть - из методики трекинга выполнения - только спамить запросами.
В лучшем случае - это sleep 60, чтобы подождать.
Не понимаю - почему нету тула правильного для отслеживания запущенных фоновых башей: ты пускаешь кучу процессов, единый менеджер их трекает. Родилась некая идея.
🟢 Менеджер устроен как тул (например, пакован в MCP). Когда модель запускает некий процесс - она обозначает чего ждать: либо ей сразу отдать сгенерированную строку, либо собирать логи в батч, либо логи игнорировать и ждать когда в логах встретится ключевая подстрока, либо дать когда процесс в терминал чего то спросит, либо вообще стримить терминал в модель. В общем - подумать в каких режимах нам запускать надо процессы. Может, при апдейтах отдавать Stdout / stderr - посмотреть чего там надо модели.
Менеджер процессов в итоге трекает все, и по этой логике чего то возвращает в модель. Можно сразу вызвать нужный тул - чтобы он подготовил следующую пачку данных.
Для логов сжелать хранение и обработку - чтобы можно было запрос делать к логам: по подстроке, по времени и тп.
В общем, какие то такие мысли! Надо при случае выгрузить в какого то PMa буржуйского CLI агента. Жаль это реализует скорее какой нибудь дроид/opencode чем gemini/codex
А пока мучамся в кодексе как в пустыне - нифига нету. Хорошо хоть модель изворотливая относительно.
#post
@deksden_notes
▶️ Запускаю щас всякие процессы в разных LLM. Вообще жесть - из методики трекинга выполнения - только спамить запросами.
В лучшем случае - это sleep 60, чтобы подождать.
Не понимаю - почему нету тула правильного для отслеживания запущенных фоновых башей: ты пускаешь кучу процессов, единый менеджер их трекает. Родилась некая идея.
🟢 Менеджер устроен как тул (например, пакован в MCP). Когда модель запускает некий процесс - она обозначает чего ждать: либо ей сразу отдать сгенерированную строку, либо собирать логи в батч, либо логи игнорировать и ждать когда в логах встретится ключевая подстрока, либо дать когда процесс в терминал чего то спросит, либо вообще стримить терминал в модель. В общем - подумать в каких режимах нам запускать надо процессы. Может, при апдейтах отдавать Stdout / stderr - посмотреть чего там надо модели.
Менеджер процессов в итоге трекает все, и по этой логике чего то возвращает в модель. Можно сразу вызвать нужный тул - чтобы он подготовил следующую пачку данных.
Для логов сжелать хранение и обработку - чтобы можно было запрос делать к логам: по подстроке, по времени и тп.
В общем, какие то такие мысли! Надо при случае выгрузить в какого то PMa буржуйского CLI агента. Жаль это реализует скорее какой нибудь дроид/opencode чем gemini/codex
А пока мучамся в кодексе как в пустыне - нифига нету. Хорошо хоть модель изворотливая относительно.
#post
@deksden_notes
👍1
Инструкции агентам
Немного ассоциаций!
Работая с агентами, я замечаю что часто начинаю общаться как в свое время с специфическими сотрудниками, знаете таких? Которые типа хитрые, но косят под простачков и могут сильно буквально исполнять инструкции. Типа "ну вы же сказали - ..." или "а нам никто не говорил, что ...", или, что хуже "а в инструкции сказано - ... ". Ведь даже такой вид забастовки есть - итальянская забастовка, когда работаем строго по инструкции.
В итоге, следишь за словами, за указаниями - чтобы и так, и эдак "не дать ему вывернутся".
▶️ Смешаные ощущения, конечно. Зато все больше убеждаюсь что отрасль движется в сторону большей доли менеджмента
У вас так же? Или это сугубо персональный контекст?
#post
@deksden_notes
Немного ассоциаций!
Работая с агентами, я замечаю что часто начинаю общаться как в свое время с специфическими сотрудниками, знаете таких? Которые типа хитрые, но косят под простачков и могут сильно буквально исполнять инструкции. Типа "ну вы же сказали - ..." или "а нам никто не говорил, что ...", или, что хуже "а в инструкции сказано - ... ". Ведь даже такой вид забастовки есть - итальянская забастовка, когда работаем строго по инструкции.
В итоге, следишь за словами, за указаниями - чтобы и так, и эдак "не дать ему вывернутся".
▶️ Смешаные ощущения, конечно. Зато все больше убеждаюсь что отрасль движется в сторону большей доли менеджмента
У вас так же? Или это сугубо персональный контекст?
#post
@deksden_notes
🔥5❤3👍3
Подписочки для OpenCode для Codex
Вот такую штуку нарыл:
🔗 https://github.com/numman-ali/opencode-openai-codex-auth
плагин для openCode чтобы работать через подписку Plus/Pro. прикольно!
‼️ Это некоторое нарушение TOS, поэтому на основном акке я бы не тренировался с такими сетапами! Аккуратно
🔥 Upd: openCode Desktop готовится! скрин в комментах
#post
@deksden_notes
Вот такую штуку нарыл:
🔗 https://github.com/numman-ali/opencode-openai-codex-auth
плагин для openCode чтобы работать через подписку Plus/Pro. прикольно!
‼️ Это некоторое нарушение TOS, поэтому на основном акке я бы не тренировался с такими сетапами! Аккуратно
🔥 Upd: openCode Desktop готовится! скрин в комментах
#post
@deksden_notes
GitHub
GitHub - numman-ali/opencode-openai-codex-auth: OAuth authentication plugin for personal coding assistance with ChatGPT Plus/Pro…
OAuth authentication plugin for personal coding assistance with ChatGPT Plus/Pro subscriptions - uses OpenAI's official authentication method - numman-ali/opencode-openai-codex-auth
Google UX
К версии 0.18.4 в Gemini CLI появился email того аккаунта, через который ты авторизован. Всего было 219 релизов на гитхабе.
Лучше поздно
В принципе, все консистентно - это гугл! Он такой. Что то мега-крутое сочетается с лютой дичью местами в UX...
(ц) такое мы принимаем в дзене, так как изменить не в состоянии
#post
@deksden_notes
К версии 0.18.4 в Gemini CLI появился email того аккаунта, через который ты авторизован. Всего было 219 релизов на гитхабе.
Лучше поздно
В принципе, все консистентно - это гугл! Он такой. Что то мега-крутое сочетается с лютой дичью местами в UX...
(ц) такое мы принимаем в дзене, так как изменить не в состоянии
#post
@deksden_notes
👍1
DeepSeek - 3.2
Новость в деталях обсказали уже все каналы и пара утюгов, я лишь добавлю: модель продолжает тренд на interleaved thinking режим как в минимаксе м2 и кими. Ну и свежих соннетах!
так что не даром они все предоставлют антропик-стиль апи!
interleaved thinking к слову, способствует более мощной агентности.
(ц) тренд, однака!
1️⃣Upd : контекст в 128к смотрится архаично! Но мощный ризонинг формально на уровне gemini 3 pro - заставляет задуматься, что получится когда они это все опробуют на R2.
Я так понимаю нам дают результаты экспериментов по отработке разных фишек в пайплайне - но на старой базе.
Ждемс v4 + r2. Уже испытываю повышенные ожидания!)
#post
@deksden_notes
Новость в деталях обсказали уже все каналы и пара утюгов, я лишь добавлю: модель продолжает тренд на interleaved thinking режим как в минимаксе м2 и кими. Ну и свежих соннетах!
так что не даром они все предоставлют антропик-стиль апи!
interleaved thinking к слову, способствует более мощной агентности.
(ц) тренд, однака!
1️⃣Upd : контекст в 128к смотрится архаично! Но мощный ризонинг формально на уровне gemini 3 pro - заставляет задуматься, что получится когда они это все опробуют на R2.
Я так понимаю нам дают результаты экспериментов по отработке разных фишек в пайплайне - но на старой базе.
Ждемс v4 + r2. Уже испытываю повышенные ожидания!)
#post
@deksden_notes
🔥4
Модель не справляется
▶️ Наблюдение, но подтверждается многократно. Отлаживаю оркестратор, гонял его на разных моделях и часто - второго эшелона. Glm, qwen и m2, например. Хорошие модели!
И в 100% случаев когда воркфлоу падал по причине ошибок агента, когда он что=то не то делал - оказывалось проблема в контексте. Противоречивые инструкции, взаимоисключающие инструкции, недостаточно ясные формулировки, отсутствие информации, битые отсылки и тп.
То есть - все дело в промпте и контексте! Модели с понятными заданиями с нормальным контекстом справляются уверенно
👉 Поэтому: если у вас модель лажает в таком месте, где по вашим ощущениям должна справится - то скорее всего есть причина, и ее реально найти.
👌 как искать? Глазами, если вы старовер. Ну и агентами: у меня "старшие" модели проводили расследование и указывали на противоречия или иные проблемные моменты контекста! Модели такое видят. Конечно, контекст им надо предъявить.
#post
@deksden_notes
▶️ Наблюдение, но подтверждается многократно. Отлаживаю оркестратор, гонял его на разных моделях и часто - второго эшелона. Glm, qwen и m2, например. Хорошие модели!
И в 100% случаев когда воркфлоу падал по причине ошибок агента, когда он что=то не то делал - оказывалось проблема в контексте. Противоречивые инструкции, взаимоисключающие инструкции, недостаточно ясные формулировки, отсутствие информации, битые отсылки и тп.
То есть - все дело в промпте и контексте! Модели с понятными заданиями с нормальным контекстом справляются уверенно
👉 Поэтому: если у вас модель лажает в таком месте, где по вашим ощущениям должна справится - то скорее всего есть причина, и ее реально найти.
👌 как искать? Глазами, если вы старовер. Ну и агентами: у меня "старшие" модели проводили расследование и указывали на противоречия или иные проблемные моменты контекста! Модели такое видят. Конечно, контекст им надо предъявить.
#post
@deksden_notes
👍7❤4
Claude Select
Нашел небольшую утилиту:
🔗 https://github.com/aeitroc/claude-select
A unified launcher for Claude Code that lets you interactively choose which LLM backend to use.
Выбираем какая модель будет "под капотом" у СС
Возможно, кому то будет удобно такое!
#link
@deksden_notes
Нашел небольшую утилиту:
🔗 https://github.com/aeitroc/claude-select
A unified launcher for Claude Code that lets you interactively choose which LLM backend to use.
Выбираем какая модель будет "под капотом" у СС
Возможно, кому то будет удобно такое!
#link
@deksden_notes
GitHub
GitHub - aeitroc/claude-select: A unified launcher for Claude Code that lets you interactively choose which LLM backend to use.
A unified launcher for Claude Code that lets you interactively choose which LLM backend to use. - aeitroc/claude-select
🔥4👍2
Kimi Slides - free до 07.дек
Собственно, сабж! Бесплано, до 07 декабря - продлили
Пока это самые симпатичные слайды выходят из протестированных мною (Google NotebookLM, Z.ai Slides)
Собственно, сабж! Бесплано, до 07 декабря - продлили
Пока это самые симпатичные слайды выходят из протестированных мною (Google NotebookLM, Z.ai Slides)
1❤4