Циничный AI

🚬 Бенчей пост Для любителей мерять в попугуях обновил свои таблицу и график. 1) DS Flash безоговорочный лидер по цене на решенную задачу 2) Пока есть подписки - мой выбор Sol (как основной исполнитель). Высокий pass1/pass4 и лучшее время среди прямых конкурентов на решенную задачу. Флешка тут в аутсайдерах как по решению задач с первого раза, так и по времени решения задач. Остальное можете сами скачать и повертеть. Обнял.

Фотки своих шерстяных и пернатых можно постить сюда: https://t.me/cinicaichat

👌 Книга Ω - Инженерия надёжных фреймворков на AI-агентах Книга широко известного в узких кругах Ω ➡️Его позиция: профессия кодера фактически умерла. Востребованы будут оркестраторы агентных систем. Но это тяжёлая инженерная работа с предельной когнитивной нагрузкой, а не вайб-кодинг. По собственной оценке, умнее от агентов он не стал, но его полезная загрузка как специалиста выросла в разы. Книга - это попытка вытащить из его практики переносимую систему. Для написания книги использованы: ⚪️ сообщения Ω в чате DEKSDEN (chat) с 1 июля по 5 августа 2026 ⚪️ Sol + Fable ⚪️Ω прочитал рукопись и внёс исправления — в тексте они помечены как «Правка автора». Немного про Ω: ➡️Практик, инженер старой школы с 25-летним опытом коммерческой разработки и дипломом инженера-системотехника. ➡️Ключ к его подходу — выученная ещё в вузе теория надёжности и дисциплина о том, как строить надёжные системы из ненадёжных элементов. Именно этот взгляд он перенёс на AI-агентов: для него они не виртуальные сотрудники, а ненадёжные компоненты, вокруг которых выстраивается архитектура ограничений — изолированные роли, независимые проверки и технические запреты, лишающие агента возможности сойти с заданной траектории. ➡️За полгода он в одиночку собрал и довёл до шестой версии собственный конвейер разработки. Себя в этой конструкции он видит дирижёром при команде агентов. Масштаб — не демонстрационный: работающий проект на 350 тысяч строк под NDA, ещё один на 300 тысяч доводится до MVP, игровой клиент на полмиллиона строк отложен в стол, а проект на 250 тысяч закрыт — честно, из-за невозможности монетизировать. И это только то, что известно из его сообщений. P.S. Ещё раз, как создавалась книга - я взял все диалоги Ω с 1 июля, обработал и собрал из этого единую концептуально-практическую философию 🤦‍♂️ P.P.S. Приятного чтения ) #opensource #Ω

🙋Исследований пост С утра читал сводку по новым исследованиям. Большого поста не будет. Цифр не будет. Но они есть 🤓.Выделю две ключевые мысли, которые меня сейчас больше всего интересуют, это про собственные фреймворки для разработки на ии-агентах и как там дела у мемори-банков: 1. Если вы строите свой framework для агентной разработки, то делайте слой для самсовершенствования: - сбор телеметрии и результатов работы компонентов вашего фреймворка - анализ результатов, исследование чужого опыта, поиск решения проблем и построение гипотез как изменить вашу обвязку, чтоб улучшить результаты - внести исправления и повторить сначала, проверить, подтвердились ли гипотезы Улучшение результатов работы агентов можно и нужно добиваться улучшением среды в которой они работают. А не ждать, когда выйдет новая модель. При чем это должен быть постоянный процесс, а не спорадический. Т.е. необходимо выстроить loop улучшений вашего фреймворка, каким бы простым/сложным он ни был. 2. Меня интересуют мемори-банки, потому что я пока не могу никуда приткнуть эту приблуду. Какие есть техники для того, чтобы мемори-банки не были 5-м колесом в телеге, а приносили пользу? Разделить память на пять функциональных банков: -цели - текущее состояние задачи - ограничения - эпизодический опыт - справочная информация. Перед каждым действием система решает, какие элементы сделать центральными, какие оставить фоном, а какие временно скрыть. Это давало прирост успеха относительно базового прохода. Удаление такого функционального разделения ухудшало результаты работы агентов. ➡️Подключение vector database само не решает проблему памяти. Агенту нужен отдельный механизм, который определяет, какая информация должна влиять на текущее решение. Второе исследование даёт похожую гипотезу. Необходимо проверять, какие выводы записывает агент, что извлекает из памяти, может ли заменять устаревшие знания, а не просто накапливать историю. Итого. Мемори-банки способны как ухудшать, так и улучшать работу агентов. Это зависит от точности подхода, понимания как работают эти механизмы и их тонкой настройки. Нельзя просто подключить память к агенту и сказать - на, дорогой друг, пользуйся. Это может привести к непредсказуемому результату. P.S. Что у вас с мемори-банками, пользуетесь?

