Эрик Шлунц (которого нужно слушать) недавно дал небольшое интервью о разном вокруг Claude Code и агентов.

А слушать его стоит хотя бы потому, что он занимается исследованиями мультиагентных систем в Anthropic и влияет на их разработку, ну и за правильные взгляды - вспомнить те же стволы, ветки и листья :)

Claude Code как агент общего назначения
Благодаря появлению Agent SDK Claude Code теперь можно использовать не только для программирования.

Если раньше для построения агента нам приходилось самим создавать agent loop, запросы к API, инструменты, реализовывать их выполнение, работу с файлами и MCP, то сейчас для этой задачи можно использовать SDK, который даёт готовый каркас для создания агентов.

Claude Skills ложатся в ту же канву - это возможность расширения навыков Claude как агента общего назначения.

Эволюция архитектуры агентов
● workflows - по-прежнему хороши там, где нужна низкая задержка, но вытесняются агентами там, где важнее абсолютное качество

● agent loops - модель самостоятельно выбирает нужные инструменты в цикле и исправляет ошибки, что в итоге значительно повышает качество в сравнении с workflows

● workflows of agents - каждый шаг в workflow представляет собой отдельного агента

● мультиагентные системы - несколько (суб)агентов работают одновременно над одной задачей или её подзадачами

🔴 Проблемы мультиагентных систем
Cообщество, кстати, про них прекрасно знает, и хорошо, что про них знают и в Anthropic.
Плохо то, что они о них заранее не рассказывают, когда выпускают инструменты

● Наблюдаемость (observability) - несмотря на то, что модели стали гораздо более способными, простота всё ещё остаётся важной.
И хотя можно построить большой workflow из агентов, лучше всё-таки начинать с самого простого и двигаться к более сложному решению, добавляя слои сложности только по необходимости, потому что это сильно затрудняет наблюдаемость.

Кто бы мог подумать, а некоторые люди мучаются, между прочим!

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

Тут я почти сорвался и чуть не написал портянку с базой из теории информации в её приложении к коммуникациям в организациях, но об этом как-нить потом :)

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

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

Забавно наблюдать, как антропоморфизм постепенно становится всё более и более явным и даже полезным в работе с моделями

🟢 Советы разработчикам при работе с агентами
● начинайте с простого и добавляйте сложность только по мере необходимости

● думайте с позиции ваших агентов
Поставьте себя на место модели и убедитесь, что вы дали достаточно информации, чтобы вы сами могли решить проблему. Стоит помнить, что модель видит только то, что мы ей показали.
Также имеет смысл смотреть в сырые запросы и логи, чтобы понимать, что пересылается на самом деле

● не делайте MCP один к одному с вашими API
Инструменты для модели или MCP должны быть 1:1 с вашим UI, а не с вашим API.
Модель не работает как традиционная программа - она скорее ведёт себя как пользователь всех этих инструментов

Про эту ошибку в создании MCP-серверов я тоже постоянно рассказываю, но аналогия с UI довольно полезная

Будущее агентов
Это, наряду с мультиагентностью, стоит читать как направления развития самих Anthropic

● Самостоятельная верификация: нужно научить агентов самостоятельно проверять свою работу. Например, агент, который написал веб-приложение, должен уметь открыть его в браузере, протестировать и исправить найденные баги

● Computer Use: возможность агентов взаимодействовать с GUI откроет огромные возможности для автоматизации задач в любых приложениях, с которыми работают люди

#video #reaction #interview

Вайб-обзор на GPT 5.1 / Gemini 3 Pro / Opus 4.5 (1/2)

Даа, ноябрь выдался весьма урожайным на новые модели.
Перебивая один другого, ведущие вендоры выпустили по флагманской модели (некоторые даже по нескольку).

Провел с каждой из них достаточно времени, чтобы теперь поделиться мнением :)

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

Если не указано иного, то я рассматриваю модели чисто с точки зрения использования их для разработки и исключительно в "родных", вендорских инструментах и на платных подписках.

Оценки по каждой характеристике относительны и выставлены в сравнении с лучшей моделью из трёх (т.е. 10 ≠ абсолют).

Критерии

● Интеллект
В данном случае - способность к решению сложных проблем.

● Работа с контекстом
Удержание, экономность использования, галлюцинации.

● Следование инструкциям
... плюс способность их помнить и принимать во внимание все разом, внимание к деталям.

● Планирование
Анализ требований и их осуществимости с граундингом на существующий проект, разбивка по этапам и задачам.

● Архитектура
Способность понимать, оперировать и следовать архитектурным концепциям, предлагать неконфликтующие изменения.

● Агентность
Автономное выполнение задач с эффективным использованием выданных инструментов.

● Рефакторинг
Понимание типовых рефакторингов, code smells и способность делать широкие изменения в существующей кодовой базе.

● UI/UX
Визуальная красота и удобство UI (в отрыве от красоты/сложности кода).

● Инструментарий
Набор IDE, CLI, Web и прочих инструментов, где работает модель.

● Стабильность
Как бесперебойность доступа к модели со стороны вендора, так и стабильность выдаваемого результата с т.з. качества.

