Книжный куб

Где профит от данных, Лебовски? Материалы первого выпуска (Рубрика #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

[1/2] DistServe: зачем разделять prefill и decode (Рубрика #Research)

Этот пост посвящен статье DistServe от команды из Peking University, UC San Diego и StepFun, опубликованной на OSDI 2024. Причем в разборе llm-d я уже рассказывал про разделение prefill и decode. А в работе DistServe очень хорошо разобрана инженерная сторона этого решения: что выигрываем, когда разносим стадии по разным GPU, и чем за это платим. Помимо самой статьи есть и открытый код который позволяет не только посмотреть на результаты авторов, но и почитать при желании код.

Если возвращаться к основной теме, то у запроса к LLM есть две довольно разные части:
- Prefill обрабатывает входной текст, вычисляет KV-кэш и первый токен ответа. Позиций много, их можно обрабатывать параллельно; при достаточно длинном промпте стадия обычно упирается в вычислительную мощность.
- Decode выпускает следующие токены по одному на запрос. При небольшом батче вычислений относительно мало, а веса и кэш приходится читать из памяти снова и снова. Здесь ограничением часто становится её пропускная способность. Объединение запросов в батч помогает эффективнее использовать GPU.

Когда обе стадии живут вместе, новый тяжёлый prefill задерживает уже идущую генерацию. Даём приоритет decode — новые пользователи дольше ждут начала ответа. Плюс обеим стадиям достаётся одна конфигурация параллелизма, хотя потребности у них разные.

В DistServe процесс выглядит так: Запрос → очередь prefill → обработка промпта и первый токен → передача KV-кэша → очередь decode → генерация остальных токенов.

У prefill- и decode-экземпляров свои копии весов модели. KV-кэш содержит промежуточные ключи и значения attention: с ними другая GPU продолжает вычисление, не обрабатывая промпт заново. Prefill и decode теперь можно отдельно масштабировать и настраивать.

Дальше начинается знакомая жизнь распределённой системы: появились сеть, дополнительная память и ещё одно место, где может вырасти очередь :)

Для OPT-66B авторы оценивают кэш промпта из 512 токенов примерно в 1,13 ГБ. При 10 запросах/с это около 90 Гбит/с только на кэш. Причём совпадения средней потребности с полосой мало: всплескам нагрузки нужен запас. Если decode принимает работу медленнее prefill, готовые кэши тоже начинают ждать и занимать память.

Поэтому DistServe учитывает топологию. При медленной сети между серверами соответствующие стадии prefill и decode размещаются на разных GPU внутри одного сервера, чтобы передавать кэш по NVLink. В их измерениях более 95% запросов передавали кэш менее чем за 30 мс.

Цель авторов — goodput на GPU: предельный поток запросов при заданной доле соблюдения требований к задержке (SLO). Проверяются TTFT (time to first token) — время до первого токена — и TPOT (time per output token), среднее время на следующий токен. Обычно целевая доля — 90% запросов. Средний TPOT, кстати, ещё не гарантирует отсутствие отдельных пауз в генерации.

Они проверяли свой подход на OPT-13B/66B/175B, кластере из 32 A100 и данных для чата, дополнения кода и суммаризации. В чатовых тестах получили в 2–4,6 раза больший поток на GPU относительно тогдашнего vLLM; максимум 7,4 раза — относительно DeepSpeed-MII. Это выигрыш всей конфигурации при выбранных SLO. Времена поступления запросов синтезировали, а пороги задержки задали сами; переносить множители на произвольный сервис нельзя.

Остаётся самая интересная часть: сколько GPU выделить каждой стадии и как разложить на них модель. Во второй части поста будет рассказ про intra-op, inter-op и теорию очередей, которая помогает понять, почему самый быстрый отдельный запрос ещё не определяет лучшую конфигурацию сервиса.

#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

Stanford MS&E435: от мегаватта до молекулы — весь курс в девяти разборах (Рубрика #AI)

С курсом Stanford MS&E435 «Economics of the AI Supercycle» в канале всё: девять лекций — девять разборов, от экономики GPU и строительства дата-центров до кодинговых агентов и разработки лекарств. Курс интересен тем, что не пытается выбрать «лучшую модель», а рассматривает AI как большую производственную и экономическую систему. На каждом слое повторяются одни и те же вопросы: где сейчас бутылочное горлышко, кто оплачивает капитальные затраты, что становится commodity, а у кого остаются влияние на цены, данные и замкнутый цикл обратной связи.

Если сложить лекции вместе, бутылочное горлышко всё время переезжает: из чипов — в электричество и готовые дата-центры, затем в корпоративный контекст, человеческое внимание, evals, дистрибуцию и лабораторный эксперимент. Вместе с ним перемещается и граница между тем, что компания может купить как услугу, и тем, что ей приходится контролировать самой.

Все разборы по порядку:

1️⃣ Экономика AI-суперцикла — вводная лекция интересна картой всего стека chips → infrastructure → models → applications и вопросом, почему основная экономика пока сосредоточена внизу.
2️⃣ Inference как производственная система — разговор с Sunny Madra и Brad Gerstner показывает, почему prefill и decode могут требовать разного железа, а считать полезнее стоимость проверенного результата, а не число сожжённых токенов.
3️⃣ Дефицитный мегаватт AI-фабрики — Чейз Локмиллер из Crusoe опускает «облачный AI» на землю: к подстанциям, охлаждению, стройке и дефициту площадок, где GPU вообще можно включить.
4️⃣ Али Годси: AGI уже здесь, а компания — ещё нет — лекция интересна кейсом Databricks, в котором заметный рост throughput появился после перепроектирования процесса, а не после замены модели.
5️⃣ Sachin Katti и человек как bottleneck AI-системы — взгляд оператора frontier-лаборатории связывает динамические агентные нагрузки, гетерогенную инфраструктуру и цену человеческого внимания, проверки и ответственности.
6️⃣ Yash Patil: внутреннее знание компании как learning loop — здесь корпоративная экспертиза превращается из абстрактного «контекста» в evals, reward, post-training и воспроизводимый цикл обучения.
7️⃣ Кто выбирает технологический стек — разработчик или кодинговый агент? — Guillermo Rauch показывает, как агент становится новым gatekeeper, а open source, документация и агентная эргономика — каналом дистрибуции.
8️⃣ Baseten и как юнит-экономика меняет стратегию — история полезна симметрией: по мере роста приложение забирает под контроль модели, а инфраструктурная платформа — вычислительные мощности.
9️⃣ Chai и Claude: кто заберёт деньги в AI-биотехе? — финальная лекция переносит ту же экономическую рамку в drug discovery, где ценность зависит не от красивой молекулы, а от замкнутого цикла гипотеза → дизайн → эксперимент → данные и прав на результат.

Это не нейтральный учебник: среди гостей инвесторы, основатели и руководители компаний, которые продают ровно те слои стека, о которых рассказывают. Но если отделять механизм от vendor pitch, получается редкая сквозная карта AI — от электронов до молекул.

Если времени на весь плейлист нет, выбирайте слой, за который отвечаете. А если есть — я бы шёл по порядку: так особенно хорошо видно, как дефицит и ценность путешествуют по стеку.

#AI #Engineering #Infrastructure #Product #Strategy #Economics

3 AImigo S1E5: джун без простых задач. Как войти в IT в эпоху AI?

Начать делать продукты в IT стало проще. Начать получать за это деньги — сложнее. AI-агенты уже справляются с багфиксами и небольшими фичами, на которых джуны раньше «тренировались на кошечках». А если простые задачи исчезают, то как теперь вырастить следующего инженера?

В пятницу в 12:00 в пятом выпуске 3 AImigo продолжаем разговор о найме, но смотрим на него со стороны тех, кто только выбирает профессию, заканчивает университет или пытается получить первую работу.

У привычной лестницы "junior → middle → senior" сломалась нижняя ступень. Индустрии всё ещё нужны новые инженеры, но отдельному бизнесу выгоднее усилить опытного специалиста агентами, чем годами растить новичка. Для индустрии это риск, для джуна — новая реальность.

Обсудим, что может стать рабочим входным билетом:
— собственный end-to-end проект: от проблемы и критериев приёмки до production, поддержки и плана отката;
— умение не просто получить код, а объяснить решение агента, проверить его и принять ответственность;
— способность учиться: находить пробелы, задавать вопросы и встраивать ответы, а не складывать их в чек-лист;
— интерес к бизнесовой задаче и пользователю, а не только к технологии;
— отношения с людьми и профессиональное сообщество — этот путь никуда не исчез.

Как обычно, разбираемся втроём: Евгений Сергеев, Алексей Литвинов и Александр Поломодов.

#AI #AI4SDLC #Agents #Engineering #Career #Education

Заходите на прямой эфир про первые 90 дней CTO, которые начинаются задолго до выхода на работу:) 40-минутную версию этого доклада я рассказал на мероприятии Стратоплана, а теперь я расскажу расширенную версию + поотвечаю на ваши вопросы.

PyTorch как слой переносимости: зачем туда пришли Cambricon и Ant Group (Рубрика #AI)

В этой новости легко зацепиться за геополитику: Alibaba Cloud, Ant Group, Cambricon и Huawei вместе выступили на PyTorch Conference China в Шанхае. Но мне здесь интереснее другой вопрос. Зачем производителю собственных AI-ускорителей платить $350 тысяч в год за Platinum-членство в PyTorch Foundation, если код PyTorch и так открыт?

Сначала поправлю новостную оптику. Не все четыре компании «только что вошли в PyTorch». Cambricon объявили Platinum-участником 7 сентября 2026 года, Ant Group — Gold-участником 8 сентября. Alibaba Cloud состоит в Foundation с 26 мая 2026 года, Huawei — с 17 октября 2023-го. Свежая часть истории — Cambricon и Ant, а общий шанхайский анонс собрал китайский AI-стек на одной сцене: модели Qwen, облачную инфраструктуру, чипы MLU и Ascend, а также runtime для агентов.

Моя интерпретация: китайские компании покупают не контроль над PyTorch, а место за столом, где снижают стоимость ухода от CUDA.

За $350 тысяч Platinum-участник получает по голосующему месту в Governing Board и Technical Advisory Council. Gold-членство стоит $150 тысяч, но отдельного кресла Ant не гарантирует: Gold-компании выбирают одного представителя на троих. Это влияние на бюджет, рабочие группы, CI и общие приоритеты экосистемы. Но не право нажимать Merge: техническое управление PyTorch закреплено за конкретными maintainers на основе вклада, а не за компаниями по уровню взноса.

И вот здесь начинается действительно важная часть. Проблема альтернативного AI-чипа — не только в FLOPS. Нужны операторы, compiler, distributed collectives, профилировщик, интеграции с библиотеками и синхронизация с каждым новым релизом PyTorch. Именно этот длинный программный хвост превратил CUDA в moat, который нельзя догнать одной красивой таблицей производительности.

PyTorch постепенно строит общий слой подключения ускорителей через PrivateUse1, эталонный backend OpenReg и Accelerator Integration Working Group. Идея в том, чтобы модель и большая часть прикладного кода видели единый PyTorch API, а CUDA, ROCm, CANN или Neuware оставались ниже. Тогда производители конкурируют уже качеством backend: покрытием операторов, поддержкой torch.compile, стабильностью distributed training и скоростью выпуска обновлений.

Но до взаимозаменяемости ещё далеко. Cambricon сейчас требует отдельный пакет torch_mlu и vendor-компоненты CNToolkit, CNNL и CNCL. Huawei продвинулась дальше: Ascend уже есть в публичной CI рабочей группы, но torch_npu всё равно устанавливается отдельно и зависит от CANN. Иными словами, общий фасад появляется, а под ним пока остаются разные лестницы, ключи и инструкции по эвакуации :)

Ant Group здесь про соседний слой. Компания показала runtime для AI-агентов на базе Kubernetes Agent Sandbox и Kata Containers. Это не вклад в PyTorch core и не ускоритель; скорее признак того, что вокруг Foundation начинают собирать более широкий open-source AI stack — от tensor runtime до изолированного выполнения агентов. Общей технической архитектуры четыре компании пока не объявили.

Поэтому смотреть я бы стал не на число китайских логотипов в Foundation, а на три скучных инженерных сигнала:
1️⃣ Появится ли Cambricon MLU в общей публичной CI рядом с Ascend;
2️⃣ Смогут ли torch_mlu и torch_npu поддерживать актуальный стабильный PyTorch без специальных сборок и долгого отставания;
3️⃣ Будут ли приниматься upstream-изменения в Inductor, distributed stack и domain libraries, а не только расти внешние vendor-репозитории.

Если это произойдёт, PyTorch станет для AI-железа настоящим слоем переносимости и немного уменьшит программный lock-in NVIDIA. Не отменит CUDA, её зрелые kernels, NCCL и инструменты — именно уменьшит цену первого шага в сторону другого ускорителя. Если нет, членство останется дорогим логотипом на сайте.

#AI #OpenSource #PlatformEngineering #Infrastructure #Architecture #Bigtech

Заходите на очередной прямой эфир Code of Leadership, что стартует прямо сейчас.
Сегодня мы с Глебом Михеевым (@tired_glebmikheev) поговорим про то как, поменяется роль программистов в ближайшие три года и обсудим концепцию продуктового инженера.

Ollama: как агенты меняют экономику открытых моделей (Рубрика #AI4SDLC)

Этот выпуск YC Lightcone с сооснователем Ollama Джеффом Морганом хорошо собирает несколько тем, которые в канале до этого жили отдельно: экономику токенов, локальные модели, routing и быстро меняющуюся агентную обвязку. Ценность разговора для меня в том, что знакомая архитектурная схема уже превращается в устройство рынка.

Тезис Моргана такой: агенты резко увеличивают потребление токенов, поэтому использовать дорогую frontier-модель для каждого промежуточного шага становится бессмысленно. Большой объём работы заберут дешёвые открытые модели, а самые сильные закрытые останутся для сложных решений и эскалации.

В выпуске прозвучали несколько оценок Ollama
1️⃣ С начала 2026 года общий объём токенов в Ollama Cloud, по данным компании, вырос примерно в 150 раз. Это внутренняя метрика Ollama, а не независимый замер эффективности.
2️⃣ Морган прогнозирует, что открытые модели смогут выполнять 80–90% корпоративных токенов, получая лишь 10–20% общего AI-бюджета. Пока это гипотеза участника рынка, но асимметрия интересная: массовая работа и основная маржа могут оказаться в разных слоях.
3️⃣ Архитектура будет гибридной: простые и чувствительные задачи можно исполнять локально, тяжёлые — отправлять в облако, сохраняя общий интерфейс.

Многое здесь подтверждает то, о чём я писал раньше. [Цена токена плохо описывает экономику агента: считать нужно завершённую и принятую задачу вместе с проверкой, повторами и последствиями ошибки. Сам рост token volume тоже нельзя путать с ростом ценности — в разборе данных OpenCode я отдельно показывал, как на объём влияют длина сессий, кеш и небольшая группа тяжёлых пользователей.

Routing тоже уже перестал быть красивой схемой на слайде. AT&T описывает 45 млрд токенов в день, cache-aware router и экономию до 90% на своих сценариях. А в истории OpenCode мы видели ту же продуктовую ставку: агрегировать спрос, проверять связки «модель + провайдер» и давать приложению переключаться между моделями.

Что для меня здесь новое

1️⃣ К приватности и суверенности как причинам выбирать открытые модели добавляется агентная экономика. Когда один запрос превращается в сотни model calls, дешёвый исполнитель нужен уже для масштабирования самого цикла.
2️⃣ Ollama хочет зарабатывать на самом скоропортящемся месте стека — совместимости модели, inference engine, железа, облачной ёмкости и agent harness в день релиза. Я недавно писал, что generic harness разумно арендовать, оставляя своими задачу, контекст и evals. Ollama пробует стать поставщиком похожего изменчивого слоя этажом ниже.
3️⃣ Яснее разошлись роли знакомых инструментов. LM Studio тяготеет к персональной рабочей среде, vLLM — к производительному serving engine, а Ollama претендует на слой дистрибуции и совместимости между локальным запуском, облаком и агентными приложениями. Поэтому её сравнение с Docker здесь содержательнее обычного «ещё один способ запустить LLM».

Но open weights не делают систему автоматически локальной, дешёвой или безопасной. В разборе конфигураций агентного стека я разделял модель, harness, инструменты, identity и границы исполнения. А локальная модель просто переносит расходы из API в GPU, эксплуатацию и риск недозагрузки.

Если ставка Ollama сработает, открытые модели не уничтожат платформы. Они создадут новый класс платформ поверх взаимозаменяемых весов. И тогда компании полезно владеть не каждым компонентом, а теми слоями, где находится её реальная ценность: контрактом задачи, состоянием, полномочиями, воспроизводимыми эпизодами и outcome-evals. Остальные слои можно арендовать — но [перепроверять после каждого заметного сдвига модели и обвязки.

#AI4SDLC #AI #Agents #Architecture #PlatformEngineering #FinOps

AI для среднего бизнеса: материалы выпуска (Рубрика #AI)

Собрал материалы 75-го выпуска Code of Leadership — «Как действовать среднему бизнесу с AI, которому „по науке“ дорого?»
С Александром Воронцовым, партнёром Revelio Tech и автором AI Subjects, поговорили о компаниях, у которых нет собственной AI-лаборатории и большой команды внедрения. Зато есть падающая маржа, ручные таблицы, проблемы с ассортиментом и наймом.

В разговоре:
- Как торговая компания начала с задач сотрудников, выделила бюджет эксперимента и устроила конкурс прототипов с денежными призами;
- Зачем рядом со специалистом по AI нужен аналитик, понимающий реальные данные и особенности 1С;
- Почему автоматизация в аутстафинговой компании распалась на отдельные инициативы;
- Как получилось, что готовым агентом для товарной аналитики никто не пользовался;
- С чего начать: за одну-две недели изучить фактическую работу и выбрать одну-три задачи, которые можно улучшить сразу.

Главная мысль: AI снижает порог входа в автоматизацию. Но сотрудникам всё ещё нужно понимать, зачем менять привычный процесс, кто поможет и что они получат от этих изменений.

Подготовил и конспект на 7 минут — с кейсами, ограничениями и практическими выводами, если удобнее читать.
📌 Все материалы и таймкоды
📖 Читать конспект
🎬 Смотреть: YouTube · VK Видео
🎧 Слушать: Яндекс Музыка · Apple Podcasts · Podster

#AI #Management #Leadership #Podcast

Stanford MS&E435: Chai и Claude - кто заберёт деньги в AI-биотехе? (Рубрика #AI)

Последняя лекция курса Stanford MS&E435, о котором я писал посвящена теме life sciences и здесь обсуждается вопрос где в AI-стеке экономика. В биотехе один удачный результат может стоить десятки миллиардов, но между демкой и продажами — годы биологии, клиники и регуляторики. Ведущий Apoorv Agrawal разговаривает с Joshua Meier, сооснователем Chai Discovery, и Eric Kauderer-Abrams, Head of Life Sciences в Anthropic. Они предлагают не «лекарство по одному промпту», а новую архитектуру R&D.

Как выглядит обычный процесс
Если сжать его до одной строки: болезнь и группа пациентов → биологическая мишень → тип терапии → первый hit → оптимизированный lead → кандидат в лекарство → доклиника → фазы I–III → регистрация и производство

Путь нередко занимает 10–15 лет, а программа может умереть на любой ступени: неверная мишень, токсичная или непроизводимая молекула, отсутствие эффекта в клинике. Поэтому: binder ≠ кандидат в лекарство ≠ лекарство.

Что предлагают Chai и Anthropic
1️⃣ Chai строит «CAD для молекул» — внутренний контур. Модель получает структуру мишени и проектирует антитела, которые должны с ней связаться. В собственном нерецензированном препринте Chai-2 компания сообщает о hit rate около 16%: для 52 мишеней проверяли не более 20 дизайнов на каждую и для половины нашли хотя бы один binder менее чем за две недели. Сильный результат discovery, но ещё не доказательство эффективности лекарства.
2️⃣ Claude — внешний контур: прочитать литературу, выбрать инструмент, запустить специализированную модель, подготовить эксперимент, разобрать данные и предложить следующий шаг. Chai проектирует деталь, Claude координирует процесс, а лаборатория остаётся источником истины.

Откуда ускорение относительно стандартного процесса

- Обычный discovery перебирает большие библиотеки и повторяет цикл «синтез → тест → анализ → новый дизайн». Здесь модель сужает поиск до десятков конструкций, а агент сокращает передачи между людьми, софтом и лабораторией. Быстрее становится весь feedback loop.
- Дальше AI может помогать с мишенями и клиническими испытаниями. Eric предполагает, что полный цикл удастся сократить примерно до пяти, а затем и до нескольких лет. Пока это прогноз: биологию человека, длительное наблюдение и регулятора из конвейера не убрать.
- Лабораторной работы при этом может стать больше. Если каждый эксперимент дешевле и информативнее, выгодно проверять больше гипотез — парадокс Джевонса в халате.

Где будут деньги

- Фарма владеет кандидатом, клинической инфраструктурой, производством и продажами. Здесь пока остаётся основная ценность успешного препарата.
- Создатели инструментов — Chai, Anthropic, лабораторная автоматизация и CRO — продают доступ, вычисления и эксперименты. Чтобы забирать больше, им нужно доказать рост вероятности успеха программы. Но Eric предупреждает: продавать инструменты большой фарме — тяжёлый бизнес.
- AI-native biotech может небольшой командой владеть молекулами и лицензировать их после первых доказательств. Это максимальный upside вместе с клиническим и капитальным риском. Если дизайн станет доступен всем, moat сместится в выбор мишени, данные, лабораторный feedback loop и права на препарат.

Насколько большой рынок

IQVIA оценивает выручку глобальной life-sciences-индустрии в 2025 году примерно в $1,94 трлн, а расходы биофармы на разработку лекарств — в $199 млрд. Это разные круги: $1,94 трлн — не TAM (Total Addressable Market) для Chai или Claude. Инструменты конкурируют за часть R&D-бюджета; владелец одобренного препарата — за конечный рынок.

Масштаб разницы хорошо показывает одна молекула: tirzepatide под брендами Mounjaro и Zepbound принёс Lilly 36,5 млрд продаж за 2025 год. Поэтому главный вопрос не в том, кто первым сгенерирует красивую молекулу, а в том, кто замкнёт цикл «гипотеза → дизайн → эксперимент → данные», сохранит права на результат и доведёт его до пациента.

#AI #Biotech #DrugDiscovery #LifeSciences #Engineering #Economics