🙋Что с Опусом? ➡️Обратил внимание, что после того, как я перешёл на Opus 5 на этапе планирования, на меня легла дополнительная когнитивная нагрузка. Многие решения Opus'a нельзя было принимать в предлагаемом виде. В ситуациях, где решением проблемы является банальное упрощение, Opus предлагает добавить ненужной сложности и начинает заниматься архитектурной мастурбацией. Даже там, где в самой проблеме есть ответ на вопрос, Opus старательно игнорирует очевидное. ➡️Заметил, что и Твиттер постепенно наполняется негативными отзывами использования Opus 5. Его ругают за самоуверенность, за игнорирование инструкций, за выдуманные предположения вместо проверки фактов/файлов, за бесконечные циклы исправления собственных ошибок, за привычку менять больше, чем просили. ➡️Значит ли это, что Opus "плохой"? Говорить лучше языком цифр. Честно - я не сравнивал в лоб с Opus 4.8, на котором раньше планировал. Но я проверил сессии за последнюю неделю и выяснил, что около 6-8% предлагаемых им решений на этапе планирования могли завести не туда. Хотя субъективно мне казалось, что я поправляю его чуть ли не каждый второй раз. Посмотрев на цифры я понимаю, что должен (а) планировать тщательнее и (б) лучше понять, какие у Opus 5 особенности, сильные/слабые стороны и как ими пользоватся. ➡️Не нужно читать твиттер, слушать кудахтанье из курятника и жаловаться на тяжелую жизнь vibe-разработчика, а нужно перестраивать свои рабочие процессы / подходы / мышление под новую модель. Вот небольшой разбор на основании открытых данных. ➡️Главное изменение в Opus 5 - модель стала намного реже останавливаться, когда ей не хватает информации. С одной стороны это улучшило результаты в программировании, с другой повысило риск ошибок при планировании и принятии архитектурных решений. Что произошло с галлюцинациями? ➡️На AA-Omniscience Opus 5 vs 4.8 стал давать больше правильных ответов +11% (71% vs 60%), и (внезапно!) больше неправильных +5% (22% vs 17%), и стал реже отказываться давать ответ -16% (23% vs 7%) Т.е. на каждые 100 вопросов Opus 5 дал на 11 правильных ответов больше, и одновременно больше на 5 неправильных. При этом он на 70% реже признаёт незнание. Opus 5 чаще прав, но реже явно сообщает, когда не знает ответа. Что изменилось в планировании и архитектуре? ➡️ Архитектурный план строится на предпосылках, и в это Opus 5 стал одновременно и полезнее и опаснее. ➡️Он больше знает и чаще предлагает правильные решения. Но если необходимого факта у него в знаниях нет, то модель теперь реже останавливается и чаще достраивает правдоподобную предпосылку. Пользователь под впечатлением от сильного рассуждения выключает нативные мыслительные процессы и принимает решения об архитектуре поверх выдуманных ограничений или несуществующих возможностей. ➡️Ближайший к пониманию архитектуры кодовой базы тест — SWE-Atlas-QnA. На максимальном effort результат вырос лишь с 47% до 49%. То есть понимание существующего репозитория улучшилось, но значительно меньше, чем непосредственное выполнение задач. Поэтому субъективное ощущение, что Opus 5 приходится чаще поправлять при планировании я объясняю так: Модель генерирует больше решений, включая больше ошибочных решений. Кодинг. ➡️В кодинге галлюцинации работают в плюс. Запасайтесь грибами ) Не добившись результата с первого раза модель не сдаётся, галлюцинирует и пробует следующий вариант, в итоге чаще доводит задачу до рабочего состояния. Т.е. Opus 5 стал лучшим исполнителем, стал лучше как архитектор, но его ршешения на этапе планирования необходимо проверять тщательнее. ➡️Модель стала больше знать, лучше рассуждать и охотнее действовать. И одновременно стала увереннее ошибаться. Всё это плохо это сочетается с теми промптами и агентными обвязками, которые вы писали / использовали для предыдущих/других моделей. Но изменилась не только модель. Изменились и мы. 🟢 Во-первых, мы стали значительно опытнее в работе с агентами. В 2025 году для нас было шоком, что нейросеть САМА пишет работающий код. Сейчас мы оцениваем blast radius, архитектурные границы, наблюдаемость, безопасность, DoD, Out of scope, AC, инварианты и много слов, которые раньше или не приходили в голову или считались какой-то бестолковой церемонией. 🟢 Во-вторых, у нас накапливается опыт совместного с моделями принятия решений. После тысяч рабочих сессий начинаешь лучше узнавать типовые паттерны и ошибки модели. Читая текст, я могу с высокой вероятностью сказать, какая модель его генерировала. 🟢 В-третьих, у людей, которые ежедневно создают что-то с агентами, постепенно растёт ШИРОКАЯ техническая и продуктовая компетенция. ⭐️ Сейчас необходимо тащить весь SDLC в solo и хочешь не хочешь, но приходится разбираться во всём: в архитектуре, в базах данных, в интерфейсах, в безопасности, в построении инфраструктуры, в экономике продукта, и как сука собрать свой собственный фреймворк для ai-friendly разработки. ⭐️ Идёт время и вау-эффект от агентов пропадает. LLM становится сложнее "продать" неверное решение в обёртке из уверенного тона и умных терминов. И это гораздо более важный прогресс, чем очередные +3 п.п на бенчмарке у новой модели Сейчас недостаточно просто пилить продукты с помощью нейросетей. Продукт устареет. Модель поменяется через месяц. Промпт перестанут работать. Сегодняшнее конкурентное преимущество превратится в стандартную функцию. ⭐️Главный актив, который стоит создавать сейчас - это даже не просто обучение или его скорость. А развитие умения обучаться. Необходимо обучаться обучению. ⭐️ Сейчас самая опасная стратегия - это ждать развития моделей, чтобы их интеллект полностью закрывал проблемы отсутствия ваших собственных знаний/умений и навыков. Действительно, такой момент наступит, и возможно гораздо быстрее, чем кажется обывателям. Модели станут намного-намного умнее. А вы - нет. Мир разделится на тех, кто несколько лет учился и развивался вместе с ними, и тех, кто всё это время просто нажимал ДАЛЕЕ.