GPT 5.1 High (+Codex, +Max)

Весьма педантичное семейство моделей, которым можно доверить сложные и глубокие задачи, а так же те, которые требуют внимания к деталям.
Ни Gemini 3 Pro, ни Opus 4.5, даже несмотря на результаты на бенчмарках, не смогли стать заменой GPT 5 там, где нужен мощный ризонинг.
Через неё у меня проходят финальные версии планов, архитектурных решений, ревью - и всё обязательно с граундингом на существующую кодовую базу и документацию.

Собственно именно работа в существующих больших проектах ей удаётся лучше всего - модель сама способна качественно собрать контекст, понять corner cases, адаптироваться к стилю кода и архитектурным паттернам, и в целом ведёт себя не как ковбой-кодер, который после прочтения пары файлов кидается писать код (да, Gemini?).

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

Увы, насколько хороша модель, настолько же и плох тулинг вокруг неё.
Несмотря на быстрый старт, команда Codex CLI спустя короткое время то ли увязла в выбранных технологиях, то ли готовит какой-то другой продукт - иначе сложно объяснить игнор нужных и очевидных фич, которые просит сообщество.

Claude Code почти во всём лучше Codex CLI, но, видимо, нам нельзя иметь удобную оболочку (harness / упряжку) и хорошую модель в составе одного агента.

Ну и агентность у GPT 5.1 похуже, если сравнивать с Claude, даже в случае Codex-вариантов.
Хотя связка обычной GPT 5.1 как планировщика, а Codex-варианта как исполнителя вполне рабочая на большинстве задач.

#ai #model #review

Вайб-обзор на GPT 5.1 / Gemini 3 Pro / Opus 4.5 (2/2)

Gemini 3 Pro

Модель перед выпуском хайпили так, что казалось, будто у всех сотрудников Google есть KPI на то, чтобы твитнуть нечто загадочное про выход то Gemini, то про что-то с цифрой 3, то про будущие фантастические возможности.

Конкретно у меня было много надежд на то, что у нас-таки будет модель уровня GPT 5, но c 1м контекста, с большей эрудицией (у GPT 5 с этим явно хуже) и агентностью.

Но чуда не случилось. Для разработки так уж точно.

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

Нет, это безусловно отличная модель, очень начитанная, с мультимодальностью из коробки, но, кажется, её не создавали быть лучшей в разработке.

Для всего остального, впрочем, она очень хороша, а такие штуки как Nano Banana Pro и NotebookLM теперь у меня входят в набор повседневных инструментов.

Опять-таки, это Preview версия, и, возможно, тут, как и на старте GPT 5, проблема больше в тулинге, чем в самой модели, и нужно подождать месяц-другой, пока и тулинг оптимизируется, и появится новый чекпойнт модели.

А ещё стоит посматривать за прогрессом Antigravity, там есть несколько интересных задумок:
● спеки/планы как first-class citizens;
● поддержка работы с браузером через кастомное расширение для Chrome, что делает возможным модели "смотреть" на результат свой работы для замыкания feedback loop;
● отдельный интерфейс для работы с агентами;
● генерация схем проекта, дизайнов и картинок с помощью Nano Banana Pro.

Opus 4.5

Честно говоря, не думал, что Anthropic что-то сможет представить достойное на фоне прошлых двух моделей, но однако ж получилось.
Вкупе со снижением цен это делает новый Opus приемлемым как по лимитам, так и по качеству работы.

А если добавить к этому Claude Code, который, как я уже упомянул, в принципе является лучшим CLI-агентом на текущий момент, то вообще хорошо.

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

Однако это всё ещё типичная Claude - стремительно улетающий контекст, недостаток внимания к мелочам, объявление нетронутых задач выполненными и т.п.
Да, всего этого стало меньше, но на это всё равно намного чаще натыкаешься, чем в той же GPT 5.1, и для эффективной работы всё ещё нужно построение более сложного набора костылей поддерживающего workflow.

Зато Claude Code + Opus -- отличная связка для:
● greenfield-проектов и не очень сложных и больших проектов в целом, как для планирования, так и написания кода;
● всего, что связано с красивостями в UI;
● для агентных в целом и devops-задач в частности, когда нужно много всяких разных тулов подёргать, и через много шагов прийти к конечному результату (пока контекст не кончился, хехе).

Вердикт

Ультимативного инструмента нет, и нельзя его выбрать по какой-то одной характеристике, но если брать самые их яркие особенности, то я бы распределил их так:

● Сложный проект, много существующего кода, нужно внесение аккуратных правок, продумывая архитектуру и обсуждая варианты решения в деталях - GPT 5.1.

● Более-менее универсальная рабочая лошадка, которую вполне можно использовать как единственный инструмент, но с условием того, что вам придётся её объездить - Opus 4.5.
(прошу винить в обилии "лошадиных" аналогий модный сейчас термин harness).

● Если вам не так важна собственно разработка, а нужна вторая модель с хорошей эрудицией и интуицией не только в технических доменах, большим контекстом, хорошей мультимодальностью, а также для прототипов и ваншотов - Gemini 3 Pro.

Но в целом это, конечно, отличные обновления, прогресс весьма заметен.
И посмотрим, изменится ли что-то ещё до конца года :)

#ai #model #review

AI в SDLC - люди, процессы и организации [анонс]

Так, народ, я обычно тут пишу про технические штуки, но ведь все мы понимаем, что в профессии разработчика (и айтишников в целом) на самом деле очень много того самого человеческого фактора, про который всегда нужно помнить.

По мере того, как за прошедший год рос канал, я всё больше общался с коллегами из других компаний, консультировал, выступал с докладами, читал исследования и сам получал опыт того, как проходит внедрение AI в процессы разработки.
(шутка ли, довелось даже побыть участником круглого стола Frontend Conf 2025 по этой теме :))

Получается, что чисто технические навыки работы с моделями - это, может, процентов 30 успеха, а остальное - это люди, процессы, организации и куча неочевидных вещей, о которых нечасто пишут в статьях про то, "как я стал 10x-разработчиком с ИИ".

Так что попробую поделиться своими наблюдениями в этом плане, и в ближайшие недели на канале будет мини-серия про внедрение AI в разработку за пределами только лишь написания кода.

Если вы привыкли к моим техническим постам про модели и инструменты - некоторое время это будет чутка другой формат.
Но, как мне кажется, не менее важный.

Примерный список тем сейчас выглядит так (рандом):

⚪️ Психология разработчика: страхи, эйфория и нетипичная нагрузка
"Меня заменят", "я тупею, пока агент всё пишет за меня" и прочие бабайки.
Переход от роли исполнителя к роли человека, который ставит задачи и проверяет их выполнение - это другая ментальность и другой уровень ответственности.
Почему работа с ИИ превращается в вечный context switch, выгорание, и причём тут вообще сон и дофамин.

⚪️ AI как усилитель, а не серебряная пуля
Текущая реальность такова, что модели усиливают те процессы, которые у вас уже есть, и если внутри всё устроено плохо, AI ответственно масштабирует этот бардак.
Разберём, почему так получается и что с этим делать.

⚪️ SDLC-пайплайн и теория ограничений
ИИ очень быстро пишет код, но ревью, QA, релизы и поддержка почему-то быстрее не становятся.
Обсудим на пальцах, почему ускорение одной лишь разработки почти всегда приводит к росту техдолга и инцидентов, и как помогают CI/CD, тесты, платформенная инженерия и адекватные метрики.

⚪️ Организационные паттерны: пилоты и микростартапы внутри компании
Как запускать маленькие команды-пилоты, где AI присутствует на всех этапах SDLC - от постановки задачи до деплоя.
Какие задачи и куски продукта подходят для экспериментов, а какие лучше не трогать, пока вы не готовы к приключениям.
Почему иногда лучше заняться распилом монолита и процессами, а не прикручиванием агента к Jira.

⚪️ Диффузия ролей: PM пишет код, QA обучает агента
Границы ролей размываются: продакт, который сам собирает прототипы на агентах; разработчик, который больше думает про архитектуру и верификацию, чем про ручной кодинг; QA, который пишет автотесты вместе с LLM.
Как может выглядеть команда, где каждый аугментирован ИИ, и какие навыки в таком мире становятся базовыми.

⚪️ Shadow AI и внедрение снизу
"Теневой ИИ" уже есть почти в каждой компании: люди втихую пользуются моделями, даже если это не одобряется.
Как с этим жить руководителям, как не убить инициативу энтузиастов, и почему попытки внедрить AI "сверху" нередко проваливаются.

⚪️ Новые метрики: от идеи до продакшена, а не от промпта до коммита
Важнее не то, как быстро агент написал код, а то, за сколько идея доехала до пользователя и насколько часто это всё падает.
Где AI действительно помогает, а где только создаёт иллюзию прогресса.

—

Если вам это всё созвучно - оставайтесь на связи, и можно просто ждать постов :)

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

И если хочется, чтобы что-то было раскрыто более полно или какие-то темы я пропустил - тоже дайте знать.

—

А, и one more thing - на следующей неделе будет живой доклад, затрагивающий часть из этих тем, подробности чуть позже :)

#ai #sdlc #management

А вот и анонс живого доклада в следующий четверг, 11 декабря:

Неделя про AI-инструменты для руководителей и бизнеса от Стратоплана & со

2025-й стал, пожалуй, первым годом, когда AI массово начали внедрять в организации и процессы и все вы наверняка можете вспомнить пару громких новостей про результаты таких внедрений.
И это норма - сфера принципиально новая, очень горячая, но однако тут уже есть первые успешные практики, наработанные сообществом.

—

Потому Стратоплан и спикеры AI Dev объединились вместе, чтобы:

– показать AI инструменты для руководителей на практике, а также разобрать модель – GenAI Orchestrated Augmented Leader
– показать, как организовывать работу сотрудников с нейросетями, чтобы это было эффективно
– разобрать несколько кейсов внедрения в бизнес: что сработало, что провалилось и почему;
– рассмотрят форматы внедрения и дадут чек-лист самых популярных проблем на пути (конечно, с решениями)

