Книжный куб

Разобраться, чтобы решить: как я осваиваю новые темы с помощью ИИ (Рубрика #SelfDevelopment) 9 ноября я выступлю на pmclub upskill week, где расскажу как AI помогает мне глубоко разбираться в темах, которые мне требуются для принятия сложных решений. Выступить меня позвал Дима Ильенков, с которым мы в подкасте обсуждали его книгу "Не усложняй", причем мы долго думали, а о чем рассказать ребятам и @pmclub и в итоге остановились на том, что я расскажу как погружаюсь в незнакомые темы: - составляю карту темы - выбираю источники - проверяю противоречия - превращаю изученное в критерии выбора и небольшие эксперименты Примерно на эту тему мы общались в подкасте 3 AImigo в серии шесть "Как не утонуть в потоке AI-изменений и сохранить силы" #Reasoning #Thinking #Leadership #Management

Giga Conf: что делать с обвязкой агента после новой модели (Рубрика #AI4SDLC) Сегодня, 16 октября, я выступаю на Giga Conf с докладом «Harness: прошлое, настоящее и будущее слоя между моделью и миром». Подключиться к трансляции можно в 16:00. Про агентную я рассказывал много в последнее время, про инструменты, память, контекст, проверки и весь тот инженерный быт, благодаря которому модель доводит задачу до результата. А в этом докладе я хочу собрать картину целиком и разобрать неприятный вопрос: что из построенного нами всё ещё нужно после выхода следующей модели? Ведь обвязка постепенно обрастает инструкциями. Здесь модель забывала проверить результат — добавили правило. Там теряла состояние — придумали ещё один шаг. Потом модель обновилась, а все эти подпорки остались. Получается такой музей ограничений предыдущих поколений, который мы продолжаем носить с собой :) В докладе пройду путь от ранних агентных циклов до современных Claude Code, Codex и Cursor. Посмотрим, из чего они собираются и где хранится состояние работы. А дальше — как смотреть на одну и ту же обвязку как на готовый комбайн, самостоятельного агента или компонент своей системы. Слайды есть уже на моем сайте, но сегодняшнее выступление ограничено 20-30 минутами, поэтому если вам интересно послушать режиссерскую версию, то накидайте 100 🔥 и я сделаю прямой эфир с расширенной версией этого выступления. #AI4SDLC #Agents #Engineering #Architecture #Conference

Stack Overflow 2026 (Рубрика #AI4SDLC) Почитал результаты опроса StackOverflow, что вышел 10 дней назад. Сначала рамка: 30 903 анкеты из 169 стран, сбор с 23 июня по 5 августа 2026 года. Участники пришли через площадки и рассылку Stack Overflow. Это добровольная выборка, ее нельзя автоматически переносить на всех разработчиков. Проценты ниже — среди ответивших на конкретный вопрос, состав и размер этих групп различаются. В блоке про сообщество 64,1% говорят, что из-за AI реже заходят на Stack Overflow с простыми вопросами. 28,9% задают меньше вопросов, 26,5% меньше участвуют в наполнении платформы. Больше участвуют только 1,2%. При этом 15,9% чаще приходят проверять информацию. Честно говоря, я на StackOverflow теперь захожу только поучаствовать в опросах и почитать их результаты — не ясно зачем теперь задавать вопрос на этом ресурсе, если можно спросить агента:) Интересный момент вынесен прямо на главную страницу - рост доверия к AI На главной написано, что некоторое доверие к AI выражают уже более 87% против 31% годом ранее. Но в отчёте за 2025 год указаны 33% доверяющих точности ответов, а в 2026-м вопрос и шкалу изменили: теперь варианты описывают условия применения. В новых ответах: — 48% доверяют результату, когда его легко проверить — 16,3% — только для задач с низким риском — 6,6% — для многих задач, включая важные рабочие решения Любопытен и расклад популярности инструментов 1) Claude Code — 65,5% 2) GitHub Copilot — 58,7% 3) Codex — 29,5% 4) Cursor — 25,5% Тут можно было выбрать несколько продуктов, причем в другом вопросе видно, что у 41% от трех до пяти AI инструментов используется совместно:) Другой раздел посвящен тому, а что мешает получать нужный рабочий контекст для решения задач: — 63,2% — информация неполная —60,9% — важное находится в головах людей —56,5% — информация устарела —53,4% — она разбросана по слишком многим инструментам Отдельно отмечается, что опытные специалисты относятся к AI благосклоннее начинающих Положительное отношение выражают 69% участников с профессиональным стажем от 16 лет и 53% со стажем 1–5 лет. Возможное объяснение: опыт помогает выбирать подходящие задачи и замечать ошибки. А может дело в том, что их экспертиза и опыт защищает их достаточно хорошо от того, чтобы их работу передали AI:) В общем, я не нашел каких-то особых инсайтов в результатах исследования, но полистать его было достаточно интересно. Заодно в очередной раз навестил обезлюдевший StackOverflow:) #AI4SDLC #Engineering #Software #Management #Research

Scion - замена git внутри Anthropic для агентной разработки (Рубрика #DevTools) Агенты пишут код, а инфраструктура разработки начинает захлёбываться. В Anthropic дошли до собственной системы контроля версий — Scion. И агенты же помогли её построить. 15 октября 2026 года в 17:00 в сольном выпуске Research Insights Made Simple #39 разберу статью «Redesigning source control at Anthropic». Это инженерный отчёт команды о том, как меняется работа с кодом, когда основными клиентами репозитория становятся постоянно подключённые агенты и CI. Меня здесь особенно интересуют две вещи: знакомые идеи баз данных в устройстве Scion и изменение гарантий вокруг merge. Что мы выигрываем, если быстрее принимаем изменения в общую историю? И что после этого обязаны проверить до деплоя? В выпуске: — почему Anthropic перенесла операции с историей, merge и rebase на сервер; — как устроены журнал изменений, производные структуры чтения и кеширование неизменяемых объектов; — что именно ускорилось на итоговом графике и почему эти числа нельзя переносить на всю разработку; — какие гарантии меняются при переходе к post-merge проверкам и как связать допуск к релизу с конкретным проверенным артефактом; — как дать агенту стабильную базу и при этом раньше замечать конфликты с движущимся main. Разбор для инженеров, архитекторов и платформенных команд, которые внедряют кодинговых агентов и хотят понять, что придётся менять вокруг них. Все выпуски Research Insights Made Simple: https://polomodov.tech/research-insights/ #ResearchInsights #AI4SDLC #Anthropic #Architecture #SystemDesign #DistributedSystems #BigTech

3 AImigo S1E10: Агенты с правом платежа: доверим ли AI свои деньги? (Рубрика #AI) Завтра в 11:00 по мск будет очередной выпуск подкаста 3 AImigo, который станет десятым юбилейным:) Мы обсудим вопросы, а что нужно, чтобы поручить AI покупку целиком: выбрать подходящий товар, уложиться в бюджет и заплатить? Сколько агент должен знать о наших привычках — и сколько самостоятельности мы готовы ему дать, когда речь идёт о деньгах? В десятом выпуске 3 AImigo продолжаем разговор об автономности агентов и переходим к покупкам и платежам. Обсуждают Александр Поломодов, Алексей Литвинов и Евгений Сергеев. Поговорим о том: — какие повседневные покупки хочется делегировать агенту и что мешает довести их до оплаты; — как объяснить ему свои предпочтения, ограничения и бюджет; — где оставлять подтверждение человека и что делать, если покупка не подошла; — зачем нужны платёжные протоколы для агентов и как в эту историю вписываются банки, магазины и AI-платформы; — кто будет выбирать, что мы покупаем, если основным посредником между человеком и магазином станет AI-ассистент. Начнём с собственных бытовых задач и экспериментов, а дальше посмотрим на устройство сервисов и интересы компаний. Разговор для тех, кто строит агентные продукты, работает с платежами или просто хочет однажды делегировать покупку продуктов без подробной инструкции на каждый случай. #AI4SDLC #Agents #Engineering #Management #3AImigo

А теперь заходите на прямой эфир, мы стартуем

Scion: когда агенты упираются в инфраструктуру разработки (Рубрика #AI4SDLC) В свежей статье Anthropic про Scion есть занятный самоподдерживающийся цикл: агенты производят столько изменений, что инфраструктура разработки перестаёт справляться. А затем помогают построить новую инфраструктуру, чтобы производить ещё больше изменений :) По данным команды, с мая по сентябрь 2026 года число вливаемых изменений выросло примерно с 2500 до более 30 000 в день. Семь инженеров за пять месяцев построили Scion, инструмент ревью Antique и несколько связанных систем, полностью мигрировав монорепозиторий с Git. В аннотациях я отдельно отметил скорость миграции: написать систему и перевести на неё работающую компанию — весьма разные задачи. 🔸 Кто теперь клиент системы контроля версий? Преимущественно постоянно подключённые агенты и задания CI. Поэтому в Scion историю, blame, merge и rebase обрабатывает сервер. Клиент держит ограниченный кеш, получает нужные файлы, а многие операции вообще выполняются через API без рабочей копии. Дальше мои пометки всё чаще сводились к «напоминает базы данных». Changeset — запись в WAL со списком изменённых файлов и ссылками на содержимое. Деревья, история путей и blame строятся как производные данные. Похоже на CQRS: запись изменений и структуры для чтения оптимизируются отдельно. Можно добавлять новые индексы, считать их заранее или по запросу и менять внутренности без обновления клиентов. Неизменяемые объекты раздаются через кеши на нодах и в регионах. Стоимость коммита должна зависеть от размера изменения. Знакомые принципы масштабирования под новую нагрузку. И хорошо, что авторы признают предшественников: Google Piper и Meta Sapling. 🔸 Инженер, который умеет сказать агенту «нет» Команда по-прежнему ревьюит каждое изменение, но смотрит прежде всего на его намерение. Люди удерживают архитектурные ограничения и останавливают лишнюю сложность: например, агентный ревьюер может придумать гипотетическую угрозу, а другой агент — старательно обложить сервис ненужными проверками. Вот где проявляется инженерное суждение. Хотя правильное намерение ещё нужно подтвердить проверками реализации. Ещё одна моя пометка — «электронный SRE». У каждого компонента есть агент-«суперфанат»: смотрит телеметрию и логи, ищет странности. По утверждению команды, такие агенты замечают проблемы, которые пропускают обычные алерты. Сами алерты при этом остаются. 🔸 Переосмысление доходит до CI Пока идут тесты, в main могут попасть сотни других изменений. Anthropic делает ставку на post-merge и pre-deploy проверки, допуская конфликты между параллельными изменениями и рассчитывая на быстрое исправление агентами. В аннотациях я отметил именно redesign процесса. Здесь хочется больше деталей: что разрешено выпускать, как долго main бывает сломан и как это мешает остальным агентам? Статья такого контракта не раскрывает. И красивые цифры стоит читать внимательно. В тексте заявлены два порядка ускорения checkout, а на итоговом графике у compute jobs — 8×, у CI — 8,8×, у создания нового worktree агентом — 84×. Возможно, условия разные, но расхождение не объяснено. Число merge тоже само по себе не измеряет полезность кода. Перед нами инженерный отчёт компании о собственном решении. Авторы честно оговаривают необычный масштаб и доступный им бюджет токенов. Копировать Scion целиком большинству команд вряд ли нужно. А вот проверить, какие операции в нашем SDLC существуют по привычке и действительно ли они нужны агентам, — уже вполне прикладная идея. P.S. Сегодня ближе к вечеру проведу прямой эфир Research Insights Made Simple, где расскажу про эту систему подробнее #AI4SDLC #Architecture #DistributedSystems #DevTools #Engineering

Stanford CME295, лекция 2: что изменилось внутри Transformer (Рубрика #AI) Появилась запись второй лекции курса про трансформеры и LLM. Причем если в разборе первой лекции мы дошли от токенизации до Transformer из статьи 2017 года, то во второй Афшин и Шервин Амиди показывают, как из этой конструкции получаются современные LLM. И здесь уже интересно проверить себя: насколько хорошо за знакомыми аббревиатурами помнишь, а что они реально значат и почему они появились. За 1 час 43 минуты авторы разбирают семейства BERT и GPT, баланс размера модели и обучающих данных, изменения архитектуры и способы генерации. Я бы выделил несколько моментов. 🔸 MoE: большая модель не обязана использовать все веса для каждого токена. Вместо одного feed-forward блока ставят несколько «экспертов», а роутер выбирает, какие из них задействовать. Причём выбор делается для каждого токена. Но в этой схеме возникает занятная проблема с обучением таких моделей: эксперты, которых выбрали в начале обучения, получают больше обновлений, становятся лучше и выбираются ещё чаще. Остальные простаивают. Это routing collapse; в лекции объясняют, как дополнительный штраф за дисбаланс помогает распределять нагрузку. Хороший пример того, сколько работы скрывается за простой картинкой с роутером. 🔸 RoPE: зачем вообще вращать векторы? Здесь особенно хороша подача. Сначала позиционные представления объясняют через стрелки часов с разными частотами, потом доходят до поворотов query и key. В их скалярном произведении появляется зависимость от разницы позиций токенов. Так становится понятно, как порядок текста учитывается прямо в attention. Знать расшифровку RoPE (Rotary Position Embedding) и понимать, откуда взялся поворот, — довольно разные уровни знакомства с темой. 🔸 Attention приходится укладывать в память. При генерации ключи и значения предыдущих токенов можно сохранять и использовать повторно. Но чем длиннее текст, тем больше памяти нужно. Отсюда GQA (Grouped-Query Attention): несколько query-голов используют общие ключи и значения. Ещё один приём — sliding window attention, где каждый слой смотрит только на ближайшие токены. При этом через несколько слоёв информация доходит из-за границ одного окна. Преподаватели хорошо связывают это с рецептивным полем свёрточных сетей. 🔸 Даже temperature = 0 не обещает одинаковых ответов. После разных подходов к генерации токена в виде greedy decoding, beam search, top-k и top-p разбирают тонкость, которую легко пропустить. Сервер объединяет запросы в пакеты, и изменение размера пакета может менять порядок вычислений. У чисел с плавающей точкой результат сложения зависит от порядка операций; небольшие расхождения могут повлиять на выбор токена. Поэтому воспроизводимость зависит и от реализации инференса. Подробности есть в разборе Thinking Machines, на который ссылаются в лекции. 🔸 Корректный JSON можно обеспечить на этапе выбора токенов. Guided decoding ограничивает допустимые продолжения согласно нужному синтаксису. На каждом шаге модель выбирает среди разрешённых токенов. Это объясняет, что стоит за гарантией формата; правильность самих данных внутри JSON всё равно нужно проверять. В финале коротко проходят контекстное окно, context rot, обучение на примерах в промпте и техники рассуждения. Полезное напоминание: способность вместить длинный текст ещё не гарантирует, что модель надёжно использует каждую его часть. Даже если вы уже знаете, как работает LLM, запись стоит посмотреть ради этих связей. После неё удобно открыть схему знакомой модели и объяснить, зачем там MoE, RoPE или GQA, где экономят вычисления, где память и от чего зависит получившийся ответ. А объяснение RoPE вполне заслуживает отдельной паузы с карандашом. P.S. Я уже много раз читал статьи и разные книги на эту тему, но тут подача конечно хороша - можно вспомнить основы и получше уложить их в голове. #AI #LLM #Learning #Engineering #Architecture

(poll without text)

Обновление по сегодняшнему прямому эфиру с Павлом Голубевым, Principal FDE Manager в Microsoft, а также автором канала @corporateAI: - Оказалось, что я промахнулся при назначении прямого эфира на Youtube - мы с Пашей договаривались на четверг, но я почему-то поставил эфир на среду. - Поэтому приходите завтра в 11:30 и все будеn. А пока можете посмотреть а что мы обсуждали год назад и как остановились в самом конце на переходе к схеме с FDE (forward deploy engineers), о которой будем разговаривать с Пашей завтра. Мои извинения тем, кто хотел посмотреть этот эфир сегодня

AI и платформа данных — материалы выпуска №37 Research Insights Made Simple (Рубрика #Data) Материалы выпуска #37 Research Insights Made Simple уже доступны. 12 октября 2026 года поговорили с Николаем Головым о том, как подключить AI ко всем данным организации и какую инженерную работу скрывает обещание «единой платформы». Дать агенту доступ к нескольким базам — ещё не значит получить согласованный ответ. Где-то данные приезжают с задержкой, где-то большой JOIN гоняет их между системами, а где-то удобство заканчивается на счёте за облако. Обсудили: - Четыре подхода из схемы Николая: классическое хранилище с подготовленными витринами, федеративные запросы, универсальную СУБД и общий слой хранения для разных движков. - Что остаётся за обещанием zero-ETL: копии, задержки, восстановление после сбоев и выбор таблиц, которые всё-таки придётся переносить. - Как эти подходы смешиваются у Microsoft, AWS, ClickHouse и Google и какие компромиссы возникают при совмещении транзакций и аналитики в Oracle и SAP HANA. - Куда движутся Databricks и Snowflake, объединяя аналитику с PostgreSQL. По оценке Николая, компоненты ещё собираются в общую систему — считать задачу решённой рано. - Почему открытый формат не освобождает от эксплуатации: частые небольшие записи в Iceberg, множество файлов и ограничения объектного хранилища никуда не исчезают. Материалы: - Страница выпуска с таймкодами - Видео: YouTube, VK Видео. - Аудио: Podster, Яндекс Музыка, [Apple Podcasts - Текстовый конспект разговора. Если уже подключаете агентов к корпоративным данным, расскажите, где упёрлись: в доступ к источникам, смысл показателей, свежесть или стоимость запросов? #Data #DataEngineering #Databases #Architecture #PlatformEngineering #AI

Материалы выпуска 3 AImigo S1E9: границы автономности (Рубрика #AI4SDLC) Собрал материалы девятого выпуска первого сезона 3 AImigo — «Что можно доверить AI-агенту? Границы автономности». 9 октября 2026 года мы с Евгением Сергеевым и Алексеем Литвиновым обсуждали, что именно делегируем агенту и сколько нашей работы остаётся за кадром, когда он вроде бы действует самостоятельно. Обсудили: 🔸 От действия до зоны ответственности Выполнить команду, решить задачу и отвечать за результат под ключ — разные договорённости. Для каждой нужны свои критерии, контекст и полномочия. 🔸 Почему быстрая генерация упирается в согласования Евгений рассказал об автоматизации выпуска контента во Flo Health. Если экспертные требования появляются только на последней проверке, ускорение подготовки ещё не ускоряет весь процесс. 🔸 Где заканчивается удачный эксперимент Перенос игры с iOS на Android через сравнение в эмуляторах и создание подкастовых обложек. По словам Евгения, агент перенёс игру примерно за пять часов без вмешательства. Но в этом опыте не было немедленной публикации в магазине и ответственности перед пользователями — это существенная граница примера. 🔸 Как пересматривать накопленные инструкции Алексей рассказал об экспериментах с их сокращением после обновления модели. Убирать лишнее полезно, если есть свои задачи и критерии, по которым видно, что качество сохранилось. 🔸 Какой контекст переживёт следующую сессию Причины архитектурных решений и ограничения нужно сохранять. При этом слишком подробная инструкция может заранее закрыть агенту пространство поиска. 🔸 Как посчитать реальную самостоятельность Подготовка правил, проверки, вмешательства, неудачные попытки и восстановление входят в стоимость принятой задачи. Часы работы агента сами по себе не показывают ни размер решённой задачи, ни пользу для человека. В финале поговорили о том, как это меняет работу инженеров и руководителей. Здесь у нас разные ожидания: устройство и масштаб организации пока слишком важны, чтобы обещать всем один сценарий. Материалы выпуска: 📌 Страница выпуска с таймкодами 📖 Лонгрид по теме выпуска 🎬 YouTube, VK Видео 🎧 Podster, Яндекс Музыка, Apple Podcasts 📝 Текстовый конспект Расскажите в комментариях про задачу, которую уже отдаёте агенту целиком. На каком шаге вам всё-таки приходится возвращаться? #AI4SDLC #Agents #Engineering #Management #3AImigo

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

Factory: инженеры становятся менеджерами — а кто тогда остаётся инженером, способным проверить их исполнителей? (Рубрика #AI4SDLC) Название с обложки 18-минутного доклада Davis Palmie, инженера Factory, хорошо продолжает нашу тему dark factories. На AI Engineer World's Fair 2026 он описывает систему, которая превращает баг-репорты и обратную связь пользователей в production-код. Человек задаёт направление и управляет агентами. Звучит как повышение, но давайте посмотрим на должностную инструкцию:) 1️⃣ Управлять всей цепочкой Palmie считает, что написание кода давно не главное узкое место. Изменения ждут ревью, баги нужно воспроизвести, документация устаревает, продуктовые решения теряются между командами. Его software factory связывает эти этапы: сигнал → диагностика → план → код и тесты → ревью → выкладка → наблюдение за результатом. Обратная связь возвращается в следующий цикл. Это развитие factory model из The New SDLC: инженер строит систему, которая производит изменения. 2️⃣ Подготовить среду У Factory восемь направлений agent readiness: линтеры и форматирование, сборка, тесты, документация, воспроизводимые окружения, модульность, наблюдаемость и безопасность. Агенту нужны понятные команды, актуальные инструкции и доступ к контексту за пределами репозитория. Всё это полезно и людям. Плюс возможность выбирать модель под задачу и размещать исполнение в пределах своей инфраструктуры. 3️⃣ Включать автономность постепенно Начать с диагностики инцидента: агент читает alert из Sentry, собирает traces и отправляет вывод в Slack. Инженер проверяет и решает, что делать. Сначала каждый этап получает владельца и контроль, потом цепочка замыкается. Это рифмуется с нашим Loop Engineering: проверяющий должен уметь вовремя сказать «нет». И вот здесь обложка оказывается смелее содержания. Palmie прямо говорит, что точное исполнение не предотвращает плохой дизайн: архитектура, стратегия и допуск изменений по-прежнему требуют людей. Поэтому с докладом Dex Horthy у него больше общего, чем кажется. Dex описывал, как HumanLayer перестала следить за изменениями своей lights-off factory и во время инцидента столкнулась с кодом, который уже плохо понимала. Его аргумент: тесты проверяют «работает сейчас», а цена плохого проектирования проявляется через месяцы. Менеджерская часть работы действительно растёт: постановка, приоритеты, делегирование, обратная связь. Но как проверить решение, если перестал понимать систему? В доклада Geoffrey Litt это и есть новое узкое место: AI ускоряет изменения, а человеческая модель системы отстаёт. Назначить инженера проверяющим ещё не значит дать ему время разобраться. Метрики Palmie предлагает полезные: время от сигнала до production, число человеческих вмешательств, время восстановления, срок жизни кода и стоимость PR. Для меня число вмешательств требует оговорки: оно может падать и потому, что всё работает, и потому, что люди перестали проверять. Сопоставимое качество здесь обязательно. Но интересно, а что продаёт компания Factory? На сайте компании эта картина превращается в платформу: Droid для работы с кодом, автоматизации, маршрутизация моделей, Mission Control, ревью и обновляемая документация. Для организаций — интеграции и управление доступом. Компания продаёт инструменты, через которые можно организовать и контролировать работу агентов. В Missions это особенно видно: оркестратор разбивает цель на задачи, исполнители работают со свежим контекстом, отдельные агенты проверяют результат, состояние хранится в общих файлах. Роли и проверки становятся частью продукта. Так что «Engineers become managers» — ещё и объяснение, зачем покупать Factory: если теперь управляешь агентами, тебе предлагают рабочее место для этого управления. А способность оценить архитектуру и понять, что именно получилось, инженер приносит с собой. #AI4SDLC #AI #Agents #Engineering #Management #DevTools

Harness Engineering: знакомые идеи под одной обложкой (Рубрика #Books) У O’Reilly есть книга Nicole Koenigstein "Harness Engineering". Пока это early release, всего две главы, но я ей заинтересовался после наших разборов harness для Research Insights. У меня возник вопрос, а сколько нового даёт книга человеку, который уже читал исходные статьи? Мой предварительный ответ: большая часть концептуальной основы этих двух глав уже есть в материалах, которые мы обсуждали. Книга собирает её в последовательное объяснение устройства агентной системы. И качество этой сборки ещё предстоит оценить. Вот где идеи пересекаются: 🔸 Модель сама по себе ещё не рабочий агент В Research Insights #33 про SWE-agent мы разбирали, как инструменты, интерфейс и обратная связь меняют результат той же модели. Книга начинает с этого же общего тезиса и показывает его на разборе инцидента. 🔸 Контекст заканчивается, задача продолжается В #34 про долгоживущих агентов — список функций, журнал прогресса, git и передача работы следующей сессии. Во второй главе книги эта проблема получает более общий язык: состояние задачи должно переживать вызов модели и процесс. 🔸 Цикл должен уметь отклонить результат В разборе Loop Engineering мы уже проходили путь от промпта и контекста к обвязке, проверке и сохранению состояния. В книге модель предлагает откат сервиса, а код исполнения блокирует действие без разрешения. Просьба «соблюдай правила» превращается в проверяемое ограничение. 🔸 Инженер проектирует среду и обратную связь Это пересекается с кейсом OpenAI, который я разбирал для #35: знания доступны агенту, границы закреплены проверками, ошибки возвращаются в процесс. Это сопоставление идей. По двум главам я не могу установить, какие именно статьи использовала автор. Но читателю наших разборов знакомая основа будет хорошо видна. При этом у книги есть полезная добавка. Во второй главе отдельно разобраны checkpoint, история событий и записи внешних эффектов. Где продолжить работу, что произошло и какое действие нельзя случайно выполнить второй раз — три разных вопроса. Ещё есть разделение идентификатора задачи и права доступа к ней. Такая детализация делает обзор ближе к проектированию системы. А вот чего мне пока не хватает — проверки применимости рецептов. В своём лонгриде об эволюции harness я отдельно разбирал, как меняются его части вместе с моделью. В продолжении Anthropic автор убирает принудительные сбросы контекста и затем спринты по мере перехода к более сильным моделям. Права доступа остаются обязанностью системы; конкретная процедура планирования требует пересмотра. А в завтрашнем выпуске #38 с разбором "An Empirical Study of Harness Design for Coding Agents", о которой я уже писал, есть экспериментальный подход к оценке разных частей харнесса и как они влияют на итоговый результат. В книге пока преобладает перспектива улучшения обвязки при фиксированной модели. Отключение проверок на записанной последовательности ответов хорошо объясняет механизм, но ещё не измеряет выигрыш на реальных задачах. К тому же обещанные ноутбуки по присланной версии проверить нельзя: в начале глав сказано, что GitHub-репозиторий появится позже. Поэтому сейчас я вижу перспективную систематизацию знакомого материала. Если вы пропустили нашу серию, книга может дать удобный вход. Если следили за разборами, первые две главы скорее помогут разложить знания по полочкам. От следующих жду работающего кода, трудных случаев восстановления и объяснения, когда очередной элемент harness стоит усложнения системы. #Books #AI4SDLC #Agents #Architecture #Engineering #ResearchInsights

Материалы выпуска Research Insights #36: обвязка для долгой разработки (Рубрика #AI4SDLC) Доступны материалы сольного выпуска Research Insights Made Simple от 9 октября 2026 года — «Проектирование обвязки для длительной (автономной) разработки приложений». В нём разобрал инженерный пост Anthropic: как довести приложение до работающего результата, если исполнитель слишком легко соглашается, что уже всё готово. Кстати, сам paper я уже разбирал раньше В выпуске разобрал: 🔸 Зачем разделять создание и оценку Планировщик разворачивает запрос в спецификацию, генератор пишет приложение, оценщик проходит пользовательские сценарии. Но отдельного проверяющего тоже приходится учить замечать существенные проблемы. 🔸 Когда договариваться о готовности Контракт спринта задаёт объём и критерии приёмки до реализации. Для дизайна нужны ещё и понятные критерии качества с примерами: последняя итерация не обязательно лучшая. 🔸 Что дает дополнительный бюджет В примере Anthropic прямой запуск конструктора ретро-игр занял около 20 минут и стоил $9, но основные функции не работали. С обвязкой — 6 часов и $200, зато результат полнее. Бюджеты разные: это демонстрация возможностей, а не доказательство универсальной экономии. 🔸 Что делать после смены модели В описанном переходе к Opus 4.6 автор проверяет компоненты по одному и отказывается от спринтов. Пользу каждой роли и ограничения нужно измерять заново. 🔸 Чего оценщик не замечает В браузерной музыкальной студии он видит интерфейс, API и базу, но не слышит звук. Проверка кнопки Play ещё не говорит, что с музыкой всё хорошо. Отдельно обсудил границу упрощения: часть обвязки компенсирует слабости модели, а часть ограничивает риск её действий. Улучшение исполнителя само по себе не отменяет контроль полномочий. Материалы выпуска: 📌 Страница выпуска с таймкодами 📊 Слайды 📖 Лонгрид об эволюции агентных оболочек 🎬 YouTube, VK Видео 🎧 Podster, Яндекс Музыка, Apple Podcasts 📝 Текстовый конспект #AI4SDLC #Agents #Evals #Engineering #ResearchInsights #RnD

Приходите на прямой эфир с Колей Головым про то, как добавить AI к дата-платформам

Meet Pi: The Minimalist, Self-Modifying Coding Agent (Рубрика #AI4SDLC) У кодинг-агентов есть неприятное свойство: инструмент обновился, а привычный рабочий процесс вокруг него вдруг поломался. В 11-минутном фильме CultRepo создатель Pi Марио Цехнер объясняет, почему решил собрать своего агента. Его ставка — маленькое, понятное ядро, поведение которого можно контролировать, и расширения под конкретную работу. У этой позиции есть биография. Цехнер рассказывает о libGDX и RoboVM, о поглощениях и закрытии проекта. Армин Ронахер, второй собеседник фильма, связывает будущее Pi с открытой основой для инструментов. Поэтому разговор о минимализме здесь еще и про то, кому принадлежит управление собственным рабочим процессом. Техническое объяснение Цехнер начинает предельно просто: запрос к LLM → вызовы инструментов → исполнение → результаты обратно модели. Повторяем, пока модель не выдаст ответ без новых вызовов. В его описании Pi собран из четырех пакетов: 1) слой работы с моделями и провайдерами, включая перенос контекста и нормализацию ответов; 2) терминальный интерфейс; 3) ядро агентного цикла; 4) кодинг-агент, который соединяет предыдущие три. Дальше возникает самая интересная мысль: агент умеет писать код — значит, можно попросить его написать недостающую возможность для самого себя. Ронахер описывает именно такой опыт с расширениями и навыками. «Самомодификация» из названия фильма здесь означает создание программных дополнений и инструкций. Переобучение модели в этом механизме не описано. Мне в этом подходе интересен перенос сложности. Можно держать основу небольшой, а нужные возможности собирать вокруг нее. Но кто-то все равно должен понимать, как эти дополнения взаимодействуют. По документации Pi, расширения — исполняемые модули с правами процесса агента. Маленькое ядро само по себе не решает вопрос границ доступа. Цехнер дает и несколько громких ориентиров. По его словам, Shopify использует Pi примерно для 50% задач агентного кодинга, а на OpenRouter Pi занимает четвертое место, но в фильме нет деталей, чтобы подтвердить или опровергнуть эти заявления. Самая полезная часть начинается с 7:53. Цехнер критикует гонку за количеством агентов и потраченных токенов и требует читать код, понимать решения и отвечать за последствия. Ронахер добавляет очень узнаваемый сценарий: успел собрать и разослать что-то за 15 минут, но сам еще не попробовал. Скорость есть. Ценность пока предстоит доказать. Мне кажется, что Pi стоит рассматривать как ставку на инструмент, который можно приспособить к себе и разобраться в его устройстве. #AI4SDLC #AI #Agents #Architecture #Engineering #DevTools

Материалы выпуска Research Insights #35: среда для агентов (Рубрика #AI4SDLC) Собрал материалы сольного выпуска Research Insights Made Simple от 8 октября 2026 года — «Инженерия обвязки: среда для агентов». Разобрал опыт команды OpenAI, которая поручила Codex весь код внутреннего продукта и дальше описала это в статье "Harness engineering", которую я уже разбирал. В выпуске разобрал: 🔸 Что агенту нужно знать о проекте Решения из переписки и голов инженеров должны стать доступными исполнителю. Короткий AGENTS.md помогает найти архитектуру, планы и требования; огромная инструкция быстро устаревает. 🔸 Как дать агенту проверить собственную работу Отдельный экземпляр приложения, браузер, логи, метрики и трассы. Иначе пожелание «сделай быстрее» так и останется пожеланием. 🔸 Как превратить архитектуру в обратную связь Проверяемые границы модулей и линтеры, которые объясняют, что нарушено и как исправить. Внутри этих границ у агента остаётся свобода реализации. 🔸 Откуда берётся технический долг Агент копирует и удачные, и неудачные паттерны. Повторяющиеся замечания можно превращать в правила и небольшие фоновые исправления. 🔸 Чем измерять результат Принятые задачи, время людей, дефекты и стоимость прогонов. А в эпилоге — Symphony и переход от ручного управления сессиями к координации задач. Если читать оригинальную статью, то команда оценивает ускорение примерно в десять раз. Это оценка авторов для нового внутреннего продукта, без контрольной группы; она не доказывает такой же эффект в существующей системе. Переносить отдельные механизмы стоит с проверкой на своих задачах. Материалы выпуска: 📌 Страница выпуска с таймкодами 📊 Слайды 📖 Лонгрид об эволюции агентных оболочек 🎬 YouTube, VK Видео 🎧 Podster, Яндекс Музыка, Apple Podcasts 📝 Текстовый конспект Если вы уже перестраивали репозиторий под агентов, расскажите, где оказался главный пробел: в знаниях, инструментах или проверке результата? #AI4SDLC #Agents #Engineering #PlatformEngineering #ResearchInsights

Паша и папа (Рубрика #ForKids) Вместе с младшим сыном, Кириллом, прочитали эту книгу с зарисовками из жизни обычной семьи, где есть детсадовец Паша, а также мама и папа. Мне книга очень понравилась - в ней мама в отличие от других книг почти не присутствует и мы видим чисто мужские взаимоотношения достаточно самостоятельного Паши и его папы. Перед нами пролетают картины посещения цирка или уборки дома, игры в работу и путешествий, болезни папы и готовки праздничного кекса для мамы. В общем, читать эту книгу очень приятно, рекомендую. P.S. Я купил эту книгу, потому что у меня старшего сына зовут Пашей, но я с ним не проводил так много времени - когда он был примерно в том же возрасте, что герой этой книги, мы с Пашиной мамой разошлись и мой Паша остался жить со своей мамой. Теперь вот с Кириллом наверстываю упущенное, а Паша уже вырос и учится в универе:) #ForParents #ForKids #Family