DEKSDEN notes

Когда добазарился с моделью... Хм - это ачивка?

Ну и тут такой Z.ai выбегает со своим AI Slides - и такой: я тоже в теме! Вот пруф: https://chat.z.ai/space/n093jap4utt0-ppt

Kimi Slides vs Google NotebookLM

Затестим Kimi Slides vs Nano Banana Контент - цикл #deksdenFlow (сами посты по тегу)

Я делаю примерно так: - пишу инструкцию по запуску теста: технически, что надо сделать чтобы запустить тест; в том числе - как поднять систему, как посмотреть что система корректно поднялась; - обозначаю контрольные точки тестов в документе; - агент запускает тесты, контролирует систему, решает мелкие проблемы с работой теста; - агент контролирует прохождение теста; падение интеграционного теста - всегда повод для фиксов или рефакторинга; - интеграционные тесты - самые хрупкие, так как очень много всего в них задействовано, агент помогает решать возникающие сложности, что надежнее чем просто детерминированный тест без агента; - самая важная часть агента как раннера тестов - провести расследование отклонений в тесте: чтобы понять суть бага нужно грамотно и полно собрать информацию - агент это делает самостоятельно, особенно если его промптить именно на это; - отчет агента об обнаруженных отклонениях с итогами проведенного расследования - это отличное начало для фикса бага. ▶️ Такие приемчики. Остался еще один неописанный, но имеющийся блок - работа с UI тестами через штуки типа Playwright, но это отдельная большая тема. В ближайшее время выберусь из бэкэнда и обновлю методику. Надо внимательно погонять разные MCP для контроля браузера, посмотреть как там data-testid поживает, сравнить с браузером в антигравити, посмотреть на новые мультимодальные модели. В общем, тема требует проработанного апдейта - поэтому в свое время. (ц) вот такое мы практикуем! #post @deksden_notes

Тестирование в эпоху AI агентов ч1/2 ... Теперь к некоторым техникам. Хочу поделится парой моментов. ‼️ Эфемерная БД: сейчас модно и молодежно использовать в проектах штуки типа 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. ‼️ Агентный раннер. Всегда гоняю тесты "под агентом". Чем сложнее тесты, тем выгоднее гонять агентами. Если юнит тесты - это просто часть проверок в protocol из #deksdenFlow, то гонять сложные интеграционные тесты идеально агентами. По мне так чем сложнее тест, тем правильнее гонять его агентами.

Тестирование в эпоху AI агентов ч1/2 Попробую изложить имеющиеся соображения по тестированию и подходов к нему в некотором преломлении к агентам. Может быть покапитанствую местами - но куда ж без этого) Сначала о термине "тестирование". Это огромная тема, весьма многогранная, посему вначале нужно выровниться (как говаривает кодекс) по терминологии. Я буду про тестирование, которое автоматические тесты, которые мы запускаем через какой то раннер, и которые чего то ожидают (Expectations), чего то делают, чего там в итоге проверяют как оно вышло (Assertions). Методики типа TDD нам выходят ортогонально - из этой же темы, но другое направление, и их мы пропустим. ▶️ Тесты я поделю так: - юнит тесты - полу- и интеграционные тесты, бизнес-процессы - специализированные тесты: ui, компонентные - ну и хватит, этого уже достаточно 1️⃣ Юнит тесты: самые простые тесты для кусочков кода. Они тестируют базовые алгоритмы в коде и делаются изолированно - если в алгоритме используем внешние зависимости, то всегда их мокаем - делаем имитацию внешней зависимости с предопределенным поведением. 2️⃣ Все варианты e2e тестов (e2e = end-to-end, интеграционные тесты): это когда наши зависимости уже не мокаются (тогда интеграционные), или не полностью мокаются (может стаб используем для части тестов, или мок - но часть зависимостей "боевая"). Когда несколько кусков вашего кода взаимодействуют мы можем проверить как оно работает вместе. Бизнес-процессы- это такие "сквозные" интеграционные тесты, которые используют фичи приложения в приближенной к "боевой" среде, представляя собой некий сценарий использования системы пользователем, проверяя как система в целом работает. 3️⃣ Специализированные тесты: тут можно тестировать какой то интерфейс, дергая его через инструменты наподобие Playwright / Selenium - причем как алгоритмически так и агентами через соответственный MCP. В эту же группу запишем компонентные тесты, когда у нас дергается специфический сложный компонент и проверяется как он себя ведет в разных режимах. ▶️ Пару слов о раннерах - это софт, который позволяет описать тесты и запускать их, учитывая чего там у нас упало, брать логи и прочее. Примеры: Vitest, Jest, Playwright Test, всякие xUnit, и еще миллион разныш штук для разных языков / стеков / технологий. ...

