Книжный куб

Kubernetes: слишком сложно? Материалы DevOps Deflope №62 (Рубрика #PlatformEngineering) Сходил в гости к DevOps Deflope — вместе с Александром Качмашевым из «Точки». В выпуске №62 от 13 сентября 2026 года поговорили о том, почему запустить приложение в Kubernetes проще, чем потом со всем этим жить. Обсудили: - Сложность Kubernetes. Что происходит, когда за привычным Helm-чартом приходится разбираться с сетями и протекающими абстракциями. - Внутренние платформы. Какую работу они снимают с разработчиков и кто берёт её на себя. Число подключённых команд ещё не говорит, насколько им удобно. - AI-агентов в кластере. Читать состояние, советовать и менять инфраструктуру — три разных уровня доверия. Обсудили проверки, ограниченные права и изменения через GitOps. Материалы выпуска: 🎧 Apple Podcasts , Яндекс Музыка, Spotify 📌 Страница выпуска у меня на сайте и текстовый конспект 📖 Лонгрид моей подготовки: куда переезжает сложность Kubernetes А у вас какая часть сложности осталась у разработчиков, а какая переехала в платформенную команду? #PlatformEngineering #Kubernetes #DevOps #AI #Engineering

Раньше я читал whitepapers и обсуждал их сам с собой. Выглядело это как игра и за белых и за черных на шахматной доске. Теперь я читаю whitepapers, оставляю заметки на полях, а потом обсуждаю это с Codex/Claude, причем ассистент не только видит исходный текст, но и мои отметки и готов с ними поспорить. Честно говоря, теперь их изучать стало сильно интереснее. Кстати, дальше буду выкладывать краткие саммари по научным статьям со своими отметками на полях - теперь я их в основном на планшете читаю. А раньше я часто печатал их на бумаге - в итоге, в моем кабинете в Т-Банкке осталась стопка в 20 см распечатанных научных статей с моими отметками во время разборов.

Как Vercel строила d0: путь агента и вопросы к результату (Рубрика #AI4SDLC) В докладе «How We Solved Agent Building» Andrew Qu, Chief of Software в Vercel, рассказывает, как команда строила внутреннего аналитического агента d0. Каждое архитектурное решение упиралось в следующую проблему. В итоге, по оценке Qu, получился полезный агент, а затем и фреймворк eve. Насколько этот путь подтверждает слово «solved» в заголовке — хороший вопрос по ходу разбора. 1️⃣ Большой промпт: проверить, умеет ли модель решать задачу Исходная боль вполне приземлённая: аналитиков постоянно отвлекали вопросы коллег о клиентах, продуктах и показателях. Qu начал со схемы Snowflake, вставленной в системный промпт. Модель генерировала SQL, который он копировал и запускал вручную. Хороший дешёвый эксперимент. Но между исполняемым SQL и правильным ответом на бизнес-вопрос ещё есть расстояние: нужно выбрать нужный показатель, период, фильтры и связи между таблицами. Следующая версия должна была выполнять весь процесс. 2️⃣ Цепочка специалистов, затем один агент с общей историей Команда разложила работу на этапы: исследовать схему, спланировать запрос, выполнить SQL, подготовить отчёт. Каждому агенту дали узкую роль и свои инструменты. По словам Qu, проблема была в передаче контекста: следующий участник получал лишь краткую выжимку предыдущего шага. Когда выполнение обнаруживало неверное предположение, хотелось вернуться к исследованию. Поэтому этапы объединили в одного агента, который сохранял историю работы и сам переключался между планированием, выполнением и проверкой. Обобщать этот результат на все многоагентные системы рано: здесь мешали жёсткая последовательность и потеря контекста при передаче. И первые пользователи всё равно оценили новую систему плохо — их вопросы выходили за пределы сценариев разработчиков. 3️⃣ Рабочий каталог вместо разрастающейся обвязки Следующий поворот случился, когда, по словам Qu, Claude Code с Opus 4.5 стал отвечать на их вопросы заметно лучше собственного агента. Команда перенесла этот подход в d0: изолированная среда, файлы семантического слоя, обычные инструменты чтения, поиска и bash, плюс операции для задач Vercel. Семантический слой — это описания показателей и связей между сущностями. Теперь агент мог сам исследовать их и возвращаться за деталями по мере необходимости. Qu говорит, что оценка на внутренних тестах примерно удвоилась. Тут сразу два вопросика: ❔ Какую часть улучшения дала архитектура, а какую — более сильная модель? Доклад не позволяет разделить эти эффекты ❔ Насколько убедительны сами тесты? «100% успеха» в связанной статье — это пять успешных запросов из пяти вместо четырёх. С удвоением оценки из выступления их объединять нельзя: сопоставимость наборов не показана. Кстати, в статье Qu отдельно оговаривает: у команды уже были хорошо документированные данные. Файловая система открыла модели доступ к готовому знанию. При переносе такого решения в другую компанию качество этого знания придётся проверять отдельно. 4️⃣ Повторяющиеся запросы превращаются в skills После расширения использования d0 команда заметила, что многие запросы похожи по структуре. По словам Qu, регулярная задача анализирует недавние запросы и выделяет из них навыки; к моменту выступления накопилось около ста. Следующий запуск получает уже подготовленный способ работы с типовой задачей. В eve такие навыки — инструкции, которые подгружаются по необходимости. Вот здесь становится особенно интересно. Кто проверяет, что популярный способ посчитать показатель ещё и правильный? Как обновить навык после изменения бизнес-логики? Как откатить процедуру, которая разносит одну ошибку по новым ответам? Механизм генерации описан, а проверка, обновление и удаление навыков остались за кадром. Частота повторения сама по себе качество не гарантирует. 5️⃣ Удачный внутренний опыт упаковывают во фреймворк Из этого пути вырос eve: инструкции, навыки, инструменты и каналы общения задаются файлами, а фреймворк собирает из них агента и обеспечивает среду выполнения. Qu говорит о тысячах запросов к d0 в день и примерно 20 востребованных агентах внутри Vercel. Это признаки использования. Для оценки эффекта хотелось бы ещё увидеть долю правильных ответов, время на их проверку и стоимость сопровождения. Заявление, что аналитики освободились для более содержательной работы, выглядит правдоподобно, но измерений экономии времени в докладе нет. Путь d0 хорошо показывает, как работа над агентом постепенно затрагивает устройство знаний самой компании. Самый интересный следующий доклад был бы про жизнь этих ста навыков: кто отвечает за их правильность и как команда замечает, что накопленный опыт пора пересмотреть. #AI #AI4SDLC #Agents #Data #Architecture #Evals

YC Paper Club: что делает модель рабочим агентом (Рубрика #AI4SDLC) Посмотрел интересную встречу YC Paper Club про harness, которая называлась «Why The Harness Matters More Than The Model» и где обсуждалась обвязка модели: инструменты, память, выполнение кода и управление работой агента. Сама запись появилась 7 сентября и хоть заголовок видео спорный, но внутри четыре инженерных выступления о том, а что меняется, когда той же модели дают больше возможностей работать с окружающей средой. 1️⃣ Вступление François Chaubard из Y Combinator отлично работает как вступление. Он проходит путь от генерации текста к инструментам, памяти, навыкам, субагентам и системам, которые меняют собственную обвязку по результатам работы (тут прямо много отсылок к whitepapers). Заодно показывает свой эксперимент с автоматизацией исследований: задаёшь идею и метрику, дальше агенты ищут статьи, ставят эксперименты и готовят текст. Среди ролей есть даже научный руководитель, который периодически напоминает исследователю, что пора двигаться дальше. Академическую жизнь тоже автоматизируют :) 2️⃣ Seth Karten из Prime Intellect рассказывает про Prime Agent. У него интересная аналогия с иерархией памяти компьютера: веса модели, активный контекст, переменные в работающем Python-процессе и долговременные файлы. Большой результат инструмента можно оставить в памяти процесса, обработать кодом и передать модели только нужный фрагмент. Субагента можно вернуть к задаче с сохранённым контекстом. По мере работы обновлять навыки и инструкции, чтобы полезный опыт переживал отдельную сессию. Кстати, сама идея «дать агентам общаться друг с другом» выросла у Karten из вполне человеческой проблемы: надоело самому переносить информацию между параллельно работающими помощниками. Среди примеров — создание эмуляторов игровых систем, оптимизация GPU-ядер и многодневные исследовательские задачи. Есть и история про почти идеальный результат на ARC-AGI: по словам Karten, первый запуск показал 99,9%, но просмотр логов обнаружил жульничество. Пришлось исправлять изоляцию среды и запускать заново. Полезная деталь для всех, кто привык смотреть только на итоговую цифру бенчмарка. 3️⃣ Jon Saad-Falcon из Stanford показывает OpenJarvis — персонального помощника, работающего на собственном устройстве. Здесь интересна схема настройки: сильная облачная модель изучает ошибки локальной системы и предлагает изменения модели, инструментов, памяти и логики агента. Изменения проходят проверку, а готовая конфигурация выполняет задачи локально. Авторы заявляют снижение предельных API-затрат примерно в 800 раз на своих тестах. Это не полная стоимость владения с железом и электричеством. Но сама возможность использовать облачную модель для подготовки более дешёвого локального помощника заслуживает внимания. 4️⃣ Самая прикладная часть — Josh France и Regan Bell из YC Labs про QM, внутреннюю платформу агентов для сотрудников YC. До неё команда подняла больше 50 Hermes-агентов в виртуальных машинах. Помощники были полезными, но требовали настройки и постоянного обслуживания: приходилось заходить в отдельные экземпляры и что-то чинить. В QM историю и состояние разговоров вынесли в PostgreSQL, а песочницы стали ресурсами, которые агент подключает по необходимости. Обсуждают и менее очевидные трудности: агент слишком рано заканчивает работу; автоматические исправления помогают одному участку, но не учитывают систему целиком; информация из личного разговора может попасть в общий канал, потому что модель плохо понимает социальный контекст. В общем, рекомендую посмотреть оригинальную запись - она длится всего час и там есть и исследовательские идеи и прикладной опыт. #AI4SDLC #AI #Agents #Engineering #PlatformEngineering

Как AI изменит разработку ПО: материалы Organized Programming №92 (Рубрика #AI4SDLC) Собрал материалы разговора с Кириллом Мокевниным: 13 сентября 2026 года вышел выпуск №92 Organized Programming, где я был гостем. Обсуждали, как AI меняет программистов, команды и IT-компании. Делился опытом внедрения AI в Т-Банке — и тем, почему после ускорения написания кода ещё приходится разбираться со всей остальной разработкой. Если продуктовый менеджер быстрее пишет постановки, аналитик — требования, а разработчик — код, очереди между ними могут только вырасти. Интереснее посмотреть, сколько людей и согласований проходит одна задача, прежде чем результат увидит пользователь. Обсудили 🔸 Команды с агентами Один инженер может брать на себя больше этапов работы, сокращая передачи задачи между людьми. При этом необходимые роли сохраняются. Компактная команда — обсуждаемое направление изменений, а не уже достигнутая норма для любой компании. 🔸 Внедрение на масштабе Общий доступ к моделям, инструменты, навыки для агентов и изолированные среды дают техническую основу. А менять процесс должно само продуктовое направление: исключения, на которых взлетел пилот, ещё нужно научиться воспроизводить для остальных. 🔸 Спецификации и проверку плана Кирилл рассказал, как использует эти практики даже в небольших проектах: агенты снижают стоимость оформления. Но требования к качеству всё равно нужно подкреплять автоматическими проверками — один документ ничего не гарантирует. 🔸 Знания и внутренние платформы Агенту трудно разобраться с неявными правилами и корпоративным форком, который ведёт себя иначе, чем исходный продукт. При этом документацией пользуются и люди вне разработки: переезд всего знания в Git меняет их работу тоже. 🔸 Три уровня измерения пользы Используют ли инструмент, сколько времени он высвобождает и что компания получает с учётом всех затрат. Больше закрытых задач может означать, что команда просто добралась до менее полезной части очереди. Нужны новые стоящие гипотезы и понимание, куда направить освободившееся время. 🔸 Обучение и границы автономии Готовая функция мало говорит о том, чему научился джун: надо разбирать постановку, план и понимание результата. В сложном легаси похожая проблема — сначала выяснить, почему система устроена именно так и кто зависит от её поведения. Материалы выпуска 📌 Страница выпуска 📖 Когда код пишет агент: что остаётся инженерией — лонгрид подготовки к разговору. 🎬 Запись на YouTube 📝 Текстовый конспект разговора Если уже внедряете агентов в команде, расскажите: что теперь дольше всего задерживает полезное изменение на пути к пользователю? #AI4SDLC #AI #Agents #Engineering #PlatformEngineering #Management

Материалы выпуска: свобода CTO в стартапе и корпорации с Кириллом Евсеенко (Рубрика #Leadership) Собрал материалы разговора с Кириллом Евсеенко, CTO аудиостримингового сервиса «Звук». Эфир Code of Leadership прошёл 11 сентября 2026 года. Обсуждали свободу технического директора: можно быстро принять решение и упереться в нехватку людей, а можно получить ресурсы для большого изменения — и обнаружить, сколько ещё людей должны с ним согласиться. Кирилл сравнивает эти среды через свой опыт: медицинский стартап, START и «Звук». По его словам, за шесть лет команда START выросла примерно с 12 до 150 человек, а на понимание правил работы в «Звуке» ушло около полугода. Разговор получился про то, как вместе с масштабом меняется сама работа CTO. Обсудили: - Когда пора строить своё. START начинал с внешних CDN, биллинга и кодировщика; затем стоимость и ограничения поставщиков стали поводом делать отдельные компоненты внутри. Как связать архитектуру с деньгами и учитывать поддержку решения через несколько лет. - Как перестать чинить всё лично. Кирилл рассказал о переходе к работе через руководителей и платформенные команды. В том числе о распределении знаний, которые раньше держались на отдельных незаменимых людях: с ростом компании такая зависимость обходится дороже. - Куда расти сильному инженеру. Техническая карьерная ветка позволяет расширять влияние без обязательного ухода в менеджмент. Но под роль нужны реальные сложные задачи и польза бизнесу — одного нового названия должности мало. - Что происходит после «решили делать». Безопасность, юристы и смежные команды могут остановить уже подготовленный запуск. При этом Кирилл оговаривается: в корпорации решение тоже может занимать несколько часов. Важны конкретные полномочия, зависимости и цена ошибки. - Как закрывать ненужные инициативы. Команде хочется продолжать свой проект, а руководителю бывает безопаснее ждать указаний: личный риск неудачи выше награды за успех. Обсудили, как такие стимулы мешают изменениям и зачем нужна ответственность за завершение работы, включая решение её остановить. Материалы выпуска: 📌 Страница выпуска с таймкодами 🎬 YouTube, [VK Видео 🎧 Podster, Яндекс Музыка, Apple Podcasts 📝 Текстовый конспект разговора Если переходили между стартапом и большой компанией, расскажите: какую привычку пришлось менять первой — и какое решение оказалось труднее всего довести до результата? #CodeOfLeadership #Management #Leadership #Career #Strategy #Engineering

Science Museum Souvenir Book (Рубрика #Museum) Музей науки в Лондоне мне очень понравился - по нему было интересно гулять как одному, так и с детьми. В нем много экспонатов, организованных в серии по доменам, а внутри по времени. Примерно та же схема прослеживается и в сувенирной книге, что выхватывает изобретения, которые продвинули человечество, а также присутствуют в коллекции музея. В общем, это крутое место, что заслуживает посещения:) #Science #Museum #History

Где профит от данных, Лебовски? Материалы первого выпуска (Рубрика #Data) Собрал материалы первого выпуска «Где профит от данных, Лебовски?». Эфир прошёл 7 сентября 2026 года: вместе с Андреем Цыбиным и Николаем Головым обсуждали, как превратить данные в деньги. Начали с вполне житейского запроса: данных накопили много, теперь хочется на них заработать. Только размер хранилища ещё ничего не говорит о том, кто готов за его содержимое платить. Кстати, у проекта есть собственный отдельный сайт prodata.tech, а следующий эпизод выйдет где-то через неделю. Получился разговор с трёх сторон: продуктовая аналитика и эксперименты, архитектура платформ данных и инженерное лидерство. И со спором о том, сколько ценности остаётся в данных, когда убираешь подробности. Обсудили: - Три пути к деньгам. Продать данные наружу, улучшить решения внутри компании или построить на них продукт. Рамку обозначили целиком, а большую часть первого выпуска посвятили внешней продаже. - Покупателя и его задачу. Кому нужен именно этот набор и что человек сможет с ним сделать? Андрей обращает внимание на охват, репрезентативность и стабильность сбора: рост показателя может означать, что мы стали больше наблюдать, а не что вырос сам рынок. - Копию, права и обезличивание. Николай разбирает вопросы целей сбора и дальнейшего использования; отдельно говорили о повторной идентификации по событиям и маршрутам. Юридические примеры в разговоре — вопросы к проверке конкретной сделки, а не готовое разрешение продавать данные после удаления имён. - Агрегированную аналитику. На примерах Strava и аналитики для поставщиков X5 спорили о цене детализации. Мы с Николаем обсуждали, как её потеря может снизить ценность; Андрей возражал, что качественный ответ на нужный покупателю вопрос сам может стать продуктом. - Расходы после выгрузки. Подготовка, поддержка, защита, возможность копирования и собственное конкурентное преимущество, которым делишься с покупателем. Счёт за первую поставку ещё не отвечает на вопрос, выгодно ли всё это компании. Материалы выпуска: 📌 Страница выпуска с таймкодами 📖 Лонгрид: три пути от массива к деньгам — отдельный разбор темы с кейсами и схемами, который я делал при подготовке к выпуску 🎬 Запись на YouTube 📝 Текстовый конспект разговора Если пробовали монетизировать данные, расскажите, где оказалось сложнее: найти покупателя, подготовить полезный продукт или посчитать, что осталось после всех расходов? #Data #Product #Analytics #Architecture #Management

Habitat: эволюция слоя хранения OpenAI (Рубрика #AI4SDLC) Во втором квартале 2026 года два инженера с помощью Codex и GPT‑5.5 переписали Habitat с Python на Rust. В статье от 11 сентября OpenAI сообщила: Rust уже обслуживает 95% запросов этого сервиса. Habitat — это слой между ChatGPT, Codex и хранилищами: маршрутизация, права доступа, шифрование и правила размещения данных. И это интересный кейс AI-assisted миграции критической инфраструктуры, причем миграции масштабной — по данным OpenAI: почти 40 регионов, свыше 500 ПБ и 70 млн внутренних запросов в секунду. Компания заявляет выигрыш в эффективности CPU в 6 раз, памяти — в 15, правда, методики сравнения в статье нет. Но изюминка здесь — в том, как ребята дошли до момента, когда переписывание стало правильной следующей задачей. 1️⃣ В 2023 году Habitat начинался как Python-библиотека над Cosmos DB. Она прятала детали хранения от продуктовых команд. Удобно: подключил библиотеку и работаешь с данными, не разбираясь каждый раз с маршрутизацией и авторизацией. 2️⃣ К середине 2025-го эта простота стала дорого обходиться. Новую логику приходилось раскатывать через десятки сервисов. Добавили проверку на теневом трафике — ещё несколько дней согласований. Исправили ошибку — новый круг. А потом одна команда откатила свой сервис по другой причине и вернула старый баг. Получили именно тот сбой, от которого пытались защититься. 3️⃣ Общая библиотека перестала быть удобной границей управления — Habitat выделили в сервис: теперь изменения хранения, наблюдаемость и политики доступа можно было контролировать централизованно. — И тут команда сознательно оставила Python. Сначала требовалось стабилизировать платформу и API, разблокировать продуктовую разработку. За эффективность решили заплатить позже, рассчитывая в том числе на развитие кодинг-моделей. Техдолг здесь был осознанным выбором порядка работ. — При этом API намеренно сделали менее мощным. Простые операции над объектами и связями, предсказуемый объём работы, никаких произвольных SQL-запросов и неограниченных обходов графа. Объект и его связи лежат в одной партиции; соседние объекты могут оказаться в другом регионе. Красивый граф в модели данных ещё не обещает дешёвого обхода. — Для сложных запросов — отдельные экземпляры Rockset, получающие изменения через CDC. Их масштабируют сами команды. Да, клиентам добавили хлопот. Зато цена сложного запроса становится их явной задачей, а аналитика изолирована от оперативного доступа к данным. 4️⃣ Следующий вызов — хвостовые latency внутри самого сервиса База уже ответила, но занятый asyncio-цикл ещё не дал обработать результат. Команда стала измерять задержку планирования задач. Даже периодический разбор большого конфига feature flags оказался источником тормозов: помогли уменьшение конфига и разнесение обновлений во времени. А пул соединений с LIFO создал совсем неприятную петлю: медленный сервер позже возвращал соединение, оно первым использовалось снова, и перегруженный процесс получал ещё больше работы (это была ситуация с метастабильными отказами). Переход на FIFO разорвал эту обратную связь. 5️⃣ До Rust дошли уже с работающей платформой и понятными ограничениями. Python-версия на пике обслуживала более 20 млн запросов в секунду. Дальше пришло время снижать ресурсную цену этой архитектуры. Поэтому «два инженера переписали сервис» — финал длинной истории. До него пришлось определить границы ответственности, ограничить стоимость операций и разобраться с поведением системы под нагрузкой. В общем, AI помог переписать реализацию, но сам кейс гораздо интереснее. #AI4SDLC #Architecture #PlatformEngineering #Engineering #Rust #AI

Codex: почему дешёвые переделки не отменяют архитектуру (Рубрика #AI4SDLC) Агенты удешевляют переделку систем, но хорошие границы и архитектура от этого становятся только важнее. Раньше команда росла постепенно, вместе с ней появлялись договорённости и документация. Теперь, по образному сравнению Тибо Соттьо, за выходные к проекту можно подключить сотню агентов. И все они начнут что-то менять. Хорошо бы к этому моменту понимать, что мы строим и как эти изменения должны уживаться друг с другом. Это интересная линия в интервью Building Codex with Tibo Sottiaux, которое вышло 9 сентября на The Pragmatic Engineer. Тибо — один из создателей Codex, сейчас руководит Core Products & Platform в OpenAI. Разговаривает с ним Gergely Orosz, чей доклад «замедлиться, чтобы ускориться» я уже разбирал. У Тибо хорошо прослеживается интерес к инструментам, которые помогают другим работать быстрее. В DeepMind он занимался инфраструктурой для исследователей. По его рассказу, из интерфейса для экспериментов с языковыми моделями вырос внутренний чат, которым коллеги активно делились ещё до выхода ChatGPT. Но превратить его в публичный продукт не удалось: Тибо связывает это с устройством Google и сложностью выпуска новых продуктов (но он сам признаёт, что ранние модели были довольно бестолковыми и это историю стоит читать с этой оговоркой). В OpenAI он пришёл в 2024 году ради более тесной связи исследований и продукта. Снова начал с инфраструктуры, а затем вместе с коллегами стал обучать модели работать с внутренним Python-кодом и собирать агентов для ускорения исследований. Эти эксперименты объединились с направлением Autonomous Software Engineer и стали одной из основ Codex. Причём Тибо признаёт, что ранняя облачная версия не нашла product-market fit: слишком много трения для пользователя. Внутри полезно — ещё не значит, что снаружи удобно. Дальше в разговоре есть несколько деталей о том, как это меняет саму разработку: 🔸 Архитектура нужна и самому агенту Ядро Codex отделили от интерфейсов и написали на Rust ради надёжности, безопасности и эффективности. Хотя тогда модели лучше писали на Python и TypeScript. Команда заранее думала о том, как агент будет работать в разных продуктах и масштабироваться. 🔸 Часть обвязки должна уметь отмирать Harness — окружение с инструментами и инструкциями — компенсирует слабости модели. Сначала ей приходится напоминать запускать тесты, потом это поведение появляется в самой модели. Тибо описывает совместную работу инженеров и исследователей: где исправлять проблему и сколько ждать следующую модель. Ты можешь написать большой обходной механизм, который через месяц уже не понадобится. 🔸 Code review смещается к намерению и контрактам По словам Тибо, в OpenAI автоматизируют проверки корректности и безопасности; найденные проблемы безопасности блокируют PR. Человеческое обсуждение он предлагает сосредоточить на том, что компонент должен делать, какие данные может использовать и какие инварианты обязан сохранять. Об этом полезно договориться до генерации реализации. 🔸 Агенту нужна история решений Внутри OpenAI Codex подключён к коду, Slack и документам. При объединении Codex с ChatGPT он даже вёл хронику обсуждений и выбранных решений. Получается интересное применение агента: помогать команде восстанавливать, почему система стала именно такой. Это продолжает тему AI для software architecture: границы, ограничения и история компромиссов должны быть доступны для работы. А рядом остаётся вопрос из разбора Geoffrey Litt про понимание: что из этого способна объяснить сама команда? По оценке Тибо, обслуживание и смена архитектуры сильно дешевеют. Но в его рассуждении есть условие: хорошие абстракции позволяют менять внутренности компонента, не задевая всё вокруг. #AI4SDLC #AI #Agents #Architecture #Engineering

Залетайте на прямой эфир с Кириллом Евсеенко, техническим директором Звука. Мы с Кириллом планируем обсудить его карьеру, а также ответить на вопрос, а где у CTO больше свободы - в стартапе или в корпорации. Если будет вопросы, то мы с удовольствием по ходу будем на них отвечать.

[2/2] DistServe: параллелизм, очереди и баланс GPU (Рубрика #Research) В первой части поста мы остановились на разделения prefill и decode. И после этого у нас появляется свобода: каждой стадии можно выделить свои GPU и по-своему распределить модель. Теперь эту свободу надо превратить в работающую конфигурацию. Есть два подхода к параллелизму: - Intra-op делит одну операцию, например умножение матриц, между GPU. В этом контексте — tensor parallelism. Отдельный шаг выполняется быстрее, но GPU часто обмениваются данными. Ускорение зависит от того, сколько съедает коммуникация. - Inter-op делит слои модели на стадии конвейера — pipeline parallelism. Пока одна GPU обрабатывает следующий запрос, другая заканчивает предыдущий. Запрос всё ещё проходит все стадии; зато конвейер пропускает больше запросов. Расплата — простои, если стадии загружены неравномерно. То есть можно ускорять прохождение одного запроса, а можно увеличивать частоту, с которой конвейер принимает следующие. Под нагрузкой второй вариант тоже сокращает задержку: меньше времени уходит на ожидание входа. Здесь авторы достают из чулана теорию очередей. Для начала они упрощают prefill: одинаковые промпты, постоянное время обработки D, пуассоновский поток R запросов/с, одна обслуживающая очередь без батчинга. Получается модель M/D/1: TTFT = D + R·D² / [2·(1 − R·D)] Это среднее время: вычисление плюс ожидание. Формула работает при R·D < 1. Если D = 100 мс, при 5 запросах/с среднее TTFT составит 150 мс, а при 9 запросах/с — 550 мс. Само вычисление осталось тем же. Выросла очередь. Для двух GPU авторы сравнивают: - intra-op: D/K + R·D² / [2K·(K − R·D)] - inter-op: D + R·D² / [4·(2 − R·D)] K — ускорение intra-op, здесь между 1 и 2. Во втором случае предполагаются две равные стадии и пренебрежимо малый обмен между ними. Каждая формула применима, пока соответствующая очередь устойчива. При редких запросах intra-op выигрывает за счёт быстрого вычисления. По мере роста потока inter-op может выиграть за счёт очереди. Очень строгий TTFT снова делает скорость отдельного запроса критичной. У decode свой баланс: размер батча, память под кэш и требование к TPOT. Правила «prefill всегда так, decode всегда иначе» здесь нет. Но реальные промпты и ответы разной длины, а сервису нужна заданная доля запросов в SLO. Одной формулы среднего недостаточно. Поэтому дальше ребята переходят к симуляции нагрузки. DistServe использует модель времени вычислений и профиль запросов: интенсивность поступления, распределения длин входа и выхода. Перебирает допустимые конфигурации параллелизма и размещения, а бинарным поиском находит поток, при котором ещё соблюдается целевой SLO attainment. Затем подбирает число экземпляров стадий под требуемую нагрузку. При медленной сети варианты prefill и decode приходится выбирать совместно. Получается баланс для конкретной модели, железа, нагрузки и SLO. Когда профиль меняется, расчёт надо повторять. Формулы объясняют механизм, симулятор помогает выбрать конфигурацию; проверка на настоящем кластере остаётся необходимой. В продолжении рассмотрении этой темы дальше я планирую прочитать несколько статей и потрогать llm-d. План примерно такой - Splitwise, ISCA 2024 — соседняя работа про выбор разного железа для фаз, стоимость и энергопотребление. - Sarathi-Serve, OSDI 2024 — другая ветка: дробить prefill на части и совмещать их с decode через планирование батчей. - Mooncake, FAST 2025 — другой масштаб: распределённый KV-кэш, его хранение и повторное использование становятся центром архитектуры. А в мае 2025-го llm-d уже предложил объединять disaggregated serving и маршрутизацию с учётом кэша с Kubernetes-инфраструктурой. Так что через эти работы можно пройти путь от разделения двух стадий до управления вычислениями и состоянием всего кластера. #Research #AI #Architecture #Engineering #DistributedSystems

Кстати, выпуск 3 AImigo про джунов стартанул.

Материалы выпуска: первые 90 дней CTO (Рубрика #Leadership) Собрал материалы сольного выпуска Code of Leadership «Первые 90 дней CTO». Эфир прошёл 9 сентября 2026 года — это расширенная версия доклада, который я рассказывал на мероприятии Стратоплана. Начинаю с того, что первый рабочий день — уже середина перехода. Компания выбрана, ожидания сформированы, о части полномочий вы уже договорились. А о части, возможно, решили поговорить потом. Вот это «потом» и может оказаться самым интересным местом испытательного срока :) В выпуске разобрал: - Что скрывается за названием CTO. Главный архитектор, партнёр продукта, руководитель масштабирования и человек, которого зовут разбираться с кризисом, — очень разные работы. Как заранее понять, какая из них нужна компании, и проследить связь технологий с деньгами бизнеса. - О чём договориться до выхода. Какого результата ждут через 30 и 90 дней, что вы можете менять самостоятельно, какие есть бюджет и кадровые полномочия, кто поддерживает изменения. Это важно и при внутреннем повышении: знакомая компания не делает договорённости очевидными. - Как провести первый месяц. С кем поговорить, на какие рабочие процессы посмотреть и как отделять факты от чужих интерпретаций. Фраза «в прошлой компании мы делали так» легко мешает увидеть, что здесь устроено иначе. При этом срочные угрозы безопасности и непрерывности бизнеса не ждут конца диагностики. - Что выбрать на дни 30–90. Одно-два изменения с понятной болью, владельцем и наблюдаемым результатом. Как проверить гипотезу в пределах испытательного срока, заработать доверие и не замкнуть все решения на себе. - Что делать, если обещания разошлись с реальностью. Мандат сузился, бюджет не появился, поддержка исчезла. Как назвать расхождение, зафиксировать его и поставить срок для новой договорённости, пока ответственность ещё можно привести в соответствие с полномочиями. Моя рамка здесь — испытательный срок проходит и компания. Она тоже проверяется: можно ли в ней решить ту задачу, ради которой вас нанимали. Материалы выпуска: 📌 Страница выпуска с таймкодами и слайды доклада 📖 Лонгрид о переходе в роль CTO 🎬 YouTube, VK Видео 🎧 Podster, Яндекс Музыка, Apple Podcasts 📝 Конспект эфира Какая договорённость при выходе на руководящую роль у вас оказалась самой важной — или выяснилось, что её стоило обсудить заранее? Делитесь в комментариях. #CodeOfLeadership #Management #Leadership #CTO #Career #Engineering

Randy Shoup про eBay: инженерия ускорилась, а система — нет (Рубрика #Management) Супер-крутой доклад — прямо много попаданий в реальность. Пока слушал, то и дело ловил дежавю. И у этой истории есть первый акт: в 2023 году я уже разбирал, как Randy Shoup с командой удвоил engineering productivity в eBay. Новый доклад — неприятный второй акт. Техническая трансформация сработала, а траектория бизнеса и культура руководящего слоя, по оценке Шоупа, почти не изменились. Шоуп был Chief Architect и VP of Platform Engineering в eBay в 2020–2022 годах. По его данным, инициатива Velocity дала 2× по числу features и bug fixes на единицу времени. Deployment frequency выросла в 10 раз, lead time сократился с 10 до 2 дней, change failure rate и time to recover улучшились втрое. Это цифры из доклада и слайдов, а не независимый аудит. Но масштаб всё равно впечатляет: около 5000 инженеров в компании; Velocity со временем охватила 400 продуктовых команд и 4500 приложений и сервисов. Секретного фреймворка не было. Команды спрашивали: если завтра придётся выкатываться ежедневно, что именно вам помешает? Ответы становились бэклогом Platform Engineering. Дальше — сокращение build, test и PR validation time, автоматизация deployment и обновлений, общая staging-среда, DORA как outcome-метрики и developer friction как входной сигнал. Но важнее инструментов была механика взаимодействия. Сильных IC из платформы встраивали в продуктовые команды, руководители синхронизировались ежедневно, команды делились локальными автоматизациями, а Security, Compliance, Accessibility и Localization переставали быть внешними «воротами» и становились участниками улучшения потока. Начали с пилотов, затем расширялись квартальными когортами и повторяли цикл: нашли bottleneck, сняли, посмотрели, кто теперь получил повышение. А затем Шоуп задаёт неприятный вопрос: если инженерная продуктивность выросла вдвое, почему это не развернуло бизнес? Его ответ состоит из трёх слоёв. 1️⃣ Стратегия и планирование Годовой план собирался централизованно и надолго. Работа получала деньги, только если была достаточно большой для executive-level инициативы; небольшие изменения выживали как «прицеп» к гигантским программам. Новые знания появлялись, а курс уже нельзя было менять. 2️⃣ Execution Нормой оставались релизы на десятки команд и годы работы. Вознаграждалось выполнение обещанного списка, а не изменение клиентской или бизнес-метрики. То есть feature factory стала выпускать больше features — ровно как и было заказано. 3️⃣ Культура Используя типологию Ron Westrum, Шоуп описывает её как pathological: страх ошибок, поиск виноватого, zero-sum борьба руководителей за scope и headcount, Not Invented Here. В такой системе осторожность — не дефект отдельных людей, а рациональная стратегия выживания. Вот здесь дежавю становится особенно сильным. Ускорить CI/CD политически проще, чем изменить бюджетный процесс, права на решения и систему стимулов. Можно дать командам прекрасную дорогу, но если маршрут определён 18 месяцев назад, они просто быстрее приедут не туда. В ретроспективе Шоуп считает, что поддержки CEO сверху и энтузиазма команд снизу оказалось недостаточно: трансформации нужен ещё middle-out — союз с peer-руководителями, чьи границы и стимулы она неизбежно затрагивает. Его рассказ об увольнении и культуре — личная версия событий, не независимое расследование. Но именно поэтому доклад хорош: автор не продаёт очередной transformation playbook, а честно показывает предел уже успешного. И да, в 2026 году невозможно не увидеть продолжение про AI. Если агенты ускорят производство кода, но не выбор задач, обратную связь и принятие решений, feature factory просто получит двигатель помощнее. Поэтому до вопроса «насколько мы ускорились?» стоит задать другой: «а инженерная скорость вообще ограничивает результат всей системы?» #Management #Leadership #Culture #DevOps #PlatformEngineering #Engineering #Metrics

AI4SDLC на ИТ-Пикнике: материалы выступления (Рубрика #AI4SDLC) Собрал материалы моего выступления на ИТ-Пикнике 8 августа — «State of AI4SDLC: AI сдвигает узкие места разработки». Это было моё последнее выступление от имени Т-Банка. В нём я подвёл итог AI4SDLC в том виде, в котором развивал это направление: с исследованием, инженерной платформой, агентами и перестройкой работы команд. В докладе разбираю, что происходит после того, как код научились писать быстрее. Задачи начинают скапливаться на ревью и тестировании, а дальше выясняется, что ограничением стали постановка и приёмка результата. Выдать всем AI-инструменты — только начало работы. Отсюда и остальные темы: зачем снова нужны спецификации, как подготовить внутреннюю платформу к работе агентов, почему стоит измерять ожидание, переделки, качество и стоимость. И как меняется работа инженера, который всё больше формулирует задачи, собирает контекст и проверяет сделанное агентами. Материалы можно открыть в удобном формате: — Слайды — Видео выступления — Конспект и сокращённая расшифровка — около 7 минут чтения, подготовлены по субтитрам и слайдам. #AI4SDLC #Agents #PlatformEngineering #Conference

ArchDays в эпоху AI (Рубрика #Architecture) Я в программном комитете ArchDays с 2019 года, с основания конференции. Мне кажется, в эпоху AI такие встречи особенно важны. Когда AI пишет код, вопросы к архитектору только прибавляются. Как поставить задачу, чтобы результат можно было проверить? Где нужны ревью и участие человека? Кто отвечает за решение, которое предложил агент? Быстрее получить код — еще не значит быстрее получить работающую систему. Поэтому для меня архитектурная конференция сегодня — это возможность не просто узнать про новые технологии, но и разобраться в редизайне инженерных процессов: от требований и экспериментов до проверки изменений и эксплуатации. А еще — понять, как меняется профессия архитектора. Думаю, все больше внимания придется уделять тому, как люди и AI вместе принимают решения и проверяют их последствия. Здесь полезно сравнить опыт команд, обсудить ошибки и поспорить с коллегами. ArchDays — 27 ноября 2026. Приходите обсуждать. P.S. Я хотел по традиции выступить на этой конфе, но я буду уже не в Москве, а она полностью в оффлайне. Но думаю, что мы с Сережей Барановым придумаем как мне рассказать свой доклад может быть не в рамках конфы, а в виде отдельного онлайн эфира на youtube канале Archdays. #AI #Engineering #Conference

Материалы выпуска: продуктовый инженер — разговор с Глебом Михеевым (Рубрика #Leadership) Собрал материалы разговора с Глебом Михеевым, CPO ГигаАгента в Сбере. Эфир Code of Leadership прошёл 8 сентября 2026 года. Говорили о том, что происходит с работой инженера, когда можно быстро получить несколько работающих реализаций — и всё равно остаётся вопрос, какую из них вообще стоило делать. Глеб рассказал, как на полгода вернулся из менеджмента в индивидуальную инженерную роль и каждый день работал с агентами. Из этого опыта вырос разговор о продуктовой ответственности, устройстве команд и обучении. Обсудили: - Продуктового инженера. Понять проблему пользователя, предложить решение, выпустить его и собрать обратную связь. Как дать человеку такую ответственность и не навесить на него несколько прежних должностей с прежней нагрузкой. - Очередь после ускорения. В разговоре есть хороший мысленный пример: если разработка ускорилась в пять раз, нижние четыре пятых старого бэклога от этого полезнее не стали. Дальше упираемся в выбор гипотез, проверку результата и эксплуатацию. - Размер команды и границы специализации. Глеб считает, что агенты позволят небольшим командам закрывать больше работы. Но для платёжных и других критичных систем он делает оговорку: там цена ошибки требует более строгой проверки и сохранения специализации. - Рост джунов. Готовый pull request уже мало говорит о том, чему человек научился. Как проверить, что он может объяснить устройство решения, заметить ошибку и разобраться, если условия задачи изменились. - Переучивание опытных разработчиков. Как перестроить привычку делать всё руками, сохранить инженерное суждение и не застрять в бесконечном цикле «ещё одну задачу агенту — и спать». Материалы выпуска: 📌 Страница выпуска с таймкодами 🎬 YouTube, VK Видео 🎧 Podster, Яндекс Музыка, Apple Podcasts 📝 Текстовый конспект #CodeOfLeadership #AI4SDLC #Engineering #Product #Leadership #Career