Книжный куб

Building AI-Powered Products (Рубрика #AI) Прочитал интересную книгу Marily Nika, AI Product Lead (Google, ex‑Meta) и основателя AI Product Academy. Marily рассказывает в ней про то, как выглядит отдельная дисциплина AI product management и как определить, а что именно строим, как меряем качество продукта, сколько это будет стоить в продакшене и почему пользователи не уйдут через неделю. Эта книга вышла в феврале 2025 года и пыталась выдать плейбук, который связывает идею → продуктовую ценность → архитектуру → эксплуатацию → метрики → риски. В ней рассматривались вопросы вида - Как выбирать AI сценарии, которые приносит value, а не "потому что модно" - Как думать про измерение успеха: оффлайн‑метрики, human eval, мониторинг в проде - Как оценивать trade‑offs: качество vs latency vs стоимость инференса vs риски - Как выстроить работу продакт менеджеров, инжиниринга, data science и research, чтобы ожидания совпали - Как быть с этикой и compliance: данные, приватность, "галлюцинации", ответственность за работу моделей Если говорить про содержание книги, то она состоит из preface, 8 глав и appendix. Chapter 1. The Role of AI Product Managers Здесь автор рассказывает про роль AI продакт менеджеров и как развивалась эволюция AI: традиционный AI → GenAI → грядущий AGI. Какие особенно у AI продуктов, включая вероятностную природу, зависимость от данных, дрифт моделей, требования к интерпретируемости/объяснимости, автоматизированные решения, масштабируемость и влияние этого всего на UX. Тут же описывается какой набор скиллов требуется для AI продакт менеджеров Chapter 2. The AI Product Development Lifecycle Здесь автор рассказывает про каркас AI Product Development Lifecycle (AIPDL) и проводит по стадиям: - Типы AI‑продуктов: 0‑to‑1 (новый продукт) vs 1‑to‑n (AI‑фичи в существующем) (напоминает историю "Zero to One" Питера Тиля) - Этап Ideation (в т.ч. брейншторм и приоритизация через RICE - Этап Opportunity: product‑market fit + бизнес‑viability (ROI/монетизация/риски/регуляторика), реализуемость и desirability, - Concept & Prototype: прототип "хардкодом", проверка интеграции, доменная экспертиза, ценность "с первого дня", - Testing & Analysis и Rollout Chapter 3. Essential AI PM Knowledge В этой главе автор рассказывает про базовые практики продакт менеджмента, классическую оценку build vs buy, лидерство и коммуникации, связь с инженерной командой, базовые технические концепции и так далее. В общем этакий product management 101. Chapter 4. The AI PMs Day‑to‑Day Здесь автор рассказывает про карьерную лестницу AI PM: execution → AI/ML PM → стратегическое лидерство. Дальше она приводит примеры людей, которые работали в этих ролях в разных компаниях. Здесь же идет рассказ про выстраивание кросс‑функциональных взаимодействий в командах. Chapter 5. Strategic Thinking in AI Здесь речь про стратегию и "правильные вопросы" до того, как писать код: - Когда AI может быть не ответом, - Disruptive vs sustaining и как не проиграть “innovator’s dilemma”, - AI‑стратегия build vs buy (матрица решения + гибридные подходы), - Data‑стратегия: synthetic vs real‑world data, - Выбор подхода: fine‑tuning vs RAG vs grounding + фреймворк принятия решения, - Product reviews как инструмент получения buy‑in от руководства. Chapter 6. Setting Goals and Measuring Success Здесь автор рассказывает про метрики и измеримость: product health, system health, ai proxy metrics. Как собирать OKR. Chapter 7. AI Tools for Product Managers Обзор классов инструментов для поддержки AIPDL и инструментов для совместной работы. Chapter 8. Building AI Agents Глава про агентные продукты, что это такое и как "сконструировать" агента под продукт: вертикальный vs general‑purpose, activation, autonomy, feedback/learning. #ProductManagement #Software #SoftwareDevelopment #AI #Engineering #Management #Leadership

+6

Кафедральный собор Святого Павла (Рубрика #Travel) Мы сегодня с Настей посетили этот собор и остались в восторге. Величественное здание возвышается над округой и внутри выглядит замечательно. Кроме первого этажа можно спуститься в крипту, где покоятся исторические деятели, а также можео подняться под свод собора и даже выше, чтобы со смотровой площадки увидеть Лондон вокруг. В общем, это обязательное для посещение место ... как минимум для туристов. #Culture

[2/2] Retired Netflix Engineering Director On Regrets, Video Engineering, Hiring Stories (Рубрика #Engineering) В продолжении этого крутого интервью, я хотел бы поделиться выводами из него для инженеров и технических руководителей. Что это значит для разработчиков (IC) - Если ты single point of failure - это не "круто", это риск. Документация, runbook’и, ротации on-call, передача контекста, “absence drill” (плановая недоступность) — это то, что делает команду взрослой. - Собирай "evidence of impact" до того, как тебя об этом попросят. Простая привычка: раз в месяц фиксировать “что сделал → какой эффект → какие риски снял → какие метрики/сигналы подтверждают”. Это помогает и в оценке, и в повышении, и в переговорах. - Не путай "много работал" с "много решил". В разговоре красной нитью: часы - плохой KPI. Системы и команды должны работать так, чтобы не требовать постоянного героизма. - Про собесы: будь готов к стандартизированным фильтрам, но выигрывает инженерная зрелость. Умение рассуждать про trade‑offs, неопределённость, дизайн систем и реальные решения - то, что отличает сильных на дистанции. Что это значит для техлидов и технических руководителей - Культура должна "исполняться", а не декларироваться. Например, "No brilliant jerks" работает только когда есть реальный enforcement: обратная связь, понятные ожидания и готовность расставаться даже с сильными, если они ломают команду. - Сделайте отпуск диагностическим инструментом. "Vacation/bus‑factor тест": кто уходит на неделю → что ломается → какие знания/доступы/процессы надо распаковать из головы в систему. - Видимость вклада - это инфраструктура роста. Не обязательно сразу “как в Meta”. Но вам нужна лёгкая версия: цели → зафиксированный impact → регулярная синхронизация ожиданий между командами, иначе на масштабе всё начнёт “тонуть в тумане”. - Найм: определитесь, что вы реально измеряете, и структурируйте процесс. Если хотите системное мышление и зрелость - добавляйте этапы, которые это проявляют (work‑sample / разбор реального кейса / обсуждение решений при неполных данных), а не только "задачки". - Компенсируйте перекос в индивидуальной аттрибуции резульататов. Если "светится" только личный вклад - получите локальную оптимизацию. Добавляйте командные сигналы, качество взаимодействия, ownership на длинной дистанции, культуру совместного результата. #Culture #Management #Leadership #Processes #Engineering #Software #Career #Interview

[1/2] Retired Netflix Engineering Director On Regrets, Video Engineering, Hiring Stories (Рубрика #Engineering) Интересное интервью Дэвида Ронка, экс Engineering Director в Netflix (пришёл в 2007), позже Director/Principal в Meta (видеотехнологии), которое он дал Райану Питерману , Staff SWE в Instagram. В этом интервью Дэвид, который уже вышел на пенсию, делится ретроспективой своей карьеры и управленческих решений. Основные инсайты следующие 1️⃣ "No brilliant jerks" - это не HR-лозунг, а инженерная оптимизация throughput Токсичная "звезда" может быть сильной индивидуально, но снижает скорость и качество всей команды (а значит и системы). 2️⃣ Героизм и 24/7 - симптом организационного бага, а не доблесть Если команда не переживает нормальный отпуск ключевого инженера, проблема почти всегда в устройстве системы: ownership, знания, ротации, процессы, приоритеты. 3️⃣ Culture Memo "aspirational": культура без инфраструктуры ломается при росте На небольшом масштабе "контекст вместо контроля" и сильные люди могут вытягивать многое. На большом масштабе без уровней/процессов/прозрачности вклада начинаются перекосы: вклад размывается, аттрибуция успехов уезжает вверх, компенсации сложнее объяснять. 4️⃣ Масштаб реально меняет физику инженерных решений Переход в Meta показал ему, что некоторые задачи (например, видео на уровне платформы) нельзя "дожать CPU’шками и количеством серверов" - нужна другая парадигма. 5️⃣ Найм: конфликт "точность оценки <=> масштабируемость процесса" У него жёсткая позиция про LeetCode (как не очень хороший сигнал качества инженера), но при этом он признаёт: в big tech стандартизация этапов часто неизбежна. Плюс важный тезис: over‑leveling - дорогая ошибка, потому что "мягко опустить ожидания" потом почти невозможно. 6️⃣ Performance/калибрации могут быть отличной школой управленческой объективности Да, это тяжело и неприятно, но заставляет формулировать вклад инженеров так, чтобы он держался на фактах и impact’е, а не на харизме менеджера. 7️⃣ Риск формализованных систем: перекос в "индивидуальную аттрибуцию результатов" Вклад становится видимым, но риск в том, что люди начинают оптимизировать "видимость" и личную победу, а не командный результат. В продолжении расскажу как можно этот опыт переложить на практические рекомендации инженерам и техническим руководителям. #Culture #Management #Leadership #Processes #Engineering #Software #Career #Interview

Граф знаний сайта system-design.space (Рубрика #SystemDesign) Материалов на сайте про system design стало слишком много и мне самому потребовалось средство для визуализации тем, глав и связей между ними. Так у меня получился граф знаний, который показывает 222 глав и 820 связей между ними. Каждый узел - это глава книги, а линия - смысловая связь между материалами. Связи строятся по перекрёстным ссылкам внутри контента глав: MarginNote на полях справа, ссылки из блоков "связанные главы" в конце глав и ссылки, что раскиданы по тексту статьи. Я планирую в будущем добавить в этот граф возможность выбора траекторий изучения, но пока он работает попрощ - Клик по кластеру в сайдбаре приводит к зуму и фокусу на главы из этой темы, а остальные главы затемняются - Клик по ноде в графе открывает панель с деталями главы, списком связанных глав и появляется кнопка перехода к материалу - Скролл / pinch позволяыт зумить. При приближении появляются названия глав - Перетаскивание - можно передвигаться по графу или если потянуть за отдельный узело, то можно его перместить - Цвета узлов соответствуют своим темам (кластерам) - По разному отмечаются связи внутри кластера и между кластерами + сами связи направленные - Для отрисовки графа используется force-directed layout (d3-force): узлы отталкиваются друг от друга, а связи притягивают. В итоге связанные главы оказываются рядом, а изолированные - на периферии. Я использовал этот граф сам для того, чтобы проверить, что у меня я сам не забыл добавить кросс-ссылки между темами (на самом деле забыл и граф мне позволил это исправить). #SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering

+6

Science Museum (Рубрика #Travel) Были в будний день в Музее Науки в Лондоне и это было очень круто. Музей расположен рядом с Имперским колледжом Лондона, насчитывает пять этажей и каждый этаж посвящен своей теме. Сам вход в музей бесплатный, но можно пожертвовать сколько хочешь. Мы пришли за два часа до закрытия и практически бегом пробежали экспозиции инжиниринга, космоса, полетов, компьютеров, медицины и на выходе успели еще купить подарки детям. В следующее посещение Лондона мы сюда обязательно зайдем, но уже вместе с детьми. #Science #Museum #ForKids #ForParents #Culture

Zero to One (От нуля к единице. Как создать стартап, который изменит будущее) (Рубрика #Startups) Прочитал интересную книгу Питера Тиля, со-основателя PayPal и Palantir, еще 2014 года, которая является конспектом его курса в Stanford, который он читал за пару лет до этого. В этом курсе Питер обсуждал не рецепты успеха, а говорил про сдвиг мышления: как из технологии сделать новую категорию, а не ещё один продукт, что будет чуть лучше, чем у конкурентов. В 2010 году эта книга пришлась ко двору во время бума венчура и стартап‑культуры - всем хотелось поймать "следующего единорога", а книга требовала делать наоборот: искать уникальность и строить защитный ров вокруг своей идеи. В книге было много ярких формулировок, например, вокруг того, что "конкуренция - это для лузеров", а это привело к тому, что они стали вирусными и разошлись на цитаты. В общем, с точки зрения маркетинга идей книга была хороша. С тех пор многое поменялось, но ее до сих пор полезно прочесть и подумать над идеями вроде 1️⃣ Идея "0→1 vs 1→n" Вообще, название книги противопоставляет идею создания чего-то нового с нуля (0→1) и идею дальнейшего масштабирования и улучшения (1→n). По мнению Питера ценность часто в 10x скачке за счет архитектуры, алгоритмов, UX, стоимости или надёжности и т.д., а не в бесконечной полировке продукта 2️⃣ Идея секретов Эта идея крутится вокруг важной истины в вашей области, что неочевидна большинству. Собственно, это очень напоминает мышление from the first principles, когда можно взглянуть на ситуацию не через стереотипы, а шире и найти нестандартное решение 3️⃣ Про пользу монополий по сравнению с идеальной конкуренцией У Тиля очень нестандартный взгляд на монополии и кокуренцию. Я думаю, что это особенность позиции большого капиталиста, но он говорит про творческое преимущество, а не про возможность задушить рынок. Для него монополия - это идея вокруг того, а почему вас сложно повторить (данные, интеграции, сеть, стандарты, бренд, скорость поставки). 4️⃣ Про важность дистрибуции У Тиля это часть системы - можно собрать идеальный движок, но без канала доставки ценности он не станет продуктом. Но про остальные процессы для рабочего продукта он почти не говорит. Если посмотреть, а как менялись подходы к венчуру после выхода книги, то получим примерно такой таймлайн - 2014–2019: Lean/MVP + рост → затем мода на blitz scaling (захватим рынок, потом оптимизируем) - 2020–2021: дешёвые деньги → мегараунды, гонка оценок, “growth at all costs” - 2022→ now: разворот к эффективности и юнит‑экономике: burn, выручка, маржа, путь к прибыльности снова стали "first-class metrics" - 2023→ now: AI‑волна усилила запрос на реальные рвы (данные, модели, доступ к compute) и честный GTM (go-to-markt), а не просто красивую историю Какие вопросы можно задать себе как руководителю - Какой секрет мы видим в нашем продукте? - Где наш потенциальный 10x? - Почему нас сложно скопировать - и как мы доставим ценность пользователю? #Startup #Management #Leadership #Economics #Engineering

+6

Студия, где снимали Гарри Поттера (Рубрика #Travel) Вчера с Настей были в студии Warner Brosers под Лондоном, где снимались все книги про Мальчика, что выжил. Посмотрели на павильоны, интерьры, костюмы, спецэффекты и нам все очень понравилось. Видно, что была проделана огромная работа, но в результате получилась легендарная экранизация. В мае приедем сюда же, но уже с детишками.

The Rise and Rise of FastAPI (Рубрика #API) Интересная мини‑документалка о FastAPI, которая длится меньше 10 минут. В ней говорится о том, как FastAPI прошел путь сверхбыстрого роста open source проекта по траектории вида: side‑project → "индустриальный дефолт" для API на Python. После документалки мне стало интересна судьба этого проекта и кажется, что FastAPI "выстрелил" не потому что "он fast", а потому что собрал в одном месте: - Стандарты** (ASGI, OpenAPI/JSON Schema) - Типизацию как интерфейс** (type hints → Pydantic модели) - DevEx как продукт (авто‑документация, предсказуемые ошибки, быстрый старт) - Композиционную архитектуру (Starlette‑стек, middleware, зависимости) В итоге, для команд, что его используют результаты выглядят так, что у них меньше боли на границах ответственности (APE endpoints) + быстрее интеграции + быстрее онбординг Если говорить про вехи развития проекта, то получится следующее 1️⃣ Side‑project → фреймворк Фокус был на создании "API без боли": валидируй вход, сериализуй выход, документируй автоматически 2️⃣ Технический стержень - ASGI‑модель (современная I/O‑архитектура) - Starlette как "тонкий" веб‑слой - Pydantic как слой данных: строгая валидация/сериализация поверх type hints 3️⃣ Контракт становится "живым артефактом" - OpenAPI генерится из кода. - Интерактивная документация /docs и /redoc делает API‑контракт частью ежедневной разработки, ревью и интеграций 4️⃣ Снежный ком крутого DevEx (developer experience) - Шаблоны, практики, интеграции, “как правильно” из коробки. - Порог входа падает → adoption растёт. 5️⃣ Взросление и коммерциализация вокруг поддержки - Когда популярность становится инфраструктурой для бизнеса, неизбежно появляются: поддержка, консалтинг, managed‑подходы, облака и т.п. - Это меняет ожидания: "фреймворк" → "платформа вокруг фреймворка". Если раскрывать ключевые инсайты подробнее, то получаем примерно так 1) FastAPI - это "композиция стандартов + DX", а не "магия" FastAPI не "заменяет архитектуру". Он фиксирует удачный дефолт: типы → модели → валидация/сериализация → схема → документация. По итогу у нас становится меньше неявных договорённостей и "случайных JSON" 2) Контракт‑ориентированная разработка - становится нормой OpenAPI в FastAPI - не "дока на потом", а контракт в процессе: - Проще подключать фронт - Проще делать партнёрские интеграции - Проще ревьюить изменения В итоге, скорость и надежность на другом уровне 3) Производительность - следствие правильной I/O‑модели, а не цель ASGI + async дают выигрыш только если вы: - Не блокируете event loop - Используете правильные драйверы/клиенты - Умеете проводить границы sync/async Правда, "async ради async" = быстрый путь к деградации и непредсказуемым p95/p99 4) OSS‑рост почти всегда приводит к вопросу устойчивости Если фреймворк становится критическим для тысяч компаний, возникает давление: - На поддержку - На эксплуатационные "best practices" - На продуктовую упаковку вокруг деплоя/наблюдаемости В итоге, с точки зрения технического руководителя это уже не просто "выбор библиотеки", а уже управление зависимостью На сайте system-design.space есть чуть более подробный разбор. #Engineering #Architecture #DistributedSystems #Software #SoftwareArchitecture

A Brief History of Bjarne Stroustrup, the Creator of C++ (Рубрика #Engineering) Интересная история Бьярне Страуструпа, датского учёного в области информатики, автор языка программирования C++. Вся история снята в городке Орхус (Дания), где он родился в 1950 году и учился в университете Орхуса, там же получил магистерскую степень. Дальше он защитил PhD в Кембридже, а затем работал в Bell Labs рядом с Керниганом, Ритчи, Моррисом и др. Ниже интересные моменты про его биографию, не все из которых я знал - В программирование Бьярне попал "случайно": выбрал направление "математика с датологией", не понимая, что "datologi" - это компьютерные науки - На него сильно повлиял Кристен Нюгорд (Kristen Nygaard), создатель Simula и концепции объектно‑ориентированного программирования; идеи структурирования кода в Simula до сих пор для него опорные. - В Bell Labs Бьярне интересовался операционными системами и архитектурой машин и, не найдя подходящего языка, решил "сделать свой". - Первый вариант языка назывался "C with Classes" - фактически C с классами в стиле Simula; затем название сменили на C++ (оператор инкремента в C), потому что это было "милое и необычное" имя. Не забыли они обсудить и сам C++, его предназначение и историю развития - В какой‑то момент Бьярне знал около 24 языков программирования (Snowball, Algol 68, PL/I, PL/360 и др.) - правда, он говорит, что раньше языки было проще изучать, т.к. у них не было огромного "багажа" и экосистемы. - Бьярне описывает философию C++ метафорой: "я должен был вырастить сорняк, а не розу", т.е. язык, который выживает и растёт без постоянного "полива" автором. - Особенно гордится тем, что у C++ не было маркетинговой кампании и "спонсора" - язык распространялся органично, через пользу и сообщество. - Через 10 лет после появления у C++ было уже около миллиона пользователей, а сейчас оценивается порядка 7 миллионов инженеров, использующих язык. В итоге, я себе отметил моменты 1. Роль случая - это про вход в профессию и что серьёзные карьерные траектории в ИТ часто начинаются не с продуманного плана, а с любопытства и случайного выбора. 2. Сила хороших идей и наставников - это про встречу с Нюгордом и знакомство с Simula и что один сильный ментор и одна сильная идея (ООП в Simula) могут задать направление целому поколению технологий. 3. Создание инструмента "для себя", а не для рынка - это про то, что фокус на реальной инженерной боли, а не на маркетинге, может дать шанс, что инструмент станет стандартом де‑факто. 4. Устойчивость важнее "идеальности" - тут метаформа сорняка говорит о том, что проектирование для реального мира, а не идеальной академической конструкции приводит к тому, что выживает тот, кто успешно работает в проде, а не на бумаге 5. Рост без маркетинга - это про то, что для инфраструктурных технологий органическое принятие и решённые задачи ценнее пиара. 6. Отношение к работе и мотивация - Бьярне продолжает учить, выступать и писать код, потому что ему "просто интересно видеть, как это используется, и приятно общаться с людьми". В итоге, долгосрочная мотивация строится на удовольствии от процесса и ответственности за последствия своей работы. #Engineering #Software #Management #Leadership #Architecture

+6

Путешествие в Лондон Вчера мы сначала 10+ часов летели в Лондон с пересадкой в Баку, а потом целый день бродили по нему. Была отличная погода: солнышко, +10 градусов и запах весны. В итоге, мы находили порядка 20 тысяч шагов и успели прогуляться по центру города и вернуться в номер. Часов в 20 по местному времени мы отключились, а сегодня утром идем на персональную экскурсию по Лейстер square. В обшем, эту неделю я побуду в роли туриста, а не технического директора (но материалов для tg-канала я приготовил заранее достаточно, так что вам все еще будет, что почитать - посты будут продолжаться и во время моего отпуска) #Travel

How to be a CEO when AI breaks all the old playbooks | Sequoia CEO Coach Brian Halligan (Рубрика #Management) Интересная серия подкаста Лённи, в котором к нему пришел Брайан Холлиган, со‑основатель и экс‑CEO HubSpot. Они обсудили каким становится лидерство и бизнес в эпоху ИИ: как нанимать, расти и продавать, когда старые плейбуки трещат по швам. Брайан был CEO 15 лет, а теперь выступает как внутренний CEO‑коуч в Sequoia и ведёт подкаст про лидеров Long Strange Trip. Основные инсайты примерно такие 1️⃣ Стартовая компанию проще, чем когда‑либо; масштабировать - сложнее, чем когда‑либо ИИ и облака кратно удешевили запуск, поэтому число компаний взлетит в небеса в ближайшие 10 лет, но шум и конкуренция делают масштабирование и дифференциацию всё труднее 2️⃣ Работа CEO → бесконечный найм и орг‑дизайн "Взрослые CEO" тратят до половины времени на рекрутинг, интервью и конструкцию exec‑команды, а не на продукт или операционку. 3️⃣ Все ужасно переоценивают своё умение интервьюировать Инстинкт "мне кажется, он классный" почти ничего не стоит; куда важнее жёсткие blind‑references, рабочие сессии с кандидатом и правильные вопросы про повторный найм 4️⃣ Нужно нанимать "острых" (spiky), а не консенсусных людей HubSpot перестал использовать консенсус в виде "3/4 от всех голосов" и начал брать людей с сильными плюсами и заметными минусами; это улучшило хит‑рейт 5️⃣ Люди из bigtech почти всегда не заходят компаниям на ранней стадии Найм из Microsoft/Salesforce/Google на компанию в 50–500 человек часто даёт "импеданс‑мисмэтч": ожидания процесса и ресурсов не совпадают с реальностью стартапа 6️⃣ Базовый плейбук - команда как Red Sox‑2004: микс homegrown и пары "звёзд" Большая часть менеджмента вырастает изнутри, плюс несколько дорогих ветеранов, а не "ковёр‑самолёт" из McKinsey/FAANG. 7️⃣ Фреймворк LOCK(S) для оценки фаундеров - L (lovable): хочется за этим человеком идти, он вдохновляет последователей - O (obsession): глубоко одержим проблемой, сильный founder–market fit - C (chip on the shoulder): идиома про "затаить обиду", когда человек чувствует себя оскорбленным из-за прошлого оскорбления или предполагаемой несправедливости, тогда появляется внутренняя мотивация "доказать". Тут интересно, что я раньше не знал эту идиому и она мне нравится (кажется, что я лучше всего работаю, когда у меня есть такое чувство) - K (knowledge): глубокое знание домена - S (student): фанатичный студент игры, копает и историю, и современность 8️⃣ CEO может стать не любой, но одновременно и ими не только рождаются Есть редкие "5‑tool CEOs", которые умеют кодить, продавать, вдохновлять, иметь вкус и видение (пример - Брет Тейлор), но большинству приходится добирать умения: обратная связь, детектор BS, вдохновение людей. 9️⃣ Боль №1 у фаундеров - давать фидбек и менять ранних сотрудников Самое тяжёлое - сказать кофаундеру/раннему head of X: "ты больше не управляешь, ты - визионер/CTO, а мы нанимаем операционного лидера над тобой" и сделать это экологично, но жёстко 🔟 ИИ уже сильно бьёт по разработке и саппорту, но не по enterprise продажам Кодинг, support, legal уже трансформируются, а enterprise‑продажи, где нужно доверие между двумя людьми, будут последними в белых воротничках, кого заменит ИИ. Но вообще у всех будут свои персональные агенты, подключённые к почте, календарю и заметкам, которых можно звать в митинги как активного участника, а не просто как запись Ну и финально про воронку go-to-market, которая становится ориентирована на агентов - Воронка "Google → сайт → demo" сменится на "Gemini/Claude/ChatGPT → глубокое исследование → уже образованный клиент". Сайт станет менее важен - На сайте будет "всезнающий аватар", который понимает продукт, цены и контекст клиента, ведёт беседу и пишет в CRM - У сейлза на созвоне будет свой "аватар", который знает всё о продукте и клиенте и помогает отвечать в реальном времени В продолжении я расскажу про то, а что можно почерпнуть из этого выступления инженерам и техническим руководителям. #Leadership #Management #Software #AI #ML

Laravel Origins: A PHP Documentary (Рубрика #Engineering) Интересный документальный фильм про фреймворк Laravel, который по моему ощущению занял нишу Ruby on Rails, но вместо Ruby тут языком выступает PHP. В фильме присуствуюте ключевые люди и именно они рассказывают историю развития проекта. Например, одна из главных ролей за Taylor Otwell, что создал Laravel и сейчас выступает как BDFL фреймворка ("benevolent dictator for life"), также там есть Jeffrey Way (автор образовательного ресурса Laracasts), Dayle Rees (автор первых книг по Laravel) и другие. Мы видим последовательное развитие истории: - Сначала жизнь и работу Тейлора в Арканзасе, а дальше старт проекта Laravel от caravel, где была изменена одна буква в названии коробля - Ранний рост проекта: первые GitHub‑звезды, переход UserScape на Laravel, полугодовой период, когда Тейлор фактически фуллтайм развивал фреймворк в рамках работы - Формирование экосистемы: очереди, миграции, пакеты, затем вокруг ядра вырастают Laravel Forge, Envoyer, Spark, Nova, Vapor, которые закрывают полный цикл от разработки до деплоя. - Комьюнити и медиа: книги Dayle Rees, Laracasts, Laravel News, агенства вроде Tighten, появление Tailwind CSS - как побочный эффект культуры "делать инструменты для других девелоперов" - Конференции и культура: Laracon в США, Европе, Австралии, "Laracation" как неформальные поездки, ощущение "как любимая группа в городе", а не корпоративное мероприятие. - Социальный эффект: карьеры тысяч людей, компании уровня Apple, госструктуры США и крупные бренды (например, Winter Olympics API, Boston Celtics) на Laravel. Ключевые инсайты из фильма такие - Видно, как Laravel вырос как решение собственных болей Тейлора - поэтому факторы скорости, продуктивности и "fun to use" стали ядром продуктового видения, а не были выстроены от маркетинга - Сильное, единое видение ("benevolent dictator for life") позволяет фреймворку быть цельным, последовательно эволюционировать и избегать scope creep и дрифта базовых концепций - DevEx как продукт: документация, выразительный синтаксис, консистентная эстетика кода (вплоть до формата комментариев) - сознательно воспринимаются как конкурентное преимущество - Коммерческая экосистема не подменяет open‑source, а дополняет его: SaaS‑продукты ведёт команда, а Тейлор фокусируется на ядре и R&D, что сохраняет качество фреймворка Отдельно видно, что коммьюнити вокруг Laravel сложилось крепкое и отсюда тоже можно извлечь инсайты - Осознанный дизайн культуры: с первого дня цель - "дружелюбное, chill, welcoming" сообщество, где люди чувствуют принадлежность и не боятся задавать вопросы - Конкуренция за вклад "в плюс миру": участники соревнуются в количестве бесплатных материалов, тулов и библиотек, а не в токсичности или статусе - Инклюзивность как практическая работа: создание Larabelles и других инициатив для вовлечения всех в профессию и коммьюнити - Сообщество как социальный капитал: люди обсуждают, как Laravel поменял их жизнь Для технического руководителя это напоминание о том, что - Хороший фреймворк - это не только API, но и эстетика, документация, DX и осознанное лидерство; это так же важно, как техническая "чистота" - Сильное ядро + продуманная коммерческая надстройка позволяют маленькой команде (порядка пяти человек) поддерживать огромную экосистему и влиять на индустрию - Сообщество и образовательная инфраструктура (типа Laracasts) критичны для adoption не меньше, чем сам код, особенно в мире, где каждые пару лет приходит новая волна девелоперов - Инклюзивная, по‑настоящему дружелюбная культура вокруг технологии может стать решающим фактором её популярности и longevity, а не только технические фичи #Documentary #Software #Architecture #Leadership #Culture #Management

Дискуссия с Гришей Скобелевым про подготовку к System Design Interview (Рубрика #Architecture) На этих выходных мы с Гришей из клуба { между скобок} поговорили про подготовку к System Design Interview и про то, как я дошел до жизни такой, что собрал сайт system-design.space. Основные моменты, что мы успели обсудить следующие ​ - Книга по System Design быстро устаревает: паттерны и требования меняются, а живой сайт можно непрерывно допиливать под практику, а не под "вечную теорию" ​- Ожидания на интервью сдвигаются от "знаешь ли ты стандартный набор сервисов и buzzwords" к умению думать как архитектор: трезво выбирать компромиссы, задавать вопросы, формализовывать требования - Разобрали типовые ошибки кандидатов​ - - Сразу рисовать «кубики и стрелочки» без уточнения ограничений, - - Оптимизировать за пределами реальных bottleneck’ов - - Заучивать шаблоны задач вместо понимания инвариантов (consistency, durability, latency budgets и т.д.) ​- System Design интервью на самом деле проверяет не "знаешь ли ты Kafka", а: как ты принимаешь решения, как разговариваешь с продакт менеджером, как эволюционируешь систему от MVP до сложной архитектуры ​- Разница между "рисованием кубиков" и архитектурным мышлением: во втором случае ты всегда привязываешь решения к пользовательским сценариям, нагрузке, отказоустойчивости и стоимости владения, а не просто перечисляешь модные технологии ​- Для senior/staff обязательны темы: масштабирование хранения и вычислений, очереди и асинхрованная работа, кэширование, консистентность, observability, эволюция схемы данных и rollouts, а также работа с неопределённостью и неполными требованиями ​- Готовиться нужно не "по чек-листу задач", а системно: строить свой набор инвариантов и шаблонов мышления, прогонять реальные кейсы, а не просто зубрить решения. ​ Если говорить про инсайты для руководителей, которыми можно поделиться, то - Интервью по SD стоит перестраивать с "угадай сервис" на разбор реального кейса: дать неполные требования, посмотреть, как кандидат уточняет, режет scope и развивает архитектуру итеративно ​Хорошее SD-интервью - это мини-совместное проектирование: вы вместе выходите хотя бы к первому адекватному приближению системы, а не к идеальной картинке из учебника. ​- Стоит явно формализовать, какие уровни архитектурного мышления вы ждёте от middle/senior/staff, и дать людям прозрачную лестницу роста (в идеале - с примерами на внутренних кейсах). ​- Вместо того чтобы ждать от команды "чтения книг по SD", проще дать живую базу практик, чек-листы и разборы постмортемов - то есть institutional knowledge, а не набор ссылок на классические книги. ​ #SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering

[2/2] OpenClaw Creator: Why 80% Of Apps Will Disappear (Рубрика #AI) Интервью было очень интересным и прорывным, но всегда интересно, а как перевести эти идеи в практическое русло. Для разработчиков отсюда можно извлечь следующее Если ваш продукт можно выразить как операции - агент сможет "съесть" ваш UI. Поэтому фокус смещается на “agent-ready интерфейсы”: - Tool-first мышление: превратите ключевые фичи в чёткие операции (CRUD/поиск/экспорт/триггеры), которые можно дергать напрямую. Минимум - хорошая CLI или SDK + примеры. - Документация "как для агента": понятные help‑тексты, примеры входов/выходов, ошибки, ограничения, idempotency там, где возможно. - Нормализуйте “опасные входы”: prompt injection и неожиданные действия - это базовый режим, если агент читает DMs/почту/веб. Тестируйте это как часть фичи, а не как edge case. - Локальная память = новый тип "секрета": думайте, что именно агент сохраняет, где лежит workspace, как чистится и бэкапится. Если хочется посмотреть а как это работает, то можно поднять OpenClaw локально/на тестовом сервере, подключить один канал, включить pairing/allowlist, запретить опасные tool‑группы и прогнать 3 сценария: "поиск/сводка", "операция с файлами", "задача через браузер". А дальше уже оценить насколько это удобно/безопасно/перспективно. Что это значит для техлидов и технических руководителей - Пересоберите threat model: "агент с инструментами" - это RPA + LLM + доступ к секретам. Нужны политики: где хранятся ключи, какие каналы доверенные, какие действия требуют подтверждения, как устроена изоляция сессий/пользователей. - Вводите governance по памяти: ретеншн, классификация данных, экспорт/удаление, audit trail - это станет не менее важным, чем логирование микросервисов. - Контроль экономики агентности: агентные циклы могут неожиданно "жечь" стоимость из-за контекста/памяти/инструментов. Нужны лимиты, бюджеты, режимы, мониторинг. Стратегия продукта: если тезис про "80% apps" хотя бы частично верен, дифференциаторы смещаются в (а) данные/память (б) безопасные интеграции (в) доверие/комплаенс (г) hardware/sensors/сообщества #AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture

[1/2] OpenClaw Creator: Why 80% Of Apps Will Disappear (Рубрика #AI) Интересное и короткое интервью Peter Steinberger, создателя OpenClaw (недавно перешедшего в OpenAI) проlocal-first персональных агентов и то, как они могут "съесть" большую часть привычного софта. Интервью у него брал Raphael Schaad, Visiting Partner в Y Combinator; основатель/CEO Cron (проект купил Notion). Ниже представлены основные инсайты 1️⃣ Local-first агент ≠ «ещё один чат-бот» Агент живёт на вашей машине/вашем сервере, поэтому может быть шлюзом между чатами и вашими инструментами: файлы, shell, браузер, интеграции - "всё, что может пользователь на компьютере". Это принципиально другой класс возможностей по сравнению с облачным ассистентом. Забавно, что создатель Manus AI рассказывал о том, как они ушли от локального агента в браузере в облако, чтобы отвязаться от локальной машинки:) 2️⃣ Магия - это tool-use + выбор кратчайшего пути Самый показательный кейс из интервью: голосовое сообщение внезапно само транскрибировалось, хотя функциональность "явно не кодили заранее". Агент сам сделал следующие шаиг - Определил формат аудио по заголовку (даже без расширения) - Перегнал через ffmpeg - Не стал ставить локально Whisper, а выбрал быстрый путь - отправить аудио в speech-to-text API через curl, потому что так быстрее получить результат В итоге, по мнению Питера конкурентное преимущество смещается от "самой умной модели" к инструментам, оркестрации и данным/памяти пользователя 3️⃣ "80% приложений исчезнет" - речь про приложения‑контейнеры данных Смысл тезиса не в том, что UI умрёт. А в том, что приложения, чья основная функция - ввод/хранение/менеджмент данных, становятся избыточными, если агент: - Сам собирает контекст (файлы/логи/фото) - Пишет/читает из хранилищ - Планирует/напоминает - И делает результат без отдельного “перехода в приложение”. Отдельно проговаривается идея, что выживут продукты, сильно завязанные на специфическое железо/сенсоры. 4️⃣ Главная ценность и риск - "память" агента Если агент становится персональным, то его “memory” - привычки, контекст, история действий, локальные файлы - это новый приватный периметр. В отчёте подчёркнуто, что такие memory‑файлы могут быть "более приватными", чем условная поисковая история. Также упоминаются файлы вроде SOUL.md / AGENTS.md / TOOLS.md как часть "инжектируемого" контекста в workspace. 5️⃣ CLI как универсальный "адаптер" для агента Одна из инженерных мыслей, что противоречит текущему вектору: вместо специальных протоколов интеграций агентам часто достаточно обычных человеческих инструментов - CLI. Если есть --help, примеры и предсказуемые команды - агент часто "разберётся". В отчёте это подано как практичный вектор (в т.ч. обсуждение CLI vs MCP). 6️⃣ Security - не "потом", а сразу Агент, который читает чаты/веб и имеет доступ к shell/файлам/браузеру, резко расширяет поверхность атаки. В отчёте много акцентов на базовых контролях: threat model, изоляция, allowlist, аудит, sandboxing, политики для DMs, защита от prompt injection. В продолжении обсудим, а что из этого интервью могут почерпнуть инженеры и технические руководители #AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture

+2

Мюзикл на чердаке (Рубрика #Culture) Были вчера с женой на этом мюзикле в Детском музыкальном театре "Поколение" и нам очень понравилось. У нас случилась накладка по расписанию и мы оба ехали туда отдельно и опоздали - я на 10 минут, а жена на полчаса, но как мы добрались нас сразу впустили в зал и мы смогли насладиться концертом, в основе которого знакомые с детства шлягеры в жанре мюзикла. По легенде спектакля брат и сестра спрятались от своей мамы на чердаке и нашли кассету с хитами мировых мюзиклов - а дальше музыка начинает оживать вокруг них. Мне понравились все хиты, но особо части про призрака оперы (когда ехали обратно, то слушали Nightwish), а Насте понравилась песня из диснеевского мультика "Русалочка". В общем, я непрочь и повторно сходить на этот же спектакль еще раз, но мы решили съездить с детишками в этот театр на спектакль попроще и покороче (этот был 12+ лет и длился 2.5 часа). #ForParents #ForKids

Modular Monoliths and Other Facepalms - Kevlin Henney - NDC London 2026 (Рубрика #Architecture) Интересное видео Kevlin Henney, где он выступает евангелистом монолитов, модульных монолитов:) Если сокращать, то он говорит, что проблема была не в монолитах, а в запутанных зависимостях и размытых границах. Союственно, микросервисы не лечат плохую декомпозицию. Но они просто делают ошибки дороже (сеть, консистентность, наблюдаемость, эксплуатация). Забавно, что свой первый монолит в Т-Банке я начал пилить как раз для того, чтобы довести эту стоимость до предела и перейти Рубикон (первая бекенд система, что мне досталась была сделана фронтедерами для фронтендеров и напоминала лапшу - по-другому выставить границы было нельзя).Но если возвращаться к рассказу Кевлина, то его совет в том, чтобы начинать с хорошо структурированного модульного монолита → и только потом (если есть устойчивые драйверы) выделяйте сервисы. Отдельно мне понравилась история вокруг эволюции подходов, так как я сам люблю так выстраивать сторителлинг для своих докладов - 1972 - Дэвид Пэрнас: критерии декомпозиции + information hiding (прячем то, что часто меняется) - 1974 - Лисков и Зиллс: abstract data types (ADT), работа с абстракциями данных - 1997 - Foote & Yoder: антипаттерн Big Ball of Mud (система "уползает" в комок без дисциплины) - 2014 - Fowler/Lewis: микросервисы как набор independently deployable сервисов (а не "мелкие модули по сети") - 2014+ - Simon Brown: предупреждение про distributed big ball of mud Если говорить про инсайты, то они примерно такие 🧩 Модульность - свойство кода и зависимостей, а не инфраструктуры Если внутри одного процесса вы не удерживаете границы, микросервисы не спасут - они просто добавят частичные отказы и сложность диагностики. 🕸 Архитектура проявляется в зависимостях сильнее, чем в диаграммах Значит архитектуру можно (и нужно) делать проверяемой: правила → CI → "ломаем билд" на нарушениях. 🧩 “Монолит” становится проблемой, когда он превращается в tangled monolith То есть не "один деплой" плохо, а переплетённость (циклы, обход границ, случайные импорты, нарушение слоёв). 🤑 Микросервисы - это инвестиция (техническая + организационная). Они оправданы, когда реально нужно независимо деплоить, изолировать изменения, масштабировать по частям, разводить ответственность команд. Если драйверов нет - вы покупаете overhead без выигрыша. Для разработчиков следуют такие практические выводы - Цель: сделать “границы” реальными, а не декоративными Модуль = единица эволюции, а не папка. Есть публичный API, есть скрытая внутрянка, есть запреты на “обход”. - Направление зависимостей важнее названий слоёв Следите за циклами, “обратными” ссылками, протеканием инфраструктуры в домен. Для технических руководителей следуют такие практические выводы Архитектурные ярлыки не заменяют управления границами. Если мотивация “давайте микросервисы, чтобы код разделился сам” - это красный флаг. Сначала: границы, ownership, правила, ревью‑политики, архитектурные тесты. Микросервисы по определению увеличивают: - Число deploy‑единиц - Количество коммуникаций - Требования к CI/CD, observability, security, data contracts Стратегия, которая обычно работает лучше: - Modular monolith - дефолт - Microservices - осознанная инвестиция при устойчивых драйверах P.S. Как обычно, расширенная версия есть на system-design.space. #Architecture #Software #DistributedSystems #Engineering #Management

Как взять идеи Google и построить себе похожий контроль качества архитектуры (Рубрика #Architecture) В прошлом посте мы разбирали whitepaper от ребят из Google "Understanding Architectural Complexity, Maintenance Burden, and Developer Sentiment - a Large-Scale Study". А сейчас я хотел бы поговорить про практические шаги, что можно сделать у себя в компании, если вы не Google, но тоже хотите контролировать качество архитектуры и размер техдолга. 1️⃣ Сформулируйте "maintenance burden" так, чтобы его можно было считать Самый практичный вариант - доля багфиксов vs фич за период: - % задач типа Bug в трекере - % PR/коммитов, привязанных к Bug - % LOC (или хотя бы файлов), изменённых ради Bug 2️⃣ Соберите минимум данных (обычно уже есть) - Git/PR-логи: кто/когда/что менял (changed files, размер). - Issue tracker (Jira и т.п.): тип задачи (bug/feature), компонент/сервис, команда. - Dependency graph: зависимости между пакетами/модулями/сервисами (из build graph, import graph, API calls). - Active coding time по задачам или DAT (Diff Authoring TIme), которым так хвалилась запрещенная в России Meta и про который я уже рассказывал - Если нет Active Coding Time, то начните с прокси: lead time PR, время ревью, размер batch’ей (а потом все-таки соберите ACT) 3️⃣ Архитектурные метрики: начните "дёшево", потом усложняйте Метрики из приведенного выше whitepaper конечно крутые, но сложные. Я говорю про - Propagation Cost (PC): насколько широко расползаются изменения по зависимостям - Decoupling Level (DL): насколько хорошо система декомпозирована на независимые модули В академии есть DV8 от авторов оригинального исследования (Yuanfang Cai, Rick Kazman) или условный Sonar в качестве коммерческого инструмента. Но для старта хватит - Отслеживать циклы на уровне модулей/сервисов (SCC) - Считать fan-in/fan-out, транзитивный fan-out - Отслеживать co-change кластеры: файлы часто меняются вместе, хотя "по архитектуре" не должны По правилу Парето мы так найдем 20% проблем, что приносят 80% боли 4️⃣ Склейте всё в регулярный отчёт (по кварталам/месяцам) На уровне repo/сервиса/команды: - Тренд coupling/циклов/co-change - Тренд bugfix ratio - Микро-опрос 1 вопрос раз в квартал: "насколько техдолг/сложность мешали вам работать?" Важно искать не виноватых, а проблему в системе: high coupling + растущий bugfix ratio = кандидат #1 на тех-инвестиции Если воспользоваться этим алгоритмом, то у вас будет набор карт на руках, с которыми никакой техдолг не страшен - У вас будут аргументы для рефакторинга в цифрах (и разговор с бизнесом пройдет на понятном им языке) - У вас будет внятная приоритизация: какие 2–3 hotspot’а чинить в первую очередь - Вы увидите ранние сигналы деградации: поймаете тренды до того, как команда уйдёт в вечный багфикс - Вы улучшите DevEx и скорость доставки фич как следствие Но важно не облажаться и не наступить в анти-паттерны - Не превращайте метрики в KPI людей/команд - будет гейминг - Не ставьте одинаковые абсолютные пороги по метрикам - нужны базовые нормы "что ок" для вашего домена; - Не пытайтесь получить одну метрику техдолга - он многомерен и метрики - это сигнал, а не приговор. Дальше нужны дизайн‑ревью и инженерная оценка найденных проблем Если бы я делал это в компании, то попробовал бы - Катануть пилот на 10–20 репозиториях/сервисах - Собрал бы базовую панель метрик, перечисленных выше - Подождал сбора результатов, напрмер, квартал - Дальше сделал бы точечные рефакторинги (благо сейчас рефакторинг становится сильно дешевле, если его делать с помощью AI-инструментов) - Сравнил бы "до/после" по bugfix ratio и скорости доставки - Если бы метрики улучшили, то планировал бы дальше раскатку В общем, с точки зрения алгоритма примерения тут нет никакого rocket science, но дьявол кроется в деталях:) #Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

Understanding Architectural Complexity, Maintenance Burden, and Developer Sentiment - a Large-Scale Study (ICSE’25) (Рубрика #Architecture) Наконец-то у меня дошли руки написать про этот интересный whitepaper про связь качества архитектуры с нагрузкой на поддержку решения и восприятия инженерами самого проекта. Лид автором этой статьи была Yuanfang Cai, профессор в Drexel University и автор метрик применяемых метрик, а также команда Google Developer Infrastructure / Engineering Productivity Research (Ciera Jaspan и др.) Авторы взяли данные - 1200+ проектов внутри Google (C++/Java). - Логи разработки: commits, LOC (lines of code) и Active Coding Time; отдельно мерили их в разрезе "фичи" vs "багфиксы" - 7200 ответов инженеров из регулярного опроса: насколько техдолг/избыточная сложность мешали работе (подробнее про этот опрос было в статье ребят из Google "Measuring Developer Experience With a Longitudinal Survey", что я уже разбирал) Цель всего приседания была в том, чтобы заменить "ощущения техдолга" на измеримые связи: архитектура → бремя сопровождения → настроение разработчиков. Кстати, про техдолг ребята из Google уже публиковали крутую статью "Defining, measuring and managing technical debt", которую я уже разбирал Измеряли они следующие три категории 1️⃣ Архитектурная сложность - Propagation Cost (PC): насколько широко расползаются изменения по зависимостям - Decoupling Level (DL): насколько хорошо система декомпозирована на независимые модули - Архитектурные запахи: циклические зависимости, co-change без явных зависимостей, нестабильные интерфейсы, проблемы наследования и т.п. 2️⃣ Maintenance burden - Доля усилий на багфиксы: по commits, LOC (lines of code), ACT (active coding time) 3️⃣ Developer sentiment - Ответы на вопросы из опросы вида "тормозит ли меня техдолг" Методология выглядела так - Для каждого проекта считают PC/DL/запахи по dependency graph + считают "bugfix ratio" по истории изменений - Дальше делают статистический анализ (корреляции/значимость) между тремя слоями В итоге у них на выходе получились результаты, что - Более сложная архитектура (PC↑, smells↑) связана с тем, что команда тратит больше доли усилий на багфиксы и меньше - на развитие - Чем больше "feature work" у команды, тем реже инженеры говорят, что техдолг их тормозит - "Архитектура <-> недовольство" во многом проявляется через рост багфиксов: когда вы живёте в поддержке, техдолг становится осязаемым Отдельно стоит отметить, что исследование нашло корелляцию, но это не причинно-следственная связь. Но это частая картина для сложных методологий исследований, что через a/b тест не катанешь. В следующем посте я расскажу свои мысли, а что можно из этого забрать себе, чтобы контролировать качество архитектуры и не стать техническим банкротом. P.S. Я рассказывал про многие статьи ребят из Google, у них отлично выстроена методология и есть очень интересные результаты - подробнее можно посмотреть в подборке из двух постов: 1 и 2 #Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes