Книжный куб

Сегодня пришло письмо от Medium о том, что они наконец-то сделали dark mode, который у них запрашивали в 2015 году. Кажется, что ребята просто подождали пока появятся достаточно мощные AI модели, которые из коробки делают dark mode любому сайту. Чем-то это напоминает коммунальные службы, которые в мае отчитываются о том, что сосулек на крышах уже нет ... надо было просто подождать горячего весеннего солнышка:) В общем, дорога ложка к обеду:)

[2/2] Stanford CME295: GLM-5 и роль агентной обвязки (Рубрика #AI) В практической части третьей лекции Stanford CME295 Шервин Амиди собирает методы обучения в историю одной модели — GLM-5 (теоретическую часть обсуждали раньше). И здесь возникает вопрос, который легко потерять за названиями алгоритмов: как научить модель новому и сохранить то, что она уже умела? Сначала — как устроен путь обучения в его разборе. 🔸 Pretraining: фильтруют веб-данные, подбирают код и научные материалы, меняют их пропорции по ходу обучения. Модель приобретает общую основу через предсказание следующего токена. 🔸 Midtraining: расширяют контекст на длинных материалах — книгах, обсуждениях задач, PR и изменениях кода. Здесь важна и упаковка документов: нужно сохранять связи внутри материала, по которым модель учится использовать длинный контекст. 🔸 SFT: показывают желаемые ответы, решения и работу с инструментами. В примерах рассуждения могут чередоваться с вызовами инструментов: модель учится продолжать работу после получения результата. 🔸 RL: развивают несколько групп способностей. Reasoning RL связан с решением задач; agentic RL — с действиями в среде, например исправлением кода и проверкой тестами; general RL — с качеством ответов и взаимодействия с пользователем. Но улучшения не обязаны складываться без потерь. Каждый следующий этап меняет ту же модель. Успешное обучение новым задачам может ухудшить результаты на прежних. Это не обязательно буквальное «стирание знаний»: может измениться и способ отвечать или выбирать действия. В финале используют on-policy cross-stage distillation. Сохраненные версии модели с предыдущих этапов — checkpoints — становятся учителями: текущая модель генерирует ответы, а учителя дают обучающий сигнал на ее продолжениях. Цель — восстановить полезные способности предыдущих этапов, сохраняя новые. Это попытка совместить навыки, успех которой нужно проверять на разных задачах. Мне здесь нравится сама идея: предыдущая версия может уступать новой в целом и при этом оставаться полезным учителем. Сохраненный checkpoint оказывается еще и материалом для дальнейшего обучения. Отсюда Шервин переходит к гипотезе про агентную обвязку — код, который организует работу модели с инструментами и контекстом. Если модель уже обучена выбирать действия, проверять результаты и исправлять ошибки, часть подробных внешних сценариев может стать лишней. В лекции он приводит Pi; его создатель Марио Цехнер тоже связывает работоспособность минимального агента с подготовкой самих моделей. Возьмем исправление бага. Выбор файла, реакцию на упавший тест и решение повторить проверку модель может освоить в обучении. А запуск тестов, доступ к репозиторию, хранение состояния и контроль прав по-прежнему обеспечивает среда. У этих частей разные обязанности. Кстати, в самом отчете GLM-5 есть хорошая граница для гипотезы об упрощении: удаление старых результатов инструментов с сохранением свежих повышает результат на BrowseComp с 55,3% до 62,0% в эксперименте авторов. Управление контекстом продолжает помогать уже сильной модели. #AI #LLM #Agents #Engineering #AI4SDLC

Сегодня пришла отбивка о том, что "Your application for a Unitied Kingdom (UK) visa has been successful", что продолжает историю про полученный раньше endorsement. Жене и младшему сыну тоже подтвердили визу, а для среднего попросили подгрузить еще документов - так что история с визами пока закончена не до конца (но есть ощущение, что после подгрузки доп. документов все будет ок). Ну и пока план оказаться в Лондоне во второй половине ноября:) P.S. Ждал решения ровно календарный месяц.