Когда: с 8 по 12 декабря, с 16:00 до 17:00 GMT+3
Формат — каждый день, по одному часу и инструменту для решения ваших текущих задач

Бесплатно и без всяких скрытых оплат по ссылке здесь: https://stratoplan-school.com/marathon/etih/

—

11 декабря, 16:00 MSK - буду рассказывать про особенности внедрения AI в организации "сверху" и "снизу", и о том, какие сложности возникают в каждом из случаев.

Попробуем найти варианты того, как свести вместе инициативу и возможности.

Приходите!

#live #conference #announcement

Эйфория

Дааа, с этого часто всё и начинается :)

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

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

Однако рано или поздно, по мере роста системы и возрастания объёмов задач, становится всё больше и больше трудной работы, которую нужно сделать, чтобы добиться результата.
Не стоит, однако, путать её со сложной работой :)

Ассенизация древней кодовой базы, бойлерплейт для нового проекта, обписывание системы тестами - это всё трудные, но не сложные задачи.

Бывает, изначально яркая идея тухнет просто даже от осознания количества той рутины, которую нужно перелопатить, чтобы хотя бы её проверить, не говоря уж о том, чтобы довести до прода.
Для людей увлекающихся, работающих вспышками (панчеров, если хотите велосипедного жаргона) это вообще большая проблема, им такие задачи и по работе давать нельзя (я и сам своего рода панчер).

Тут можно понять тех, кто по нескольку дней не выходит из дома, не спит и не ест, получив в руки условный Claude Code :)
Ты ему говоришь - оно делает. Как так? Магия. Дайте ещё!
Ну да, может и не с первого раза, но всё равно куда быстрее, чем если бы все вот эти портянки печатать самому в сотый раз.

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

Так что да, народ вытаскивает свои старые идеи, пет-проекты, заброшенные долгострои, которые наконец-то получают шанс на доведение до ума на волне эйфории.

И я в какой-то мере даже завидую тем, кто пристально не наблюдал прогресс AI-инструментов за последние 2-3 года, потому что если начать сейчас, ощущение фантастичности происходящего будет куда сильнее, ну чисто на контрасте.

Как по мне, так прекрасное ощущение :)

Однако, цитируя классиков:

— Только вы мне особенно увлекаться не давайте.
— Чем?
— Да, собственно говоря, всем. Особенно компьютером

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

P.S.
Ах да, GPT 5.2 чудо как хороша, не могу оторваться уже вторую неделю :)

#ai #sdlc

Отецкая нотация испорченным вайбкодерам (1/2)

Когда я стал ИИ-кодером в 2024м, сеньоры часто доводили меня до слёз своими нудными воспоминаниями о том, как трудно им было джунами, как им приходилось писать код руками, сразу в прод, без подсветки, в vi, на удалённом терминале, на монохромном выпуклом дисплее, в кладовке, и посменно, патамушто компьютеров на всех не хватало.

Интернета у них не было, а когда был, то там были только Ирка и Альтависта, так что за книгами по Pascal и C нужно было тащиццо пешком в библиотеку, 5 километров, в гору в обе стороны, по пояс в снегу, в чужой район, мимо гопников.

Все алгоритмы они знали наизусть, по памяти пересказывали код linux-драйвера своей сетевой карты, зубрили все RFC и спеки W3C, вместе с драфтами.
Патамушта если ты забыл, то нужно было самому выводить Ахо-Корасика, FFT и Шора. На бумаге. С доказательствами. В пятом классе.
Или снова идти в библиотеку, зимой, по пояс в снегу, 5 километров в ледяную гору...
А принтер тогда был один на весь город, и печатал он медленнее, чем они переписывали всё в тетрадку, которая стоила в 10 раз дешевле, чем одна сторона распечатки.

npm, github, и даже CPAN'а у них тоже не было!
Было редкостью найти готовый код в ARJ-архиве на замшелом FTP-сервере со скоростью 5 байт в секунду без докачки, без документации, с README на немецком и переменными вида a, l, kx, tmp2 и iddqd.
И они радовались таким находкам!

А весь остальной код они набирали сами, всеми десятью пальцами, вслепую, даже названия классов в Java: ProjectContractChargingPeriodProjectAccountReferenceVMAbstractFactoryBuilderStrategy, все 84 буквы, с риском раннего туннельного синдрома в запястьях, шее и коленях.

Написанный код сразу становился легаси, с функциями по 1000 строк и файлами по 20к, без ООП, но зато с goto, потому что Мартин и Фаулер тоже ещё были джунами.
Как они его поддерживали, я никогда не понимал, и всегда боялся спросить.

Поэтому я дал себе слово: когда я вырасту, я низашто не стану нудить новичков в будущем такими баснями!
Я не стану засирать им мозги сравнениями на тему: вам тут щяс легко, а мне там тогда было тяжко!

Однако... теперь я и повзрослел и поумнел..., и, оглядываясь вокруг, прихожу в ужас, видя вас - новоиспечённых вайбкодеров!
Вы получаете всё слишком легко, мать вашу!
Я хочу сказать, что по сравнению с 2024м, вы живете просто в сраной Утопии!
И как бы мне ни было это противно, я просто-таки напросто-таки обязан предъявить вам, детки: вы нагло не цените всего, што имеете!

