⚪️ История про git flow для оркестратора, часть 1

Когда я задумал сделать себе операционный оркестратор (который потом назвался dd-flow) идея была такая: я "закидываю" работу в оркестратор, и он "впиливает" эту работу дальше автоматически, важно, чтобы "закидывание" было процессом асинхронным. Типа, можете добавлять несколько параллельных задач, которые будут реализованы, и автоматически смержены в проект.

Чтобы это все работало, предполагался простой флоу: от главной ветки делаем фичабранчи (оптимизируя это через worktree, чтобы чекауты бранчей были покомпактнее).

Вроде бы все просто. Но есть нюансы. Нюанс называется "релиз". Если у вас ci/cd, то любой мерж в origin сразу триггерит релиз. На каждую вмерженную фичу это неудобно.

Усложним. Делаем две главные ветки:
* main. Пуш в main триггерит релиз.
* develop. Главная ветка разработки, в нее собираем все фичи. Как набрали достойное количество - переливаем все в main, вот вам и релиз.
* hotfix пока решил не делать, вроде не было нужды.
* Решил что впоследствии мой main будет релизить beta.project.com, а в прод будем промоутить после тестирования beta если все ок. почти ничего не будем менять.

Теперь мы все вливаем в итоге в origin/develop. Выяснилось, что оркестратору реально нужно иметь свой локальный чекаут origin/develop, которым только он управляет. Это важно для работы очереди мержей.

Очередь мержей: разберем, что это такое. Когда параллельно пилятся куча разных задач/фич, то "вливать" итоги в develop нужно все равно по одному в некоей четкой последовательности. Это важно для обеспечение консистентности и стабильности develop: ветка должна быть всегда "зеленой", то есть на ней всегда должны проходить все тесты и она должна собираться в продукт. При вливании нужно решать конфликты, что требует синхронности - решать проблемы шаг за шагом. Вот эту последоватльность и обеспечивает очередь мержей, это такой механизм в оркестраторе.

Очередь мержей важно чтобы не косячилась и не зависала - важно чтобы механизм работал. Она должна всегда легко синхрониироваться с origin/develop. Пришлось сделать много гардов, чтобы они ее периодически обслуживали - сервисный чекаут был бы на origin/develop, чтобы на нем чеки проходили зелеными. В оркестраторе сервисные операции оказалось довольно удобно делать: организуем детерминированные команды, а если что то идет не так - у нас есть агентный флоу для фикса! И state, возможность переживать остановки, и ui чтобы если что - пользователя вовлечь к решению проблемы. Удобно.

⚪️ Агентный Git flow, часть 2: когда дистрибутив пакетами через npm

Когда релиз через npm, то важно тестировать работоспособность пакетов. Для этого внутрь пакетов должно попасть что положено. Желательно при этом протестировать чего туда попало. Работаем в монорепозитории через pnpm.

При этом не хочется тестировать только через npm. Иногда хочется посмотреть живьем фичи, которые живут в develop ветке, но чтобы было похоже на работу через пакеты. Это можно сделать если линкануть нужные монореповские пакеты через link глобально на машину.

В итоге пришел к такому: для запуска системы локально есть два режима:
* запустить из develop ветки
* запустить из релиза с npm

Все это обеспечил cli / скриптами. Как работает: есть команда cli dev sync, которая делает: служебный чекаут origin/develop, собирает систему там, и делает pnpm link global соответсвующих пакетов. В результате на локальном компе появляется софт, который через npm распространяется, в свежей сборке.

Если надо посмотреть версию которая в npm лежит, то делаем cli dev sync --prod. Она убирает глобальные линки пакетов pnpm (если были), и ставит версии пакетов из npm. Если потом захотим посмотреть develop версию, то команда cli dev sync уберет npm версии (деинсталлирует), обновит свой чекаут, и поставит pnpm link версии пакетов.

Обратили внимание? Да, я сделал для работы с dev ops задачками в проекте не просто скрипт, а cli для проекта! Зачем? Помимо того, что это удобно, это еще позволило сделать скилл и при необходимости управлять всем этим через агента. Cli очень органично пакуются в скиллы для агентной работы.

⚪️ Агентный git flow, часть 3: а где же human?

