Книжный куб

Приходите через 5 минут обсудить новости за август - у нас в 3 AImigo пройдет экспериментальный эфир, где мы обсудим интересные истории этого месяца.

Dominika Rogala про выгорание: AI ускоряет работу — и поднимает норму нагрузки (Рубрика #Management) В посте про AI-burnout речь шла о конечности человеческого внимания. Dominika Rogala добавляет организационный слой: AI может удешевить задачу и одновременно перегрузить рабочую систему. Инструменты стали быстрее — и ожидания тоже. Rogala — founder и leadership coach в Good Job Coffee, бывший VP of Engineering NeuroDevice и Engineering Manager в Vector Technologies и Intel. Её рамка инженерная: искать проблему не только в человеке, но и в системе приоритетов, решений и восстановления. Доклад начинается у океана в Назаре. Rogala — подготовленный спасатель и хороший пловец, но большая волна всё равно сбила её с ног. Когда волну уже хорошо видно, ты часто внутри неё. С выгоранием так же: лучше замечать ранние сигналы. Rogala раскладывает их на четыре измерения. Первые три опираются на классическую рамку выгорания; четвёртое — её практическое расширение. 🔸 Истощение — энергия перестаёт восстанавливаться достаточно быстро, и даже небольшие решения становятся дорогими. 🔸 Эмоциональная дистанция — ещё работаешь, но отстраняешься от того, что раньше было важно; «работает — и ладно» вытесняет заботу о качестве. 🔸 Снижение ощущения эффективности — занят постоянно, но всё равно чувствуешь, что отстаёшь и уже не справляешься как прежде. 🔸 Identity gap — человек на работе всё меньше похож на инженера или руководителя, которым хотел стать. Иногда тяжелее не усталость сама по себе, а то, что перестаёшь узнавать себя в собственной работе. Дальше Rogala использует модель Job Demands–Resources — Demands — нагрузка, переключения контекста, постоянная доступность и адаптация — Resources — автономия, ясность, поддержка, смысл, время на обучение и восстановление — Риск растёт, когда высокие demands становятся нормой, а resources системно не хватает. AI попадает в обе колонки. Он снижает усилие на задачу, но человек по-прежнему отвечает за результат, проверяет его и принимает решения. Параллельно растут скорость, число контекстов и ожидания. Главная мысль Rogala: система не обязательно становится проще — она становится быстрее. А выигрыш в эффективности быстро превращается в expectation inflation. Здесь доклад стыкуется с постом Paweł Soluch — основателя NeuroDevice и нынешнего CEO и co-founder Spinally. В NeuroDevice Rogala позже была VP Engineering. В начале карьеры Soluch мог работать двое суток без сна и постоянно менять часовые пояса. Годы всё выглядело нормально; затем он набрал 30 кг, организм заставил остановиться, а восстановление заняло месяцы. Его формула: с инвесторами можно договариваться, с биологией — нет; восстановление — это фундамент компании. Rogala ответила под этим постом: такую инфраструктуру нужно встраивать в каждый день. Маленькие регулярные паузы удерживают энергию лучше, чем ожидание «подходящего момента», после которого недельного отпуска уже может не хватить. Это не диагноз со стороны, а два уровня одной истории: у Rogala — модель дисбаланса, у Soluch — личный рассказ о цене его многолетнего игнорирования. Практический вывод — не wellness-перки — Если половину недели съедают status meetings, нужно меньше встреч, а не лекция по тайм-менеджменту — Если приоритетно всё — убрать два приоритета — Ещё три идеи: вернуть 1:1, защитить deep work и дать команде buffer week с самостоятельным выбором работы. — Обучение AI становится ресурсом, только когда есть рабочее время применить его. Для меня здесь важна мысли, что AI не создаёт энергетический долг автоматически. Но если каждый сэкономленный час сразу заполнить новой задачей, мы получим не устойчивую систему, а более быстрый маршрут в ту же кроличью нору. #Management #Leadership #AI #Engineering #DevEx #Process

Ищу человека, который подхватит AI4SDLC после меня (Рубрика #AI4SDLC) 31 августа я покидаю компанию. Но задача, которой я занимался, остаётся: менять процессы разработки и вести компанию к AI Native. Планка здесь высокая. Нужно знать передовые подходы, иметь hands-on опыт, уметь работать со множеством стейкхолдеров — и действительно хотеть изменить к лучшему одну из крупнейших технологических компаний России. Про текущее состояние AI4SDLC лучше всего расскажет моё выступление на Turbo ML Conf этого года. Работать предстоит под руководством Игоря Маслова — VP и руководителя департамента платформенной инженерии всей компании. Если вы читаете это и думаете «кажется, это про меня», напишите мне в личку (или сразу @kovalevatin). А если знаете подходящего человека — пожалуйста, перешлите ему этот пост. #AI4SDLC #AI #Engineering #PlatformEngineering #Leadership

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