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
Интересный рассказ Линуса Торвальдаса о том, как 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
YouTube
Two decades of Git: A conversation with creator Linus Torvalds
Twenty years ago, Linus Torvalds created the basis for Git in just 10 days, forever changing how developers collaborate on code. In this candid interview, Linus Torvalds discusses Git's unexpected journey from a Linux kernel management tool to the foundation…
❤12🔥8👍6🎉2
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
Интересный получасовой эпизод подкаста 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
YouTube
How McKinsey Plans to Survive AI (and Reinvent Consulting)
How does a storied consulting firm reflect on its history while forging a path ahead in uncertain times? In this episode of HBR IdeaCast, McKinsey Global Managing Partner Bob Sternfels speaks with host Adi Ignatius about the controversies that have ignited…
🔥11❤7👍4
"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
Очередной интересный выпуск 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
YouTube
OpenAI’s head of platform engineering on the next 12-24 months of AI | Sherwin Wu
Sherwin Wu leads engineering for OpenAI’s API platform, where roughly 95% of engineers use Codex, often working with fleets of 10 to 20 parallel AI agents.
*We discuss:*
1. What OpenAI did to cut code review times from 10-15 minutes to 2-3 minutes
2. How…
*We discuss:*
1. What OpenAI did to cut code review times from 10-15 minutes to 2-3 minutes
2. How…
🔥13❤7👍7
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
В этом видео Лэсли Лэмпорт за 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
YouTube
The Man Who Revolutionized Computer Science With Math
Leslie Lamport revolutionized how computers talk to each other. The Turing Award-winning computer scientist pioneered the field of distributed systems, where multiple components on different networks coordinate to achieve a common objective. (Internet searches…
❤12🔥6👍3
История 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
Интересное видео про историю операционных систем от канала 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
YouTube
История Linux и UNIX! Кто породил ВСЕ современные системы!
Получите месяц Толка бесплатно по промокоду PRO — https://bit.ly/3tzEklU
Недорогой монитор QHD https://www.citilink.ru/product/monitor-sunwind-27-sun-m27bg130-chernyi-ips-8ms-16-9-hdmi-mat-250cd-1772349/?utm_source=yt_blogger_prohitech&utm_medium=display…
Недорогой монитор QHD https://www.citilink.ru/product/monitor-sunwind-27-sun-m27bg130-chernyi-ips-8ms-16-9-hdmi-mat-250cd-1772349/?utm_source=yt_blogger_prohitech&utm_medium=display…
❤10👍6🔥3
Дискуссия с Гришей Скобелевым про подготовку к 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
Завтра, 21 февраля, в 11 часов утра по Москве мы с Гришей из клуба { между скобок } решили собраться и поговорить про подготовку к System Design Interview и про то, как я дошел до жизни такой, что собрал сайт system-design.space
Мы точно обсудим вопросы, что есть в программе встречи
• Почему книга не лучший формат для System Design
• Как меняются ожидания на интервью
• Какие ошибки чаще всего допускают кандидаты
• Что на самом деле проверяют на System Design интервью
• Как отличить «рисование кубиков» от настоящего архитектурного мышления
• Какие темы обязательно нужно понимать senior / staff инженеру
Но также думаю, что затронем вопросы системного мышления и фундаментальной подготовки, а не просто запоминания задач.
Встречаемся завтра c кофе ☕️ в 11:00 на YouTube
#SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering
Telegram
{ между скобок } анонсы 📣
21 февраля 11:00 по мск Александр Поломодов: Как на самом деле готовиться к System Design интервью
Саша решил не писать книгу по System Design, а создать живой сайт с лучшими практиками — https://system-design.space.
Мы обсудим:
• Почему книга не лучший…
Саша решил не писать книгу по System Design, а создать живой сайт с лучшими практиками — https://system-design.space.
Мы обсудим:
• Почему книга не лучший…
👍17❤10🔥6
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
Интересно интервью Бориса из Anthropic в подкасте Lightcone от Y Combinator. Обсуждение строилось вокруг Claude Code и того, как Борис создал этот один из самых успешных AI инструментов в виде простого терминального продукта, а также про то, а что будет дальше.
Если говорить про ключевые инсайты, то они такие
В Anthropic принцип: не оптимизировать продукт под текущую модель, а думать о том, какой она будет через ~полгода. Любой сложный «скэффолдинг» вокруг модели часто даёт +10–20% и полностью обнуляется следующим релизом, поэтому лучше минимальный слой обвязки и ждать апгрейда модели.
Борис просто хотел научиться пользоваться API Anthropic и написал терминальный чат‑клиент, без UI. Добавил bash‑tool, попросил модель "узнать, какую музыку я слушаю", та сгенерировала AppleScript и залезла в плеер - для него это был первый "AGI‑момент»: модель "очень хочет использовать инструменты".
🖥 Почему терминал и почему он "прилип"
Терминал выбран не из идеологии, а как самый дешёвый способ сделать прототип. Внутри Anthropic люди начали использовать его "до того, как он был готов", потому что:
- Удобно автоматизировать git, bash, Kubernetes, рутинные DevOps‑таски
- Продукт ощущается как "игра", а не как тяжёлый IDE‑плагин
Из этого вырос принцип: следовать латентному спросу (latent demand) - смотреть, что люди уже пытаются делать, и облегчать ровно это, а не навязывать новый поток работы. Это прямо топовый продуктовый подход для создания внутренних инструментов разработки.
У Бориса личный CLAUDE.md - всего две строки: включать automerge на PR и постить PR в командный канал для быстрого ревью. Вся остальная "политика" живёт в repo‑локальном CLAUDE.md, который вся команда правит по несколько раз в неделю. Он советует: если файл раздулся до тысяч токенов, просто удалить и собрать заново - с каждой моделью нужно всё меньше инструкций.
Команда постоянно тюнингует детализацию: пытались скрывать bash‑вывод, сотрудники взбунтовались - он нужен для дебага (Kubernetes, сложные команды). Скрыли подробные логи чтения файлов/поиска, но по жалобам GitHub‑юзеров добавили режим verbose в конфиге.
- 80% сессий начинает в plan mode: сначала план, потом выполнение.
- Распараллеливает работу: несколько вкладок в терминале и десктоп‑приложении, каждая начинает с плана.
- При сложных задачах явно просит несколько подагентов (3, 5, 10) исследовать проблему в параллели и потом объединить вывод.
- Plan mode - просто одна дополнительная фраза в промпте "пожалуйста, пока не пиши код".
- Он считает, что срок жизни явного plan mode ограничен: при росте способностей модели она сама будет входить в "режим планирования", а потом и вовсе можно будет "одним шотом" давать задачу.
- Уже сейчас Claude Code иногда сам включает план‑режим, когда это было бы естественно для человека.
⛓️ Автоматизация всей инженерной цепочки
- Внутри Anthropic Claude‑агенты (через Claude Agents SDK) автоматизируют: code review, security review, triage и лейблинг задач, путь фичи до продакшена.
- Фича plugins для Claude Code полностью была написана «роем» агентов за выходные: один агент получил спеку, создал задачи в Asana, породил подагентов, те подняли PR‑ы.
- Главное - научный подход, мышление от first‑principles и готовность признавать ошибки; многие опытные инженеры застряли в старых паттернах.
- Борис ценит либо гипер‑специалистов (как команда bun / люди, одержимые devtools, рантаймами), либо гипер‑генералистов, которые пересекают продукт, инженерку, ресёрч, бизнес.
- Отбор кандидатов - в том числе по поведению с агентами: можно ли по транскрипту сессии понять, что человек умеет мыслить системно, использовать план, логи, корректировать модель.
#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Inside Claude Code With Its Creator Boris Cherny
A very special guest on this episode of the Lightcone! Boris Cherny, the creator of Claude Code, sits down to share the incredible journey of developing one of the most transformative coding tools of the AI era.
00:00 Intro
01:45 The most surprising moment…
00:00 Intro
01:45 The most surprising moment…
🔥11👍5❤3👎1😱1👌1
It takes two (Рубрика #Games)
Почти 20 лет я не играл в компьютерные игры, но на этот новый год мы купили детишкам PS 5 с кучей игрушек. Но Настя (моя жена) не обделила и нас и купила эту кооперативную игру. Мы в нее играли иногда по вечерам и за полтора месяца прошли. Игра оказалась очень интересной, веселой, местами психологической и наводящей на мысли о семейном быте. Вся история крутится вокруг родителей маленькой девочки, что решили развестись. Чаяниями их дочки мама и папа оказываются в своем доме в виде игрушек и им нужно пройти большой путь, чтобы стать опять людьми.
В общем, игра была превосходная - мы даже купили игру Split Fiction, которую сделала та же студи и в которой история другая, но кооперативные механики те же.
#ForParents
Почти 20 лет я не играл в компьютерные игры, но на этот новый год мы купили детишкам PS 5 с кучей игрушек. Но Настя (моя жена) не обделила и нас и купила эту кооперативную игру. Мы в нее играли иногда по вечерам и за полтора месяца прошли. Игра оказалась очень интересной, веселой, местами психологической и наводящей на мысли о семейном быте. Вся история крутится вокруг родителей маленькой девочки, что решили развестись. Чаяниями их дочки мама и папа оказываются в своем доме в виде игрушек и им нужно пройти большой путь, чтобы стать опять людьми.
В общем, игра была превосходная - мы даже купили игру Split Fiction, которую сделала та же студи и в которой история другая, но кооперативные механики те же.
#ForParents
👍32❤10🔥5
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
Наконец-то у меня дошли руки написать про этот интересный 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
Google Research
Understanding Architectural Complexity, Maintenance Burden, and Developer Sentiment -- A Large-Scale Study
❤8👍4🔥4
Как взять идеи 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
В прошлом посте мы разбирали 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
Telegram
Книжный куб
Understanding Architectural Complexity, Maintenance Burden, and Developer Sentiment - a Large-Scale Study (ICSE’25) (Рубрика #Architecture)
Наконец-то у меня дошли руки написать про этот интересный whitepaper про связь качества архитектуры с нагрузкой на…
Наконец-то у меня дошли руки написать про этот интересный whitepaper про связь качества архитектуры с нагрузкой на…
🔥17⚡2❤2👍1
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
Интересное видео 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 → "ломаем билд" на нарушениях.
То есть не "один деплой" плохо, а переплетённость (циклы, обход границ, случайные импорты, нарушение слоёв).
Они оправданы, когда реально нужно независимо деплоить, изолировать изменения, масштабировать по частям, разводить ответственность команд.
Если драйверов нет - вы покупаете overhead без выигрыша.
Для разработчиков следуют такие практические выводы
- Цель: сделать “границы” реальными, а не декоративными
Модуль = единица эволюции, а не папка. Есть публичный API, есть скрытая внутрянка, есть запреты на “обход”.
- Направление зависимостей важнее названий слоёв
Следите за циклами, “обратными” ссылками, протеканием инфраструктуры в домен.
Для технических руководителей следуют такие практические выводы
Архитектурные ярлыки не заменяют управления границами. Если мотивация “давайте микросервисы, чтобы код разделился сам” - это красный флаг.
Сначала: границы, ownership, правила, ревью‑политики, архитектурные тесты. Микросервисы по определению увеличивают:
- Число deploy‑единиц
- Количество коммуникаций
- Требования к CI/CD, observability, security, data contracts
Стратегия, которая обычно работает лучше:
- Modular monolith - дефолт
- Microservices - осознанная инвестиция при устойчивых драйверах
P.S.
Как обычно, расширенная версия есть на system-design.space.
#Architecture #Software #DistributedSystems #Engineering #Management
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Modular Monoliths and Other Facepalms - Kevlin Henney - NDC London 2026
This talk was recorded at NDC London in London, England. #ndclondon #ndcconferences #developer #softwaredeveloper
Attend the next NDC conference near you:
https://ndcconferences.com
https://ndclondon.com/
Subscribe to our YouTube channel and learn…
Attend the next NDC conference near you:
https://ndcconferences.com
https://ndclondon.com/
Subscribe to our YouTube channel and learn…
🔥19❤11💯5👍3
Мюзикл на чердаке (Рубрика #Culture)
Были вчера с женой на этом мюзикле в Детском музыкальном театре "Поколение" и нам очень понравилось. У нас случилась накладка по расписанию и мы оба ехали туда отдельно и опоздали - я на 10 минут, а жена на полчаса, но как мы добрались нас сразу впустили в зал и мы смогли насладиться концертом, в основе которого знакомые с детства шлягеры в жанре мюзикла. По легенде спектакля брат и сестра спрятались от своей мамы на чердаке и нашли кассету с хитами мировых мюзиклов - а дальше музыка начинает оживать вокруг них. Мне понравились все хиты, но особо части про призрака оперы (когда ехали обратно, то слушали Nightwish), а Насте понравилась песня из диснеевского мультика "Русалочка". В общем, я непрочь и повторно сходить на этот же спектакль еще раз, но мы решили съездить с детишками в этот театр на спектакль попроще и покороче (этот был 12+ лет и длился 2.5 часа).
#ForParents #ForKids
Были вчера с женой на этом мюзикле в Детском музыкальном театре "Поколение" и нам очень понравилось. У нас случилась накладка по расписанию и мы оба ехали туда отдельно и опоздали - я на 10 минут, а жена на полчаса, но как мы добрались нас сразу впустили в зал и мы смогли насладиться концертом, в основе которого знакомые с детства шлягеры в жанре мюзикла. По легенде спектакля брат и сестра спрятались от своей мамы на чердаке и нашли кассету с хитами мировых мюзиклов - а дальше музыка начинает оживать вокруг них. Мне понравились все хиты, но особо части про призрака оперы (когда ехали обратно, то слушали Nightwish), а Насте понравилась песня из диснеевского мультика "Русалочка". В общем, я непрочь и повторно сходить на этот же спектакль еще раз, но мы решили съездить с детишками в этот театр на спектакль попроще и покороче (этот был 12+ лет и длился 2.5 часа).
#ForParents #ForKids
❤7👍2🔥1
[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
Интересное и короткое интервью 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
YouTube
OpenClaw Creator: Why 80% Of Apps Will Disappear
You’ve probably already heard all about OpenClaw (formerly Clawdbot/Moltbot). The viral sensation is an open-source AI assistant that runs on your own device, connects with messaging apps you already use, and goes beyond chat to actually execute tasks like…
❤8🔥6⚡2
[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
Интервью было очень интересным и прорывным, но всегда интересно, а как перевести эти идеи в практическое русло.
Для разработчиков отсюда можно извлечь следующее
Если ваш продукт можно выразить как операции - агент сможет "съесть" ваш 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
Telegram
Книжный куб
[1/2] OpenClaw Creator: Why 80% Of Apps Will Disappear (Рубрика #AI)
Интересное и короткое интервью Peter Steinberger, создателя OpenClaw (недавно перешедшего в OpenAI) проlocal-first персональных агентов и то, как они могут "съесть" большую часть привычного…
Интересное и короткое интервью Peter Steinberger, создателя OpenClaw (недавно перешедшего в OpenAI) проlocal-first персональных агентов и то, как они могут "съесть" большую часть привычного…
🔥8❤5👍3👎1🎃1
Дискуссия с Гришей Скобелевым про подготовку к 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
На этих выходных мы с Гришей из клуба { между скобок} поговорили про подготовку к 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
YouTube
Александр Поломодов: Как на самом деле готовиться к System Design интервью
Саша решил не писать книгу по System Design, а создать живой сайт с лучшими практиками - https://system-design.space.
Мы обсудим:
• Почему книга не лучший формат для System Design
• Как меняются ожидания на интервью
• Какие ошибки чаще всего допускают кандидаты…
Мы обсудим:
• Почему книга не лучший формат для System Design
• Как меняются ожидания на интервью
• Какие ошибки чаще всего допускают кандидаты…
1❤16🔥11👍8
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
Интересный документальный фильм про фреймворк 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
YouTube
Laravel Origins: A PHP Documentary
🎥 More tech documentaries coming out soon, subscribe to be notified 👉
👕 Get your Laravel Origins swag: https://bit.ly/laravel-swag
Featuring Laravel creator Taylor Otwell and many others who’ve contributed to making Laravel the technology and community that…
👕 Get your Laravel Origins swag: https://bit.ly/laravel-swag
Featuring Laravel creator Taylor Otwell and many others who’ve contributed to making Laravel the technology and community that…
🔥5❤3⚡1