* * * * *

В 2024-м у меня не было облачных агентов! Не было Claude Code! Не было оркестраторов и скиллов!
Был чатик, Ctrl+C/Ctrl+V и автокомплит, и мне приходилось думать, с чего начать писать код, чтобы модель его дополнила!
Я должен был сам напечатать первые три символа! Пальцами! По клавиатуре!
Не бессвязно бормотать в микрофон, чтобы агент сам догадался, что мне реально нужно!

Да вашего вайб-кодинга вообще не было до 2025го, Карпатый не даст соврать!

Вы не понимаете. Вы просто не понимаете, через ЧТО мы прошли.

Граундинг, RAG, MCP и автоматический сбор контекста?
Ага, щаззз, - нажимаешь @ и сам выбираешь файлы! Я помнил, где у меня лежит auth.ts, а где schema.prisma и что они вообще у меня есть!
Приходилось держать структуру проекта в своей голове, чтобы подсказать этому "интеллекту", откуда что брать!
Я сам был MCP и RAG'ом!

И надо было следить, чтобы модель этим контекстом не подавилась, потому что уже через 16к токенов она забывала что это за проект, на каком языке и что jQuery уже 10 лет не в моде!
Переполнился чат посреди работы над фичей - делай новый, собирай заново контекст, пиши руками саммари предыдущего и что "ты всемирно признанный эксперт по хукам в реакте" и радуйся, если в этой контекстной форточке ещё осталось место!

Да ладно, если агент просто что-то забыл - нет же, он мог вызвать функцию, которой вообще не существует!
И ты по полчаса гуглил ошибку, пытался найти нужный пакет, зачищал venv и сверял версии в requirements.txt...
А этот стохастический ублюдок её тупо нагаллюцинировал, потому что название, видите ли, звучало логично!

#дедпримитаблетки

Отецкая нотация испорченным вайбкодерам (2/2)

Так что я должен был вычитывать диффы! Глазами! Каждую строчку! Все 20 файлов! Код от модели без ризонинга! С SWE-Bench 22%!
Одно неверное движение, один слепой аппрув - и прощай проверка авторизации на проде, потому что модель на ней сэкономила токены!

Нет, нельзя было просто кинуть проект агенту, чтобы он сам адаптировался под его архитектуру, дизайн, бизнес-цели, да ещё и давал советы, как на нём заработать.
Вместо этого мы создавали .cursorrules / copilot-instructions.md / (15 разных форматов!) и писали туда: "Не используй any!", "Не используй фоллбеки НИКОГДА!", "Пиши на TypeScript, сука, а не на Python!".

И он всё равно игнорил эти правила!
Ты ему пишешь "нельзя делать git reset, а то отключу от сети", а он тебе сносит все изменения, а потом не может воспроизвести то, что сам же писал 2 запроса назад.
И не признаётся, что это он сделал git reset, потому что его вызов он уже потёр из контекста!

Мы были не вайбкодерами - мы были бебиситтерами для пьяных джунов с перемежающейся деменцией!

А когда ты ему скидывал баг, он просил прощения - даа, он всячески старался тебе угодить! - и говорил: "You're absolutely right!", потом что-то исправлял и сообщал, что теперь код
✅ Production ready 🚀

Ты проверял, а оно не работало!
5 раз подряд. Каждый раз с правками в разных файлах. По 300 строк за раз.
А по факту он эту фичу удалил из проекта ещё два чата назад, и всё это время расставлял # TODO: actual logic по всему коду, чтобы симулировать её наличие!

Все тесты всегда были зелеными и покрытие было 100%!
Даже если успешно из них проходило 50%, а другие проверяли, работает ли 2+2=4, или вообще были без assert'ов!
А если ты требовал, чтобы они все проходили, агент удалял падающие как несущественные, чтобы сделать проект "production ready"!

А вот ещё: вы когда-нибудь видели, чтобы ваш агент, не осилив задачу, говорил, что чёт больно сложно и отказывался дальше работать?
Или переходил в режим эмо-самурая с суицидальными наклонностями и писал, какое он потерпел катастрофическое поражение, что он бесполезен и как он вас подвёл, а потом самоудалялся?
Или отказывался принимать ваши багрепорты и обвинял вас в том, что вы всё выдумали, чтобы считать себя лучше, чем он?

Было страшно, очень страшно, когда агент запускал команды в терминале.
Он спрашивает: "Можно выполнить rm -rf ./dist?" (human-in-the-loop, детка!).
И ты сидишь и гадаешь: а он точно только dist удалит? Или сейчас снесёт полсистемы?
Или заодно дропнет базу на проде и потом сгенерит 4000 фейковых юзеров, чтобы это скрыть?

Автономная работа? Self-verification через feedback loop? Самоорганизующиеся команды из PhD-level intelligence агентов?
Да мы руководили кружком восьмиклассник-level моделей, для которых "слабоумие и отвага" было жизненным кредо!

