Книжный куб

Research Insights Made Simple #29 про «The AI-Native SDLC playbook» с Антоном Костериным (Рубрика #AI4SDLC) Через 5 минут стартанет прямой эфир Research Insights Made Simple, где мы вместе с Антоном Костериным, principal engineer RnD-центра Т-Банка, разберём свежий материал Anthropic — The AI-Native SDLC playbook. С Антоном мы уже говорили об architecture governance, RFC/ADR и архитектурных ревью. Теперь вопрос шире: как перестроить под агентов не только написание кода, но весь SDLC. #AI4SDLC #AI #Agents #Engineering #Architecture #DevOps #Research

3 AImigo S1E3: Новостной дайджест AI за август (Рубрика #AI) В пятницу в 12:00 у нас пройдет последний эфир 3 AImigo в этом августе и мы решили проверить новый формат с обсуждением новостей AI за месяц. Вообще, тема AI развивается очень бурно и событий, что достойны упоминания достаточно много: новые модели и продукты, исследования, заметные кейсы, изменения в подходах команд к разработке с AI. Мы выбрали новости, доклады и тренды, которые показались нам действительно важными, и обсудим не только «что произошло», но и что за этим стоит. Мы попробуем разобраться где новости относятся к реальным изменениям для инженеров и компаний, а где это пока маркетинговая шумиха. На что стоит обратить внимание прямо сейчас, а что можно пока отложить. Как обычно, разбираемся втроём: Евгений Сергеев, Алексей Литвинов и Саша Поломодов:) Если формат зайдёт, будем делать такой выпуск в конце каждого месяца. #AI #AI4SDLC #Agents #Engineering #Architecture #Management #Metrics #DevEx #Productivity #Software

Bassem Dghaidi: «Simple is complicated enough» — system design без театра овер-инженерии (Рубрика #Architecture) Почти любой разговор о разработке сейчас довольно быстро съезжает к моделям, агентам и процентам сгенерированного кода. Поэтому эта 46-минутная беседа на Beyond Coding особенно хороша: AI появляется только в последней четверти. До него — спокойный инженерный разговор о system design, вертикальном масштабировании, цене абстракций и ответственности перед бизнесом. Очень уместный контрапункт общему AI-хайпу. В гостях у Patrick Akil — Bassem Dghaidi, senior software engineer в GitHub, работающий над GitHub Actions. У него больше 15 лет опыта в разных доменах: от банков и контейнерных терминалов до интернет-сервисов. В разговоре он опирается на конкретные задачи — перестройку частей GitHub Actions, инфраструктуру терминала и системы для банков, — поэтому «масштаб» здесь не упражнение у доски. Основной тезис Dghaidi: system design — не конкурс на самое большое количество модных коробочек. Систему стоит проектировать на следующий порядок величины, а не на воображаемые 100x, и только после того, как данные показали предел текущего решения. ПО не строят один раз — оно постоянно развивается, поэтому архитектура требует регулярных инвестиций, а не одной попытки угадать устройство системы на десять лет вперёд. Из разговора я бы забрал четыре мысли. 1️⃣ Масштабирование начинается с измерений По словам Dghaidi, некоторые сервисы GitHub обрабатывают миллионы запросов в секунду всего на пяти-шести контейнерах. Это внутренний пример спикера, не независимый бенчмарк. Сам контекст перестройки позже описал GitHub: старое ядро Actions обслуживало 23 млн jobs в день, новую архитектуру проектировали с запасом 10x, а к декабрю 2025 года она держала 71 млн jobs в день. Принцип тот же: сначала реальная кривая нагрузки, потом распределённая сложность. 2️⃣ Конкретное решение полезнее универсального фреймворка Кеш, NoSQL или новая абстракция появляются, когда есть конкретное узкое место. Иначе невозможно осмысленно выбрать компромиссы: универсальная конструкция оптимизируется сразу для всех гипотетических задач — и ни для одной реальной. 3️⃣ Архитектуру надо объяснять в единицах, что понятны бизнесу На контейнерном терминале, который вспоминает Dghaidi, задержка означала деньги и иногда риск для людей, а не просто красный график времени ответа. Его совет инженерам: переводить «база данных перегружена» в стоимость простоя, окно разгрузки, скорость поставки фичи и риск для клиента. Самый красивый Kubernetes-кластер ничего не доказывает, пока не показан измеримый эффект для бизнеса. 4️⃣ AI меняет рычаг, но не задачу инженера Dghaidi утверждает, что агенты пишут около 90% его кода. В одном кейсе агент за 20 минут собрал и прогнал три бенчмарка для разных ключей Redis — вручную это, по его оценке, заняло бы два-три дня. Освободившееся внимание он тратит на паттерны доступа к данным, надёжность, эксплуатацию и последствия ошибки. Его аналогия с автоматическим сцеплением на мотоцикле здесь точная: переключать передачи стало проще, но дорогу, скорость и допустимый риск всё ещё выбирает человек. Есть и с чем поспорить. Dghaidi прямо называет увольнения дегуманизирующим, но эффективным способом перераспределять инженерные ресурсы. Для меня это звучит слишком бухгалтерски. Но от этого запись только честнее: собеседники обсуждают реальные компромиссы, а не продают ещё одну серебряную пулю. В эпоху, когда заголовки соревнуются в том, какая модель написала больше кода, здесь задают менее эффектные вопросы: какой предел мы измерили, какой риск уменьшаем, кто будет эксплуатировать решение и что изменится для бизнеса. AI из разговора не исчезает — он просто возвращается на своё место: мощный инструмент внутри инженерной системы, а не замена system design. #Architecture #SystemDesign #Engineering #Software #AI #AI4SDLC

Материалы выпуска с Сергеем Бережным: что остаётся дефицитным, когда код становится дешёвым? (Рубрика #Management) Готовы материалы очередного выпуска Code of Leadership S2E14, который прошёл 24 августа. Вместе с Сергеем Бережным — директором по взаимодействию с разработчиками Яндекса, CTO Яндекс Практикума и соавтором БЭМ — разбирали, что становится узким местом, когда сам код генерировать всё легче. Обсудили: - Как БЭМ вырос из внутреннего решения для большой фронтенд-разработки в методологию, инструменты и инженерную экосистему; - Как митапы, DevRel и open source помогают распространять технологии — и почему публичность приносит не только охват, но и ответственность; - Как устроена матрица продукта и технологии: продуктовые задачи меняются быстро, а профессиональная специализация живёт дольше; - Как лидеры уровня Staff+ проводят поперечные изменения через стандарты и договорённости, не имея прямого административного мандата; - Почему AI даёт системный эффект после перепроектирования рабочего цикла, а не просто ускорения прежних тикетов; - Что, по итогам разговора, остаётся дефицитным при дешёвом коде и контенте: постановка задачи, инженерное суждение, критическая проверка, фокус, обратная связь, доверие и ответственность за результат. Все материалы выпуска: - Страница выпуска - Видео: YouTube, VK Видео - Аудио: Podster, Яндекс Музыка, Apple Podcasts - Текст: краткая расшифровка Спасибо Сергею за разговор. Если после просмотра появятся вопросы — пишите в комментариях: соберу их для продолжения темы о техническом лидерстве в эпоху AI. #Management #Leadership #Engineering #AI4SDLC #OpenSource #Education

Research Insights Made Simple #29 про «The AI-Native SDLC playbook» с Антоном Костериным (Рубрика #AI4SDLC) Кодинговые агенты уже пишут код гораздо быстрее. Но если планирование, архитектурное ревью, безопасность, тестирование и деплой остаются на «человеческой скорости», ускоряется ли delivery — или очередь просто переезжает в соседний этап? 27 августа в 14:00 в прямом эфире Research Insights Made Simple вместе с Антоном Костериным, principal engineer RnD-центра Т-Банка, разберём свежий материал Anthropic — The AI-Native SDLC playbook. С Антоном мы уже говорили об architecture governance, RFC/ADR и архитектурных ревью. Теперь вопрос шире: как перестроить под агентов не только написание кода, но весь SDLC. Тезис playbook: после ускорения Build bottleneck смещается в Plan, Test/Review и Deploy. Anthropic предлагает замкнуть шесть стадий, от Plan до Maintain, в цикл. intent.md, spec.md, plan.md, diff с тестами, результаты review и записи об инцидентах образуют цепочку версионируемых артефактов и одновременно audit trail. Человек остаётся ответственным, но подключается в точках, где действительно требуется суждение. Обсудим: - Действительно ли код перестал быть узким местом и где теперь скапливается очередь; - Зачем нужны markdown-артефакты, если уже есть Jira, wiki и архитектурные процессы; - Как превратить знания компании в CLAUDE.md, skills и проверяемые политики, не законсервировав ошибки; - Как связать continuous evals, hooks, агентное и человеческое review с production monitoring; - С какого участка SDLC начинать и какими метриками доказывать эффект. Это практическое руководство команды Claude, а не исследование со сравнительным экспериментом. Поэтому отдельно проверим, где здесь переносимый инженерный подход, а где пока видение поставщика — особенно для большой регулируемой организации. Подключайтесь 27 августа в 14:00 и приносите свои кейсы и вопросы. Особенно если coding agents уже ускорились, а delivery почему-то нет. #AI4SDLC #AI #Agents #Engineering #Architecture #DevOps #Research

Почему удачный POC (proof of concept) AI продукта ещё не готов к production (Рубрика #AI4SDLC) Посмотрел новый доклад с конфы AI Engineer World’s Fair, который развивает тему FDE (Forward Deploy Engineer). В прошлый раз я разбирал FDE — инженера, который встраивается в команду клиента и доводит AI до работающего процесса. А новый доклад показывает следующий акт этой истории: POC уже работает, а production ещё даже не начинался. Christopher Lovejoy из Anthropic и Saul Howard, VP Engineering в Anterior, начинают с условного сценария. Два инженера за четыре недели собирают агента для медицинского workflow. Accuracy хорошая, система быстрая и относительно дешёвая. На презентации все довольны: финансы считают бюджет, медицинский директор готов рассказывать коллегам о точности, а продажи уже хотят написать на сайте «Powered by AI». На следующий день в комнате появляются другие вопросы. Где полный audit trail? Как перемещаются медицинские данные? Кто подтверждает спорное решение? Может ли недоверенный документ управлять моделью? Как проверять качество после релиза? И красивый POC останавливается: он оптимизирован под правильный ответ, но не под доказуемость каждого действия. Спикеры предлагают поменять порядок: сначала сделать production-ограничения несущей конструкцией, а уже потом возвращать точность прототипа. Для этого нужны три примитива: 1️⃣ Append-only журнал событий — единая история действий, доступов и авторизаций. Он помогает воспроизводить состояние и строить аудит, но у компромисса есть цена: записывать легко, читать сложнее, нужны projections и snapshots; 2️⃣ Schema-driven object storage для самих медицинских данных. В журнале остаются ссылки, доступ выдаётся в момент использования, а инженер может отлаживать путь агента, не видя PHI; 3️⃣ Единый контракт действий для LLM и человека. Любой шаг можно передать человеку посреди workflow, а общий контекст отобразить либо как prompt, либо как UI. Речь об одинаковом интерфейсе, а не об одинаковых полномочиях. Из этой основы, по мнению авторов, получаются и evals: можно повторно проигрывать тот же эпизод с другим prompt, моделью или кодом, сравнивать действие агента с человеческим и запускать проверку на production data внутри контура клиента. И мне здесь нравится именно порядок мышления. Если audit, границы данных и human approval появляются в плане «после успешного POC», архитектура уже опоздала. В регулируемой системе это не ворота перед релизом, а сама модель данных и исполнения. #AI4SDLC #AI #Agents #Architecture #DevSecOps #Evals #Engineering

Материалы выпуска «Дата-платформа в 2026 году» (Рубрика #Data) Готовы материалы 28-го выпуска Research Insights Made Simple, который вышел 24 августа. Вместе с Николаем Головым и Александром Филатовым из Tengri Data мы прошли путь от границы между OLTP и OLAP до прав, изоляции и проверки запросов AI-агентов. Обсудили: - Как по реальной нагрузке понять, когда операционная СУБД перестаёт справляться с аналитикой; - Где упирается классическое MPP-хранилище и что меняет разделение хранения и вычислений; - Из чего на практике складывается Lakehouse на S3 и Iceberg: каталог, вычислитель, права, кэш, уплотнение мелких файлов и эксплуатация распределённых компонентов; - Почему переход с Vertica на Trino, Iceberg и S3 занимает годы и какой длинный хвост создают унаследованные расчёты и хранимые процедуры; - Чему год разработки, пилотов и продаж научил Tengri Data: технологию платформы нужно связывать с измеримым результатом для бизнеса; - Почему AI-агенту мало доступа к SQL — нужны семантический слой, детерминированные проверки, строгие права и изоляция нагрузки. Все материалы выпуска: - Страница выпуска - Видео: YouTube, VK Видео - Аудио: Podster, Яндекс Музыка, Apple Podcasts - Текст: краткая расшифровка Если после просмотра останутся вопросы — пишите в комментариях. Соберу их для продолжения темы дата-платформ: здесь ещё есть куда копать. #Data #PlatformEngineering #Architecture #Database #AI4SDLC #Engineering

Первые 90 дней CTO начинаются до первого рабочего дня - Менеджмент 360 (Рубрика #Management) В айтишке есть странная традиция: сначала получаешь новую должность, а потом начинаешь выяснять, на какую именно работу согласился. Для CTO это особенно дорогой способ знакомиться с ролью. Поэтому 3 сентября в 19:35 на «Менеджменте 360» от Стратоплана я буду рассказывать про первые 90 дней технического директора. Начну с небольшого переворота: первый рабочий день — уже середина перехода. В докладе разберу весь маршрут: - Как выбирать задачу, а не красивый шилдик; - Зачем до выхода договориться о полномочиях, ресурсах и критериях успеха; - Почему первый месяц лучше потратить на сбор реальной карты компании, а не на формирование портфеля изменений; - Как к 90-му дню выбрать одну-две системные ставки, показать первый результат и не пропустить красные флаги. Это не универсальный чек-лист «успешного успеха», а практическая модель: исследование → взаимный контракт → диагностика → первые изменения. И ещё: компания в эти три месяца тоже проходит испытательный срок. «Менеджмент 360» идёт онлайн 1–4 сентября, каждый день с 18:00 до 21:00 GMT+3. Четыре дня — четыре управленческие роли: тимлид, руководитель отдела, CTO и COO. В программе 16 живых эфиров про переход в роль, базовые инструменты, первые 90 дней и типовые грабли; записи останутся у участников. Среди спикеров — тренеры Стратоплана, COO Welltory, руководители из Yandex Infrastructure и Ozon, основатель Product Heroes. Если вы примеряете следующий управленческий уровень или уже получили новую роль и управленческий компас слегка крутится — приходите. Кстати, иногда «чужой» день оказывается полезнее своего: наконец видно, как ваша работа выглядит из кресла руководителя. Регистрация бесплатная при подписке на Telegram-каналы спикеров. Есть и платный вариант без подписок — с именным сертификатом и курсами «Менеджмент 101» и «Директор 101». 👉 Регистрация #Management #Leadership #CTO #Conference

Материалы 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 сессию завтра. Если есть желание у меня что-то спросить, то закидывайте вопросы сюда, а завтра вечером я на них поотвечаю в прямом эфире. Если наберется достаточно вопросов, то эфир случится.