🤦‍♂️ Гейтов пост Ворота не должны стоить дороже того, что они охраняют.

🖕 Написать, что я не прав сюда: https://t.me/cinicaichat

продолжение... ➡️ (3) Зоопарк ролей - persona orchestration вместо capability isolation: в системе целая баржа аналитиков, архитекторов, разработчиков всех мастей, ревьюеров, тестировщиков, библиотекарей, девопсов, различающихся преимущественно ролью в промпте. 🟡 роли не добавляют моделям знаний, несколько персонажей на одной модели воспроизводят одинаковые ошибки и создают видимость разделения ответственности. ➡️ Необходимо использовать специализированных исполнителей с подобранными для конкретной задачи моделью, effort, контекстом, инструментами, правами и форматом результата. 🟢 Агенты должны двигаться через цепочку проверяемых гейтов. Следующий этап начинается не потому, что «ревьюер согласен», а потому что выполнены формальные критерии перехода. ❤️... были и другие наблюдения, но эти покрывают 80% проблем. Сфокусируемся сегодня на них. 🤓 В заключение. ⭐️ Не стройте второй GitHub поверх GitHub. Используйте нативные примитивы, которые агенты уже понимают: issues, branches, PR и checks. Не заставляйте модели изучать ваш YAML-протокол, файловый sequencer, ролевой театр, терминальную автоматику, обмазанные хуками. ⭐️ Не создавайте ненужную хрупкость - не делайте сложные инструменты, которыми агент не умеет пользоваться нативно, но при этом они являются ядром вашего framework'а. ⭐️ Контроль должен происходить на явных границах: precondition gate → исполнение → postcondition gate → следующий этап. До действия проверяются права, ограничения и допустимость операции. После действия — тесты, типы, контракты, миграции, политики безопасности и acceptance criteria. ⭐️ Гейты должны опираться на воспроизводимые проверки. LLM может искать проблемы и давать дополнительный сигнал, но не должен заменять детерминированные критерии перехода.