После реализации всего вышеописанного, оказалось, что разработка проекта закуклилась внутри оркестратора. Я просто даю задачи, и получаю результат. Вроде бы не плохо! Но мне это показалось слишком радикальным, ведь хочется иногда в режиме "ручного" управления что то доработать! Ну - агентом, конечно, но под управлением. Хотя бы иметь такую возможность.

Это прекрасно что агенты в своих рабочих деревьях чего то пилят сбоку.

Но хотелось прям вот тут, в оригинальном чекауте проекта, иметь возможность тоже чего то впилить. В общем, нужна локальная dev ветка. Вот ее я правильно прикручивал дольше всего.

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

Первая мысль возникла - отправлять мои правки в ту же мерж очередь, и пускай оно туда впиливается! типа - заслал, оно вмержилось. Но есть ограничение - нельзя трогать dev пока правки не влились. И тут выяснилось, что ждать очереди - это дискомфортно, бывает долго и скучно.

Следующая идея: закидывать в очередь последний коммит. Типа, сделал в dev коммит с правками, вот его пускай именно его "завозят" в origin/develop. Правда, быстро выяснилось, что одного коммита - мало, и надо бы цепочку коммитов кидать. Схема вышла норм: цепочки заезжают норм.

Ну и дополнительные хлопоты возникли с тем, что "моя" ветка dev предполагалась "долгоживущей". Фичабранчи создаются под задачу. А вот dev ветку я не планировал регулярно менять - следовательно, появилась необходимость регулярных подтягиваний базы dev ветки на текущее состояние origin/develop.

Для реализации пришлось сделать отдельный небольшой тулинг.

* Мои изменения отправляет dd-flow dev add-merge: берет из ветки dev все невмерженные в origin/develop коммиты, и засылает их "трамвайчиком" в общую очередь мержей.
* Другой тул dd-flow dev sync --dev: делает "обратный мерж" - вливает изменения из origin/develop в dev, попутно решая конфликты. То есть такая "очередь мержей" для одной ветки, и в обратном направлении. Команда похожа на dev sync, но только названием - внутри там совсем другая логика, и она реализована через вызов оркестратора и специального флоу под хту задачу dev-sync.

Так организовалась работа с human in the loop.

⚪️ Git flow, часть финальная. А чо так замороченно?

Я всегда говорил, что у каждого свои флоу. Но свой я задумал завернуть в оркестратор. Когда это работает "в ручном" режиме, кажется все намного проще.

Попытки автоматизации всего процесса делают его немного более сложным: каждая часть флоу при автоматизации требует обустраивания. Детерминированные части работают не всегда автономно, и без агентных добавок могут требовать ручного вмешательства. Поэтому везде по возможности прикручивал агентов.

В итоге получилось не особо сложно:
* агенты крутятся в своих флоу, пилят фичи в рабочих деревьях, и мержат их очередью
* результаты можно пощупать через пары релизных пайплайнов - чтобы и npm релизы посмотреть, и текущую работу в develop
* а сам могу руками поработать в dev ветке, которую "тащат" два процесса: Add-merge добавляет мою работу в общую очередь мержей, и dev-sync "подтягивает" мою ветку на текущий origin/develop

Вот такая гравицапа вышла

❓ А вы как работаете с агентами? с git?

⚪️ Соннет 5

… и опус 4.6 по слухам вот вот. Еще вчера!

Ждемс?

Чего думаете поправят?

Мои боли от Клодов: контекст, внимание, вранье.

⚪️ Kilo CLI 1.0


Я чего то перестал все известные мне CLI агенты постить (а их пара десятков то наберется, наверное) - но этот стоящий упоминания.

Во первых KILO - довольно известное и популярное расширение для VS code. Поэтому - своей популярностью уже заслужил.

Во вторых, на этот раз это форк ОПЕНКОДА!

Ну - посмотрим посмотрим на развитие

🔗 блог : https://blog.kilo.ai/p/kilo-cli
🔗 страничка на оффсайте: https://kilo.ai/cli
🔗 гит : https://github.com/Kilo-Org/kilocode

@deksden_notes

⚪️ .agents/skills петиция


К Антропикам. Сабж:

https://x.com/iannuttall/status/2018760297368932726?s=20

Хотят чтобы де-факто народившийся стандарт поддержали все топовые вендоры. Это разумно! почему не agent/skills? По AGENTS.md аналогии.

В общем - хорошее дело!