Agents по антропиковски, ч2 ... Продолжим с разбором самой статейки. ▶️ Вначале рассказывают почему ваншоты сложных штук не взлетают, спотыкаясь о контекст. Впрочем, это довольно очевидно. Проблема компакта разделена на два аспекта: - забытые точные инструкции посередине реализации; - новый контекст агента неправильно считывает статус выполнения задачи, поверхностно - что ведет к отметке выполненными недоделанных задач; Как они порешали для поставленной задачи проблему: - сделали сначала описание всей задачи, - разбили задачу на более мелкие подзадачи - работают с подзадачей в "оборудованном" окружении - подзадача начинается в понятном состоянии проекта - работаем с верификацией - фиксируем статус работы в файл, передача статуса через контекст не срабатывает (компакты беспощадны) - рабоатем многими контекстами Да, кто смотрел #DeksdenFlow - все именно так и заведено. Те же шаги на итерацию, также сохраняемся в файл. Да, у меня чуть более навороченно - но это и понятно, у меня то "настоящий" flow, а не пример к статье. Также шаг 0 заключается в инициализации всего процесса и подготовки окружения. ▶️ Для длительной работы анты аналогично пришли к системе - делаем коммит в гит, записываем статус процесса в файл. Они отметили важным что каждая итерация должна оставить систему в относительно консистентном состоянии - проверки проходят, коммит сделан, репо чистое. ▶️ Далее в статье особо отмечено что агент любит привирать и метить фичи сделанными без надлежащего тестирования. Промпты примера пытаются оградить от такого поведения: - помимо необходимости тестов, особо отмечено необходимость e2e тестирования! 👉 Надо, видимо, написать про тестирование, видимо это неочевидно что e2e нужно обязательно, и как раз без других видов тестирвоания можно обойтись, но не без этого. Причем, многие то его руками делают, протыкивая типичный флоу с приложухой. Анты делают вывод что если у агента появляется обратная связь от работы веб приложения - то это улучшает качество. Некоторое капитанство, но это правда от и до. Без демонстрации модели в браузере чего она там наворотила я не понимаю как можно что то работающее получить. Может, новые модели ваншотят кое что без ошибок, но я бы в более менее реальных приложениях такого бы не ждал - только верификация. ▶️ Также как и в моем протоколе - анты опираются на изучение лога гита для ориентировки агента. Это логично и работает. ▶️ Там есть даже зачатки некоего меморибанка, где агент в init.sh скрипте читает как работать с проектом, как чего делать. Думаю, меморибанк точно нужен, но грамотно скомпонованный - впрочем, это отдельная большая тема для дискуссий! ▶️ Далее говорится что если делать специализированных агентов на каждый класс задач, то можно улучшить качество. Типа, агент тестирования, агент QA, агент code cleanup, ... Ну а кто спорит? Фокусная работа, как я это называю, дает свои результаты! Спасибо антропик, за верификацию подхода)) 🟢 В общем, прикольно было верифицировать некоторые подходы мнением фронтирной топовой лабы! (ц) Такое мы читаем #post @deksden_notes

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 с нейросетями делает, нервные и задерганные они все какие нынче. ...

Экономическое Уже и грок сравнивает во сколько раз он дешевле антропиков! https://x.com/xfreeze/status/1993328493359215054?s=46 Сомнительное реноме на рынке. #post @deksden_notes

Way back context О технике промптинга Интересно, как быстро вендоры додумаются до сворачивания истории «прыжком в прошлое»? Чтобы контекст экономить. Типа, модель что то делала-делала, и у нее наконец получилось (или не получилось) - и мы режем историю, возвращаемся в момент когда это все только начиналось и рассказываем модели чем все кончилось (успех или неуспех). Как в «назад в будущее». Результат? Экономия контекста, эффективные «хождения кругами», без траты контекста, cache friendly к слову! Пока я это иногда делаю руками для своих сообщений в кодексе с esc esc - типа обсудил что то детальное, уяснил, вернулся к старту обсуждения и продолжил по первоначальной теме разговор. Но это будет дико полезно для любой агентной работы!

🧩 Memory Bank - опрос 👉 Коллеги! Кто то пользуется в работе с проектами меморибанками / их аналогами? ❓ Какую структуру используете - какие блоки информации там держите? Эволюционировала ли у вас концепция со временем? ▶️ Интересна обратная связь. Планировал публиковать небольшие апдейты по теме меморибанка и подходов к ведению. #post @deksden_notes

