Книжный куб

Материалы Code of Leadership #86: AI-агенты и эффективность разработки (Рубрика #AI4SDLC) Готовы запись и конспект 86-го выпуска Code of Leadership от 22 октября 2026 года — «Агенты пишут код. Как понять, что разработка стала эффективнее?». Поговорили с Владимиром Долговым, создателем DevOptify, который ранее руководил AI-трансформацией разработки в Сбере. Кода стало больше, PR закрываются чаще, токены расходуются — а что из этого получает бизнес? На этом вопросе и построили разговор. Обсудили: 🔸 Что считать результатом Владимир рассказал, как в Сбере переходили от доли AI-кода к числу PR, а затем к выполненным задачам. Но и задачи можно просто нарезать помельче. Поэтому рядом нужны размер работы, ошибки и возвраты на доработку. 🔸 Как хороший график вводит в заблуждение Я привёл пример команды, которая сначала строила платформу, а потом делала на ней однотипные продуктовые изменения. Число закрытых задач выросло, но состав работы тоже изменился — это важно учитывать до объявления победы. 🔸 Почему с агентами приходится заново учиться планировать В команде Владимира сначала закладывали на задачи слишком много времени, затем качнулись в другую сторону и начали недооценивать сроки. На демо DevOptify посмотрели, как это видно в данных, вместе с параллельными задачами и переработками. 🔸 Где остаётся работа человека Агенту нужны контекст, инструменты и границы полномочий, а объём сгенерированного кода упирается в возможности ревью. Владимир рассказал о выборочной проверке человеком в своей команде; переносить эту практику на любой продукт без оговорок нельзя. 🔸 Что объясняют расходы на модели В одном из примеров большую модель использовали для массовой замены идентификаторов, с которой справилась бы команда IDE. Но высокая стоимость сама по себе ещё не говорит о плохой работе: задачи бывают разными. 🔸 Как сохранить доверие к аналитике Возвраты задач и ночная работа дают повод для разговора с инженером. Обсудили доступ сотрудника к тем же данным и возможность оспорить выводы руководителя — например, показать внеплановые задачи, из-за которых поехал первоначальный план. Важная оговорка к демо: на момент разговора результаты крупных пилотов DevOptify ещё ожидались. Владимир описал цикл проверки: собрать исходные данные, изменить работу и посмотреть, что получилось после. Материалы выпуска: 📌 Страница выпуска с таймкодами 🎬 Видео: YouTube и VK Видео 🎧 Аудио: Podster и Apple Podcasts 📖 Текстовый конспект А по каким изменениям в своей команде вы понимаете, что агенты действительно помогают? Особенно интересно, если метрики и ощущения расходятся. #CodeOfLeadership #AI4SDLC #Agents #Management #Metrics #DevTools