продолжение... Если вы собираете свои собственные фреймворки, то не делайте этих ошибок. Итак, что плохо: ➡️(1) Любой собственный самодельный control plan / state-плейн / runtime: SQLite, Dolt, YAML-статусы, JSONL-мейлбоксы, step-файлы, внутренние event bus, CLI-платформы, дашборды, tmux-флоты и десятки hooks для управления задачами, состояниями и последовательностью работы агентов 🟡 GitHub Issues, PR, branches и checks уже образуют готовый control plane, который современные агенты понимают и используют из коробки. Они умеют читать issue, создавать ветки, связывать коммиты с задачами, открывать PR, анализировать checks и обновлять статус работы. 🟡 Самодельный control plane необходимо объяснить агенту и ещё и заставить агента использовать неудобный и непривычный механизм. Модель данных, команды, форматы, переходы состояний и правила восстановления - все это буде в контексте как инструкции, а не в весах. Вместо выполнения задачи агент тратит контекст и действия на обслуживание нестандартного протокола. Каждый дополнительный слой создаёт новые адаптеры, точки отказа и поведение, которого нет в нативном harness. 🟣 В результате вы не усиливаете агента, а заставляете его ездить по собственной инфраструктуре на квадратных колёсах. ➡️GitHub должен быть основным control plane разработки: 🟢 issue — единица работы; 🟢 labels, milestones и dependencies — планирование; 🟢 branch и commit — реализация; 🟢 PR — доставка изменения; 🟢 checks — доказательства качества; 🟢 merge — завершение работы. Это база. ➡️ Собственный runtime допустим только для краткоживущего состояния исполнения, которого GitHub не предоставляет: процессов, leases, очередей, retries, sandbox-сессий и технических логов. Он не должен заменять GitHub как модель проекта. ➡️(2) Параллельный spec-plane вне issue body: активная задача одновременно описывается в GitHub Issue и в specs/, .claude/epics, docs/plans или других файловых структурах фреймворка. 🟡 Это когда вы используете GitHub Issues, но продолжаете попытки построить второй control plane. Агенту приходится выяснять, где находится актуальный контракт задачи, какая версия старше, где источник истины. 🟡 Файловые спецификации также требуют дополнительной навигации, соглашений об именовании, правил синхронизации и специальных инструкций. GitHub Issue уже предоставляет агенту идентификатор, историю изменений, обсуждение, зависимости, статус и связь с PR. 🟣 Параллельный spec-store повторяет часть этой модели в менее нативной форме. ➡️Тело issue должно быть единственным контрактом активной задачи: цель, контекст, ограничения, критерии приёмки и ссылки на связанные материалы. 🟢 Репозиторий хранит не копию issue, а долгоживущие артефакты продукта: ADR, архитектурные документы, API-схемы, миграции, код и тесты. Issue ссылается на них, но не конкурирует с ними за владение одной и той же спецификацией. продолжение...

🚬 5050.4343 framework-а пост С утра тестирую 3 варианта инструкций для ревьюеров и судей на этапах планирования и имплементации. Подписка горит🔥 Напишу, если будут интересные находки. К понедельнику хочу завершить его обновление. Затем ~месяц тестирования и доработки напильником на живых проектах. 📂 В планах выпустить 5050.4343 framework в опенсоус🥫 Для кого подойдёт? Для тех, кто: - не является сеньором-помидором, - желательно имеет доступ к моделям двух разных вендоров. Что я хотел от фреймворка 5050.4343: человек ставит задачу - система отвечает за всё остальное. Пользователь определяет, что и зачем должно быть построено. Система помогает пользователю определить требования, далее проектирует, реализует, проверяет и доставляет. Результат - работающий и поддерживаемый в ДОЛГУЮ продукт. ➡️Агент настроен так, чтобы давать сложную техническую информацию, но при этом объяснять её доступным языком. Да, надо перекладывать очки навыков в ветки чтения и восприятия. ➡️С разработкой на 5050.4343 должен справляться любой человек, который умеет критически мыслить, строить логические цепочки и способен перекладывать информацию из краткосрочной в долгосрочную память. Широкие прикладные знания становятся намного ценнее глубоких узкопрофильных. Намного важнее - умение в моменте разобраться в проблеме, задать правильные вопросы, увидеть противоречия, найти более простое решение, которое находится вне поля зрения модели. Часто для этого технических знаний нужно примерно ноль. Делал под себя. Доволен. ➡️Сейчас в процессе доработки решил не останавливаться на точечных изменениях, а пересобрать framework практически полностью, доавтоматизировать налаженные процессы, сделать роутер для маршрутизации задач по моделям/effort'ам, снять с оркестратора обязанности судьи и выделить это в отдельную роль, переехать на новые модели и оптимизировать под них инструкции. ➡️Для поиска улучшений в том числе проанализировал и сравнил свою уже старую версию в лоб с: - superpowers - spec-kit - BMAD - oh-my-claudecode - beads ... и т.д. Всего с 14 фреймворками. Ничего существенно значимого, что можно было бы глобально позаимствовать - не нашлось. ‼️На что хочу обратить внимание! продолжение...