Агенты пишут код. Как понять, что разработка стала эффективнее? | Code of Leadership (Рубрика #AI4SDLC) Через 20 минут в 17:00 по Москве в прямом эфире Code of Leadership встречаемся с Владимиром Долговым. Поговорим про developer productivity и то, как меняется разработка, когда в команде появляются AI-агенты. Допустим, агент быстро написал код. Дальше кто-то проверил его, попросил переделать, встроил в систему и довёз до пользователя. Хочется посчитать весь этот путь: сколько времени и сил потратили, что получили на выходе и где на самом деле случилось ускорение. Счётчик токенов сам на эти вопросы не ответит :) Владимир Долгов — технологический и продуктовый лидер с более чем 20-летним опытом управления командами и крупными проектами на уровне CxO в финансах и телекоммуникациях. В Сбере он руководил AI-трансформацией процесса разработки, внедрял AI-ассистентов и развивал продукты Developer Experience: GigaCode, GigaIDE, GigaView и API/Function Studio. Ранее построил с нуля CRM/MDM-направление, управлял распределёнными командами до 430 человек и внедрял крупнейшие Oracle Siebel CRM. Математик по образованию, выпускник СПбГУ. С Владимиром разберём несколько больших тем: 🔸 Как развиваются инструменты разработки IDE, CLI, фоновые агенты — как меняются рабочие привычки, что стоит строить самим и по каким признакам новый инструмент заслуживает места в команде. 🔸 Что мы называем developer productivity Скорость отдельного инженера, движение задач через команду, качество, польза для бизнеса — как связать всё это и понять, что именно удалось улучшить. 🔸 Как устроена агентная разработка От постановки задачи и подготовки контекста до тестов, ревью и выпуска. Что можно поручить агенту, где нужен человек и сколько стоит проверка результата. 🔸 Как оценивать эффект AI Что сравнивать до и после внедрения, как учитывать переделки и отличать пользу инструмента от изменений в составе команды или сложности задач. И что делать, если PR стали появляться быстрее, а релизы выходят с прежней частотой. И будет демо DevOptify (https://devoptify.ru/) — платформы для оценки developer productivity, которую строит Владимир. Посмотрим, как устроен переход от инженерных данных к выводам и решениям руководителя. Заодно обсудим границы метрик: что они способны показать, где им не хватает контекста и как разработчик может оспорить оценку своей работы. Приходите, если внедряете агентов, развиваете инструменты или отвечаете за результат команды. Приносите вопросы и свои истории: что происходило с командой и продуктом после того, как вы научились быстрее писать код. #AI #Agents #Engineering #AI4SDLC #Software #Knowledge #Data #DevEx #DeveloperProductivity #Management #Leadership

Agent Skills и Open Knowledge Format (OKF): скиллы, знания и доверие (Рубрика #AI4SDLC) Агент умеет писать код и вызывать инструменты. Но как передать ему рабочую процедуру команды? Где хранить знания о системе, которые меняются независимо от этой процедуры? И чем подтвердить, что агент выполнил задачу правильно? Через час обсудим это в прямом эфире подкаста Research Insights Made Simple вместе с Максимом Смирновым, с которым мы летом обсуждали Loop Engineering о том, как проектировать циклы, которые запускают агентов, проверяют результат и возвращают работу на доработку. Теперь продолжим разговор — через Agent Skills и Open Knowledge Format (OKF). Максим — ИТ-архитектор, автор Telegram-канала «Архитектура ИТ-решений» https://t.me/it_arch. В прошлом — руководитель департамента ИТ-архитектуры «Билайн» и главный архитектор информационных систем Банка России; спикер, автор и преподаватель курсов по ИТ-архитектуре. В новом выпуске мы разберём, из чего состоит навык: SKILL.md, описание, инструкции, вспомогательные файлы и скрипты. Посмотрим, как агент выбирает подходящий навык, когда подгружает подробности и почему успешная загрузка файла ещё не означает успешного выполнения задачи. В программе: — Чем отличаются инструкции проекта в AGENTS.md, навыки, инструменты MCP и обработчики событий. — Как проверять не только результат навыка, но и то, вызывается ли он в нужной ситуации. — Что появилось вокруг Agent Skills: каталоги, установка, автоматические проверки и оценка качества. — Как OKF связывает Markdown-файлы в граф знаний и описывает происхождение и актуальность сведений. — Почему отметка времени или подтверждение в метаданных сами по себе не гарантируют истинность. — Что означает квитанция выполнения вычисления, кто её проверяет и где остаётся ответственность команды. Сквозной пример — утренний разбор упавшего CI: какие инструкции нужны агенту, откуда он узнаёт правила проекта и как мы проверяем предложенное исправление. Сопоставим Agent Skills, OKF v0.2 и предложение Knowledge-as-Skill. Опираемся на спецификации, документацию и примеры по состоянию на конец октября 2026 года. Отделим свойства форматов от возможностей конкретных реализаций. Приходите с кейсами: какие процедуры вы уже передаёте агентам и какие знания они регулярно теряют? #AI #Agents #Engineering #AI4SDLC #Software #Knowledge #Databases

[1/2] Stanford CME295: как обучают LLM (Рубрика #AI) В третьей лекции Stanford CME295 Афшин и Шервин Амиди разбирают, как из модели, предсказывающей следующий токен, получается полезный ассистент. Мне здесь интересна связь между способами обучения: каждый дает модели свой сигнал о том, как ей следует отвечать. Сначала — общая основа. В pretraining модель учится продолжать тексты, код, математические решения. Cross-entropy измеряет, насколько хорошо она предсказывает токены из обучающих данных: чем выше вероятность правильного следующего токена, тем меньше ошибка. Поэтому состав данных имеет огромное значение: нужно решать, что фильтровать, как смешивать источники и какие материалы повторять. В midtraining обучение продолжается на более целевых данных; здесь же могут расширять контекст. Причем недостаточно разрешить модели принимать больше токенов. Нужны примеры, где для продолжения действительно приходится использовать информацию далеко назад по тексту. Дальше удобно сравнивать методы по двум вопросам: на чьих ответах учимся и насколько подробную обратную связь получаем? 🔸 SFT (supervised fine tuning) — показываем желаемое поведение Даем пары «запрос — хороший ответ». Модель по-прежнему предсказывает следующий токен, но в показанной схеме ошибку считают по ответу, а запрос служит условием. Так можно обучать следованию инструкциям, формату диалога и нужному стилю. Рядом авторы разбирают LoRA (low-rank adaptation): основные веса замораживают, а их изменение задают произведением двух небольших обучаемых матриц. Это способ снизить стоимость адаптации; отдельной обязательной ступенью после SFT он не является. 🔸 Preference tuning — сравниваем ответы Человеку часто проще выбрать лучший из двух вариантов, чем написать идеальный ответ. В описанной схеме RLHF на таких предпочтениях сначала обучают модель награды. Затем она оценивает новые ответы LLM, а обучение повышает ожидаемую оценку, ограничивая отклонение от исходной модели. Оценщик может ошибаться, поэтому высокий балл еще не гарантирует качество. DPO позволяет обучаться непосредственно на парах предпочтений, без отдельной модели награды. В базовом варианте пары фиксированы: новые попытки текущей модели на каждом шаге не требуются. 🔸 RL (reinforcement learning), обучение с подкреплением: оцениваем результат попытки Если награда проверяемая, для математической задачи можно сверить ответ, для программы — запустить тесты. В лекции это объясняют через GRPO: модель генерирует несколько решений и учится с учетом их относительной успешности. Сам GRPO — алгоритм обучения; проверяемость обеспечивает выбранный способ оценки. Но оценка целого решения мало говорит о том, где именно произошла ошибка. Агент мог сделать девятнадцать полезных действий, а на двадцатом сломать программу. 🔸 On-policy distillation — учитель помогает на собственных попытках ученика Ученик генерирует продолжение, а учитель дает сигнал о вероятностях следующих токенов в этих же контекстах. Ученик обучается уменьшать расхождения с учителем. Обратная связь получается подробной, хотя ее качество по-прежнему зависит от учителя. Это возвращает нас к вопросу студента в начале лекции. При teacher forcing модель получает правильные предыдущие токены из датасета, даже если сама предсказала бы другое. При использовании она продолжает собственный текст, включая ошибки. Обучение на своих попытках позволяет работать с ситуациями, в которые модель действительно попадает. Во второй части расскажу про практический пример GLM-5, которые рассматривали авторы на лекции. Так они показывали как все эти теоретические подходы сочетают на практике и что делают, если новый этап обучения ухудшил уже полученные навыки. #AI #LLM #Learning #Engineering #Agents

Материалы 3 AImigo S1E10: агенты с правом платежа (Рубрика #AI) Собрал материалы десятого выпуска 3 AImigo, который вышел 16 октября 2026 года: «Агенты с правом платежа: доверим ли AI свои деньги?». Вместе с Евгением Сергеевым и Алексеем Литвиновым обсуждали, что нужно помощнику для покупки целиком. Дать ему бюджет проще, чем объяснить, какие продукты нужны семье на этой неделе. Обсудили: 🔸 Почему повторить прошлую корзину недостаточно Предпочтения меняются, а удачный поиск ещё не гарантирует удачную покупку. Евгений рассказал про агента для Vinted и ненужные удлинители, оказавшиеся в заказе вместе с шуруповёртом. 🔸 Какие полномочия мы вообще делегируем Поиск, выбор, переговоры, согласие на заказ и платёж — разные шаги. На примере Checkout и Payment в AP2 разбирали разницу между выбором товара и разрешением перечислить деньги. 🔸 Где остановить автоматизацию Подготовленная корзина с подтверждением человеком уже может быть полезным результатом. Евгений предложил ограниченный бюджет на маркетинг как более понятный сценарий самостоятельных расходов. 🔸 Почему магазины не спешат отдавать покупателя чату В разговоре сошлись актуальные цены и остатки, отношения с клиентом, аналитика и дополнительные продажи. За удобным интерфейсом помощника остаются интересы всех участников сделки. 🔸 Кто разберётся с неудачной покупкой Обсудили возвраты, ошибки и возможность манипулировать самим агентом. Идея, что помощник защитит от мошенников, пока остаётся гипотезой; общего ответа на вопрос ответственности мы не установили. Получился разговор про ступени доверия: от «найди варианты» до «выбери и купи». Между ними гораздо больше решений, чем одна кнопка оплаты. Материалы выпуска: 📌 Страница выпуска с таймкодами и конспект 📖 Лонгрид о полномочиях и согласии при агентных платежах 🎬 Видео: YouTube и VK Видео 🎧 Аудио: Podster и Apple Podcasts Какую покупку вы готовы поручить агенту уже сейчас — и на каком шаге захотите подтвердить решение? #AI #Agents #Product #Security #Engineering #Podcast

Demystifying evals for AI agents: устройство оценки и заметки на полях (Рубрика #AI4SDLC) Продолжаю тему agent harnesses. В "Demystifying evals for AI agents" ребята из Anthropic разбирают, как понять, что агент после очередного изменения стал лучше. Статья вышла 9 января 2026 года; авторы — Mikaela Grace, Jeremy Hadfield, Rodrigo Olivares и Jiri De Jonghe. Это инженерный обзор опыта Anthropic и клиентов; рекомендации основаны на отдельных практических случаях. Сначала про основные части статьи. 🔸 Устройство eval Задача, отдельная попытка, grader, траектория и итоговое состояние среды. «Билет забронирован» в ответе агента ещё не означает, что бронь появилась в базе. Здесь же два harness: agent harness обеспечивает работу модели с инструментами, evaluation harness запускает испытания и собирает оценки. Проверяем мы модель вместе с её обвязкой. 🔸 Чем оценивать Кодом, LLM-судьёй и человеком. Для coding agents естественны тесты; для исследовательских — проверка опоры на источники и полноты; для диалоговых важны и результат, и качество общения. Оценки LLM нужно калибровать по человеческим. 🔸 Что измерять Capability evals показывают, чему агенту ещё предстоит научиться; regression evals защищают уже освоенное. А pass@k и pass^k отвечают на разные вопросы: получился ли хотя бы один успех за k попыток или успешны все k. 🔸 Как построить и поддерживать Авторы советуют начать с 20–50 реальных случаев, явно определить успех, изолировать прогоны и читать трассы. Ошибаться может и сам grader. Дальше набор нужно обновлять, а картину дополнять production-мониторингом, обратной связью и человеческой оценкой. Теперь мои заметки по ходу чтения, которые есть в приложенном PDF 1️⃣ Знакомая инженерия Изоляция прогонов и сходство среды с production напоминают правила тестирования, eval-driven development — TDD. Даже организация работы знакомая: отдельная команда поддерживает инфраструктуру, продуктовые команды приносят задачи. Привет platform teams и stream-aligned teams. Только зелёный результат одного прогона здесь ещё не обещает зелёного следующего. 2️⃣ Ожидания тоже надо сформулировать На ранней стадии пользователей может ещё не быть, а критерии качества только складываются. Evals помогают задать этот уровень и дальше удерживать его. Особенно полезно при частых обновлениях моделей: появляется свой набор проверок для решения о переходе. 3️⃣ DOM и скриншоты Раньше я считал, что скриншоты дороже, а работа через DOM дешевле. У авторов есть обратный пример: выгрузка всего DOM может съесть больше токенов. Тут хочется отдельно считать объём переданных данных, задержку и число действий — универсального победителя из этого не получается. 4️⃣ OR, AND и независимость Метрику pass@k удобно понимать как логический OR, pass^k — как логический AND. Но расчёт p^k требует независимых попыток с одинаковой вероятностью успеха. При p = 0,75 три успеха подряд дают примерно 42% только с этими допущениями. Общая среда, оставшиеся файлы или память между попытками могут их нарушить. 5️⃣Траектории Симулятор пользователя напомнил мои разборы "SWE-Together" и "SWE-Interact". В статье рядом живут два совета: оценивать процесс и не навязывать агенту конкретную последовательность шагов. Я бы совместил их через проверку свойств процесса: агент мог начать исправление бага с теста или чтения кода, но заявление «проверено» должно относиться к окончательной версии. А права доступа и запрет записи за пределами рабочей области стоит обеспечивать самим harness: успешный eval не заменяет блокировку запрещённого действия. #AI4SDLC #Agents #Evals #Research #Engineering #PlatformEngineering

Материалы Code of Leadership #85: FDE с Павлом Голубевым (Рубрика #Leadership) Готовы материалы 85-го выпуска Code of Leadership от 15 октября 2026 года — «FDE: кто отвечает за то, чтобы AI заработал у клиента». Поговорили с Павлом Голубевым, Principal AI FDE Manager в Microsoft и автором канала Corporate AI. Как обещать бизнес-результат, если данные заказчика ещё не посмотрели, а кто вправе менять его процессы — ещё неясно? Обсудили: 🔸 Как меняется работа у заказчика Павел описывает переход от инженерной помощи ради потребления Azure к оплачиваемым проектам с обязательствами по результату. По его словам, эта операционная модель ещё формируется. 🔸 Зачем отдельно проверять реализуемость Прежде чем обещать эффект, нужно разобраться с данными и ограничениями. Павел предлагает оплачиваемый исследовательский этап; мы обсуждаем, почему отказ от маленькой начальной инвестиции может увеличить риск большого проекта. 🔸 Как доступы определяют архитектуру В кейсе нефтяной компании сложные права на документы и позиция внутренней IT-команды повлияли на решение сильнее, чем желание просто добавить агентов. Компромисс оставил создание решений за IT. 🔸 Почему инженер участвует в продажах Нужно превратить общие амбиции в выполнимую работу, оценить ресурсы и договориться о контрольных точках, на которых проект можно пересмотреть или остановить. 🔸 Кому подходит FDE Быстро освоить чужую предметную область, договориться с несколькими сторонами и работать с неопределённостью. Иногда результатом будет решение на обычных правилах — даже если заказчик пришёл за AI-агентом. Это разговор о практике и ограничениях конкретной команды. Особенно рекомендую тем, у кого технический пилот уже работает, а до результата у клиента всё ещё далеко. Материалы выпуска: 📌 Страница выпуска с таймкодами и текстовый конспект 🎬 Видео: YouTube и VK Видео 🎧 Аудио: Podster и Apple Podcasts На чём у вас чаще застревает внедрение: данных, доступах или договорённости о том, кто вправе менять процесс? #CodeOfLeadership #Leadership #Management #AI #Engineering #Product

Оценки агентов: как понять, что агент справился / Research Insights Made Simple #42 (Рубрика #AI4SDLC) Агент написал «готово». Но изменился ли нужный файл, появилась ли бронь в базе и выполнены ли условия задачи? Красивый ответ ещё не означает, что работа сделана. А низкий балл иногда говорит о сломанной проверке, а не о слабом агенте. Завтра в 10 утра по мск разбираем руководство Anthropic «Demystifying evals for AI agents» и продолжаем серию об обвязках агентов. После разговора об их устройстве переходим к вопросу: как доказать, что система работает и очередная правка действительно её улучшила? Обсудим: — Чем итог работы отличается от траектории: что агент оставил в среде и как к этому пришёл. — Почему оценивается модель вместе с обвязкой, инструментами и настройками среды. — Как устроены набор задач, отдельная задача и повторные попытки — и почему у процентов успеха бывают разные знаменатели. — Когда подходят программные проверки, модельные судьи и оценка человека; как проверять самих проверяющих. — Чем pass@k отличается от pass^k: хотя бы один успех и стабильный успех во всех попытках отвечают на разные вопросы. — Зачем изолировать прогоны, читать траектории и превращать реальные сбои в тестовые задачи. Отдельно поговорим о доверии к оценкам: как отличить регрессию от случайного разброса, заметить неверные критерии и не принять рост балла за улучшение продукта. В эпилоге обратимся к более поздним материалам Anthropic: Petri v2, измерению автономности агентов и разбору апрельских регрессий. Это практическое руководство, основанное на опыте команды и клиентов Anthropic. Разделим рекомендации авторов, результаты отдельных работ и наши выводы для разработки собственных агентов. Эфир для разработчиков, технических руководителей и всех, кто хочет проверять AI-агентов на реальных задачах. Приходите с примерами: что в вашей системе считается доказательством успеха? #AI4SDLC #Agents #Engineering #Architecture #Evals

+6

The How to be British Collection Two (Рубрика #Humor) В апреле я писал про первую коллекцию "The How to be British Collection" — шуточную книжку о том, как быть британцем. Теперь очередь второй, от тех же Martyn Ford и Peter Legon. Судя по выбранным страницам, до получения почётного звания британца ещё есть над чем поработать :) Начать можно с устройства мозга. На картинке нашлось место чаю, пиву, ностальгии и хранилищу бесполезных фактов для викторины в пабе. А вот участок, отвечающий за изучение иностранных языков, предлагается искать невооружённым глазом без особой надежды на успех. Зато для узнавания королевской семьи предусмотрен отдельный центр. Приоритеты расставлены. Дальше — питание. После полного английского завтрака авторы советуют вернуться в кровать и поспать до обеда. Правда, на соседнем снимке между завтраком и обедом ещё стоят brunch и elevenses. Сразу видно слабое место этого плана: пока спишь, можно пропустить два приёма пищи. Железные дороги здесь превратили в настолку De-Railed: то тоннель затопило, то объявили не ту платформу, то на рельсы упала снежинка — возвращайся на старт. Но лучше всего само условие старта: выбросить семёрку на нарисованном обычном кубике. Кажется, поездка уже не складывается. А ещё есть урок предлогов с целой любовной историей: от подъёма на балкон до неудачного возвращения. Вот у кого надо учиться придумывать примеры для учебников — сюжет успевает закончиться, пока ты разбираешься с up, on и out. Но самый прикладной урок — как принимать комплименты. Похвалили твой дом? Ни в коем случае не соглашайся, что он прекрасен: сочтут самодовольным. Расскажи, что переплатил, всё разваливается, а соседи странные. Сразу приятный, скромный человек. Так что фотографии прилагаю, но заранее отмечу: свет так себе, страницы криво, клавиатура лезет в кадр. Урок самоиронии можно считать отработанным :) #Books #Humor #Travel #Culture

Заходите на прямой эфир Research Insights Made Simple #41"Анатомия агента: семь обязанностей обвязки", который сейчас стартует. На эфире разберём препринт «Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents. A Source-Code Study of Eleven Systems»

Jediah Katz про harness: что остаётся после новой модели (Рубрика #AI4SDLC) Jediah Katz, инженер из Cursor, теперь в SpaceXAI, в 18-минутном докладе разбирает занятный процесс: команда улучшает harness, а следующая модель позволяет удалить часть этой работы. Запись вышла 19 октября на AI Engineer под названием «Smarter Models Killed the Harness. Here's What's Left». По словам Каца, в Cursor раньше приходилось отдельно объяснять модели, как исследовать репозиторий и проверять результат, а для применения правок использовать вспомогательную модель. Постепенно модели освоили эти действия. Его объяснение: обвязка делает более сложные задачи доступными, появляются полезные траектории работы, на них учатся модели — и часть прошлих подпорок становится лишней. Это взгляд инженера изнутри продукта, а не независимое доказательство того, что сложная обвязка больше нигде не нужна. У этого процесса есть продолжение. В Grokbot, где постоянный агент-координатор распределяет работу между исполнителями, команда снова добавляет инструкции и вмешательства. Теперь нужно осваивать сайты, вовремя сообщать о ходе работы, понимать, когда действовать, а когда уточнять, и запоминать предпочтения человека. На новом классе задач модель опять нуждается в помощи, но это уже похоже на мета-харнесс:) Отдельно Кац выделяет следующие устойчивые части обзвизки: - Исполнение: где живёт агент, как сохраняется состояние и продолжается работа после сбоя. - Полномочия: к каким данным и действиям у него есть доступ, где заканчивается бюджет. - Эффективность: сколько стоят контекст, повторные вызовы и выбор моделей. Одинаковый балл на бенчмарке ещё не означает одинаковую цену задачи. А самая вкусная деталь — учёт временных подпорок, которые команда называет shims. Например, агенту приходится напоминать, что пользователь ждёт ответа. По словам Каца, такие вмешательства учитываются централизованно, срабатывания логируются, а бот предлагает PR на удаление тех, которые перестали срабатывать. Здесь доклад очень рифмуется с тем, что я рассказывал 16 октября на Giga Conf: после новой модели стоит пересматривать накопленные инструкции. Иначе обвязка постепенно становится музеем ограничений предыдущих поколений. В Research Insights #38 я разбирал, как проверять вклад отдельных компонентов: какой сбой исправляет план, управление контекстом или инструмент? А в лонгриде об эволюции harness предложил реестр предположений: зачем добавили компонент, при какой модели он помогал, какое есть доказательство и когда его перепроверить. Кац показывает, как к такому реестру прикрутить наблюдение за реальной работой. Но «перестало срабатывать» — только повод для эксперимента. Могли исчезнуть нужные задачи, сломаться логирование или просто давно не повторялся редкий сбой. Я бы проверял удаление так: - Сохранить эпизоды, ради которых появилась подпорка, и добавить характерные текущие задачи. - На одной версии модели и при одинаковом бюджете сравнить полную обвязку с вариантом без этого компонента (это исследования через абляции). Повторить запуски - Заранее определить допустимое ухудшение. Смотреть на качество, стоимость, время и вмешательства человека; если данных мало, оставить вопрос открытым. - Приложить результаты к PR и сохранить возможность вернуть компонент при регрессии. И отдельно — границы полномочий. Запрет на удаление чужих данных нельзя отменять потому, что агент давно его не нарушал. Рост способностей модели сам по себе не расширяет её права. А в следующем PR, который добавляет агенту ещё одно правило, я бы сразу попросил записать: при каком результате проверки мы сможем это правило убрать? #AI4SDLC #Agents #Engineering #Architecture #Evals

Материалы Research Insights #39: Scion и разработка с агентами (Рубрика #AI4SDLC) Доступны материалы сольного выпуска Research Insights Made Simple №39 от 15 октября 2026 года — «Scion: замена git внутри Anthropic для агентной разработки». Разобрал инженерный отчёт компании "Anthropic — Redesigning source control at Anthropic": что приходится менять в хранении кода, когда основную нагрузку создают агенты и CI. В выпуске разобрал: 🔸 Зачем агенту весь репозиторий В Scion историю, merge и rebase обслуживает сервер. Если задаче достаточно ответа API, локальная копия может вообще не понадобиться. Такой выбор опирается на постоянное подключение клиентов. 🔸 Почему это похоже на базу данных Журнал изменений, производные структуры для чтения и кеши неизменяемых объектов. При этом гарантии Spanner нельзя автоматически приписать всей системе. 🔸 Что именно стало быстрее Получение кода и создание рабочего дерева — отдельные операции. Их ускорение ещё не означает такой же выигрыш во всём цикле разработки. 🔸 Что делали инженеры По отчёту Anthropic, семь человек построили Scion, Antique и связанные системы и провели миграцию за пять месяцев. Люди задавали архитектурные ограничения и останавливали лишнее усложнение со стороны агентов. 🔸 Где теперь проверяют изменения Перенос части проверок после слияния оставляет вопросы о совместимости поведения и допуске к релизу. Полный путь до проверенного выпуска в статье не раскрыт. Условия Anthropic специфичны: нагрузка, размер репозитория, доступ к моделям. В разговоре отделяю описанную реализацию от собственных вопросов к ней; готового рецепта замены Git для любой команды здесь нет. Материалы выпуска: 📌 Страница выпуска с таймкодами и Слайды выпуска 📖 Лонгрид об инфраструктуре агентной разработки 🎬 Видео: YouTube и VK Видео 🎧 Аудио: Podster и Apple Podcasts 📖 Текстовый конспект Что у вас первым упирается в рост числа агентов: работа с репозиторием, CI или проверка совместимости изменений? #AI4SDLC #Agents #Architecture #PlatformEngineering #ResearchInsights

Harness Engineering: анатомия кодинг-агентов (Рубрика #AI4SDLC) Сколько в работе кодинг-агента зависит от модели, а сколько — от среды вокруг неё? В статье на 80+ страниц "Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents" интересна попытка разобрать эту среду по исходному коду. Paul Barbaste и коллеги из Wavestone AI Lab и Inclusive Brains рассматривают 11 агентных систем, включая Claude Code, Codex, OpenHands и Pi, а отдельно — метаобвязку Omnigent. Делают это они по срезу на июль 2026 года. Авторы изучают архитектуру агентов по исходному коду, а общего эксперимента на одинаковых задачах здесь нет. В статье я бы выделил четыре части 🔸Анатомия harness Семь подсистем: рабочий цикл, интеграция с LLM, инструменты, память и контекст, безопасность, оркестрация и расширения. Карта помогает понять, где именно различаются агенты: как применяют правки, восстанавливают работу и решают, что задача завершена. 🔸 Инженерные механизмы Как сжимать историю, не потеряв цель; кому разрешать записывать долговременную память; как разделять стабильную и меняющуюся части промпта ради кэша. Особенно важен переход от текстовой просьбы соблюдать правило к проверке в исполняемом коде. 🔸Общие паттерны и компромиссы По аудиту авторов, в изученных системах нет универсальных агентных фреймворков в основном runtime и векторного поиска по коду. Вместо последнего — поиск по тексту, файлам и структуре программы. А простой агент может обходиться небольшим циклом и shell-инструментом; продуктовая сложность добавляет безопасность, восстановление и интеграции. 🔸 Платформенный поворот SDK, skills, плагины, перенос сессий и корпоративные политики превращают обвязку в среду, поверх которой строят другие продукты. Авторы считают, что конкуренция смещается к экосистемам. Но сами же описывают метаобвязки, способные сделать отдельные harness заменяемыми. К посту приложен PDF с моими заметками, где я на полях оставлял вопросы к выводам авторов и идеи, которые хочется проверить. Вот несколько точек для обсуждения. 1️⃣ «А гипотезы какие?» к выводам авторов (на странице 2) Если в выбранных системах нет LangChain или векторного поиска, следует ли из этого, что они не нужны? Отсутствие технологии в выборке ещё не доказывает её бесполезность. В рекомендациях авторы местами делают более сильный вывод, чем позволяет метод исследования. 2️⃣ «Что измерять кроме success rate?» к резульатам бенче (на странице 58) На полях у меня предположение: возможно, задачи SWE-bench уже слишком просты для такого сравнения. Это ещё надо проверять. Но стоимость принятого решения, число вмешательств человека и способность восстановиться после сбоя точно заслуживают отдельного измерения. Одинаковый процент решённых задач может скрывать очень разный опыт работы. 3️⃣ «Где здесь сетевые эффекты?» при обсуждении платформенной экономике в harnesses (на странице 61) Накопленная память и настройки усложняют переход между продуктами. А больше пользователей может привлекать авторов расширений, делая платформу полезнее. Это разные механизмы. Причём переносимые skills могут усиливать всю экосистему и одновременно ослаблять зависимость от конкретной обвязки. 4️⃣ Про совместную эволюцию модели и harness (на страницах 55-56) По мере улучшения модели часть обвязки, возможно, стоит упрощать. Хорошая тема для эксперимента: какие механизмы действительно помогают, а какие продолжают компенсировать уже исчезнувшие ограничения? Мы это уже разбирали в одной из прошлых серий Research Insights Завтра, 20 октября, в 11:30 по Москве будет прямой эфир с разбором этого whitepaper. Пройдёмся по архитектуре, спорным выводам и пометкам в PDF. Приходите со своими вопросами. #AI4SDLC #Agents #Architecture #Research #PlatformEngineering

Заходите на прямой эфир, где я разберу интересную статью от Anthropic про то, как меняется работа в компании при использовании AI.

Anthropic: что остаётся человеку в компании агентов / Research Insights Made Simple #40 (Рубрика #DevEx) Завтра в 10 утра в прямом эфире разберу "How employment is changing at Anthropic" (о ней я писал утром). По-факту, это будет продолжение разговора, который мы начали при разборе серии от "Google Developer Productivity for Humans", где мы пытались ответить на вопрос, а как понять что рост активности помогает людям получать полезный результат? Сначала посмотрим на саму статью: — Что авторы узнали о найме, продуктивности, рабочих процессах и изменении ролей; — Как устроено исследование: внутренние данные, интервью и сравнение сотрудников до и после внедрения агентов; — Что показывают графики агентских часов, объёма кода и качества — и какие выводы из них делать рано; — Почему возникает всё больше работы по организации работы агентов и куда уходит человеческое внимание. А дальше вернусь к вопросам из своих пометок на полях статьи (их можно увидеть в PDF, что был приложен к утреннему посту) — Как устроить рабочий цикл, чтобы не проверять вручную каждый шаг агента? — Где будущий самостоятельный инженер получит опыт, если простые задачи уже автоматизированы? — И на каких условиях сотруднику выгодно автоматизировать собственную работу — что он получает взамен и есть ли для него следующая роль? Это исследование одной быстро растущей компании, которая сама создаёт AI. Его данные интересны именно в деталях; переносить их на весь рынок труда будем осторожно. Приходите с вопросами и примерами из своих команд. Особенно интересно, какая работа появилась у вас после внедрения агентов, хотя её не было в первоначальном обещании «сэкономить время». Предыдущие разговоры: 1) Developer Productivity for Humans — выпуск #30 2) 3 AImigo "AI-native компания — что это значит на практике" 3) 3 AImigo "Джун без простых задач — как входить в IT в эпоху AI" #AI #Research #Agents #Engineering #Management

Материалы Research Insights #38: что даёт обвязка агенту (Рубрика #AI4SDLC) Готовы материалы сольного выпуска Research Insights Made Simple №38 от 13 октября 2026 года — «Проектирование обвязки для кодинговых агентов: что даёт обвязка». В нём разобрал исследование от сентября 2026 года "An Empirical Study of Harness Design for Coding Agents, v1" о плане, инструментах и управлении контекстом. Полезный вопрос здесь вполне приземлённый: какой именно сбой исправляет очередная деталь нашего агента? В выпуске разобрал: 🔸 Как отделить модель от обвязки Авторы сохраняют общий цикл работы и меняют отдельные компоненты: четыре модели, два набора задач, 176 настроек. Это не полный перебор всех сочетаний. 🔸 Что даёт управление контекстом В исследовании большая часть пользы связана с предотвращением переполнения окна. Вытеснение старых результатов перед пересказом снижает расчётную стоимость; возможность вернуть их из памяти модели используют редко. 🔸 Зачем сильной модели план Он может сократить лишние проверки после правки, а слабой — помочь не бросить задачу раньше времени. Меньше ходов само по себе ещё не означает лучший результат. 🔸 Почему нельзя просто оставить bash Эффект зависит от модели и задачи. Кроме того, удаляя готовые инструменты, авторы убирают и встроенную диагностику после редактирования — меняется сразу несколько условий работы. 🔸 Что искать в последовательности действий Переполнение контекста, ранний отказ и бесконечные перепроверки требуют разных изменений. Итоговый балл не расскажет, где агент застрял. Важная оговорка: одна попытка на задачу и ограниченный набор моделей не дают универсального рецепта. Из выпуска стоит забрать способ ставить эксперимент и повторять его после смены модели. Материалы выпуска: 📌 Страница выпуска с таймкодами и слайды выпуска 📖 Лонгрид об эволюции обвязок 🎬 Видео: YouTube и VK Видео 🎧 Аудио: Podster, Apple Podcasts 📖 Текстовый конспект Какую часть своей обвязки вы бы первой проверили на полезность: план, инструменты или работу с контекстом? #AI4SDLC #Agents #Evals #Engineering #ResearchInsights

Как меняется работа внутри Anthropic (Рубрика #AI) Прочитал статью "How Employment Is Changing at Anthropic", опубликованную 16 октября. Многое перекликается с [эфиром 3 AImigo про AI-native компанию и моим лонгридом: агенты ускоряют исполнение, а дальше приходится менять процессы, роли и правила принятия решений. Здесь интересно посмотреть, как это выглядит внутри самой Anthropic. Для этого авторы собрали внутренние данные о найме, использовании AI, результатах работы, встречах и коммуникациях, дополнив их 17 интервью. У исследования четыре связанных сюжета. 🔸 Кого нанимают и куда переводят Доля джунов среди новых технических сотрудников упала с 27% до 9%. Это доля найма, не число увольнений. Нетехнические сотрудники создают свои инструменты, менеджеры чаще коммитят код, а целые команды меняют занятие: авторы продуктовых текстов после автоматизации перешли к промптам и evals. 🔸 Что происходит с производительностью Растёт число коммитов, обработанных договоров, закрытых сделок на сотрудника. Авторы сравнивают работу людей до и после внедрения агентов с теми, кто их ещё не внедрил. Дизайн интересный, но группы сформировались неслучайно: большой новый проект мог одновременно увеличить output и подтолкнуть человека к агентам. 🔸 Во что превращается рабочий день Человеческое внимание становится узким местом. Доля интерактивных сессий Claude, посвящённых meta-work — инструкциям, проверкам, мониторингу агентов, — выросла с 10% до 22%. Это доля сессий, не рабочего времени. Даже у технических специалистов без управленческой роли время встреч выросло на 16% за год. Агенты требуют координации, люди продолжают договариваться между собой. 🔸 Что делать работодателю Делиться выгодами автоматизации, заранее замечать изменение ролей и переводить сотрудников на новые задачи. Авторы признают: защита уже работающих людей не помогает тем, кого вообще перестали нанимать. Для рынка труда понадобятся решения за пределами одной компании. А дальше уже расскажу про мои пометки на полях, приложенного PDF 1️⃣ Output ещё надо превратить в outcome — об этом писал еще в «Token burn как proof of work». Больше кода само по себе не отвечает на вопрос, что стало лучше у клиента. И даже рост выручки на сотрудника не изолирует эффект AI от роста бизнеса. Это исследование одной быстрорастущей компании, которая сама продаёт изучаемую технологию. 2️⃣ Meta-work хорошо ложится в наш разговор про Loop Engineering в Research Insights. Можно весь день обслуживать очередь вопросов от агентов. А можно проектировать цикл: задача, исполнение, проверка, исправление, обращение к человеку. Мне интересно, уменьшается ли после этого человеческое внимание на один принятый результат. Само по себе увеличение числа инструкций пока мало что доказывает. 3️⃣ Любопытно сближение ролей: менеджеры становятся более hands-on, а инженеры получают команды агентов. Отсюда понятнее спрос на самостоятельность и качество решений. Как их оценивать, обсуждали в «AI нанимает AI» (тут пост с материалами). Только откуда возьмётся это суждение у начинающих, если задачи, на которых раньше набирали опыт, уже автоматизированы? Это уже вопрос нашего выпуска «Джун без простых задач». И как всем этим управлять, если реальные решения остаются в личных переписках, а агентам достаются старые документы? 4️⃣ Самый важный для меня нюанс — про стимулы. Акции быстрорастущей Anthropic дают сотрудникам интерес в её успехе. Как перенести этот договор на обычную компанию? Внутренняя ротация тоже может существовать на словах, а на деле оказаться остановкой перед увольнением. Нужны реальные новые роли и возможность в них перейти. Если я автоматизирую собственную работу, какую часть выигрыша получу и что буду делать дальше? Вот этот вопрос я бы задал раньше, чем ставить сотрудникам очередной KPI по использованию AI. #AI #Research #Agents #Engineering #Management

Gautam Korlam: CI для агентного потока изменений (Рубрика #AI4SDLC) Агент за минуту исправил код, потом десять минут ждал CI. Проверка упала, пошёл следующий круг. После третьей попытки кто-нибудь открыл ревью и попросил ещё одну правку. Знакомая инженерная карусель, которую быстрый кодинг только раскручивает :) Про неё — 19-минутный доклад "Rebuilding CI for AI-Scale Commit Volume" от Gautam Korlam, сооснователя Gitar, который теперь часть Sonar, а Gautam теперь principal engineer в Sonar. Его тезис: поток агентных изменений упирается в пропускную способность сборок, проверок и согласований. Здесь интересна именно механика этих задержек. 🔸 Зелёные PR могут сломать общую ветку Корлам рассказывает про Uber SubmitQueue: очередь заранее проверяет вероятные сочетания изменений. Успех отдельных PR ещё не подтверждает их совместимость. В моём понимании, зелёная галочка всегда требует уточнения: какой состав кода она проверила? 🔸 Каждая попытка исправления снова оплачивает CI Спикер приводит две показательные цифры: - как минимум у 13% PR на его платформе случался отказ обязательной проверки; - в команде Gitar примерно десятиминутный CI сократили до менее минуты для прогретых инкрементальных шагов: кеши, меньше лишней инвалидации, шардирование. Холодная сборка в это обещание не входит. Это данные самого докладчика. А я бы рядом со временем запуска мерил число проходов до принятого изменения. Три быстрые правки могут означать три полные сборки и три ожидания. Тут появляется вполне осязаемая цена каждой следующей попытки агента. 🔸 Ревью тоже надо уметь разгружать Корлам предлагает автоматизировать первый проход и допуск подходящих рутинных изменений, а чувствительные отправлять человеку. Автор изменения не должен сам его одобрять. Есть и конкретный кейс: тесты распараллелили через nextest, но оставили общую БД без необходимых защит от взаимного влияния. По словам Корлама, Gitar поймал и исправил проблему до merge. Ускоряли CI — чуть не получили нестабильные тесты. Мне здесь интереснее всего определение риска. Обновление зависимости может поменять поведение сервиса, а правка внутреннего инструмента — затронуть выпуск всей компании. Хочется увидеть ошибочный автоматический допуск и то, как после него поменяли политику. И ещё считать работу, которую создал AI-ревьюер: каждое замечание кто-то должен разобрать, даже если замечание оказалось ерундой. 🔸 Основания для merge должны пережить логи CI В финале Корлам разбирает сохранение проверенного коммита, отчёта, независимого approval и причин исключений. Вот это особенно полезная часть. Через полгода хочется восстановить, почему конкретный сбой разрешили пропустить и кто принял решение. Название ветки уже может указывать на другой код. И я бы сохранял такой контекст сразу вместе с изменением: потом собирать историю по исчезнувшим логам будет поздно. Этот доклад продолжает тему моих разборов CI/CD и скорости доставки и Scion: рост потока изменений заставляет пересматривать устройство всего конвейера. Здесь фокус — на пути от предложенной правки до принятого кода. В выступлении есть и демонстрация Gitar, так что универсальную эффективность продукта из этих примеров выводить рано. Я бы забрал из него вопрос для своей команды: сколько времени и повторной работы стоит одно принятое изменение — вместе с исправлениями, замечаниями и исключениями? #AI4SDLC #DevOps #DevTools #Engineering #Metrics