System Design Interview. Архитектурное мышление в Big Tech (Рубрика #SystemDesign) Я подписал договор с издательством «Питер» на издание своей книги «System Design Interview. Архитектурное мышление в Big Tech». В ней 35 глав о том, как разбирать задачу, задавать вопросы, замечать ограничения и объяснять свои архитектурные решения. Что делать, когда требования неполные, нагрузка растёт, а за надёжность и скорость приходится платить. В основе — мой семишаговый фреймворк system design interview, который мы внедрили и масштабировали в Т-Банке. Он проводит от условия задачи и уточнения требований до выбора технологий, эксплуатации и развития системы. Рядом — взгляд с другой стороны стола: что оценивает интервьюер, где кандидат теряет нить и как понять, что именно стоит потренировать. Большая часть практических разборов посвящена AI/ML: как обслуживать модели, строить RAG и корпоративных AI-ассистентов, проектировать агентов для кода, антифрод и рекомендации. С конкретными вопросами: где проверить права доступа, что делать при отказе модели, как оценивать качество и сколько стоит ответ пользователю. Ещё внутри есть отдельная глава с пробным интервью по RAG-платформе: диалог кандидата и интервьюера, уточнения, ошибки и схема, которая постепенно меняется по ходу разговора. А в конце каждой главы — карта, проверочный список и упражнение, чтобы попробовать рассуждать самому. Так что книга пригодится и тем, кто готовится к собеседованиям, и тем, кто их проводит, и инженерам, которым нужно обосновывать решения в своей системе. Можно будет пройти весь маршрут или выбрать задачу и проверить на ней свой подход. У меня будет 100 авторских экземпляров. Правда, готова книга будет уже после моего переезда в Лондон:) На приложенной картинке карта всех 35 глав: по ней уже можно посмотреть, что будет внутри, и выбрать, с чего хочется начать. #Books #SystemDesign #Architecture #AI #Engineering

3 AImigo S1E12: AI-дайджест октября 2026 / IPO Anthropic, новые модели и безопасность агентов (Рубрика #AI4SDLC) 30 октября, в пятницу, в 12:00 по Москве — новый выпуск 3 AImigo. Подводим итоги октября и обсуждаем, какие новости AI меняют работу инженерных команд. Anthropic подала заявку на IPO: разбираемся в выручке, убытках и обязательствах по вычислениям. Новые модели обещают более дешёвую работу, а расследования действий агентов заставляют внимательнее смотреть на их полномочия. 3 AImigo S1E12: AI-дайджест октября 2026 / IPO Anthropic, новые модели и безопасность агентов Обсудим: - IPO Anthropic: что раскрыла заявка и какие вопросы возникают к экономике AI. - Mythos 5 и другие инциденты: почему объяснить запрет и соблюдать его для агента могут оказаться разными задачами. - Terra, Sol, Sonnet 5.5 и Gemini 4 Argon: как меняются цены и что считать, кроме стоимости токенов. - Oracle, OpenAI, Cursor и GitHub: как AI встраивается в рабочие процессы. - Математика и биология: кто проверит результаты тысяч агентов. - Muse Spark Open и DeepSeek: что дают открытые веса и альтернативное оборудование. - и многое еще Ведущие: Александр Поломодов, Евгений Сергеев и Алексей Литвинов. Присоединяйтесь к эфиру и приносите вопросы. Какие новости октября уже повлияли на вашу работу, а какие пока остались только громкими анонсами? #AI #Agents #Product #Security #Engineering #Podcast

Andy Pavlo: что меняют AI-агенты в базах данных (Рубрика #Data) Что произойдёт, когда агенты начнут круглосуточно создавать базы, читать данные и что-то в них менять? Этому посвящено интервью Энди Павло у Мэтта Тёрка от 8 октября 2026 года. Павло — исследователь баз данных из Carnegie Mellon, а с августа ещё и руководитель ClickHouse Labs. В разговоре есть несколько интересных тем: 🔸 Нагрузка от агентов Павло прогнозирует рост числа запросов в 10–100 раз. Насколько изменится их сложность, он пока не знает. Это сценарий будущего, а не уже измеренный рост всего рынка. 🔸 Права и изоляция Агентам нужны ограниченные полномочия и отдельные ветки БД для экспериментов. По мысли Павло, привычные механизмы защиты данных здесь вполне применимы; вручную подтверждать каждое действие сотни агентов не получится. 🔸 Память агента За спором «файлы или база» он предлагает видеть гарантии хранения и обновления состояния. В качестве простого решения напоминает про SQLite. 🔸 Text-to-SQL Павло связывает качество с семантическим слоем и контекстом: агенту нужно знать, как из вопроса получить правильный запрос. 🔸 Автоматическая настройка По его приблизительной оценке, LLM может пройти 80–85% пути к хорошей настройке некоторых параметров за 15 минут. Сложные случаи остаются за специализированными методами. Методика этой оценки в интервью не раскрыта. 🔸 Сближение OLTP и OLAP Павло разбирает, зачем аналитическим платформам PostgreSQL и чем отличаются отдельные сервисы с передачей данных от двух движков над одной копией. Общий интерфейс ещё не определяет внутреннюю архитектуру. Кстати, одну из работ Павло мы уже разбирали в Research Insights Made Simple — статью "What Goes Around Comes Around… And Around…", написанную вместе с Майклом Стоунбрейкером. В августе 2025 года мы с Лёшей Светличным посвятили ей два выпуска: модели данных и языки запросов и архитектура систем. Это хороший обзор примерно двадцати лет развития БД. У авторов там две связанные мысли: SQL и реляционная модель продолжают вбирать идеи конкурентов, а устройство движков серьёзно меняется вслед за железом и нагрузками. Колонки, облака, разделение хранения и вычислений — за привычным SQL может оказаться совсем другая система. А 12 октября 2026 года мы с Колей Головым уже обсуждали современные платформы данных и четыре способа собрать данные для AI: через копии и витрины, федеративные запросы, универсальную СУБД или общий слой хранения. Здесь разговор Павло про объединение транзакций и аналитики хорошо дополняет нашу карту: за одной вывеской могут скрываться очень разные компромиссы по свежести, изоляции и стоимости. На эту тему я написал и подробный лонгрид. В нём пошёл дальше выбора движка: кто определяет смысл метрик, с чьими правами агент читает данные и как проверяется действие по результатам анализа. Посчитать клиентов, которым стоит дать скидку, и действительно назначить её — два разных инженерных задания. Можно начать с интервью, а за устройством платформ и историей этих компромиссов сходить в наши разборы. #Data #AI #Database #Architecture #ResearchInsights

Материалы 3 AImigo S1E11: AI-native государство (Рубрика #AI) Собрал материалы одиннадцатого выпуска 3 AImigo «AI-Native государство: что это и где граница», который вышел 23 октября 2026 года. Вместе с Евгением Сергеевым и Алексеем Литвиновым обсуждали, можно ли перенести идеи AI-native компании на государство. Удобно, когда AI помогает заполнить заявление. Гораздо сложнее, когда он сам решает, отказать вам или нет, — особенно если оспаривать отказ приходится у другого бота. Обсудили: 🔸 Чей результат мы улучшаем Цифровизация каждого ведомства по отдельности ещё не собирает удобный путь гражданина. Начали с опыта Евгения с электронными рецептами и дошли до вопроса, где вообще заканчивается аналогия государства с компанией. 🔸 Что нужно сверх подписки на помощника Подготовить документ и самостоятельно исполнить процедуру — разные задачи. Я разбирал, какая среда нужна агенту: данные, инструкции, полномочия, проверка результата и ответственность за последствия. 🔸 Как добраться до человека, который может исправить ошибку Обратимость решения и работающий путь пересмотра стали одной из центральных тем. Евгений рассказал, как агент помог его знакомому добиться пересмотра банковского отказа; человек следил за переговорами и корректировал помощника. Это частная история, а не доказательство, что агенты уже умеют побеждать бюрократию. 🔸 Кому выгодна сложная форма Алексей использовал закон Хайрама как аналогию: вокруг неудобной процедуры вырастают роли и зависимости. Если только один человек умеет правильно заполнить форму, её упрощение меняет и его положение. Тут одного хорошего интерфейса мало. 🔸 Насколько быстро всё это может измениться Поспорили об инициативе сотрудников, поддержке руководства, государственных данных и зависимости от AI-поставщиков. Я скорее ожидаю постепенного продолжения цифровизации; Алексей предлагает не недооценивать возможность большого скачка. Общего прогноза у нас не получилось. Материалы выпуска: 📌 Страница выпуска с таймкодами и лонгрид об AI-native государстве 🎬 Видео: YouTube и VK Видео 🎧 Аудио: Podster и Apple Podcasts 📖 Текстовый конспект Какую государственную процедуру вы бы поручили агенту — и где оставили бы обязательную возможность поговорить с человеком? #AI #Agents #Management #Architecture #Podcast

Harness на Giga Conf: материалы выступления (Рубрика #AI4SDLC) Собрал материалы моего доклада на Giga Conf 16 октября — «Harness: прошлое, настоящее и будущее слоя между моделью и миром». Есть запись, слайды и большой лонгрид на эту тему. Про инструменты, память, контекст и проверки я рассказывал много. Здесь собрал их в одну картину вокруг вопроса: что из построенного нами всё ещё нужно после выхода следующей модели? Моя опора в докладе — метафора words & walls. Есть инструкции, которыми мы компенсируем слабости конкретной модели: как вести план, когда перечитывать файл, как проверять свою работу. Их пользу после обновления модели стоит проверять заново. А есть права доступа, изоляция и запреты на действия — границы, которые должны исполняться кодом при любой модели. Умение хорошо решать задачу само по себе не даёт разрешения на её выполнение. В докладе разбираю: 🔸 Как менялась обвязка От цикла в промпте до готовых агентных продуктов и управляемого исполнения. Какие функции переезжают в модель и API, а какие остаются в среде. 🔸 Что мы вообще выбираем Готовый «комбайн» для работы, отдельного агента или SDK, из которого собираем свою систему. И почему у похожих инструментов могут сильно различаться настройки доступа и исполнения по умолчанию. 🔸 Как доказать пользу компонента Убрать его в отдельном эксперименте и сравнить результаты на своих задачах. Для этого полезен реестр: какое предположение о модели мы заложили, чем его проверяем и когда пересматриваем. 🔸 Что измерять Повторяемость успеха и цену принятого результата с учётом проверки и переделок. Один удачный прогон ещё мало говорит о том, как агент будет работать каждый день. 🔸 Куда всё движется Мои гипотезы про агентов со своей машиной, памятью и идентичностью, а также перенос исполнения и проверки действий к вендору. У каждой ставки есть условие, при котором её придётся пересмотреть. И важная оговорка: пересматривать стоит именно компенсирующие инструкции. Требования к задаче, критерии готовности и знания о проекте от смены модели никуда не исчезают. P.S. Я уже писал про это выступление и обещал сделать расширенный выпуск на эту тему, если там наберется 100 🔥 под постом, пока там их всего 70, но все в ваших руках. #AI4SDLC #Agents #Engineering #Security #Conference

Макс Канат-Александер: нужно ли качество кода, который можно заменить? (Рубрика #AI4SDLC) У Max Kanat-Alexander из Capital One вышел доклад «Does Code Quality Still Matter?», который хорошо продолжает тему моего keynote на DotNext: что происходит с инженерией, когда реализацию становится проще сгенерировать заново, чем поддерживать годами? Макс начинает с того, зачем вообще нужно качество кода: чтобы понимать фактическое поведение системы и безопасно его менять. Каждое изменение может и сломать что-то сейчас, и усложнить следующие изменения. Во втором случае проблемы с пониманием начинают накапливаться. Дальше он предлагает шкалу от disposable до durable software. На одном конце — программа для организации одной вечеринки. На другом — система, от которой годами зависят люди и бизнес. Положение на шкале определяют четыре вещи: последствия отказа, стоимость замены, зависимости и стоимость сопровождения. Для первого случая, считает Макс, качество кода может не иметь значения. Для второго инженерная дисциплина остаётся необходимой. Причём заменяемость можно повышать намеренно: изолировать окружение, ограничивать зависимости и область применения, оставлять надёжный запасной путь. А саму дисциплину — удешевлять общими стандартами, автоматическими проверками и удобной тестовой инфраструктурой. И вот здесь я бы отдельно развёл срок жизни системы и срок жизни её реализации. На DotNext я развивал идеи Чада Фаулера из книги "Regenerative Software". Система может жить десятилетиями, а код отдельных компонентов — регулярно заменяться. Для этого накопленное знание должно переживать очередную генерацию: — намерение и инварианты: что система обещает и чего нельзя нарушать; — архитектурные границы и контракты: что именно можно заменить независимо; — проверки поведения: как понять, что новая версия выполняет обещания; — причины решений: почему здесь ограничены ретраи, оставлена странная проверка или выбран именно такой порядок действий. Это для меня и есть важная часть regenerative software development. Мы заранее создаём условия, при которых реализацию можно выбросить, сохранив поведение и понимание системы. Одна папка с Markdown сама по себе такой способности не даёт :) Дешевизна генерации ещё не означает дешевизну безопасной замены. Платёжный компонент можно переписать за вечер, но от этого не исчезнут требования к округлению, повторным запросам и совместимости. Возможность быстро получить другой код закрывает только часть задачи. В зрелой системе сначала придётся извлечь то, что знает только старая реализация: неявные бизнес-правила, следы инцидентов, зависимости соседей. Затем защитить это проверками, менять компоненты по частям и сохранять возможность отката. Пока знание живёт только в коде, удаление кода уничтожает и часть знания. Поэтому в тезисе Макса про удешевление инженерной дисциплины я вижу прямую связь со своим докладом. Общие проверки и инфраструктура снижают стоимость каждой следующей замены. А качество архитектуры можно проверять очень предметно: какой компонент мы способны пересоздать сегодня и чем докажем, что система сохранила нужное поведение? #AI4SDLC #Engineering #Architecture #Software #AI #Conference

Материалы Research Insights #42: Оценки агентов: как понять, что агент справился (Рубрика #AI4SDLC) Собрал материалы сольного Research Insights Made Simple #42 от 21 октября 2026 года. В основе — руководство "Anthropic Demystifying evals for AI agents". Агент написал «готово», но появилась ли бронь, изменился ли нужный файл и выполнены ли условия задачи? В выпуске разобрал: 🔸Итог и путь к нему Результат проверяем в среде, а траекторию читаем, чтобы понять причины успеха или сбоя. Оценивать нужно модель вместе с обвязкой, инструментами и настройками. 🔸Кто проверяет проверяющего Код удобен для точных условий, модельный судья — для открытых ответов, человек — для экспертной оценки и калибровки. У каждого способа есть ограничения; низкий балл может означать ошибку в самой проверке. 🔸Разницу между pass@k и pass^k Найти хотя бы одно решение за несколько попыток и успешно пройти все попытки — разные требования к продукту. Одной хорошей демонстрации для стабильной работы мало. 🔸С чего начать В руководстве предлагается небольшой набор из 20–50 реальных задач: ясные критерии, эталонные решения, отрицательные примеры и чистая среда. История предыдущего прогона не должна подсказывать ответ следующему. 🔸Что делать после релиза Регрессионные проверки дополняются мониторингом, экспериментами и обратной связью пользователей. Ни один набор оценок не ловит все проблемы; траектории нужны и для поиска дефектов задач и проверяющих. Рекомендую тем, кто уже умеет запускать агента и теперь хочет обоснованно решить, можно ли отдавать ему работу. Материалы выпуска: 📌 Страница выпуска с таймкодами и слайды выпуска 📖 Лонгрид об эволюции агентных обвязок 🎬 Видео: YouTube и VK Видео 🎧 Аудио: Podster и Apple Podcasts 📖 Текстовый конспект и аннотированная мной PDF'ка (где я свои мысли на полях фиксировал при чтении) Был ли у вас случай, когда ошибался тест, а решение агента оказывалось правильным? Приносите примеры. #ResearchInsights #AI4SDLC #Agents #Evals #Engineering

Материалы Research Insights #41: Анатомия агента: семь обязанностей обвязки (Рубрика #AI4SDLC) Доступны материалы сольного Research Insights Made Simple #41 от 20 октября 2026 года. Разобрал исследование исходников одиннадцати систем "Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents - A Source-Code Study of Eleven Systems": короткий цикл вызова модели уже умеет делать полезную работу, но вокруг него быстро вырастает целый продукт. В выпуске разобрал: 🔸 Семь обязанностей обвязки Цикл работы, интеграция с моделью, инструменты, контекст, безопасность, координация и расширения. Такая карта помогает сравнивать архитектуру и находить, где именно спрятана сложность. 🔸 Почему общего API мало Форматы правок, кеширование и инструкции различаются между моделями. Поддерживать совместимость приходится постоянно; большой каталог инструментов заодно создаёт задачу их поиска и загрузки в контекст. 🔸 Что именно мы откатываем Возврат к прошлому сообщению не обязательно возвращает файлы в прежнее состояние. История сессии, рабочая копия и долговременная память решают разные задачи — и требуют разных правил восстановления. 🔸 Как разделить разрешение и изоляцию Согласие пользователя на действие ещё не определяет, к каким файлам и сетевым ресурсам получит доступ процесс. При подключении субагентов добавляются вопросы передачи истории, инструментов и результатов. 🔸 Как проверять красивые архитектурные идеи MCP, навыки и хуки дают разные способы расширения. Небольшая выборка систем не устанавливает победителя, а чтение исходников не измеряет качество решения задач. Предлагаю брать из атласа гипотезы и проверять их на своей работе. Полезный выпуск, если за словом «агент» хочется видеть конкретные механизмы. Возможности отдельных продуктов меняются быстро; в разборе речь идёт о срезе версий, выбранном авторами исследования. ъМатериалы выпуска: 📌 Страница выпуска с таймкодами и слайды выпуска 📖 Лонгрид об эволюции агентных обвязок 🎬 Видео: YouTube и VK Видео 🎧 Аудио: Podster и Apple Podcasts 📖 Текстовый конспект и аннотированная мной PDF'ка (где я свои мысли на полях фиксировал при чтении) Какая часть обвязки сейчас приносит вам больше всего проблем: контекст, инструменты, восстановление или права? #ResearchInsights #AI4SDLC #Agents #Architecture #PlatformEngineering

Приятно, когда утро начинается с таких видов:)

Agentic Engineering — Addy Osmani (Рубрика #Books) В самолёте по пути на Мальдивы прочитал "Agentic Engineering" Addy Osmani. Книга ещё в раннем доступе: в моей версии пять глав из восемнадцати запланированных. И уже много узнаваемого. Османи удачно собирает в одну картину вещи, которые постепенно обнаруживаешь в работе с агентами: код появляется всё быстрее, а вопросов к собственной работе становится больше. Особенно зацепила глава про спецификации. Когда писать код становится дёшево, всё важнее понять, что именно нужно сделать. У меня с Spec Kit это регулярно происходило буквально по ходу уточнений: начинаешь с вроде бы понятной просьбы, агент задаёт вопросы, и выясняется, что задача сложнее, а результат нужен немного другой. Пока формулируешь требования, успеваешь пересмотреть собственный замысел. Вот в этом смысле спецификация для меня стала инструментом мышления. Например, «добавить PDF-вложения на сайт» с аннотированными разборами whitepaper. Звучит как кнопка скачивания. А дальше: храним копию или ссылку? Как убедиться, что документ тот самый? Что произойдёт при повторном импорте? Можно ли считать перенос завершённым, если страница открывается, а файл недоступен? Постепенно за кнопкой обнаруживается целый процесс переноса публикации, в котором ничего не должно потеряться. Кнопка там тоже будет :) Конечно, агент может сам написать красивую спецификацию, план, код и отчёт о том, что всё выполнено. Поэтому ценность всей этой работы я вижу в моментах, когда приходится сказать: «Я этого не учитывал» или «Такую сложность я не готов принимать». Если после уточнений решили половину не делать — тоже полезный результат. Хочется только, чтобы с каждым новым запуском не приходилось заново объяснять всё, до чего уже додумались. И здесь мне близок разговор Османи про harness — среду работы агента с её инструментами, контекстом и проверками. Я смотрю на неё как на место, где может накапливаться опыт команды. Почему приняли архитектурное решение, как выполнять повторяющуюся задачу, какую ошибку теперь ловит тест — всё это остаётся доступно следующему исполнителю. Правда, с формулой «каждая ошибка становится правилом» хочется поспорить. Так можно собрать внушительную коллекцию запретов, в которой уже никто не разберётся. Иногда полезнее исправить инструмент или удалить устаревшую подсказку. Мне нравится сама идея превращать опыт в условия работы, но за этой средой тоже придётся ухаживать. С несколькими агентами цена таких договорённостей становится ещё заметнее (особенно, если агенты из разных лагерей, навроде, Claude, Codex, Cursor и Open Code с китайскими модельками). Пока исполнитель один, многое можно удерживать в голове и поправлять по ходу. А если один делает импортёр, другой — отображение документов, им придётся заранее договориться, что они передают друг другу. Иначе оба закончат работу, а соединять два разных понимания задачи придётся тебе. Здесь согласен с Османи: самостоятельность агента и умение координировать нескольких — разные вещи. Можно далеко отпускать одного исполнителя или внимательно следить за несколькими. Само количество запущенных окон ещё ничего не говорит: легко получить очередь изменений, которую уже не успеваешь осмыслить. Код пишется, а ты разбираешь вопросы, переключаешься между задачами и проверяешь чужие решения. Работы руками меньше, решений в единицу времени — больше. Особенно интересно дождаться глав про цену оркестрации и три вида долга: технический, когнитивный и долг намерения. По первым главам книга точно передаёт знакомое ощущение: возможностей стало больше, а простоты почему-то не прибавилось. Любопытно, как Османи разовьёт этот разговор дальше. #Books #AI4SDLC #Agents #Engineering #Management

Материалы Research Insights #40: Anthropic: что остаётся человеку в компании агентов (Рубрика #Management) Готовы материалы сольного выпуска Research Insights Made Simple #40 от 19 октября 2026 года. Разобрал исследование "How employment is changing at Anthropic" о работе внутри Anthropic: агенты производят всё больше, а человеку ещё нужно понять, что из этого принимать, чему учиться и куда двигаться дальше. В выпуске разобрал: 🔸 Что показывают измерения Авторы сопоставляют использование AI, найм и результаты работы. Это наблюдение внутри быстро растущей компании: оно не доказывает, что именно агенты вызвали все изменения, а объём кода сам по себе не измеряет пользу. 🔸 Куда уходит человеческое внимание По расчёту авторов, чтение всего агентского вывода не поместилось бы в рабочую неделю инженера. Люди отвечают на это инструкциями, проверками и инструментами наблюдения. Руководить работой агентов приходится и тому, кто раньше был индивидуальным специалистом. 🔸 Где новичку набирать опыт Если простые задачи уже забрали агенты, откуда возьмётся понимание, необходимое для проверки сложных решений? Готового ответа в выпуске нет; обучение нужно проектировать вместе с автоматизацией. 🔸 Что получает сотрудник Обсуждаю переходы в новые роли, время на обучение и участие в выгодах. Возможности растущей Anthropic нельзя автоматически переносить на компанию, где следующей роли для человека просто нет. Особенно рекомендую тем, у кого разговор об AI пока заканчивается количеством сгенерированного кода. Здесь он только начинается. Материалы выпуска: 📌 Страница выпуска с таймкодами и слайды выпуска 🎬 Видео: YouTube и VK Видео 🎧 Аудио: Podster и Apple Podcasts 📖 Текстовый конспект и аннотированная мной PDF'ка (где я свои мысли на полях фиксировал при чтении) Как у вас меняются обучение и ответственность людей, когда часть работы переходит агентам? #ResearchInsights #AI #Agents #Management #Engineering

Сегодня пришло письмо от 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. Жене и младшему сыну тоже подтвердили визу, а для среднего попросили подгрузить еще документов - так что история с визами пока закончена не до конца (но есть ощущение, что после подгрузки доп. документов все будет ок). Ну и пока план оказаться в Лондоне во второй половине ноября:)

Агенты пишут код. Как понять, что разработка стала эффективнее? | 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