У нас было две подписки: на Claude Code и Codex, пять локальных моделей, полный набор MCP-серверов, полтерабайта документации, гора агентов, от аналитиков и архитекторов, до разработчиков, ревьюеров, тестировщиков и судей всех размеров контекстного окна, а ещё GitHub Actions, Docker, Playwright, Sentry, Grafana, три базы данных и две очереди сообщений. Не то чтобы всё это было нужно для разработки корпоративной ERP, но раз начал строить полный AI-driven SDLC, то иди в своём увлечении до конца. Единственное, что меня беспокоило, так это автономный агент с правом пушить в main. В мире нет никого более беспомощного, безответственного и безнравственного, чем модель, которая прогнала два теста, не прочитала логи и уверенно написала: «Задача полностью выполнена». И я знал, что довольно скоро мы дадим ей доступ к продакшену. С добрым утром, старички 👌

🙋 Конских хвостов пост 🟢 ponytail skil🟢 Использую последние 3 месяца. Всегда в памяти у планировщиков, ревьюеров и имплементаторов Хорошо, что JetBrains заморочились и доказали его эффективность - 80 парных задача в Claude Code на Sonnet 5 Medium: 🟢 Объём кода: −15,4% 🟢 Стоимость задачи: −10,3 🟢 Время выполнения: −11% 🟢 Качество: заметной разницы не обнаружено— 65 задач одинаково, 9 хуже, 6 лучше 🟢 Наиболее эффективно на крупных задачах, где модели склонны переусложнять решение. Там разница была - 31%. 🟢 На небольших задачах эффект почти исчезал. ‼️ Важно: модель на исследовании ни разу не активировала ponytail skill самостоятельно (0 из 10). Принудительно добавляйте ponytail в контекст. Все, кто ещё не использует - крайне рекомндую. Это ровно про философию минимализма. P.S. Если кратко, то skill говорит модели: Перед тем как писать код, сначала проверь, нужен ли он вообще. Поищи готовое решение в самом проекте, стандартной библиотеке, платформе или уже подключённых зависимостях. Если без нового кода не обойтись, напиши минимальное решение без лишних абстракций, обёрток и инфраструктуры «на будущее». Не сокращай проверки, обработку ошибок, безопасность и доступность. Твоя цель — не написать больше кода, а решить задачу самым простым надёжным способом. P.P.S. У меня с ponytail начались ситуации, когда на этапе планирования задача обсуждается 1-3 часа, а на выходе diff +2/-5 (и всё работает 🥰) Первоисточник: JetBrains - Ponytail Skill for Claude Code: Does It Really Cut Agent Code by 54%?

продолжение... Видимо, когда эксперимент уже был завершён, авторов спросили - а что там модели поновее? На что они сказали, вот результ Opus 4.8 (Claude Code, xHigh), у него 57,2% из публичного лидерборда - те же 124 задачи SWE-Atlas QnA Т.е. команда из Opus 4.6 (High, Claude Code) с AgentRadio набрала больше попугаев. Главная гипотеза эксперимента: на длинных задачах по изучению большого репозитория недостаточно просто разделить работу между несколькими агентами. Подзадачи зависят друг от друга, поэтому качество должно вырасти, если агенты смогут передавать важные находки прямо во время исследования и корректировать работу друг друга, а не только обмениваться готовыми отчётами в конце. Авторы проверяли гипотезу по слоям: B0 → L1: помогает ли само разделение задачи между четырьмя чистыми контекстами L1 → L2: помогает ли согласование плана и перекрёстное ревью L2 → L3: даёт ли дополнительный эффект именно фоновая связь во время работы B1 → L3: объясняется ли результат просто большим количеством токенов и запусков Именно последнее сравнение L2 → L3 является главным тестом AgentRadio: модель, число агентов, effort, задачи и общий протокол оставались прежними — менялся режим получения сообщений. Результат вырос с 51,6% до 62,1% у Opus 4.6 и с 39,5% до 50,8% у DeepSeek V4 Pro. Гипотеза подтвердилась На длинных задачах по исследованию репозитория агентам действительно полезно получать находки коллег прямо во время работы, а не только согласовать план в начале и проверить результаты в конце. Для сложного исследования кода с взаимозависимыми подзадачами фоновая связь между параллельно работающими агентами даёт существенный и статистически значимый прирост поверх совместного планирования и финального ревью.