Кому не жалко - лайкните! Я лайкнул

@deksden_notes

⚪️ Материалы канала

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

Подсобирал материал по каналу, может пригодится кому каталог ссылок:

▶️ Контекст-инжиниринг для меморибанков:

* индексные файлы index.md : https://t.me/deksden_notes/46
* главный индекс меморибанка и прайминг контекста: https://t.me/deksden_notes/51
* аннотированные ссылки : https://t.me/deksden_notes/47
* атомарные файлы : https://t.me/deksden_notes/49 , https://t.me/deksden_notes/52
* С4 модель : https://t.me/deksden_notes/52
* XML-like теги : https://t.me/deksden_notes/73
* оверинжиниринг : https://t.me/deksden_notes/368
* Progressive Disclosure : пробеги по граблям Skills и меморибанки : https://t.me/deksden_notes/407

▶️ кейсы и разбор проблем с агентами:

* Vibe Coding мифы и "охотничьи рассказы" : https://t.me/deksden_notes/59
* Разбор vibe-кейса 1️⃣ : https://t.me/deksden_notes/60
* Модель не справляется : https://t.me/deksden_notes/262

▶️ Тактические приемы работы с агентами:

* планирование в СС : https://t.me/deksden_notes/64 и https://t.me/deksden_notes/65
* vibecoding в CC : https://t.me/deksden_notes/89 и https://t.me/deksden_notes/90
* вайбкодинг в Кодексе : https://t.me/deksden_notes/124
* Codex workflow для рефакторинга : https://t.me/deksden_notes/144
* Local multiagent flow : https://t.me/deksden_notes/146
* Прайминг - Специализированные сессии : https://t.me/deksden_notes/329
* Флоу Peter Steinberger : https://t.me/deksden_notes/331
* Прайминг, если нет меморибанка : https://t.me/deksden_notes/412
* Планирование с агентом: работа с контекстом после прайминга : https://t.me/deksden_notes/413


▶️ Git flow: https://t.me/deksden_notes/420 , https://t.me/deksden_notes/421 , https://t.me/deksden_notes/422 , https://t.me/deksden_notes/423


▶️ Memory bank для существующих проектов :: Реверс-проектирование и реверс-документирование в brownfield : https://t.me/deksden_notes/66 , https://t.me/deksden_notes/67

▶️ Агентная память (обзор технологии, agents.md ): https://t.me/deksden_notes/77 , https://t.me/deksden_notes/81 , https://t.me/deksden_notes/83 , https://t.me/deksden_notes/84


▶️ Тестирование:
* Тестирование в эпоху AI агентов : https://t.me/deksden_notes/249 , https://t.me/deksden_notes/250 , https://t.me/deksden_notes/251
* Тестирование, бизнес-процессы (e2e) : https://t.me/deksden_notes/286

▶️ ‼️ Серия постов про #deksdenFlow :
* TLDR : https://t.me/deksden_notes/197 ,
* #DeksdenFlow - 1 :: git, worktree : https://t.me/deksden_notes/198 , https://t.me/deksden_notes/199
* #DeksdenFlow - 2 :: Контексты : https://t.me/deksden_notes/200
* #DeksdenFlow - 3 :: Protocol - Этап обсуждения : https://t.me/deksden_notes/201 , https://t.me/deksden_notes/202
* #DeksdenFlow - 4, Protocol, Этап фиксации плана : https://t.me/deksden_notes/203 , https://t.me/deksden_notes/204
* #DeksdenFlow - 5, Protocol, этап Реализация : https://t.me/deksden_notes/205 , https://t.me/deksden_notes/206
#DeksdenFlow - 6, Protocol, Этап Review and Merge : https://t.me/deksden_notes/207
* #DeksdenFlow - 7, Заключительное организационное : https://t.me/deksden_notes/208
* #DeksdenFlow и Gpt-5.1 : https://t.me/deksden_notes/210
* Регулярный анализ проектов : https://t.me/deksden_notes/316
* Модернизация протокола #deksdenFlow: https://t.me/deksden_notes/309
* слайды : https://t.me/deksden_notes/252


▶️ Разное:

* О верификации - коротко : https://t.me/deksden_notes/367
* Схема "Критик" : https://t.me/deksden_notes/142
* Фичапаки CLI агента : https://t.me/deksden_notes/308

⚪️ Рыбный день