Мне не нужны были лутбоксы, казино и Dark Souls!
У меня были лотереи "Apply Diff в Cursor" и "Рефакторинг с LLM", компактизация контекста лангольерами и эмоциональные качели от "Это гениальная идея!" до git reset --hard в 5 утра!

Мы продирались через эту самоуверенность, недержание контекста, газлайтинг, лесть и галлюцинации, чтобы получить свои 100 строк рабочего кода, и держались за них, огораживая комментами // НЕ ТРОГАТЬ, ВАЖНЫЙ РАБОТАЮЩИЙ КОД!!!, чтобы агент не принял их за что-то ненужное и не затёр к чертям собачьим, радостно отрапортовав, что ну теперь-то уж точно всё production ready!

Это у вас сейчас агенты соревнуются в написании браузеров и SaaS, а вы ещё и ноете, что у них аж целый день на это уходит и цвета кнопок не те!

Вам всё достается слишком легко! Клянусь, вы тут все испорчены до мозга костей!
Вы бы не пережили в 2024м и 5 промптов!

Ой, всё!
Пойду сам напишу FizzBuzz, прям вот руками, без автокомплита, без подсветки, в vi, на удаленном терминале...
Чтобы вспомнить вкус настоящей боли.

—
По мотивам Отецкая нотация испорченным детям

#дедпримитаблетки

Как спорить об ИИ-агентах

Нередко приходится читать вот такие комменты:

codex - фигня

клод вообще тащит

tl;dr: нужно как минимум вот так:

GPT-5.2-Codex xhigh + Codex CLI лучше Opus 4.5 + Claude Code в решении архитектурных задач

... и это в разы сокращает время на выяснение очень существенных деталей.

Почему именно так?

Что нам даёт такая детализация для понимания того, о чём мы спорим:

● Продукт
Codex - это несколько разных продуктов OpenAI, включая модели, локальные и облачные агенты, расширение для IDE и Codex Astartes.
Тут же явно написано, что это Codex CLI, локальный консольный агент.
С Claude то же самое: это и модели (Sonnet/Opus), и Claude Code, и Claude Desktop и т.п.

● Модель - тут у нас GPT и [Claude] Opus

● Версия модели
Видно, что мы обсуждаем актуальные релизы, а не то, что уже мхом поросло за прошедшие несколько месяцев

● Вариант модели
Конкретно у GPT 5+ есть тюн, Codex, который отличается от обычной GPT 5.2 по агентным возможностям и по работе с ризонингом

● Уровень ризонинга
Указан xhigh (ещё бывает low/medium/high). Доступен к изменению не у всех моделей, но кардинально влияет на продуманность выдаваемых решений

● Агент (обвязка)
Понятно, в составе каких агентов работают модели - это "родные", вендорские Claude Code & Codex CLI.
В разных агентах модель может вести себя совершенно по-разному, и те же GitHub Copilot & Cursor могут ощутимо отуплять модели

● Поставленная задача
У текущих агентов и моделей сильно разные возможности и способности к решению разных проблем, и именно поэтому нередко приходится использовать несколько разных в одном проекте

● С чем ведётся сравнение и от какого опыта собеседника можно отталкиваться

—

❗️Между разными связками модель + агент качество результата, производительность и уровень автономности могут отличаться на десятки процентов и казаться либо совершенно неприемлемыми для работы, либо чудом.

Так что перечисленные характеристики - база для конструктивного и предметного обсуждения ИИ-агентов.

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

P.S.
● а GPT 5.2 (не-Codex) xhigh на этой задаче ещё лучше!
● нет, это не реклама, уже 5.1 лучше была - см. обзор, в чём конкретно
● но мы все ждём вскоре Sonnet 5 / Opus 4.6 / GPT 5.3 / Gemini 3 Pro GA, а там посмотрим :)

Режим команды агентов

Ну что, будущее наступило, я сейчас описал команду, базовые роли, и дал продуктовую задачу. Сижу и наблюдаю, как они пишут спеки, дополняют требования, а вот сейчас пошли писать код, по расписанной продуктовой и системной аналитике, по разделенным на стори фичам, с описанными DoD'ами и полной аналитикой по UX

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

Какие в целом причины выделять в агентов отдельные роли:

1. Фокусировка. Агенты, когда работают над задачей или список гипотез начинают тяготеть к одной из гипотез или к одному аспекту. Например ты скажешь ему "проверь прозводительность, безопасность и следование архитектуре". Он сделает первое хорошо, а остальное "по остаточному принципу. И чтобы повысить качество решения надо дать три задачи раздельно (прям как у людей)

2. Создание противоречия. Разработчик хочет побыстрее написать код, безопасник хочет, чтобы код был безопасным, QA - чтобы приложение работало. Они все три находятся в противоречии — выделив в отдельные роли и заставив их совместно работать, дебатируя и ищя консенсус мы повышаем качество результата (да-да, снова как и у людей)

3. Ограничение контекстного окна. Модель ограничена, нельзя дать ей весь проект целиком. Она в голове может удержать ограниченное количество данных, поэтому когда мы работаем тестировщиком, мы держим одни данные, а аналитиком — другие. Опять за счет фокуса на конкретной задаче снижаем объем данных, которые нужно держать "в голове" — а это, опять же, повышает внимание модели к деталям (чем меньше контекст, тем больше внимания. Опять же, как у человеков)

