Google обновила Gemini до версии 3.1 Pro
значит ждем выход GPT-5.3 (не codex которая) - В Сан-Франциско сейчас как раз обед,глядишь к вечеру релизнут

Цифры gemini 3.1 pro показывает какие-то космические.

Когнитивная нагрузка и оценка

Насколько я могу судить это 2 больших стены с которыми сейчас сталкивается агентская разработка:

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

Насколько бы огромным не было контекстное окно агента - он будет его обобщать и использовать только необходимый контекст здесь и сейчас.
Поэтому чем более расплывчатый, несвязный, запутанный, нелогичный его контекст - тем сложнее агенту концентрироваться и реализовывать ваше намерение. Как говорил дядя Бен-"Питер, чем больше контекстное окно твоего агента - тем больше твоя ответственность." Поэтому вместо того чтобы загружать контекстное окно единственного агента - намного эффективнее вести работу агентом оркестратором, который сам ничего не читает и не делает, но только руководит командами других агентов - так контекст оркестратора становится предельно чистый и логически связанный, а агенты исполнители реализуют небольшие кусочки общего плана без необходимости распыляться на весь репозиторий разом и понимать всё и вся в один момент = невозможно и приводит к незавершенным задачам,нереализованным планам и сдаче недоделанных задач агентами.
Поэтому полагаю сейчас вы можете наблюдать тренд на мультиагентные системы, где есть оркестрация одних агентов другими агентами. Claude code и codex уже в целом реализовали это в своих TUI/CLI. (Если еще не в курсе как именно настроить codex чтобы ваш агент становился оркестратором - пишите в комментарии, я дам вам инструкции,промпты,mcp и тд.


Оценка:
Агенты не могут объективно оценивать результаты своей работы. Они способны оценить что-то исходя из четких машиночитаемых критериев а ля если ваше намерение чтобы при сумме "1 + 1" программа всегда выдавала "= 2" тогда агенту очень просто понять ваше намерение и критерий выполнения задачи. когда программа начинает выдавать 2 при сумме 1+1 - агент понимает что задача выполнена и ваше намерение реализовано => он докладывает об успехе. Но когда задача сложнее, например "Улучши текущий дизайн сайта, сделай его более красивым" - тут у агента просто нет объективных критериев и он не имеет "чувства вкуса" - он начинает двигаться в сторону того в чем он более уверен т.е. просто полагаться на свои "веса" и результат может получиться абсолютно рандомным. ИИ необходимы четкие критерии по каждому пункту дизайна чтобы он сделал именно то что вы хотите и именно это зачастую вызывает горы проблем т.к. и вы не знаете что хотите и он не знает что значит хорошо в данной ситуации а что значит плохо.
Большинство людей в подобной ситуации руководствовались бы собственным внутренним ощущением красоты и итеративно бы доводили дизайн до внутреннего ощущения "блин, вот щас это выглядит круто, можно сдавать" - у агентов такого нет. Как это решать?Честно говоря пока не знаю хороших способов. Один из лучших сейчас - это ревью агент с промптом исключительно на оценку под определенный scope. Т.е. агент который занимается предметной критикой и аналитикой результата - сообщает агенту который занимается реализацией что он создал говно - тот понимает где именно и что именно говно, переделывает и результат получается чуть лучше.Но проблема в том что оценщик так же не лишен болезни оценки. они в конечном итоге просто доведут реализацию до рабочего состояния без очевидных косяков и архитектурных проблем но фактически может разительно отличаться от того что именно вы хотели. Поэтому сейчас полностью отдавать какую-то реализацию чего-либо на совесть агентов - увы еще нельзя.

Context Pack
Небольшой но полезный MCP инструмент

Описание:
Когда ваш агент claude code или codex отправляет explore агентов разведать местность,узнать что и как реализовано и тд,чтобы самому не перегружаться ненужным контекстом и пр - агенты приносят ему обобщенную и неточную информацию без реальных знаний о коде. Т.е. они всегда сообщают мнение а не точную информацию на которую оркестратор мог бы пологаться или как-либо использовать без необходимости дальше самому лезть в код,рыскать и пачкать контекстное окно.

Для этого был создан mcp инструмент context_pack

Как он работает?
- агент проставляет якори по коду без необходимости самостоятельно писать огромные строки кода. К примеру в файле main.py агент указывает только необходимый интервал строк для добавления в контекст пакет а ля "добавить строки 123-243" и делает краткие заголовки для добавленных строк с возможностью делать заголовки сразу для нескольких вырезок. таким образом агент передает точный контекст без шума и без траты output токенов, которые значительно дороже input токенов. +агент так же строит диаграмму архитектуры и логики чтобы контекст пакет получался полным и у получившего пакет агента было полное и точное представление о необходимом ему контексте.

Что это дает?
- сильно снижает затраты и увеличивает качество контекста агентов = увеличивает точность и эффективность агента при этом уменьшая затраты.

В посте выше я как раз говорил о необходимости снижения когнитивной нагрузки с агентов для получения лучших результатов.Этот инструмент как раз является решением данной проблемы.

В репозитории так же есть скилл чтобы не нужно было настраивать всё самостоятельно. просто устанавилваете - указываете в промпте субагентов что контекст оркестратору передается через mcp context_pack с использованием скилла Explorer Context Pack и вуаля.

Ссылка на инструмент

Compas mcp
Ссылка | плагины

Описание:
mcp инструмент для того чтобы сделать разработку агентом более стабильной и качественной.
В чем суть, mcp compas позволяет:

1. Подключать все утилиты,команды,инструменты репозитория в единую точку вход - mcp__compas и сразу сигнализирует если инструменты семмантически дублируются, чтобы агент не делал копии инструментов(очень распространенная болезнь ии - вместо использования имеющегося создают новые утилиты,инструменты,дублирующиеся функции и пр.), агент получает возможность использовать все инструменты через mcp и явно не допустит дублирующихся инструментов т.к. инструмент вежливо об этом сообщит.

2. Подключать любые созданные кем-либо или создавать необходимые плагины для контроля разработки с помощью ии агента. Чтобы агент не совершал архитектурных,технических ошибок,дублирований, не допускал мертвого кода и мусора и пр. в целом mcp__compas позволяет написать любой плагин и переиспользовать свои пакеты плагинов в любом проекте. Удобно чтобы не создавать одно и тоже из проекта в проект. Позволяет работать всегда одинаково удобно в любом проекте в котором вы ведете разработку.сам mcp компас является тонким инструментом - все возможности подключаются через плагины.
Текущий список готовы плагинов для compas доступен здесь

Позвольте агентам высказаться

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

Я явно фиксирую в AGENTS.md/CLAUDE.md в корне проекта правило чтобы агент при обнаружении любой проблемы агент останавливался и создавал соответсвующий подробно описанный Github Issue, чтобы обнаруженные проблемы не оставались нерешенными, затем продолжал работу дальше.

Что мне не нравится в OpenAI

Описание:
Я нарочно подчеркиваю: это моё субъективное мнение и субъективная оценка фактов.
Это не "приговор суда",но когда 15 лет повторяется один и тот же управленческий почерк в разных местах — это уже не «случайность», а паттерн и системное поведение.

Сэм Альтман — CEO OpenAI.

До OpenAI он руководил Loopt (2005–2012).
По открытым свидетельствам и пересказам бывших участников, там уже звучали претензии к стилю управления: непрозрачность, манипулятивность, хаос в коммуникации. По слухам менеджмент дважды обращался к совету директоров с просьбой уволить Альтмана за "обманчивое и хаотичное поведение"

Потом — Y Combinator (2011–2019).
В 2019 официально рассказывали историю про «переход Альтмана с управления в менее операционную роль». По факту к 2020 его трек в YC закончился.
Параллельно в тот период звучали серьёзные обвинения по токсичной среде и системным перекосам
против женщин.
Когда второй раз проявляется похожее поведение - это уже меньше похоже на “просто недоразумения”.

Дальше — OpenAI.
Тут в целом уже окончательно складывается пазл.
Критика в адрес Альтмана шла не от «рандомов из твиттера», а от людей изнутри ближайшего окружения и круга компании: члены совета, исследователи по безопасности, ключевые сотрудники.
И когда подобные сигналы идут не одиночным голосом, а пачкой — я уже не вижу причин делать вид,
что “это всё хейтеры” или "слухи".

Ноябрь 2023 (17–22 ноября): момент, который показал как там всё устроено
Большинство помнят этот момент как "уволили, за что? - вернули потому что 700 сотрудников взбунтовались - лол, нифига его там любят", Но на самом деле там была не “мелодрама на эмоциях”, а пятидневная разборка за власть, где на секунду наружу вылезло устройство OpenAI без косметики.

Кто и как отстранил Альтмана (17 Ноября)

Альтмана убрал не Microsoft, не “рынок”, не “пользователи”, а совет директоров некоммерческой
OpenAI, Inc. той самой надстройки, которая формально управляет всей конструкцией
OpenAI.

- Сэм Альтман “уходит с позиции CEO и покидает совет”;
- Мира Мурати назначена interim CEO;
- причина — совет заявил, что Альтман был “not consistently candid” (не был последовательно откро
венен) в коммуникации с советом, и это мешало совету выполнять надзор. (Т.е. переводя на русский - он систематически врал и скрывал правду от совета.)

Ключевой момент, который многие упускают: в том совете были независимые директора + Илья Суцкевер
как главный научный исследователь. То есть это выглядело как: “люди изнутри верхнего контура управления” решили, что с таким CEO дальше нельзя.

Почему это превратилось в пожар 18-20 Ноября?

Дальше началась цепная реакция, компания буквально за дни пережила несколько смен “центров управления”, сначала руководила Мурати,затем совет ставит Эммета Шира и тд.
Паралельно Microsoft публично и очень быстро обозначила: Если OpenAI развалится "окэ, мы заберем команду к себе"
Это уже попахивало не скандалом, а расколом всей организации.

Дальше появилось письмо от 700+ сотрудников (PS: это не про любовь к лидеру)

Сотрудники, включая самых топов написали коллективное письмо в котором четко обозначили "Либо совет директоров уходит и возвращает Альтмана, либо мы все уходим"
Забавно, что Суцкевер позже комментировал ситуацию как что он был уверен что сотрудники обрадуются уходу Альтмана, но фактически получил обратный результат, потому что в момент когда всё трещит по швам - люди думают не про моральные подвиги а про самосохранение. Если OpenAI развалится - развалится и их карьера, проекты, акции, доступы к вычислениям, исследования и тд.

Развязка 22 ноября
Альтман возвращается к роли СЕО а совет перезагружается.
То есть как итог - Совет попытался снять Альтмана, но проиграл потому что для OpenAI это был слишком резкий шаг, слишком много неопределенности, компанию начало трясти что могло привести к её развалу. В итоге Альтман вернулся не слабее, а фактически сильнее, полностью захватив совет директоров и грубо говоря взяв OpenAI под свой полный контроль.

Позже Илья Суцкевер в рамках Иска Илона Маска против OpenAI и Альтмана (Про предательство миссии и уход в закрытую коммерческую модель организации) рассказал под присягой:

- он видел у Альтмана устойчивый паттерн: “сказать каждому то, что тот хочет услышать”, стравливать руководителей, давать противоречивую информацию и подрывать надзор совета директоров.
- он собрал доказательную пачку (скриншоты/заметки) и написал мемо на ~52 страницы, которое отпра
влял независимым директорам; (theverge.com
- и он объяснял, почему не отправлял это напрямую Альтману: потому что опасался, что тот "придумает как заставить это исчезнуть"

Маск публично и в исках в целом рисует такую картину:
OpenAI и Альтман ушли от исходной договорённости “делать открыто и ради человечества” и пришли к модели, где ключевые технологии закрыты, а реальным бенефициаром и партнёром стал Microsoft.
По моему мнению оно так и есть.OpenAI в целом плевать на пользователей и после ухода Суцкевера стало плевать на безопасность.


Поэтому название компании “OpenAI” это скорее шутка и издёвка, которая не имеет ничего общего с тем чем на самом деле она является

Потому что пользователь в этой системе — не партнёр, а расходник с красивым интерфейсом.

- Ваш диалог и контент может использоваться для улучшения моделей по умолчанию и без спроса, если ты
сам не отключаешь/не обходишь это отдельными настройками и режимами.
- Правила и Terms написаны так, чтобы у компании был широкий коридор манёвра, а у пользователя —
длинный коридор в поддержку без гарантий результата.
- Блокировки аккаунтов без причин и без возможности апелляции повторяются тысячами.
- Потеря аккаунта = Потерял личные данные. Тебе не дают возможность как-то загрузить свои ЛИЧНЫЕ данные и диалоги.
Для инфраструктурного AI-сервиса такого масштаба - это нонсенс.
- При блокировке аккаунта вам не возвращают средства. в соглашении явно указано что вам не вернут средства и так оно и есть в целом.Можете загуглить и проверить самостоятельно. Людей массово блокируют,не объясняют причин, не возвращают средства и данные.

Perplexity Computer
Ссылка

Описание:
Perplexity запускают какую-то новую фичу суть которой насколько я понял в том что у агента perplexity появляется собственное рабочее место и он способен выполнять какие-то большие задачи end-to-end в мультиагентном пайплайне где GPT-5.2 может делать одно, Opus 4.6 другое и тд.Разные агенты делают то в чем они хороши и работают над реализацией общей задачи. В целом это именно тот поворот рынка о котором шла речь в постах выше. ИИ рынок разворачивается к дроблению больших задач между множеством субагентов которые работают каждый над своей областью доводя общую задачу до полноценной реализации, а не просто на бумаге "мы всё сделали" а на деле 90% проекта не готово.
Она способна проводить исследования, проектировать, кодировать, развертывать и управлять любым проектом от начала до конца.

Nano Banana 2

Описание:
Google DeepMind запустили обновленную версию Nano Banana Pro -> Nano Banana 2

Nano Banana 2 становится доступен всем и сразу.

Вы нигде не найдете на сайте именно выбор модели и название "Nano Banana 2" - просто нажимаете создать изображение как всегда и под капотом работает уже обновленная модель

:)

Переусложнение | Оверинженеринг

Описание:
Как правило когда проект создается с использованием ии агентов - он выглядит не как оптимальная реализация соответсвующая своей цели, а как "создать и разработать бесконечный аккумулятор, чтобы создать терминатора с 0 чтобы он в свою очередь автоматически включал кондиционер в вашей комнате когда вам становится жарко"

Почему такое вообще происходит? - в большинстве случаев потому что:
1. Когда вы просто "вайбкодите" т.е. вообще не заглядываете в код и просто итеративно делаете то что видите перед экраном, а ля поменять кнопку А на кнопку Б - вы видите что то что вы попросили действительно было выполнено, но в коде там вместо логичного, оптимального изменения рождается какой-то очередной Франкенштейн - вы этого не видите и продолжаете разработку, в итоге получаете не просто космический корабль из костылей а межгалактический крейсер размером с вселенную просто чтобы реализовать какой-то вполне бытовой проект🤷‍♂️.

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

2. Прежде чем приступать к реализации - планировать и создавать контракт документацию.Чтобы для каждого отдельного среза, для каждой отдельной реализации чего-либо был контракт документ по которому даже модель с 1млрд параметров смогла бы что-то реализовать без лишних уточнений и гаданий.

3. Валидируйте и проводите ревью своих идей и контрактов, лучше всего самостоятельно читать что там написано (часто агенты склонны писать много текста с 50% реально полезного смысла) - полезно,необходимо и намного дешевле провести технический и архитектурный аудит и валидацию плана вместо того чтобы потом реализовывать монстра несколько дней подряд и мучаться от очередного "всё работает не так как я хотел" или вообще не работает.

Хороший проект написанный агентами - это не 150 лет мучений доводя и исправляя ошибки допущенные агентами пока вы добивались того что хотели.
Хороший проект созданный агентами - это когда вы сначала создаете полный пакет контрактов, спецификаций, правил, философии проекта, создаете полный контур документации проекта так чтобы в документации ваш проект был полностью описан и формализован end-to-end и саму документацию вы проверите, желательно лично, +с несколькими агентами и уже после прохождения полного ревью, убеждаясь что это полностью соответсвует вашему намерению - Реализуете проект.

Важно:
1. Агенты чинят симптомы а не инвариант

Питер, чем больше контекстное окно - тем больше ответственность

Даже если слухи магически откажутся правдой - это может не дать серьезной разницы в эффективности агентов