... как известно - четверг! А этот выдался особенно рыбным. Тятя, тятя! Наши сети притащили:

* Claude Opus 4.6
* gpt-5.3-codex

И это BIG! И необычно - как правило, фронтирные лабы давали побыть лидером кому-то хоть день-два! Нынче клозеды решили не межеваться. Ибо, нечего всякие ролики про рекламу снимать. Посмеялись? Ну и теперь посмейтесь)) sama конечно отжигает

Думаю, по всем каналам разойдутся очерезные SOTA бенчмарки.

из интересного - 1m контекста у опуса идет за premium прайс, о чем скромно умалчивают в новости. зато $10/$37.50 ясно указаны в карточке цен. Впрочем, на соннет 4.5 премиум цены на большой контекст тоже обозначены - хотя доступ к 1m модели был только у узкого круга ограниченных лиц.

Думаю, сейчас мы таки посмотрим как себя чувствуют модели клода на больших контекстах! по бенчмаркам - фантастические результаты. Надо сомтреть живьем

В общем, опус выглядит очень празднично. Интересно, в подписки дадут большой контекст?

——

Кодекс поколения 5.3

СОТА на куче кодинговых бенчмарков. Впечатляет рост агентного компьютерюза - х2 практически по бенчмарку OSWorld. То есть в агенте тыкать мышкой будет бодро

Еще сказали что будет развлекать пользователя комментариями в процессе работы. Аутичный стиль стремятся изжить

И еще он на 25% быстрее! Это хорошо

Кодекс 5.3 тоже выглядит бодро и интересно! Пойду включу его ))


——

🔥 GO тестить!


@deksden_notes

⚪️ Swarms - новая парадигма?


В СС вышла в качестве research preview новая фича, которая называется Agent Teams (агентные команды).

🔗 почитать тут: https://code.claude.com/docs/en/agent-teams

Идея такая: агент-координатор (team lead) создает команду из агентов, координирует работу, раздает задачи другим участникам команды и пишет отчет о результатах работы.

В чем отличие от субагентов? На первый взгляд, с точки зрения структуры работы ситуация аналогичная: главный агент-оркестратор и работающие параллельно в отдельных сессиях суб-агенты.

Разница в уровне децентрализации и оформленности выделенных членов команд. В агентной команде агенты - это полноценные агенты, в разных процессах, каждый со своей сессией. Общаться они могут друг с другом напрямую, минуя координатора (agent mail). Вы можете подключаться к каждому агенту в команде и даже давать ему инструкции через чат с ним! Агенты само-координируются в процессе работы

Недостатки? Потрата токенов возрастает кратно. Тратим время и токены на координацию.

Плюсы? Сложная работа, требующая обсуждений и предполагающая большой объем - вот тема такой фичи. Мы же все знаем что рефлексия работает. Вот тут она помогает в полный рост!

В общем, интересная фича, надо смотреть как это все будет работать.

П.С. В кодексе готовится нечто похожее - collab назыввается в рабочем порядке

@deksden_notes

⚪️ Startup perks: каталог програм поодержки стартапов

Какие облачные сервисы дают стартапам кредиты на свои услуги для поддержки. Собственно, сабж:

🔗 https://www.startupperks.xyz/

41 программа!

(ц) Такое я вижу полезным


@deksden_notes

⚪️ Антропики свармом навайбкодили С компилятор

Вот статейка:

🔗 https://www.anthropic.com/engineering/building-c-compiler

Опус 4.6 за 2 недели, 16 агентов, $20k в ценах апи потрата кредитов (это 2 подписки макс-200 наверное). 2000 сессий. 2B токенов всего. Вышло 100k loc, rust компилятор - компилирует ядро Linux, для x86, arm, risk-v.

В статье самое важное - это собственно не сам проект, хотя сделать РАБОТАЮЩИЙ компилятор - это прикольно. В статье интересно КАК разработчик организовывал этот проект. Я специально использую такой термин - ведь работа человека изменилась. Он не разрабатывает софт. Он создает условия чтобы ИИ агенты разрабатывали софт!