Opus 4.5 - релиз Нынче слухи не соврали - и он с нами! Я говорил о двух проблемах: он должен стать умнее и дешевле. Анонсировали - стал умнее и дешевле. Умнее: SOTA на SWE Bench Verified, Выше Gemini 3 pro и Gpt-5.1 / Codex Max. Умнее sonnet 4.5, что, впрочем, логично. Дешевле: цена ⅓ от прежнего. Лимиты - совсем другие, теперь Opus 4.5 примерно столько же, сколько было соннета 4.5 ранее - типа, его можно использовать для daily tasks. Использует меньше токенов при таком же или лучшем результате. Значительно. ▶️ Desktop Теперь о Desktop. Десктоп теперь умеет компактить сессию. Ну ок. Мало каким сессиям это сильно помогало, зато теперь не будет неожиданного удара об контекст. ▶️ Tool Use: https://www.anthropic.com/engineering/advanced-tool-use Сделали тул для поиска тулов! Теперь грузим тулы по мере необходимости, решая проблему context rot от множества MCP. Всех впечатлил MCP сервер от github, да - 25k токенов. Про programmatic tools use все понятно - пользвоать тулы в code sandbox и там же предобработать результаты - это коненчо сильно экономичнее чем вываливать пучок данных в контекст. Хотя могли бы придумать штуку для выкусывания ненужных данных из контекста (из истории). Ну ок. Интересное новшество: tool use examples прямо в описании тулов! Few shot lникто не отменял - это сильно повышает качество. Круто! ‼️ Хватит ли умений опуса для выравнивания с конкурентами? Посмотрим - надо тестить. Бенчмарки нормальные, от гемини опус отстает только в эрудиции. Исправили ли косяки - с враньем, с подхалимством? Посмотрим. Почти все основные фронтирные вендоры сделали свои ставки! (ц) В интересное время живем - такое нам прикольно! ) #post @deksden_notes

Opus 4.5 Слухи не отпускают, возможно антропики готовят сабж. Он им и вправду нужен! Кмк, ситуация для них сложная: им нужно решить 2 большие задачи: - сделать модель не менее умной чем gpt-5.1/gt-5.1-codex-max, Gemini 3 Pro, что само по себе уже довольно сложно - учитывая что модели конкурентов отличные; - сделать модель НЕДОРОГОЙ - потому что с текущими ценами/лимитами они сливают по всем форнтам; каждая новая кодинговая штука привыкла хвалиться ВО СКОЛЬКО РАЗ они дешевле и дают больше лимитов, чем антропики В общем, ... (ц) будм посмотреть! #post @deksden_notes

Google Gemini 3 Pro первые впечатления 🟢 Еще не затестил в полном объеме и с кодом, но первый плюсик Гемини заработала. 👉 Решал проблему входа в виртуалку Ubuntu под Paralllels на macOs. Случилась проблема с конфигурацией сетевых адаптеров и режимов работы. - Кодекс решить не смог, итераций 5-7 заняло. - Гемини 3 Про за 3 итерации решило. ▶️ Вывод: у меня всегда были ощущения что эрудиция Гемини повыше - что и подтвердилось. В devOps заработан плюсик в сравнении! (ц) Продолжаем наблюдение! 🫡 #post @deksden_notes

Google Stitch + 🍌 Pro Никто особо не пишет, но у Гугла же есть UI design tool c AI: 🔗 https://stitch.withgoogle.com/ Ну так вот - туда точно завезли NanoBanana Pro, и не исключаю что Gemini 3 Pro, но точно пока не понял. Впрочем, этим инструментом пока не пользовался, хотя попробовать планирую. Отслеживаю в любом случае! #post @deksden_notes

MCP Apps Все же помнят протокол MCP? Так вот - он развивается, несмотря на критику отдельных моментов (я про context rot и решение в виде code mode execution). Так вот - MCP UI и OpenAI Apps SDK родили в итоге MCP Apps Читаем анонс в блоге https://blog.modelcontextprotocol.io/posts/2025-11-21-mcp-apps/ Сама спека по ссылке чуть выше, но вот сам драфт документа: https://github.com/modelcontextprotocol/ext-apps/blob/main/specification/draft/apps.mdx Что дает? Возможность серверам выдавать стандартизированное UI для хоста. Фича интересная, применение тоже вроде бы разнообразное. Круто что вендоры объеденились, и вместо 2х разных решений мы получим единую спеку, с шансами на широкую адоптацию в отрасли. Прикольно (ц) Такое мы одобряем! #post @deksden_notes

Лимиты Codex ... снова сбросили! Вроде бы где то там кодекс опять лег или работал с большими задержками. "Комплимет от заведения" в итоге! Ну - гуд, чего тут скажешь!

Gemini 3 Pro in CLI ... раскатилось на пользователей Про аккаунтов из листа ожидания! Мне тоже раскатили - confirmed. Потребовался повторный вход в аккаунт, имейте ввиду - видимо, иногда так бывает Go тестить, они создали!.. #post @deksden_notes

Opus 4.5 - сегодня? Слухи такие, да Понятно почему codex-max выпустили не в обычный рыбный день: видимо, его под опус оставили! А плотненько пошли релизы!)) Ждем опуса? или уже нет?)