Книжный куб

Материалы AMA с подписчиками «Книжного куба» (Рубрика #AI4SDLC) Готовы материалы с AMA-сессии, которая прошла 23 августа. Вопросов было много, поэтому за полтора часа мы успели пройти путь от выбора следующей книги до ответственности за действия автономного AI-агента. Мы обсудили: - Как выбирать книги от текущего вопроса и превращать чтение в заметку, схему, эксперимент или решение; - Как устроены 6D, личная система знаний и переход от материалов к навыкам в System Design Space; - Зачем нужны пет-проекты и почему короткая петля обратной связи важнее их масштаба; - Вход в IT, рост лидера, завершение десятилетнего карьерного этапа и следующий шаг; - SDD, детерминированные проверки и ответственность за AI-код; - Экономику агентной разработки и сценарии AGI/ASI — без обещаний даты. Все материалы выпуска: - Страница выпуска - Видео: YouTube, VK Видео - Аудио: Podster, Яндекс Музыка - Текст: краткая расшифровка Спасибо всем за вопросы и живое обсуждение. Если после просмотра появились новые — пишите в комментариях: соберу их для следующей AMA или отдельных постов. #AI4SDLC #Engineering #Leadership #Career #Architecture #Management

Harness Engineering is not Enough: Why Software Factories Fail (Рубрика #AI4SDLC) Dex Horthy - отличный спикер и я посмотрел его очередной доклад. В предыдущих сериях сооснователь HumanLayer предлагал лечить AI-slop через context engineering и цикл Research → Plan → Implement (доклад "No Vibes Allowed"). А в разборе "The New SDLC" у нас появилась формула Agent = Model + Harness. В новом 19-минутном keynote с AI Engineer World's Fair 2026 Dex ставит к этой формуле важную сноску: хорошая обвязка резко улучшает исполнение, но сама по себе не учит модель сохранять качество архитектуры на длинной дистанции. Это достаточно интересный и местами отрезвляющий разбор текущего состояния AI-разработки. Но независимым обзором его назвать нельзя. Horthy — сооснователь HumanLayer, компании, которая продаёт AI IDE и инструменты для совместной работы людей и кодинг-агентов. В письменной версии Dex сам предупреждает о возможной предвзятости, а в финале доклада прямо предлагает продукт. То есть перед нами содержательный отчёт практика-провайдера, а не нейтральное исследование рынка. При этом он не сводит метод к своему продукту: для ревью документов прямо называет GitHub, Notion и Plannotator. Отправная точка — lights-off software factory. Агент пишет код, другие агенты рецензируют изменения и прогоняют regression tests, инциденты и обратная связь пользователей сразу попадают в очередь, а человек перестаёт читать изменения. По рассказу Dex, в июле 2025 года HumanLayer попробовала именно такой режим. Через несколько месяцев команда столкнулась со сложной проблемой, которую агенты не смогли исправить: во время инцидента с недоступностью сайта пришлось разбираться в кодовой базе, за развитием которой люди уже не следили. Это ретроспективный рассказ Horthy о собственной команде без независимых данных, но почти учебный пример потери понимания из моего разбора Loop Engineering. Почему, по версии Horthy, очередной loop здесь не спасает? На примере SWE-bench Multilingual он показывает test-based оценку: исправлена ли задача, прошли ли новые тесты и не сломались ли старые. По его гипотезе, похожий reward signal не штрафует модель за лишний try/catch, сомнительный cast или shotgun surgery, когда одно изменение расползается по всей системе. Цена плохого program design проявляется через месяцы, а короткий эпизод обучения её просто не видит. Важно, что Dex честно обозначает границу своего аргумента: доказать деградацию maintainability он не может, потому что хорошего бенчмарка для неё пока нет. Появляются long-horizon evals, а Frontier Code использует multi-PR tasks, но, по его оценке, model-as-a-judge ещё не превращает архитектурное качество в надёжно измеримый сигнал. Предложение автора — не отказаться от агентов, а «включить свет» и перенести человеческое суждение в начало процесса: 1️⃣ Product requirements: какую проблему решаем, для кого и как поймём, что результат полезен; 2️⃣ System architecture: контракты компонентов, модели данных и ограничения; 3️⃣ Program design: типы, сигнатуры методов, раскладка кода и call stacks; 4️⃣ Vertical slices: порядок реализации и проверяемые сквозные куски вместо огромного горизонтального плана. Небольшие задачи по-прежнему можно отдавать агенту напрямую. Для крупных Dex предлагает согласовывать решения до реализации, затем читать код и проверять результат по частям. Его практическая оценка — около 30 минут предварительного согласования могут сэкономить часы review; это опыт команды, не результат эксперимента. И здесь коммерческий интерес снова виден очень хорошо: рецепт явно рифмуется с workflow HumanLayer — Questions → Research → Design → Structure → Plan → Implement. Но полезную границу это не отменяет. Harness помогает агенту лучше выполнить сформулированную задачу; он ещё не заменяет архитектурный вкус, ментальную модель системы и ответственность за то, каким код станет через полгода. #AI4SDLC #AI #Agents #Architecture #Evals #Engineering

Через пару минут стартует прямой эфир с Сережей Бережным из Yandex. Мы поговорим про карьеру Сергея и обсудим вопросы - Зачем бизнесу DevRel и чем измерять его результат; - Почему внутреннюю технологию стоит открывать миру и как выбирать проекты для open source - Как разработка проходит путь от автодополнения к AI-агентам и harness-системам; - Что происходит с ролью руководителя, когда частью команды становятся агенты; - Кого и чему учить, если привычные entry-level задачи всё чаще забирает AI. #CodeOfLeadership #DevRel #OpenSource #AI #Leadership #Education

Research Insights Made Simple #28: дата-платформа в 2026 году — от DWH к Lakehouse и AI-агентам (Рубрика #Data) Совсем забыл, что сегодня в 16:00 будет эфир про дата-платформы и он будет продолжать тему из шестого выпуска Research Insights Made Simple, где мы с Николаем Головым разбирали, как строить дата-платформы в 2025 году. А 28-м выпуске мы возвращаемся к теме с вопросом посложнее: что происходит, когда аккуратная схема из storage, compute, catalog и orchestration встречается с legacy, стоимостью миграции и реальными аналитическими запросами? В гостях опять Николай Голов вместе с Александром Филатовым. Николай — директор по продукту Tengri Data, в прошлом руководитель дата-платформ в Avito и ManyChat и преподаватель Harbour.Space. Александр пришёл в DWH из backend-разработки: до этого писал инструменты обработки данных на Python и C++. Почти десять лет он развивал хранилище данных Авито, в 2022–2025 годах занимался переходом с Vertica на Trino/Iceberg/S3, а теперь возглавляет разработку Tengri Data. Поговорим о том: - Где проходит граница между OLTP и OLAP, почему аналитика на реплике быстро упирается в потолок и отчего «давайте просто прикрутим ClickHouse» — ещё не архитектура; - Как профиль чтения и записи меняет устройство системы и почему инженеру важно отличать то, что аналитик просит, от того, что ему действительно нужно; - Когда классическое MPP-хранилище становится тормозом и что на практике даёт разделение storage и compute в Lakehouse; - Как переехать на новый стек, не остановив аналитику: параллельные контуры, проверка результатов, стоимость и эксплуатационные риски; - Что AI-агенты меняют в требованиях к платформе — от метаданных и прав доступа до прозрачности действий и контроля ресурсов; - Нужна ли в итоге отдельная AI-native дата-платформа или хороший фундамент остаётся тем же. Хочется уйти от каталога модных технологий и разобрать инженерные компромиссы: когда миграция действительно нужна, чем за неё придётся заплатить и какие решения выдерживают не только презентацию, но и production. #Data #DataEngineering #Databases #Architecture #PlatformEngineering #AI

Omer Primor про CaaS: где заканчивается аренда контекста (Рубрика #AI) У контекста для агента есть неприятная бухгалтерия. Пока вопрос разовый, AI-поиск выглядит как обычный API: спросили, получили ответ, пошли дальше. Но если каждый день проверять одни и те же компании, вакансии и цены, счётчик запускается заново — даже когда ничего не изменилось. В какой-то момент мы арендуем уже не ответ. Мы арендуем способность системы помнить. Именно эту границу разбирает Omer Primor из Bright Data в докладе «The Rise of CaaS: Context-as-a-Service for Agentic AI» с AI Engineer World’s Fair 2026. Название похоже на ещё один "-aaS", но вопрос внутри вполне взрослый: когда агенту достаточно покупать контекст, а когда его пора собирать, обновлять и хранить самому? Тема уже появлялась в разборе Hands-On RAG for Production, где retrieval из одного паттерна постепенно вырастал в платформенный слой. Primor добавляет к архитектуре экономику: кто платит за обновление знаний и у кого остаётся накопленный актив. Его отправная точка — веб не снимок. По показанному в докладе анализу Bright Data, данные социальных сетей могут терять актуальность меньше чем за сутки, а новости, финансовая и retail-информация — в основном за 30 дней. Это внутренний анализ компании, а не универсальный закон. Но сама проблема понятна: один раз найти страницу недостаточно, если агенту важно знать, как менялись цена, вакансии или состав компании. CaaS в описании Primor больше похож на вертикальный поиск и платформу данных. Такой сервис заранее собирает источники, нормализует и дедуплицирует сущности, связывает их в граф и отдаёт агенту контекст через API, CLI или MCP. Плюс — структура и быстрый старт. Ограничение встроено туда же: если нужного поля нет в модели данных сервиса, агент не сможет выколдовать его запросом. А дальше частота запросов приводит к огромному счету. В модели с оплатой за запрос повторное обращение стоит как первое, даже если с прошлого раза ничего не изменилось. По наблюдению Primor, на масштабе команды начинают незаметно резать уже не расходы, а ценность: проверять компанию раз в неделю вместо раза в день, брать десять результатов вместо полного набора или вообще не задавать дорогой вопрос. Цена становится ограничителем свежести — и никто ещё не назвал это архитектурным решением. Чтобы показать механику, команда Bright Data провела небольшой тест. Карточку из 25 полей проверили на 100 компаниях-спонсорах конференции и сравнили AI-поиск, несколько CaaS и прямой сбор из известных источников. Primor сразу называет это тестом, а не benchmark. Покрытие оказалось близким, но некоторые CaaS уступили поиску на выбранных полях: сервис знает только то, что решил собирать. При этом сам докладчик оговаривает, что у этих платформ могут быть другие данные и преимущества, которые тест просто не измерял. Для собственного варианта команда использовала готовые источники Bright Data и два специально собранных скрейпера. По словам Primor, демонстрационный конвейер занял около дня. Затем он условно оценил полноценную настройку в неделю и $5 000 — при таких допущениях пересечение получилось чуть выше 15 000 сущностей или запросов. Красивое число, но переносить его в закупочную таблицу я бы не стал. Primor тут же допускает и 10 000, и 30 000, и 100 000: всё зависит от сценария. К тому же он представляет Bright Data, а «самостоятельный» путь собран на инструментах той же компании. За рамкой расчёта остаются поддержка скрейперов, полноценное сопоставление сущностей (entity resolution), контроль качества, юридические ограничения, наблюдаемость и дежурства. Собственный конвейер особенно дёшев на слайде. В жизни первый редизайн сайта-источника быстро добавляет в формулу людей и кофе :) Поэтому я бы выбирал не по магической отметке 15 000, а по пяти вопросам: — Как часто повторяется запрос? — Как быстро устаревают данные? — Насколько стабильны сущности и схема? — Сколько стоит неверный или несвежий контекст? — Во что обходится владение всем конвейером? Мой базовый вариант здесь — гибрид. Разовые вопросы и неизвестные заранее источники остаются у AI-поиска или CaaS. Частые запросы к понятным сущностям и полям уходят в собственный сбор, нормализованное хранилище и инкрементальные обновления. Внешний поиск остаётся резервом для пробелов, а не обязательным шагом каждого запуска агента. Это та же граница «арендовать — адаптировать — оставить своим», о которой я писал в лонгриде про AI-стек. Только считать здесь полезнее не цену одного запроса, а стоимость принятого результата с нужной свежестью. Практический следующий шаг простой: взять один повторяющийся сценарий, посчитать частоту, требования к свежести, цену ошибки и полный TCO. А потом ответить на более интересный вопрос: в какой момент ваш агент перестаёт искать и начинает обслуживать собственный продукт данных? #AI #Agents #Architecture #Data #PlatformEngineering #FinOps

Материалы со второго выпуска подкаста "3 AImigo" (Рубрика #AI) Наша вторая серия о том, где сейчас находится AI-разработка вышла интересной. Мы разбирались с парадоксом, который всё чаще встречается в командах: AI заметно ускоряет отдельного инженера, кода становится больше, а до пользователей доходит примерно столько же изменений. Локальная скорость не равна принятому результату — и размер компании от этого не защищает. Мы обсуждали ее втроём: Евгений Сергеев, Алексей Литвинов и я, а ниже представлены материалы выпуска - Страничка эпизода - Видео: YouTube, VK Video - Аудио: Podster, Яндекс Музыка - Текст: Краткая расшифровка P.S. У Леши есть свой канал в tg @tip_podcast и на Youtube, а у Жени пока нет:) #AI #Management #Processes #Engineering #Software #AI4SDLC #Software #Agents #Leadership

Эфир стартовал, если кто-то планировал заглянуть на него, то самое время подключиться. Если кто-то предпочитает vk, то там теперь тоже есть прямой эфир.

Code of Leadership S2E13: AMA с подписчиками: чтение, карьера, пет-проекты и AI-разработка (Рубрика #SelfDevelopment) Вы прислали столько хороших вопросов, что из комментариев получилась программа отдельного эфира. 23 августа в 16:00 МСК выйду в прямой эфир на YouTube и отвечу на вопросы подписчиков «Книжного куба» (в этот раз попробую параллельно стримить на своем VK канале) Поговорим о том: - Как я выбираю книги, читаю несколько материалов параллельно и работаю со сложными white papers; - Как устроен путь от найденного источника до поста, схемы, лонгрида или эфира и нужна ли для этого отдельная база знаний; - Как превратить знания в навык и куда развивается System Design Space; - Зачем мне пет-проекты и что AI изменил в greenfield-разработке; - Что советовать школьникам и джунам и как лидеру перейти на следующий масштаб; - Чем уход с топ-менеджерской позиции отличается от обычного увольнения и что будет дальше; - Где проходит граница автономности AI, кто отвечает за AI-код и как считать реальный эффект для компании. Можно будет задавать дополнительные вопросы в чате трансляции. Запись останется. #AMA #Engineering #Leadership #Career #AI4SDLC #SystemDesign

Стратегия разработки (Crafting Engineering Strategy) — Уилл Ларсон (Рубрика #Books) Про книги Will Larson я пишу регулярно и у меня есть целая серия постов: "Staff Engineer" — влияние без менеджерской должности, "An Elegant Puzzle" — инженерная организация как система, "The Engineering Executive's Primer" — работа технического топ-менеджера. Четвертая книга, «Crafting Engineering Strategy», связывает эти уровни одним вопросом: как принимать сложные решения и проводить их через организацию. Перевод на русский скоро выйдет, а оригинал на английском появился еще в октябре 2025 года (а многие главы я читал еще в виде отдельных постов в блоге автора) Сама книга охватывает стратегию инженерной организации — от архитектуры и миграций до найма, затрат и внедрения LLM. И эта тема важна даже в наше время, когда многие не готовы декларировать стратегию и говорят, о том, что планирование идет на короткий срок - даже в этом случае стратегия в компании все равно есть. Если она не записана, то живет в повторяющихся решениях, устных договоренностях и памяти старожилов — с разными трактовками и потерянным контекстом. Письменная стратегия у Ларсона делает решения видимыми, обсуждаемыми и улучшаемыми. В книге пять частей и 25 глав. Сначала — зачем нужна стратегия, кто может ею заниматься и когда ее документировать. Затем пять шагов: исследование → диагностика → проработка → направляющая политика → операционные механизмы. Дальше идут тестирование стратегии, системное моделирование и карты Уордли; десять реальных кейсов про миграции, LLM, Private Equity, данные, архитектуру, API и поглощения; наконец, оценка стратегии и развитие навыка. Что в книге особенно хорошо работает: 🔸 Диагноз раньше решения Сначала данные и противоположные точки зрения, потом выбор курса. Иначе стратегия превращается в любимое решение автора, которому задним числом придумали проблему. 🔸 Дисфункция — часть диагноза, а не список виноватых Это Ларсон умеет описывать особенно корректно. Неприятную реальность нельзя выкинуть, но документ не должен становиться обвинительным заключением. Частая смена позиции руководства превращается в условие: нужно быстро показать конкретный прогресс и удержать поддержку, иначе стратегия, вероятно, провалится. Если люди не используют новый инструмент, Ларсон предлагает сначала искать лишнее трение и плохую эргономику. Собственные прошлые решения тоже честно включаются в диагноз. 🔸 Сначала маленькая работающая ставка Автор советует вести одновременно одну-две стратегии, дешево проверять небольшой элемент и только потом расширять охват. В Uber команда не стала начинать с большой программы декомпозиции Python-монолита, а сначала упростила развертывание сервисов и проверила этот шаг на практике. Ларсон не проповедует медлительность — он ускоряет обучение и уменьшает цену ошибки. В общем, это почти практическое описание реализации поговорки «тише едешь — дальше будешь», только с обратной связью и метриками. 🔸 Политика должна дойти до практики Нужны явный выбор и подходящие к контексту операционные механизмы: например, правила исключений, автоматизация, метрики или регулярная проверка. Качество стратегии Ларсон предлагает оценивать по скорости следующей итерации, ее стоимости для организации и реальному влиянию. Методика выросла прежде всего из опыта Ларсона в Stripe, Uber и Calm, и в других организационных культурах ее придется адаптировать. Сильнее всего книга работает для Staff+ инженеров, архитекторов, техлидов и руководителей, которым нужно проводить межкомандные изменения. В предыдущих книгах Ларсон разбирал влияние Staff+ инженеров, системы engineering management и работу топ-руководителя. Здесь все три уровня сходятся в одном принципе: хороший курс можно дешево проверить, скорректировать и действительно провести через организацию. Вот этот спокойный подход я бы и назвал главной силой книги. #Books #Engineering #Management #Leadership #Architecture #Software

Материалы про то как выстроить собственную систему управления с Михаилом Тюргановым (Рубрика #AI4SDLC) В начале недели мы с Мишей обсудили его карьерный путь и как меняется CTO, когда небольшая команда вырастает в организацию на тысячи человек? И что делать, если прежние методы сами становятся ограничением? И теперь готовы все материалы по этому прямому эфиру - Страничка выпуска - Видео: YouTube, VK Video - Аудио: Podster, Яндекс Музыка - Текст: Краткая расшифровка #Management #Leadership #Engineering #Architecture #PlatformEngineering

llm-d: как KV-cache стал состоянием всего кластера (Рубрика #AI) У архитектурных идей бывает два дня рождения: сначала paper показывает, что приём работает, потом кто-то превращает его в систему, которую можно развернуть и сопровождать. Доклад Cong Liu из Google и Maroon Ayoub, работавшего тогда в IBM Research, на PyTorch Conference 2025 — как раз про второй случай. llm-d не изобрёл Prefill/Decode disaggregation. Он пытается сделать из исследовательского паттерна управляемый production stack. Слайды доклада здесь Это продолжение истории PagedAttention и vLLM, где KV-cache перестал требовать непрерывного куска памяти внутри одного inference engine. Здесь меняется уже единица оптимизации: prefill, decode и сам KV-cache становятся ресурсами всего кластера. - Prefill обрабатывает prompt целиком, строит KV-cache, упирается прежде всего в вычисления и определяет time to first token - Decode выпускает токены последовательно, сильнее зависит от пропускной способности памяти и определяет задержку между токенами - В одном сервере тяжёлый prefill мешает равномерному decode, а обе фазы получают одну конфигурацию железа и parallelism. llm-d разносит их по разным пулам - Scheduler выбирает decode worker с учётом prefix cache, занятой памяти и очереди - Если незакэшированной работы много, отдельно выбирает prefill worker - Sidecar отправляет туда запрос с max_tokens=1, после чего decode worker забирает рассчитанный KV-cache через NIXL и продолжает генерацию - Получается интересный сдвиг: маршрутизируется уже не только HTTP-запрос, но и вычисленное состояние модели. В собственном benchmark команда сравнила одинаковые 16 H200 с InfiniBand: четыре монолитных TP4-реплики против четырёх prefill TP2 и двух decode TP4 на Llama-4 Scout с 5000 входных и 250 выходных токенов. По данным проекта, P/D-вариант дал заметно больше throughput на GPU в средней зоне нагрузки, особенно при 64–128 одновременных запросах. На низкой и предельной нагрузке кривые сближались — универсального множителя здесь нет. История развивалась так: - в 2023 году PagedAttention сделал KV-cache эффективнее внутри одного движка; - в 2024-м Splitwise и DistServe показали, зачем физически разделять prefill и decode, а Mooncake — как строить вокруг KV-cache распределённую архитектуру; - 20 мая 2025 года запустили llm-d, а в июле v0.2 принесла первые воспроизводимые well-lit paths для P/D, cache-aware routing и wide expert parallelism; - Доклад 23 октября 2025 года зафиксировал раннюю рабочую систему, где главный вопрос был уже не «можно ли разделить фазы», а «как выбрать P, D и безопасно передать состояние»; - в 2026-м llm-d вошёл в CNCF Sandbox, вышел за границы обязательного Kubernetes и в v0.8 прямо назвал себя inference control plane. Обещанное в докладе P2P-переиспользование KV-cache стало отдельным well-lit path 15 августа, а 17 августа вышла v0.9. Самая важная оговорка прозвучала у самих спикеров: P/D подходит не каждому workload. Они советуют начинать эксперименты с моделей порядка 70B+, длинных контекстов вроде 10k input / 1k output и sparse MoE. Текущая документация vLLM всё ещё называет disaggregated prefilling экспериментальной возможностью и прямо предупреждает: само разделение throughput не повышает. Оно позволяет независимо настраивать TTFT и inter-token latency; итоговый выигрыш даёт только вся конфигурация — topology, router, workload и достаточно быстрая сеть. Поэтому начинать стоитс профиля нагрузки: распределения input/output tokens, concurrency, SLO по TTFT и задержке между токенами, стоимости KV-transfer. Без этих чисел P/D disaggregation может оказаться как хорошей системной оптимизацией, так и дорогим способом отправить несколько гигабайт кэша по сети и вернуть их почти туда же. #AI #Engineering #Architecture #Software #DistributedSystems #PlatformEngineering

Я тут подумал, что надо бы устроить ask me anything сессию завтра. Если есть желание у меня что-то спросить, то закидывайте вопросы сюда, а завтра вечером я на них поотвечаю в прямом эфире. Если наберется достаточно вопросов, то эфир случится.

Данила Штань: AI не отменяет фундамент и инженерную ответственность (Рубрика #AI4SDLC) Посмотрел выпуск Beyond Coding с CTO Nebius Данилой Штанем. В заголовке обещают рассказ о навыках, с которыми берут на работу, но для меня разговор оказался шире: найм, устройство инженерной организации и подход к доверию AI-коду у Штаня сходятся в одном принципе — автономность не убирает контроль, а переносит его ближе к тому, кто принимает решение и отвечает за последствия. Интересно, что в 2021 году на Highload++ я как раз рассказывал доклад о том, как меняется эта роль при росте организации. Ответ Штаня вполне определённый: техническая глубина остаётся, но по мере роста организации CTO прежде всего строит команду, отвечает за результат, разрешает конфликты инженерии с бизнесом и управляет ожиданиями. Обещание важно не только выполнить — отклонение нужно показать до того, как оно стало сюрпризом для чужого плана. С инженерными навыками похожая картина. По словам Штаня, для многих задач AI-облака не обязателен опыт именно в AI: нужны инженеры по распределённым системам, драйверам, сети, низкоуровневому хранению, GPU-ядрам и оптимизации инференса. Это хорошо рифмуется с недавним разбором vLLM и PagedAttention: проблему управления памятью KV-кеша решили с помощью классической идеи виртуальной памяти. Знание конкретной библиотеки или фреймворка отходит на второй план, фундаментальное мышление — нет. В описанном Штанем процессе найма проверки написания кода и алгоритмического мышления проходят без AI, а для опытного инженера есть разбор недавнего проекта целиком: откуда пришли требования, кто принимал решения, зачем строили продукт, что произошло после запуска и видел ли кандидат эксплуатационные последствия. Отдельную сессию работы с агентом компания на момент записи только проектировала. Это описание процесса из публичного разговора, а не обещание, что он останется неизменным. Организационно тот же принцип выглядит жёстче. По описанию Штаня, у инженерных команд Nebius нет отдельного архитектора и архитектурного комитета: команда сама проектирует систему, запускает её, дежурит и отвечает за сервис. Свобода решения оплачивается эксплуатационной ответственностью. Иначе автономность быстро превращается в локальную оптимизацию за чужой счёт. Интересно, что я примерно всю дорогу пропагандировал такой подход в Т-Банке, когда отвечал за архитектурную функцию, хотя мне часто ставили в укор то, что у нас нет департамента корпоративной архитектуры как в Сбере (хотя к концу моей работы в Т-Банке внутри некоторых крупных блоков появились свои отделы корпоративных архитекторов, но это инициатива на местах:)) С AI-агентами Штань проводит похожую границу. Он сравнивает работу с агентом с работой с младшим инженером: у агента нет полного контекста, он предлагает странные идеи и может далеко их развить. По словам Штаня, на момент записи в компании были доступны модели OpenAI и Codex, но не было широкого доступа к Claude Code. Он объяснял это не «запретом AI», а нехваткой защитных правил и наблюдаемости. Желаемый им протокол для пул-реквеста с участием AI включает отметку об участии агента, сохранение полной траектории сессий, возможность аудита и обсуждение не только кода, но и исходного замысла: где человек направлял модель и спорил с ней. В выпуске это именно целевое состояние, а не уже внедрённая обязательная политика. Владелец изменения в рабочей системе при этом остаётся человеком. Последние посты про Cursor Cloud Agents, одного агента с файлами вместо сложной обвязки и удаление 80% системного промпта Claude Code складывались в техническую историю: сильной модели всё меньше нужно диктовать каждый шаг, а сложность переезжает в среду, инструменты, состояние и проверки. Штань добавляет организационное продолжение: чем больше свободы получает агент или команда, тем яснее должны быть границы и человеческая ответственность за результат. Для меня главный вывод: AI удешевляет локальное производство кода, но повышает ценность владения системой. Постановка задачи, понимание ограничений, независимая проверка, эксплуатационный контекст и готовность отвечать за последствия не исчезают. Наоборот, именно они отделяют автономность от бесконтрольности. #AI4SDLC #AI #Agents #Engineering #Architecture #Management

В общем, прямой эфир с Сережей Бережным из Yandex, что должен был быть сейчас, переносится с этой пятницы по техническим причинам:( Надеюсь, что получится провести его на следующей неделе.

State of AI4SDLC, или Как меняется индустрия разработки под влиянием AI - мое выступление на DotNext в этом году (Рубрика #AI4SDLC) Видимо, крайней моей российской конференцией до отъезда в Лондон будет DotNext в Москве 25 сентября. Там у меня будет keynote доклад про состояние дел в AI4SDLC, где я расскажу и про исследования и про свой путь с AI4SDLC в бигтехе, поделюсь мыслями про влияние этих инструментов на продуктивность, а также сделаю прогнозы на будущее в этой теме. В общем, обещаю, что я постараюсь сделать этот доклад максимально крутым и полезным, так как хз когда я вернусь на сцены больших конференций в следующий раз. Если вы будете на конференции, то заходите послушать, позадавать вопросы и пообщаться после доклада - обычно я еще часами отвечаю на вопросы в зоне Q&A. Ну и спасибо организотрам jug.ru, которые предоставили мне такую площадку. Кстати, этой теме про изменение разработки и мира Java будет посвящен Joker, что пройдет 14 и 15 октября - рекомендую конфу к посещению. Возможно, я тоже туда доеду, так как меня позвали заглянуть в гости и для этого мне даже не надо делать доклад:) #AI4SDLC #Engineering #Conference #Software

3 AImigo S1E2: AI пишет больше кода. Почему поставка не ускоряется? (Рубрика #AI) Через пять минут в 12:00 по мск стартует прямой эфир 3 AImigo, где мы будем разбираться с парадоксом, который всё чаще встречается в командах: AI заметно ускоряет отдельного инженера, кода становится больше, а до пользователей доходит примерно столько же изменений. Локальная скорость не равна принятому результату — и размер компании от этого не защищает. Приходите послушать и задать вопросы. #AI #AI4SDLC #Agents #Engineering #Architecture #Management #Metrics #DevEx #Productivity #Software

Цветы для Элджернона в Чисто Театр Intact (Рубрика #Culture) Были вчера с Настей на спектакле "Цветы для Элджернона" и это было превосходно. Актеры сделали все, чтобы это произведение ожило на глазах зрителей и у них получилось. Интересно, что они сыграли всех персонажей на троих и на сцене, где из реквизита были кубики, стены и дверь Гениальная игра актеров позволила увидеть всю историю Чарли Гордон и поверить в нее. Интересно, что режиссер-постановщик нашел способ обхединить игру актоеров, а также подход из романа, где мы просто читаем дневник главного героя о происходящем с ним изменениях, которые выглядят примерно так - В самом начале рассказа Чарли предстает перед нами умственно отсталым, ответственно выполняющим свою работу и желающим стать умным. Чарли старательно учится писать и читать в вечерней школе, где его находят пара ученых, которым нужен подопытный. Чарли соглашается на эксперимент, который должен повысить его интеллект и он надеется, что это сделает его более счастливым и позволит поговорить с мамой ... - Оказывается, что успешный эксперимент приносит ему ожидаемое повышение интеллекта, но он все равно оказывается оторванным от социума ... просто теперь уже на другом хвосте гауссовой кривой ... - В итоге, это изменение оказывается временным и, когда время итекает, наступает регресс ... сначала у Элджернона, белой лаборатной мыши и единственного реального друга Чарли, а потом и у самого Чарли. Для меня эта история довольно личная, так как я прочитал ее во времена, когда из-за травмы головы (отека головного мозга) наблюдал у себя динамику изменения способностей как у Чарли ближе к концу книги (это было примерно 8-9 лет назад). К счастью, лечение тогда помогло и способности восстановились, но я еще пару лет носил очки. А на выходе из этой истории я стал сильно более публичным человеком и мотивация была в том, чтобы поделиться своими знаниями, пока я еще в адеквате. Заодно потом на старости лет можно будет показать детям, что их папа не всегда был туговат:)) P.S. На постановке мы были вдвоем и Настя, моя жена, понимающе кивала в той части, где Чарли вышел на пик его возможностей, а для меня на это было похоже на развивающую обратную связь ... P.P.S. 29 августа со старшим сыном отправимся в этот же театр смотреть "В поисках Аляски" #SelfDevelopment #SciFi #Culture #Theater

Evolution of Agentic Surfaces: harness становится инфраструктурой (Рубрика #AI4SDLC) Посмотрел доклад команды Applied AI из Anthropic — Gagan Bhat и Isabella Kai He — про эволюцию агентных поверхностей: от Messages API до Claude Managed Agents. Тезис, который я забираю: harness кодирует предположения о том, чего модель пока не умеет, поэтому это самая скоропортящаяся часть агентного стека. Доклад удачно собирает темы последних дней канала: минус 80% промпта Claude Code от Boris Cherny, облачные агенты Cursor и harness-подход Константина Крестникова, Сюжет — три поколения поверхностей 1️⃣ Сначала Messages API: токены на входе, токены на выходе, а агентный цикл каждый писал сам 2️⃣ Потом Claude Agent SDK, упаковавший harness Claude Code в библиотеку: цикл, инструменты и файловая система приезжают в коробке, но hosting, изоляция, credentials и наблюдаемость остаются на вас 3️⃣ Теперь Claude Managed Agents: Anthropic забирает production-обвязку целиком, а вам остаются задача, контекст и доменная экспертиза. Граница «что моё» продолжает сжиматься — тот же сдвиг, что Джош Ма описывал для Cursor, только с другой стороны прилавка. Лучшая иллюстрация скоропортящихся предположений — context anxiety у Sonnet 4.5: модель нервничала при приближении к границе контекста и сворачивала работу раньше времени (в Cognition наблюдали то же самое), поэтому команда встроила в обвязку сбросы контекста. Opus 4.5 вышел уже без этого поведения — и костыль превратился в чистый оверхед: лишняя латентность и некорректно сбрасываемый кеш. Когда модель сдвигается, а harness нет, обвязка начинает деградировать агента. Это то же явление, что и у Boris Cherny с системным промптом, только на уровне архитектуры, а не текста. Инженерно самое интересное — разделение «мозга» и «рук». Пока агентный цикл и sandbox жили в одном контейнере, модель не могла начать рассуждать до конца сборки среды, а падение любой половины убивало агента целиком. После разделения reasoning стартует сразу, контейнер поднимается параллельно: по замерам команды, время до первого токена сократилось на 60% в медиане и более чем на 90% в P95. Отказы становятся восстановимыми: умерший sandbox пересоздаётся, умерший «мозг» поднимается из durable session log. Сам журнал сессии работает трижды: наблюдаемость, возврат выброшенных из контекста кусков и периодический batch-процесс dreaming, который переписывает память агента, чтобы следующие сессии начинались умнее. После инцидента OpenAI и Hugging Face отдельно отмечу security-часть: credentials живут в vault и расшифровываются только в момент выполнения инструмента — модель их не видит; сеть среды ограничена списком allowed hosts; для строгих контуров есть self-hosted sandboxes в собственном VPC и MCP tunnels, чтобы MCP-сервер не выходил в публичный интернет. Ещё из любопытного — outcomes: вы описываете рубрику успеха, а отдельный grader-агент перезапускает основного, пока критерии не выполнены. По сути это production-grade evals, встроенные прямо в runtime. Финальный тезис авторов — harness стал ограничивающим фактором для того, что могут модели, — стоит читать с поправкой на рассказ о собственном продукте. Но мой вывод даже сильнее: обвязка перестаёт быть конкурентным преимуществом и становится скоропортящейся инфраструктурой, которую разумно арендовать. Своими стоит оставлять задачу, контекст, доменные знания и evals — слои, где живёт ваша ценность. #AI4SDLC #AI #Agents #Architecture #PlatformEngineering #Evals #Engineering

Code of Leadership S2E13: Что остаётся дефицитным, когда код становится дешёвым? (Рубрика #Management) Что остаётся дефицитным, когда код становится дешёвым: инструменты, инженерное мышление или доверие между компанией и разработчиками? В пятницу в 18:00 по мск в очередном прямом эфире подкаста Code of Leadership поговорим с Сергеем Бережным (veged.ru) — директором по взаимодействию с разработчиками Яндекса, CTO Яндекс Практикума и одним из соавторов методологии БЭМ. Сергей работает в Яндексе с 2005 года и прошёл путь от разработки интерфейсов до DevRel, open source и образования. Но разговор будет не про карьерную ретроспективу. Хочу понять, как техническое лидерство выходит за границы одной команды и проявляется в методологиях, платформах, работе с сообществом и публичной ответственности. Обсудим: - Зачем бизнесу DevRel и чем измерять его результат; - Почему внутреннюю технологию стоит открывать миру и как выбирать проекты для open source - Как разработка проходит путь от автодополнения к AI-агентам и harness-системам; - Что происходит с ролью руководителя, когда частью команды становятся агенты; - Кого и чему учить, если привычные entry-level задачи всё чаще забирает AI. Смотрите выпуск и приносите в комментарии свои вопросы и примеры. #CodeOfLeadership #DevRel #OpenSource #AI #Leadership #Education

Ю Су про агентов: интеллект + continual learning = экспертиза (Рубрика #AI) Посмотрел доклад Ю Су «Intelligence + Continual Learning = Expertise» с трека Memory & Continual Learning на AI Engineer World's Fair 2026. Су — профессор Ohio State University, из его группы вышли Mind2Web, SeeAct, MMMU и HippoRAG, а в апреле 2026-го он вывел из стелса стартап NeoCognition ($40 млн seed) — про агентов, которые доучиваются на работе. За двадцать минут он отвечает на вопрос, который занимает и меня: почему кодинг-агенты — большой успех, а агенты для всего остального буксуют. Рамка доклада такая. 🤖 Intelligence — способность рассуждать над незнакомой задачей из выданного контекста. Фронтирные модели делают это всё лучше, но каждый эпизод живёт отдельно. 💪 Expertise — накопленная и ситуативная компетентность: действовать в конкретном домене надёжно, эффективно и с суждением. По Су, эти оси почти ортогональны, и, масштабируя только интеллект, мы получаем «самого умного в мире новичка»: он блестяще берётся за любую подсунутую задачу, но между задачами ничего не накапливает. Почему тогда кодинг сработал? Код — привилегированный, language-native мир: всё уже записано символьно и структурировано, а тесты дают готовые награды. Происходящее Су называет современным парадоксом Моравека: «коронные» символьные дисциплины вроде кода и математики агентам даются, а повседневная цифровая работа — нет. Потому что это не один мир, а миллионы микромиров: каждая профессия и компания — даже два инстанса одного софта — настроены по-разному, со своей локальной физикой: структурами, ограничениями, динамикой. Слишком гетерогенно, чтобы одна статичная модель сжала это в себя. Самая интересная часть — как Су раскладывает экспертизу, опираясь на когнитивистику. Эксперты не просто знают больше — они видят иначе: мгновенно узнают паттерны (в огромном баг-репорте — где именно копать), видят глубинную структуру задачи (назначить встречу — не поиск общего слота в календарях, а оптимизация с ограничениями по полномочиям, приоритетам и срочности), понимают условность правил и когда их можно гнуть, владеют суждением: что такое качество и когда «good enough». Фактически эксперт выучил world model своего микромира. Отсюда же токенная прожорливость агентов: интеллект расширяет поиск, запуская сотню параллельных попыток, а экспертиза сжимает его — shortcuts уже выучены. Мост между осями — continual learning: адаптивное сжатие опыта в переиспользуемые структуры для будущего поведения. Четыре вопроса задают всё пространство решений: 1️⃣ Какой опыт - эпизоды, факты, процедуры, фидбек 2️⃣ Как сжимать - векторы, символьные индексы, дистилляция в параметры, RL 3️⃣ В какие структуры - адаптеры, графы, скиллы, world models 4️⃣ Как их использовать - вспоминание, предсказание, планирование, value function Плюс в конце автор говорит про unbounded expertise from bounded intelligence — если алгоритмы continual learning станут достаточно хороши, после некоторого порога интеллекта сильнее модель не нужна: масштабировать надо обучение на опыте. А следующая возможность уровня «интернет как датасет» — опыт приватных микромиров, когда специализированные агенты начнут возвращать выученное в общие модели. Что я забрал. — Это удачная рамка для происходящего: memory-файлы, skill libraries и RL на проверяемых наградах уже дают кодинг-агентам примитивный continual learning. Открытый вопрос — как повторить это там, где нет ни символьного мира, ни бесплатных тестов. — Управленческий вывод: если Су прав, moat компании — не доступ к модели, а learning loop поверх собственных микромиров, превращающий опыт людей и агентов в institutional memory. — Unbounded expertise — это пока гипотеза, а не результат. Как измерять экспертизу и мирить надёжность с пластичностью — открытые вопросы, Су честно перечисляет их сам. Ну и NeoCognition продаёт ровно это, так что перед нами манифест основателя, а не нейтральный обзор. #AI #Agents #Research #Engineering #Conference