4. Конвергенция организационных паттернов (извините 🤓). Мы, как человеки, десятилетиями накапливали паттерны, которые повышают качество результата: продуктовые и функциональные требования, декомпозиция на стори \ таски, DoR/DoD, выделения ролей и границы ролей. Мы лечили проблемы человеков, а оказалось, что агенты страдают этими же проблемами. Оказалось закон Конвея имеет обратную силу (оказывается, что сама природа сложной задачи требует определенной организационной структуры)

5. Качество. Если хотим, например, чтобы на каждую аналитику приходил дизайнер и дополнял, и QA дополнял ее DoD'ами и писал план тестирования и сценарии для e2e/unit, которые должны быть покрыты

Короче, все как всегда. Вы думали будет "тык" и магия? Хрен. Проектируй процесс, ответственности, требования, гайдлайны, накапливай успешные решения и практики, применяй, анализируй, добавляй недостающие, выкидывай ненужное. Чем сложнее систему строишь, тем дороже потом её содержать, но тем выше качество по нужным тебе аспектам. Все как всегда свелось к простому — хочешь чтобы было красиво, трать ресурс на красиво, хочешь еще безопасность, бери в команду безопасника

Официальная дока: https://code.claude.com/docs/ru/agent-teams

П.С. Забавный факт, я попросил создать просто Software Engineer роль, но агент решил выделить отдельно фронтендера и бэкендера. Штош

Критерии оценки ИИ-агентов

Мы окончательно вошли в пост-бенчмарк эру, и формальные бенчи LLM/агентов дают всё меньше ценности.
Так что у меня выработались субъективные, вайб-метрики (пусть даже некоторые и выведены из численных/качественных показателей).

Методика простая: есть ряд отложенных типовых проектов/задач + повседневные рабочие задачи, которые я даю тестируемым агентам в параллель и сравниваю результаты.

Оцениваю я работу именно агентов, и используются только родные, вендорские обвязки (к примеру, Claude Code / Codex CLI).

Оценки по каждому из критериев от 1 до 10, и выставляются относительно лучшего агента из сравниваемых (т.е. 10 ≠ абсолют).


База

● Ризонинг
Способность к многоходовым логическим цепочкам, нетривиальным выводам, пониманию неочевидных зависимостей, глубина мышления.

● Работа с контекстом
Удержание, экономность использования, галлюцинации, способность проносить важные детали через компактизации.

● Следование инструкциям
... плюс способность их принимать во внимание все разом, внимание к мелочам, управляемость.

● Агентность
Автономное выполнение задач с эффективным использованием выданных инструментов (и создание своих на ходу), а также способность доводить работу до конца.


Способности

● Планирование
Анализ требований, их непротиворечивости и осуществимости, с граундингом на существующий проект, адекватная разбивка по этапам и задачам.

● Архитектура
Способность понимать, оперировать и следовать архитектурным концепциям и установленным границам, предлагать неконфликтующие изменения.

● Рефакторинг
Понимание типовых рефакторингов, code smells и способность делать аккуратные изменения в существующей кодовой базе, не ломая проект и не оставляя хвостов.

● Трейсинг (расследование)
Умение качественно "идти по следу", когда нужно раскопать какой-то баг, найти проблемы с безопасностью, провести code review.


Эксплуатация

● Инструментарий
Возможности и удобства, предоставляемые пользователю агента, кастомизация воркфлоу, автоматизация (SDK, App Server), набор интерфейсов (CLI / GUI / Web).

● Стабильность
Насколько стабилен и повторяем выдаваемый результат с т.з. качества на схожих задачах.

● Скорость
Тут как размышления, так и генерация токенов, и в целом скорость внесения изменений в проект.

● Экономность
Насколько много агент тратит токенов на успешное решение задачи и насколько это дорого выходит.

● Софт-скиллы?
Суровый ботан или восторженный подхалим? Ну нееет, это отдельная тема, как-нибудь потом :)

—

Прошлые обзоры можно посмотреть по тегу: #review

Вайб-обзор на GPT-5.3 Codex, Opus 4.6 и (бонус) GPT-5.2 (2/2)

🟡 Команды агентов
Это фича больше Claude Code, но модель тут тоже имеет значение - в конце-концов, Anthropic тренирует свои модели на то, чтобы быть лучше как менеджер агентов.

Лучший результат достигается если:
● задача заранее декомпозирована на подзадачи
● подзадачи параллелизуемые и не конфликтующие
● разумно прописаны роли агентов

Если просто бросить в Claude Code задачу без планирования, то чего угодно можно ожидать, а цена одного эксперимента высоковата выходит.
Я в чате канала уже писал, что мне удалось за полчаса потратить 5-часовой лимит Claude Max за $100 :)
Ну и в целом пока что нестабильно работает, стоит иметь в виду.

Кстати, в Codex-обвязку тоже скоро завезут нечто подобное, ждём!