Что пришлось делать:
• он сделал циклы в ральф-стиле, чтобы агенты брали очередную задачу, и решали ее "до упора"; интересно что один из агентов самоубился через pkill -9 bash, убив контролирующий скрипт;
• он не делал агента оркестратора
• он не делал коммуникации между агентами
• пул задач с локом задачи
• в целом оркестрация выглядит примитивной и рудиментарной - явная область улучшения
• основная работа челоека заключалась в системе тестов, чтобы сформирвоать такую систему тестов, которая позволила агентам сделать работоспособный продукт

Интересно, как решил проблему с компиляцией ядра линукса. Это одна гиганская задача. В лоб не решалось - все 16 агентов начинали работу, сталкивались с одинаковыми багами и терли изменения друг друга. Как решил: взял GCC, компилировал им большую часть ядра - а некоторые файлы компилировал своим компилятором. Если встречалась ошибка - пробовал GCC для верификации - и если баг локализован, отдавал на фикс агенту.

Также некоторых агентов специализировал: следить за эффективностью компиляции, устранять дублирующийся код, следить за общей архитектурой решения "сверху".

Интересно, что опус 4.5 первым в 4 поколении клодов, кто сделал хоть какой то работающий компилятор. И только опус 4.6 смог сделать компиляцию ядра линукса!

В общем, вот оно: https://github.com/anthropics/claudes-c-compiler

Там куча ограничений и недоделок - подробнее в статье, но это во многом работает! Круто, конечно


(ц) Такое мы уважаем

@deksden_notes

⚪️ Vibe Хакеры


Omfg - чего нашел!

🔗 https://github.com/KeygraphHQ/shannon

ИИ агент для взлома пентеста! Ждем орду мамкиных хакеров на проектах. Видимо, надо будет в оркестратор в QA раздел добавлять тесты на него.

⚪️ Новости с фронта


👉 Для фронтэндеров - маленкая штука: https://font-stealer.vercel.app/

Можно исследовать любой сайт - какие там шрифты, и в пару кликов их спереть! WOFF, WOFF2, TTF, and OTF.


👉 Agentation обновился до 2.0

Риалтайм коллаборативный режим

🔗 https://agentation.dev/blog/introducing-agentation-2

@deksden_notes

⚪️ Сварм в Копилоте КЛИ


Похоже - да, эта тема со стаей агентов ушла в народ. Вот и копилот CLI подтянулся. Экспериментальная команда /fleet которая деплоит пучок агентов для параллельной работой над планом задач.

Todo в sqlite положено! ведь это так удобно - сделать sql запрос для получения списка задач. Видимо, готовятся масштабироваться

🔗 https://x.com/_Evan_Boyle/status/2019497961777172488?s=20


@deksden_notes

⚪️ Opus 4.6 в AMP

Акция - amp заманивает к себе

Надо идти по ссылке:

https://ampcode.com/code/AMP-WFRP-3PME

Я ходил - вроде кончились, но скоро обещали еще докинуть. Вдруг кому захочется в лотерейку игрануть!

⚪️ Cursor Credits в Lenny's Product Pass


Открыл тут LennysProductPass - а там в Курсор дают $50 для обычного Annual тира!

В связи с этим вот постом:

🔗 https://www.lennysnewsletter.com/p/how-to-build-ai-product-sense

‼️ Это вниманию тех, у кого есть подписка на Lenny. Без подписки никак

@deksden_notes

Выпустил 2.11 Agent Sessions - из главного что появилось:
- Image Browser и показ картинок из чатов прямо внутри сессии
и модное - поддержка OpenClaw сессий - первый non coding agent в большом зоопарке поддерживаемых агентов

⚪️ Свет мой, зеркальце, скажи! ... (5.2 vs 5.3-codex)

#ddeval #52vs53

Решил провести ЭВАЛ, чтобы сравнить новый 5.3-codex high и свою рабочую лошадь 5.2 high. В обычной работе чтобы понять разницу надо довольно долго поработать, только чтобы уяснить особенности поведения модели. А ведь еще надо вспомнить как оно в прошлой версии себя ведет... В общем, лучше делать предметное сравнение. Силы воли чтобы сделать полноценный бенчмарк у меня не набралось - проблема таки не зудит, но для меня вопрос довольно важный: чем работать дальше. Поэтому я придумал eval - это решение моей специфической условно узкой задачи разными моделями. Тут нужен дисклеймер: задача моя, она не претендует на обобщение и репрезентативность, методика моя, она не претендует на академическую правильность.

Итак, это будет серия постов - смотрите по тегам в поиске, но я постить их буду подряд.

▶️ Что я придумал делать, план эвала:
* берем текущий проект dd-flow
* берем мои промпты на прайминг контекста и общий анализ (прогон сценария и анализ "всего")
* делаем по три контекста gpt5.2 и gpt5.3-codex
* каждый получает идентичные промпты, цепочка из двух: прайминг и промпт на широкий анализ
* агент работает, результат пишет в индивидуальный файл
* после того как все 6 сессий отработают, начнем этап сопоставления
* сначала сделаем сгруппированные таблички по каждой модели (по 3 отчета) - и верификацию находок.
* Верификатором назначим gpt5.2-xhigh: самая дотошная, кмк.
* После верификации и сведения по модели, получившиеся 2 отчета сводим в единый итоговый отчет об обнаруженных проблемах.
* ...
* PROFIT!

‼️ Важные замечания: промпт на анализ предполагает очень широкий спектр анализа - там и code smels, и архитектурные косяки, и куча прочих аспектов. Для выцепления настоящих проблем это слишком широкая задача. Лучше каждый такой аспект отдельно аналиировать. Но у меня в первом приближении хотелось бы посмотреть что "широкой сетью" удастся вытащить! Поэтому значительные вариации в ассортименте найденного даже одной моделью вполне ожидаемы. То есть важно все правильно интерпретировать.

👉 Цель этого эвала - общая оценка работы моделей в сравнении на похожей задачей. Мы скорее будем наблюдать за работой, чем за результатами. Результаты теста по определению будут немного рандомными и разбросанными - это важно понимать, задача широкая, значит температура будет сказываться и модели будут углубляться в рандомные аспекты.

🟢 Чтобы сравнить именно внимательность модели я следом проведу такой же тест, только выберу ОДИН/ДВА аспекта, почитав "общий" сводный анализ. И там уже можно будет сравнить внимательность и дотошность моделей.

...

⚪️ Эвал 5.2 vs 5.3-codex : погнали!


#ddeval #52vs53

Итак, приступаем. Первый пункт марлезонского балета - это прайминг контекста. Запускаем, смотрим.

1️⃣ Тайминги примерно одинаковые получились, но у 5.3 больше не написано сколько модель работала. Видимо, ее комментарии по ходу работы каким то образом сбивают счетчик! Жаль, я обращал на него внимание иногда. Еще зафиксируем процент заполнения контекста на момент завершения прайминга:
* Gpt 5.2: 1:44 (90%), 1:47 (86%), 2:42 (84%)
* Gpt 5.3-codex: 74%, 66%, 66%.

Все три 5.2 начали задание с составления плана, зафиксировав схему работы. Два кодекса 5.3 тоже составили план, а один запустил сварм агентов (но план не составил). Забавно: 5.3 уже подучена пускать сварм чаще!

Первое наблюдение: скорость работы на короткой задаче прайминга - сопоставимая, но контекст кодекс забил заметно больше: все три сессии - значит, это особенность поведения модели.

2️⃣ Приступим к следующей фазе. Запускаем промпт на анализ, и ждем! Тут работа будет подольше.

gpt 5.2: время работы и контекст:
* 1 : работал 14:45, заполнил контекст до 69%, 1 компакт;
* 2 : работал 14:45, закончил на 14% - без компактов;
* 3 : 21 минута, 1 компакт, 55% контекста.

gpt 5.3-codex: время работы и контекст:
* 1 : 15 мин, 23% контекст при завершении, сварм после компакта;
* 2 : отстрелялся за 9:30 примерно, 79%, 2 компакта, без сварма :
* 3 : 20 минут, 48% контекста; сварм сразу.

Получили отчеты, записали их в соответствующие файлы. Зафиксировал размеры:
gpt 5.2: размер отчета:
* 1 : 855 строк
* 2 : 691 строка
* 3 : 662 строки
gpt 5.3-codex: размер отчета:
* 1 : 612 строк
* 2 : 784 строк
* 3 : 629 строк

Видно что между моделями нет особенной разницы в размерах отчетов. Отчет записывался всеми агентами около 2 минут, только одна из 5.2 решила записать отчет поподробнее с номерами строк и записывала 3:40.

Эти забавы скушали 89% лимита 5 часовой сессии на Teams плане (стадия анализа, без сопоставления отчетов).

...