Книжный куб

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

It takes two (Рубрика #Games)

Почти 20 лет я не играл в компьютерные игры, но на этот новый год мы купили детишкам PS 5 с кучей игрушек. Но Настя (моя жена) не обделила и нас и купила эту кооперативную игру. Мы в нее играли иногда по вечерам и за полтора месяца прошли. Игра оказалась очень интересной, веселой, местами психологической и наводящей на мысли о семейном быте. Вся история крутится вокруг родителей маленькой девочки, что решили развестись. Чаяниями их дочки мама и папа оказываются в своем доме в виде игрушек и им нужно пройти большой путь, чтобы стать опять людьми.

В общем, игра была превосходная - мы даже купили игру Split Fiction, которую сделала та же студи и в которой история другая, но кооперативные механики те же.

#ForParents

Inside Claude Code With Its Creator Boris Cherny (Рубрика #AI)

Интересно интервью Бориса из Anthropic в подкасте Lightcone от Y Combinator. Обсуждение строилось вокруг Claude Code и того, как Борис создал этот один из самых успешных AI инструментов в виде простого терминального продукта, а также про то, а что будет дальше.
​
Если говорить про ключевые инсайты, то они такие

🚀 Строить под модель через 6 месяцев
В Anthropic принцип: не оптимизировать продукт под текущую модель, а думать о том, какой она будет через ~полгода. Любой сложный «скэффолдинг» вокруг модели часто даёт +10–20% и полностью обнуляется следующим релизом, поэтому лучше минимальный слой обвязки и ждать апгрейда модели.

🎉 Рождение Claude Code как побочного эффекта
Борис просто хотел научиться пользоваться API Anthropic и написал терминальный чат‑клиент, без UI. Добавил bash‑tool, попросил модель "узнать, какую музыку я слушаю", та сгенерировала AppleScript и залезла в плеер - для него это был первый "AGI‑момент»: модель "очень хочет использовать инструменты".

🖥 Почему терминал и почему он "прилип"
Терминал выбран не из идеологии, а как самый дешёвый способ сделать прототип. Внутри Anthropic люди начали использовать его "до того, как он был готов", потому что:
- Удобно автоматизировать git, bash, Kubernetes, рутинные DevOps‑таски
- Продукт ощущается как "игра", а не как тяжёлый IDE‑плагин
Из этого вырос принцип: следовать латентному спросу (latent demand) - смотреть, что люди уже пытаются делать, и облегчать ровно это, а не навязывать новый поток работы. Это прямо топовый продуктовый подход для создания внутренних инструментов разработки.

✍️ CLAUDE.md / CLAUDE.md как «операционный контекст»
У Бориса личный CLAUDE.md - всего две строки: включать automerge на PR и постить PR в командный канал для быстрого ревью. Вся остальная "политика" живёт в repo‑локальном CLAUDE.md, который вся команда правит по несколько раз в неделю. Он советует: если файл раздулся до тысяч токенов, просто удалить и собрать заново - с каждой моделью нужно всё меньше инструкций.

🔈 Вербозность и UX терминала
Команда постоянно тюнингует детализацию: пытались скрывать bash‑вывод, сотрудники взбунтовались - он нужен для дебага (Kubernetes, сложные команды). Скрыли подробные логи чтения файлов/поиска, но по жалобам GitHub‑юзеров добавили режим verbose в конфиге.

💪 Как он сам работает с Claude Code
- 80% сессий начинает в plan mode: сначала план, потом выполнение.
- Распараллеливает работу: несколько вкладок в терминале и десктоп‑приложении, каждая начинает с плана.
- При сложных задачах явно просит несколько подагентов (3, 5, 10) исследовать проблему в параллели и потом объединить вывод.

🔮 Будущее plan‑mode и агентов
- Plan mode - просто одна дополнительная фраза в промпте "пожалуйста, пока не пиши код".
- Он считает, что срок жизни явного plan mode ограничен: при росте способностей модели она сама будет входить в "режим планирования", а потом и вовсе можно будет "одним шотом" давать задачу.
- Уже сейчас Claude Code иногда сам включает план‑режим, когда это было бы естественно для человека.

⛓️ Автоматизация всей инженерной цепочки
- Внутри Anthropic Claude‑агенты (через Claude Agents SDK) автоматизируют: code review, security review, triage и лейблинг задач, путь фичи до продакшена.
- Фича plugins для Claude Code полностью была написана «роем» агентов за выходные: один агент получил спеку, создал задачи в Asana, породил подагентов, те подняли PR‑ы.

🤖 Профиль идеального инженера / фаундера в эпоху LLM
- Главное - научный подход, мышление от first‑principles и готовность признавать ошибки; многие опытные инженеры застряли в старых паттернах.
- Борис ценит либо гипер‑специалистов (как команда bun / люди, одержимые devtools, рантаймами), либо гипер‑генералистов, которые пересекают продукт, инженерку, ресёрч, бизнес.
- Отбор кандидатов - в том числе по поведению с агентами: можно ли по транскрипту сессии понять, что человек умеет мыслить системно, использовать план, логи, корректировать модель.

#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture

Дискуссия с Гришей Скобелевым про подготовку к System Design Interview (Рубрика #Architecture)

Завтра, 21 февраля, в 11 часов утра по Москве мы с Гришей из клуба { между скобок } решили собраться и поговорить про подготовку к System Design Interview и про то, как я дошел до жизни такой, что собрал сайт system-design.space

Мы точно обсудим вопросы, что есть в программе встречи
• Почему книга не лучший формат для System Design
• Как меняются ожидания на интервью
• Какие ошибки чаще всего допускают кандидаты
• Что на самом деле проверяют на System Design интервью
• Как отличить «рисование кубиков» от настоящего архитектурного мышления
• Какие темы обязательно нужно понимать senior / staff инженеру

Но также думаю, что затронем вопросы системного мышления и фундаментальной подготовки, а не просто запоминания задач.

Встречаемся завтра c кофе ☕️ в 11:00 на YouTube

#SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering

История Linux и UNIX! Кто породил ВСЕ современные системы! (Рубрика #Engineering)

Интересное видео про историю операционных систем от канала PRO Hi‑Tech, из которого хорошо видно, что в истории unix или gnu linux победила не "одна фича", а сочетание идей + институтов (люди, лицензии, стандарты, сообщества). Из таймлана развития событий видно, что многие технологии приняли участие в ходе этой истории
- 1969: Unix в Bell Labs - простые абстракции под жёсткие ограничения (знаменитые пайпы и простые инструменты, что ждут на вход текст и )
- 1973: переписывание на C → переносимость как стратегия (переносимость между разным железом)
- 1984: BSD + TCP/IP → Unix становится “родным” для сетей
- 1988: POSIX → общий контракт совместимости среди зоопарка Unix
- 1991: Linux (ядро) → недостающий пазл для свободной системы (ядро экосистемы GNU)
- 1993+: Debian/*BSD → управление качеством, релизами, пакетами
- 2000–2008: Darwin/macOS и Android → Unix‑подход уходит в массовые платформы (на Android и в основу Mac)

Из всей этой истории можно сделать определенные выводы, что полезны и в продуктовой разработке
- Переносимость = драйвер экосистемы. Инвестируйте в стабильные API/ABI и “тонкий слой” платформенной специфики
- "Файл/процесс/pipe" → сила простых контрактов. Малые утилиты и композиция = предок современных микросервисов и пайплайнов
- Фрагментация лечится стандартами. POSIX появился не из любви к бюрократии, а чтобы снизить стоимость переносимости
- Open‑source ≠ анархия. Сообщества выживают за счёт governance, CI, правил релизов и ответственности за интеграцию
- Лицензия - архитектурное решение. Она определяет, кто и как может вкладываться, монетизировать и форкать
- "Ядро" ≠ "продукт". Дистрибуция/SDK/пакеты/политики поставки часто важнее самого kernel

Для технических лидеров это можно приземлить на набор полезных по моему мнению советов
- Зафиксируйте "поверхность контрактов": публичные API/CLI/форматы, SLA, обратная совместимость
- Постройте конвейер принятия вкладов: code review → CI → релизные ветки → rollback
- Разделяйте владельцев: ядро/платформа vs userland vs дистрибуция/поставка
- Не верьте красивым нарративам на слово: проверяйте даты/причины решений - история любит упрощения (посмотрите оригинальный фильм и почитайте доки - составьте свое мнение)

Более подробный разбор есть на моем сайте system-design.space.

#Engineering #Documentary #Architecture #Software #DistributedSystems #Leadership

The Man Who Revolutionized Computer Science With Math (Рубрика #DistributedSystems)

В этом видео Лэсли Лэмпорт за 8 минут рассказывает про специальную теорию относительности, причинность и распределённые системы, а также как это все свзяано между собой. Это видео - короткое интервью Quanta Magazine где он объясняет смысл своей классической фразы

Вы понимаете, что пользуетесь распределенной системой, когда поломка компьютера, о существовании которого вы даже не подозревали, приводит к останову всей системы, а для вас - к невозможности выполнить свою работу

Но лучше сначала расскзать, а чем известен Лэсли Лампорт, который получил премию Алана Тьюринга (аналог Нобелевской, но в информатике). За ним числятся
- Lamport clocks + happens‑before: как упорядочивать события без «общих часов»
- Paxos и replicated state machine: фундамент отказоустойчивых кластеров/хранилищ
- LaTeX: де‑факто стандарт научной вёрстки
- TLA+: спецификации + model checking, чтобы ловить дизайн‑баги до кода

Самое вкусное в этом интервью - это рассказ про связь специальной теории относительности из физики и теории распределенных систем из информатики. Мне как учившемуся на Физтехе очень понравилась эта часть про мультидисциплинарность и пользу физики (хотя я учился на факультете прикладной математики, но физика у нас выдавалась всем так, чтобы никто не ушел обиженным от того, что ее недополучил). Так вот, в СТО (специальной теории относительности) нет универсального "сейчас": наблюдатели могут спорить, что было раньше. Но они не спорят о причинности - событие A может повлиять на B только если сигнал (не быстрее света) мог дойти от A до B. И Лэсли Лэмпорт перенес это 1‑в‑1 в распределённые системы:
- Нет глобального времени (латентности, дрейф, партиции)
- Зато есть причинный частичный порядок: "могла ли информация из A повлиять на B"
В итоге, в распределёнке важнее порядок, совместимый с причинностью, чем "точные таймстемпы". Отсюда появились логические часы, тотальный порядок поверх частичного и согласованная эмуляция одной последовательной state machine несколькими узлами. В общем, я раньше не знал как Лэсли к этому всему пришел, а тут узнал и понял, что действительно это блестящая игра разума.

Но если возвращаться на грешную землю, то можно почерпнуть такие инсайты для инженеров и технических руководителей
- Programming ≠ coding. Код - последняя миля. До него должны появиться модель поведения и явные допущения (сеть, сбои, порядок сообщений, часы).
- "Алгоритм без доказательства - гипотеза". Даже если вы не пишете формальные доказательства, TLA+/модель‑чекер часто ловят те баги, которые тестами почти не поймать.
- Ищите причинность. Когда спорите о порядке операций в БД/кэше/очереди - спрашивайте не "который час был раньше", а "какая информация могла попасть куда".

Ну и отдельный момент про любимый алгоритм Лэсли "Bakery (mutual exclusion)". Здесь метафора пекарни работает так: каждый процесс берёт «номерок», и в критическую секцию входит минимальный (при равенстве - по id). В оригинальной работе он даже отмечает, что такие "номерки" можно реализовать распределённо: хранить у владельца процесса и читать по сети.
Красота в том, что алгоритм корректен даже при очень слабых предположениях о памяти: чтение, пересекающееся с записью, может вернуть произвольный "мусор", а докатазательство всё равно работает. Лэмпорт понял это, когда дописывал доказательство - это отличный аргумент, зачем вообще писать спецификации/доказательства: они находят свойства, которых вы "не закладывали".

#DistributedSystems #Software #Engineering #Architecture #Leadership #SystemDesign

"Engineers are becoming sorcerers" | The future of software development with OpenAI's Sherwin Wu (Рубрика #AI)

Очередной интересный выпуск Lenny’s Podcast, в котором Ленни общается со Sherwin Wu, который руководит инженерией OpenAI API / Developer Platform. Sherwin описывает сдвиг роли инженера: от того, чтобы "писать код" к тому, чтобы «управлять флотом AI‑агентов» и принимать инженерные решения на более высоком уровне абстракции.

Основные инсайты беседы такие
1️⃣ Codex стал стандартом
~95% инженеров OpenAI используют его ежедневно; работа всё чаще = управление “флотом” 10–20 параллельных AI‑агентов. Кстати, я тоже в восторге от Codex - это просто бомба. С ним я могу не просто обсудить архитектурные вопросы (которые мало с кем могу обсудить на работе), с ним я могу дальше еще и реализовать эти изменения - это просто magic
2️⃣ Ревью автоматизируется
OpenAI пишет, что Codex автоматически ревьюит почти каждый PR, и это помогает мерджить ~+70% PR в неделю.
3️⃣ Скорость процесса важнее "кода руками"
Ребята обсуждают кейс, где code review сократили с 10–15 до 2–3 минут.
4️⃣ Разрыв продуктивности растёт
"AI power users" уезжают вперёд; ближайшие 12–24 месяца - редкое окно, чтобы прокачаться, пока роль инженера не изменилась окончательно.
5️⃣ "Models will eat your scaffolding for breakfast"
Не стройте продукт/архитектуру вокруг временных костылей текущих моделей - они быстро исчезают.
6️⃣ Для техлидов/EM
Меньше контроля строк кода, больше оркестрации агентов + качества процесса + измерения ROI; отдельно обсуждают, почему многие enterprise‑внедрения AI сейчас дают отрицательный ROI.

Что сделать команде для того, чтобы попробовать новый процесс
- Ввести паттерн: spec → агент → тесты → PR → авто‑ревью → human‑approve.
- Усилить “контракт качества”: тесты/линтеры/статанализ, маленькие PR, чек‑листы.
- Начать мерить: lead time PR / время ревью / дефекты после мерджа - иначе AI останется "игрушкой".

Это очень перекликается с тренд отчетом на этот год от Anthropic про агентское будущее программирования, о котором я уже рассказывал.
В общем, все это напоминает цитату Уильяма Гибсона

Будущее уже наступило. Просто оно еще неравномерно распределено

P.S.
Я всегда хотел находиться в той части, где настоящее максимально тесно переплетается с будущим, поэтому в этом году сильно сменил карьерный трек, но об этом как-нибудь в следующий раз ...

#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture

How McKinsey Plans to Survive AI (and Reinvent Consulting) (Рубрика #AI)

Интересный получасовой эпизод подкаста HBR IdeaCast, в котором Adi Ignatius (HBR) разговаривает с Bob Sternfels (Global Managing Partner / фактически CEO McKinsey). Основная мысль крутится вокруг того, что AI - это на 30–50% "технология", а остальное - это оргдизайн и процессы. Если "прикрутить LLM поверх старого процесса", то будет локальная автоматизация, но не системный рост throughput.

Я смотрел с большим интересом и забрал себе следующие инсайты, которые применимы и к разработке софта

1️⃣ Барьер не в модели, а в организации
Колодцы, лишние handoff’ы, слои согласований съедают эффект AI сильнее, чем качество промпта.
2️⃣ "Human + agent" - это новая единица производительности
У McKinsey внутри нарратив про десятки тысяч "агентов" и движение к "1 агент на человека" (правда, в интервью не ясно, а что такое "агент", поэтому не ясно с чем сравнивать цифры). То есть агентов включают в состав рабочей силы и отмечают рост их количества.
3️⃣ Коммодитизация аналитики → ценность уходит в outcomes
Если анализ становится дешевле, побеждает тот, кто доставляет результат и умеет "подписаться" под эффект. Внутри компаний это аналогично: меньше "сколько тикетов закрыли", больше "какой outcome улучшили".
4️⃣ Найм/рост: resilience + обучаемость > идеальные оценки
А этот пункт про изменения критериев найма сотрудников внутри McKinsey. Раньше они искали отличников, а потом поняли, что успех лучше предсказывают не отличные оценки, а успешное преодоление кризиов - лучша взять того, кто падает-встаёт, умеет учиться и работать с людьми.
5️⃣Скорость побеждает, даже если ошибок больше - при хорошем восстановлении
Тут есть прямая параллель с хорошими инженерными практиками: маленькие батчи, feature flags, наблюдаемость, быстрый rollback → снижаете cost of mistakes и можете быть быстрее.

Если как-то переносить инсайты на советы инженерам, то получим примерно следующее
1)Перестаньте использовать AI как "магическую кнопку". Стройте конвейер: Agent → PR → quality gates → human review (тесты/линтеры/security‑сканы не отменяются).
2) Ищите, где агент убирает handoff, а не “ускоряет написание текста”. Начинайте с end‑to‑end потока (value stream).
3) Прокачивайте навыыки из второй волны: judgment + альтернативы + контрпримеры. Просите модель не "ответ", а "риски/проверки/что может пойти не так"

Для техлидов это значит следующее
1) Думайте про AI как про операционную трансформацию, а не набор пилотов.
2) Выберите 2-3 процесса и переделайте их целиком (например: triage → fix → deploy).
3) Мерьте результат outcomes‑метриками + баланс скорости/стабильности: DORA (lead time, deploy freq, MTTR, change fail rate) + DevEx/SPACE (чтобы “ускорение” не выжгло команду).
4) Управляйте агентами как продуктами: inventory + ownership + audit: (кто владелец, какие данные видит, какие инструменты вызывает, какие гейты обязаны проходить).

#AI #Engineering #Leadership #Devops #Productivity #Management

Two decades of Git: A conversation with creator Linus Torvalds (Рубрика #Software)

Интересный рассказ Линуса Торвальдаса о том, как 20 лет назад, в апреле 2005-го, Линус за 10 дней накатал первую версию Git. Он сделал это потому, что у разработчиков ядра Linux отобрали любимый инструмент (BitKeeper). Git родился из боли: CVS Линус терпеть не мог, SVN считал «тем же CVS». Он признаётся, что изначально писал Git "под себя", не парясь об удобстве для других.

Линус всего несколько месяцев сам поддерживал Git, а уже к осени 2005 передал бразды другому разработчику – Junio Hamano (он и по сей день мейнтейнер). Торвальдс вернулся к любимому детищу (ядру Linux), а Git зажил своей жизнью. Постепенно что-то переключилось в сообществе: через пару лет народ распробовал инструмент. Особенно помог приток молодых разработчиков, для которых Git стал первой системой контроля версий. Вместо возни с устаревшим CVS они с удовольствием юзали Git и удивлялись, почему раньше было иначе. В итоге Git взлетел и практически монополизировал рынок VCS – сейчас, по словам Линуса, порядка 98% проектов на нём. Даже дочь Торвальдса однажды сказала ему, что в университетской лабе его знают больше как автора Git, а не Linux 😅.

Ключевые идеи и фишки Git следующие

1️⃣ Распределённость
В Git нет главного репозитория, каждый клонированный репо - полноценный. Это не просто философия, а огромное практическое удобство: разработчик может работать локально без центрального сервера, а при надобности выложить код куда угодно (GitHub и появился благодаря этой идее). Как мне кажется, это local-first приложение by design.
2️⃣ Скорость и масштабируемость
Git проектировался под гигантский Linux-репозиторий, поэтому все операции (патчи, слияния) должны быть быстры. Линус шутит, что применить 100 патчей должно быть делом секунд – «не надо успевать пить кофе, пока ждёшь».
3️⃣ Надёжность данных
Каждый коммит и объект помечаются крипто-хешем (SHA-1): это больше про защиту от случайной порчи или ошибок, чем про безопасность. Такая проверка целостности на каждом шаге отличала Git от предыдущих систем (в BitKeeper, например, были слабее CRC/MD5 и не всё покрывали).
4️⃣ Простота ядра
В основе Git всего несколько концепций (объекты, индексы, ветки), за счёт этого первую версию удалось написать быстро и она до сих пор совместима (почти полностью) с нынешней. Всё сложное вынесено либо “наверх” (в командный интерфейс, скрипты), либо появилось позже.

Интересно, что Линус, вдохновляясь философией Unix, нарочно не копировал привычные команды CVS – делал по-своему, даже названия дал другие (commit-tree, index и т.д.), чем вызывал баталии на почтовых списках. Но он сознательно ломал устои: слишком уж его раздражали старые подходы, хотелось кардинально другой инструмент.

Вообще, история Git - это отличный пример, как разработчик решает свою проблему, а в результате меняет индустрию. Линус просто хотел продолжать разрабатывать ядро, не мучаясь с отвратительным инструментом, - и из этого родился Git, без которого сейчас не мыслят работу ни разработчики, ни тимлиды. Порой действительно стоит взять и сделать «как надо», даже если изначально продукт сырой и неудобный: если в основе заложены верные принципы, сообщество подтянется и доведёт до ума. Мы видим, как открытые инструменты побеждают закрытые (BitKeeper канул в лету, Git царит).

Торвальдс отмечает, что теперь вокруг Git выросла экосистема, которая решает проблемы, о которых он и не думал. Например, появились расширения для больших файлов и монорепозиториев (привет корпорациям) – изначально Git не планировался для этого, но жизнь заставила. Интересна его мысль о трекере задач/багов: сейчас у каждого хостинга своя система issues, и Линусу хочется единого открытого стандарта (чтобы не было привязки к конкретному сервису). Возможно, это намёк сообществу, где ещё есть простор для инноваций 😉.

#Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes

Inside Argo: Automating the Future (Рубрика #DevOps)

Если у вас Kubernetes в проде, то этот фильм про опенсорс проект может принести пользу - это история того, как Argo вырос из workflow‑движка в набор инструментов для автоматизации деплоев и процессов вокруг них (Workflows / CD / Rollouts / Events). В кадре появляются ключевые люди, что стояли у истоков Argo и которые в 2017 году запустили Argo и как вокруг него постепенно появлялось community и набор связанных инструментов. Также мы видим почему GitOps + Argo стали де‑факто стандартом для "предсказуемых" деплоев в cloud‑native мире.

Для инженеров просмотр может быть интересен, так как
- Это не "маркетинг инструмента, а кейсы взросления опенсорса: комьюнити, мейнтейнерство, стандарты качества/безопасности, и как из внутренней разработки получается индустриальный инструмент
- Это про масштаб: Argo прошёл путь CNCF Incubating (2020) → Graduated (2022), и CNCF отмечает сильную индустриальную динамику принятия инструмента (adoption)

На практике этот инструмент позволяет разработчикам иметь меньше ручных релизов и “магии” в пайплайнах → больше декларативности, повторяемости и отладки через Git как source of truth. А руководителям платформенных команд это дает понимание, что delivery‑контур - это продукт. Инструменты типа Argo ценны ровно настолько, насколько вы вкладываетесь в guardrails, стандарты и поддержку внутренней платформы.

P.S.
Более подробный разбор в моей статье на system-design.space.

#Kubernetes #DevEx #PlatformEngineering #Software #Architecture #DistributedSystems

Dyad - local‑first AI app builder: как Lovable/Bolt, только на своем компьютере (Рубрика #AI)

Я как-то уже рассказывал про продукт Lovable, этакий "AI app builder", в котром написал запрос → получил изменения кода → увидел превью → опубликовал на прод. Собственно, то Dyad делает ровно этот цикл, но локально. В самом репозитории Dyad прямо позиционируется как local/open‑source альтернатива Lovable/v0/Bolt (и в целом - альтернативный путь по сравнению с облачными платформами).

Кстати, про подход local-first я тоже уже рассказывал, когда делал саммари на документалку и в dyad есть все признаки этого подхода
- Код и проект у вас на диске: без "платформенной клетки", можно импортировать/экспортировать и свободно переходить между Dyad и обычным dev‑workflow
- Bring your own keys: вы сами подключаете нужных провайдеров и модели (OpenAI/Google/Anthropic и т.д.), без принудительного вендор‑лок‑ина
- Расширяемость: можно добавлять инструменты через MCP‑серверы и жить на шаблонах (templates) под разные JS‑стеки

Функциональность Dyad похожа на Lovable и включает в себя
- Full‑stack приложения через Supabase: быстро подключить базу, auth и server functions
- Security review на базе AI: запускаете проверку, получаете находки с уровнями критичности и можете попросить AI исправить конкретную проблему; правила проверки можно подкрутить через SECURITY_RULES.md
- Автоматическое versioning: каждое AI‑редактирование - это новая версия; по сути это git‑коммит. Можно открыть список версий и “restore” до последнего удачного состояния (механика похожа на git revert, история при этом не теряется)
- Публикация: “publish anywhere” - GitHub/Vercel или ваш стек

Если говорить про архитектуру, то это устроено следующим образом
Dyad - это electron‑приложение:
- UI живёт в renderer process,
- Доступ к файловой системе и "применение изменений" - в main process,
- Общение идёт через IPC

Ключевой трюк AI-редактирования в том, что модель отвечает не "просто текстом", а в XML‑подобном формате команд. UI стримит и красиво показывает ответ, а затем main‑процесс (через response processor) применяет команды к проекту: создать/изменить/удалить файлы, добавить npm‑пакеты и т.п.
Отдельно отмечается, что Dyad не стремится быть максимально "агентным" как Cursor, потому что сложные agentic‑циклы быстро становятся дорогими - поэтому чаще это “один запрос → один аккуратный проход”, с опциональным авто‑фиксом TypeScript ошибок.

Подробнее про архитектуру проекта можно прочитать на сайте system-design.space, куда я выложил подробный разбор с картинками и визуализациями.

#AI #Engineering #Software #Architecture #DistributedSystems #Agents #ML

[2/2] Nvidia’s Explosive Rise from Zero to Trillions (Рубрика #Documentary)

Продолжая рассказ про историю Nvidia надо отметить инсайты фильма, которые пришли ко мне после его просмотра

1️⃣ Платформа съедает продукт
NVIDIA выиграла не только “чипом”, а тем, что сделала программируемую платформу: CUDA - это не “одна библиотека”, а экосистема (компилятор, тулкит, профилинг, библиотеки). В итоге возникает “липкость” и сетевой эффект вокруг железа - редкость для hardware‑бизнеса.
2️⃣ Ставка на рынки с нулевым размером может быть рациональной
Большие pivots компании (3D‑графика для PC, потом AI) - это ставки на “zero‑billion dollar markets”. То есть не про хайп, а про умение увидеть будущий сдвиг вычислительной парадигмы.
3️⃣ Программируемость = мультипликатор
GeForce 256 была важна не только как ускорение рисования, а как шаг к программируемому ускорителю. Дальше из этого выросла CUDA и общие вычисления
4️⃣ Инженерная дисциплина под давлением решает
История “у нас один шанс на tape‑out” и ускорение цикла разработки - это не романтика, а практическая управленческая инженерия: сокращать feedback loop любой ценой.
5️⃣ AI‑инфраструктура - это “система систем”
DGX (системы) + Mellanox (сеть) = понимание, что для AI важны не только FLOPS, но и: память, интерконнект, сеть, софт‑стек, инструменты, поставки. Собственно Mellanox был куплен Nvvidia за $7 млрд в 2020 году, когда ребята поняли, что им этого не хватает.

Для технических лидеров мне кажется полезным будет подумать над такими тезисами

1) Стратегия вычислений = стратегия бизнеса
Если у вас AI‑фичи в roadmap - у вас появляется новый ресурс: GPU‑время/память/интерконнект, и этим нужно управлять как бюджетом и SLA.

2) Платформенная команда - это не роскошь
Нужны люди/команда, которые делают “внутренний CUDA” вашей компании:
- Шаблоны пайплайнов,
- Инфраструктура обучения/инференса,
- Наблюдаемость (стоимость, утилизация, узкие места),
- Guardrails по качеству/безопасности.

3) Управляйте vendor lock‑in как риском, а не как идеологией
CUDA‑экосистема реально мощная - и именно это даёт NVIDIA рычаг.
- Оставляйте “точки выхода” (абстракции, ONNX/portable‑слои где уместно, контрактные тесты производительности),
- Держите план B по инфраструктуре (облако/он‑прем/альтернативные ускорители),
- Фиксируйте метрики стоимости/латентности как продуктовые KPI.

4) "Полный стек" важнее "самого быстрого GPU"
- Покупка Mellanox и ставка на DGX - хороший сигнал: производительность AI‑системы часто упирается в сеть/IO/оркестрацию, а не в “ещё 10% TFLOPS”.

🧐 После просмотра можно пройтись по таком мини‑чеклист для команды
1. Посчитать стоимость 1 GPU‑часа (или inference‑1000 req) и сделать её видимой.
2. Ввести профилирование как обязательный шаг перед релизом ML‑фич.
3. Определить, где вам нужна "портируемость", а где можно идти в максимальную оптимизацию под конкретный стек.
4. Проверить узкие места: сеть, storage, батчинг, очереди.
5. Обновить hiring/skill‑matrix: нужен ли вам performance engineer / ML systems engineer?
6. Зафиксировать “exit strategy” от критических зависимостей (не завтра, но чтобы она была на бумаге).

#Documentary #Infrastructure #AI #ML #Engineering #Software #Leadership #Startup #DistributedSystems

[1/2] Nvidia’s Explosive Rise from Zero to Trillions (Рубрика #Documentary)

С большим интересом я посмотрел этот документальный фильм рассказывает впечатляющую историю превращения Nvidia из стартапа на грани банкротства в компанию стоимостью $3 триллиона . Фильм охватывает путь от основания в 1993 году до текущего доминирования в области AI . Мне было интересно посмотреть, а какие этапы проходила компания и какие выводы можно почерпнуть нам как инженерам и техническим руководителям

Основание и первые годы
Nvidia была основана тремя инженерами - Дженсеном Хуангом, Крисом Малачовски и Кёртисом Примом - которые познакомились работая в Sun Microsystems и LSI Logic . Легендарная встреча состоялась в ресторане Denny's в Сан-Хосе, где за чашками кофе они обсуждали будущую компанию день за днем . Их ставка была на 3D-графику для PC и видеоигр, хотя на тот момент они даже не видели персональный компьютер . Название Nvidia произошло от латинского слова "invidia" (зависть), а также от сокращения NV ("next version"), которое основатели использовали при сохранении файлов . С начальным капиталом всего $40,000 и последующим финансированием $20 млн от Sequoia Capital, они начали свой путь .

Провал и чудесное спасение
Первый продукт NV1 (1995) оказался катастрофой: из 250,000 чипов, отправленных партнёру Diamond Multimedia, вернулось 249,000 . Проблемы были в том, что чип использовал quadratic primitives вместо triangle primitives, которые стали стандартом Microsoft DirectX, плюс был слишком дорогим . После отмены контракта с Sega на NV2, у компании осталось финансирование только на один месяц зарплат . Riva 128 (август 1997) стал продуктом, спасшим Nvidia - за четыре месяца он продался тиражом в миллион единиц, в отличие от NV1, который продал едва тысячу . С тех пор в компании существует неофициальный девиз: "Мы всегда в 30 днях от банкротства". Интересно, что в моем первом компьютере был чип riva tnt2, то есть я познакомился с творчеством ребят еще до начала 21 века:)

Прорыв и IPO
GeForce 256 (1999) стал первым в мире GPU с программируемым ускорителем - это был прорыв в концепции ускоренных вычислений . В январе 1999 года Nvidia провела IPO, что дало компании больше капитала и публичности . Следующим большим шагом стал контракт с Microsoft на $200 млн на разработку чипов для оригинального Xbox .

Поворот к AI
Самое интересное решение было принято в середине 2000-х: релиз CUDA в 2006 году - платформы параллельных вычислений, которая позволила использовать GPU не только для графики . Профессор Стэнфорда Эндрю Нг вспоминает, что уже в 2008 году его студенты экспериментировали с CUDA для deep learning и получали ускорение в 10-100 раз . Это был огромный риск: в конце 2000-х никто не знал, станет ли AI прибыльным . Nvidia приняла решение о масштабной трансформации компании, добавляя затраты, нанимая людей и отвлекая внимание от основного бизнеса в gaming и компьютерной графике . Хуанг описал это как "wholesale pivot" - полную переориентацию всей компании .

Интересно, что у меня был коллега в МФТИ, которого мы взяли пилить всякие веб-сайты, а он парарллельно занимался CUDA по научной траектории и в какой-то момент сказал нам ариведерчи и ушел заниматься CUDA фултайм.

Дальше карта AI пошла хорошо - в 2012 году случился AlexNet и произошел старт “современного AI”. NVIDIA прямо отмечает, что прорыв AlexNet стал спусковым крючком эры modern AI, и GPU оказался в центре этой волны. А про инсайты и выводы из этой документалки мы поговорим в следующий раз.

#Documentary #Infrastructure #AI #ML #Engineering #Software #Leadership #Startup #DistributedSystems

Giiker Decipher (Рубрика #ForKids)

Я стал фанатом игрушек от компании Giiker - они очень приятные тактильно, а также в них просто интересно играть. Так на эту игрушку-дешифратор подсел мой пятилетний сын Кирилл, с которым мы перед сном теперь играм в загадывание кода, а потом разгадывание по очереди. Суть это игры в том, что у нас есть 4 слота, в которых загадан цветовой код. У нас есть 7 попыток на то, чтобы отгадать его. И загадывание и отгадывание в игре управляется оранжевой крутилкой, которую можно нажимать для того, чтобы установить код или проверить его. Собственно, есть опция играть вдвоем или одному против компьютера, а также можно играть в direct или non-direct версию (первая попроще). В direct версии мы выбираем зашифрованную последовательность и нажимаем проверить - дальше приходит ответ:
- Если огонек под цветом не горит, то цвета нет
- Если огонек горит белым, то цвет есть, но он расположен не в правильном месте
- Если огонек горит зеленым, то значит мы угодали цвет этого квадратика

Эта логика достаточно простая, но есть усложненная версия non-direct, которая посложнее и интереснее.
В общем, как уже стало понятно, мне эта игрушка нравится и моему сыну тоже, поэтому я и вам могу ее рекомендовать.

#Brain #Game #SelfDevelopment #Security

Borland: rise and fall of a software enmire - the delphi story (Рубрика #Software)

Посмотрел на днях документальный фильм про компанию Borland, создавшая революционные инструменты для разработчиков (Turbo Pascal, Delphi). Я понмю, как писал свой бакалаврский диплом на Delphi 6 (клеточную модель мира для расчетов биогеоценоза + климата для предсказания климата). Это было где-то в 2006-2007 годах и уже тогда был виден упадок Delphi, хотя когда-то они были на коне и будущее выглядело перспективным. Кстати, после фильма я вспомнил, что читал на Хабре отличную статью "Как Borland «профукали все полимеры»".

Ну а теперь рассмотрим ключевые вехи истории Borland

🚀 1983: Запуск Turbo Pascal
Первый громкий успех Borland - выпуск Turbo Pascal, фактически первой удобной IDE на рынке (и дешевле на порядок IDE от конкурентов). Доступный и быстродействующий компилятор завоевал популярность среди программистов и образовательных учреждений, заложив основу будущего успеха компании.

🌟 1995: Появление Delphi
В середине 90-х Borland представила среду визуальной разработки Delphi - флагманский продукт, совершивший прорыв в быстрой разработке под Windows. Delphi закрепила репутацию Borland как лидера инструментов для разработчиков.

👋 1995–1996: Уход ключевых фигур
На пике успеха компанию покидают ее вдохновители. В 1995 году из-за разногласий с советом директоров уходит основатель и генеральный директор Филипп Кан. А в 1996-м Microsoft переманивает ведущего инженера Borland Андерса Хейлсберга, архитектора Turbo Pascal и Delphi. Потеря этих лидеров стала серьёзным ударом по стратегическому курсу и инновационному потенциалу компании. Кстати, Андерс Хейлсберг потом в Microsoft сделал C# и Typescript

⚠️ Стратегические просчёты
Стремясь расти, Borland сделала ряд сомнительных ходов. Компания увлеклась расширением через покупки, не думая об интеграции продуктов: так, приобретение базы dBase при наличии собственной Paradox обернулось тем, что оба продукта потеряли позиции. Также Borland пыталась заняться офисными приложениями и другими "модными" направлениями по совету аналитиков, отвлекаясь от ядра своего бизнеса (инструментов разработки). Эти шаги ослабили фокус компании.

🔄 Смена курса и ребрендинг
В конце 90-х, следуя конъюнктуре рынка, руководство объявило, что разработка инструментов больше не стратегический приоритет, и переименовало компанию в Inprise для имиджа корпоративного игрока. Этот резкий поворот едва не погубил Borland: разработчики восприняли его негативно, и финансовое положение ухудшилось. Лишь сохраняющаяся популярность продуктов Delphi (а позднее JBuilder) временно спасла ситуацию. Но в последующие годы Borland так и не смогла вернуть утраченные позиции, продала это направление, а потом прекратила своё самостоятельное существование.

В итоге, история компании выглядит занимательно и из нее можно почерпнуть несколько мыслей для технических лидеров и компаний

🎯 Фокус на своём ядре
История Borland показывает, насколько важно держаться своих сильных сторон. Компания добилась успеха, концентрируясь на инструментах для разработчиков, и начала терять позиции, как только отвлеклась на побочные рынки и тренды.
🤝 Обдуманные поглощения
Расширение через покупки может обернуться провалом, если не продумана совместимость и стратегия.
🏃 Ценность команды и знаний
Ключевые люди - носители экспертизы и духа компании. Уход Филиппа Кана и Андерса Хейлсберга оголил стратегические проблемы Borland.
🔀 Осторожно с резкой сменой курса
Радикальные перемены в стратегии и бренде могут разом обесценить годы доверия. Ребрендинг Borland в Inprise и отказ от любимых разработчиками продуктов подорвали репутацию компании.
📣 Прислушиваться к сообществу, а не только к аналитикам
Борьба за корпоративный сегмент выглядела перспективно на бумаге, но Borland игнорировала желания своей основной аудитории - разработчиков. Поэтому когда появились альтернативы (тот же C#) разработчики отвернулись от компании.

#Engineering #Software #Management #Leadership #Architecture

Марко Спада в Большом Театре (Рубрика #Humor)

Уже сложилась традиция, что каждый год я хожу с женой в Большой Театр зимой. Обычно это подарки на Новый год или мой День Рождения. Таким темпом я постепенно начинаю разбираться в балете, но у меня все равно остается вопрос - почему у девушек в балете платья, а у мужчин "термобелье":)

#Culture