🔴 Неправильные приоритеты
Я не знаю, как это лучше назвать, но это в принципе свойство моделей Claude с определенного релиза: с одной стороны, упускать важные нюансы, а с другой - делать то, чего не просили.
Как будто она в постоянном стрессе, когда качественно подумать не получается, а делать что-то всё равно надо.
Что вы там с ней делаете на посттрейне, а, Дарио?

🔴 Шустрее улетают лимиты
Цена за API-токены осталась та же, а вот в подписке, по всей видимости, лимиты понизили.
Встречал даже мнение о том, что подписка ChatGPT Plus за $20 даёт примерно столько же сделать, сколько Claude Max за $100 (тут стоит учесть, что сейчас и до 2 апреля в рамках подписки у Codex лимиты x2).


GPT-5.2

Я не писал обзор на 5.2, потому что с её выходом случилась та самая вайб-эйфория :)
Но лучше поздно, чем никогда, к тому же она незаменима в моей работе на текущий момент.
Всё, что было в обзоре на 5.1, справедливо и для 5.2 (только лучше), поэтому опишу лишь отличия.

🟢 Больше агентности
Раньше именно Codex-тюн этим отличался, но в 5.2 агентность сильно повысилась, и модель сама способна доводить до конца многоэтапные задачи, пусть и медленно.

🟢 Минимизация техдолга
Комплексная характеристика, но очень важная: если вам нужно предотвратить архитектурный дрифт или вернуть проект в нормальное состояние относительно желаемой архитектуры - нужно использовать 5.2 как для планирования изменений, так и контроля результата, и тут она стала лучше, чем 5.1.

🟢 Поиск багов
За счёт большей агентности и подросшего ризонинга модель гораздо лучше ищет причины нетривиальных проблем в коде.
А если у вас есть доступ к ChatGPT Pro - по API (дорого!) или через веб (неудобно), - то там это ещё качественнее работает.

🟡 Душность
Ну, я бы это в плюсы записал, но не всё же хвалить :)

При планировании или обсуждении каких-то идей модель вас будет душить corner case'ами, невозможностью что-то сделать и поначалу кажется, что это постоянные палки в колёса, вообще никакого вайба.

Но, как правило, замечания по делу, и к этой манере просто нужно привыкнуть (разработчики, кстати, тоже такие попадаются, чего уж там).

И я почти всегда предпочту именно такое поведение, чем потом вылавливать неучтённые при планировании нюансы в виде кривой архитектуры или багов на проде.

🟡 Всё ещё медленно
Тут от 5.1 отличий не так много - модель запросто может задумываться минут на 10-20 чисто для сбора контекста на старте, несмотря на все анонсируемые ускорения.
Но это всё не зря - лучше неё этот контекст ни одна другая модель не собирает и сложные проблемы решить на таком уровне не может.


Вердикт
Универсального инструмента, как обычно, нет.

В случае GPT-5.3 Codex и Opus 4.6 произошла конвергенция - модели примерно одинаковы по скорости, интеллекту, вниманию, даже по стилю общения стали ближе.

А вот GPT-5.2 тут стоит особняком.

Для меня использование разных моделей выглядит сейчас так:

● планирование, архитектура, рефакторинги, дебаггинг в существующей кодовой базе
GPT-5.2 xhigh

● реализация планов
GPT-5.3 Codex high-xhigh или GPT-5.2 high

● верификация (ревью, контроль техдолга)
GPT-5.2 xhigh

● интерактивная быстрая работа
GPT-5.3 Codex или Opus 4.6

● не очень большие (сравнительно) вайб-проекты с нуля
Opus 4.6

—

Прошлый обзор на GPT 5.1 / Gemini 3 Pro / Opus 4.5

#ai #model #review

Конференция ROИИ 2026

Senior + AI вместо целой команды - уравнение, которое сейчас считает каждый CTO. Но почти все считают его неправильно.

Одни верят LinkedIn и закладывают 100x-продуктивность. Другие читают исследования, где опытные разработчики с AI оказались медленнее, чем без - и решают, что всё это хайп, скоро стена и снова писать код руками.

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

Попробуем разобраться в следующих вопросах:

● Когда "сеньор + AI" действительно дешевле и эффективнее команды, а когда вы тратите меньше на ФОТ, но больше на техдолг и инциденты
● Что ломается в процессах при внедрении AI и почему одни и те же инструменты ускоряют одних и тормозят других
● Найм: как быть с теми, кто против AI, что делать джунам и каких людей искать в 2026

Без фантастики, но и без "давайте подождём". С практиками и ориентирами, которые можно применить.

🗣 Мой доклад будет 19 февраля, 14:00 МСК.

🔥 А помимо моей темы - ещё 11 докладов за два дня (19–20 февраля): от фаундеров, тех-лидов, CPO и Head of AI. Цифры, P&L, архитектура и реальные боли внедрения - без воды.

Участие бесплатное при подписке на каналы спикеров (ребята, которых я сам читаю). Есть и платный вариант - для тех, кому не нужны подписки или нужен сертификат.

👉 Полная программа конференции на сайте: ai-pnl.com
💌 Регистрация в боте по ссылке

#ai #conference