Книжный куб

Как продакт из Meta запускает продукты, не умея программировать (Рубрика #AI) Еще полгода назад посмотрел выпуск Lenny’s Podcast с Zevi Arnovitz, продактом из запрещённой в России Meta и бывшим PM в Wix, но забыл об этом написать. Тогда мне показалось, что вот оно - новое наполнение роли продакта, но если это работает в условной Meta, то не факт, что легко переносится и в другие компании:) Сейчас я писал пост про то, что ждет продактов и вспомнил об этом видео и решил поделиться им с вами. У самого Zevi нет технического образования, и он признаётся, что почти не умеет читать код. При этом, по словам участников выпуска, за год он самостоятельно собрал и монетизировал StudyMate - сервис, который превращает учебные материалы в интерактивные тесты. Его процесс работы мало похож на классический vibe coding: - Идея превращается в задачу Linear через MCP; - Claude изучает кодовую базу, задаёт вопросы и готовит план; - Gemini берёт интерфейс, Composer - быстрое исполнение, Codex - поиск сложных ошибок; - Результат проходит ручной QA, несколько AI-review и пользовательское тестирование; - После ошибок обновляются инструкции и документация агента. По сути, Zevi построил вокруг моделей маленькую инженерную организацию. Он владеет проблемой и тем, что должен почувствовать пользователь, а агентам делегирует реализацию. Продакт теперь может не только написать PRD и ждать команду, но сам пройти путь от идеи до работающего продукта и обратной связи от пользователей. Отсюда его прогноз: названия должностей и границы ответственности начнут схлопываться, а «строителями» станут все. Для начинающих специалистов это ещё и способ получить практику сразу в стратегии, UX, маркетинге и разработке. Но есть важная оговорка. В большой компании Zevi не советует продактам самостоятельно выкатывать миграции базы или другие рискованные изменения. AI-native кодовую базу сначала должны подготовить инженеры: добавить контекст, документацию и ограничения. Разумный старт для PM - локальная UI-фича, PR и финальная проверка разработчиком. В общем, сейчас продакту не обязательно становиться программистом, но уже недостаточно оставаться только постановщиком задач. Нужно уметь собирать систему вокруг агентов, проверять результат и отвечать за него. Фраза «это сделал AI» ответственности не снимает. #AI #ProductManagement #AI4SDLC #Engineering #Management #VibeCoding

Граф зависимостей как фильтр перед хаос инженерией (Рубрика #SRE) Прочитал пятистраничную работу Анатолия Красновского "Model Discovery and Graph Simulation: A Lightweight Gateway to Chaos Engineering". Главная идея простая: перед дорогими экспериментами со сбоями можно автоматически собрать из распределенных трасс граф зависимостей, добавить число реплик и дешево прогнать по нему Monte Carlo. Практическая проблема таких моделей - ручное описание архитектуры, которое быстро устаревает. Здесь граф извлекается из Jaeger; в перспективе источниками могут быть телеметрия service mesh, манифесты Kubernetes/Terraform, API-контракты и SLO-as-Code. Получается не еще одна диаграмма, а исполняемая модель доступности, которую можно обновлять в CI/CD. Проверяли подход на DeathStarBench Social Network: два режима развертывания, пять долей отказавших экземпляров, сравнение симуляции с реальным внедрением сбоев (fault injection). Общая корреляция между моделью и живым экспериментом составила около 0,992. При репликации и доле отказов 0,3 оценки практически совпали: 0,3054 против 0,3054. Но без реплик отклонение было систематическим: от -24,4% при 0,1 до +20,7% при 0,5. Отдельно надо отметить, что модель видит только обязательные синхронные вызовы и независимые fail-stop отказы. Она не учитывает частичные и серые отказы (gray failures), коррелированные сбои, очереди, повторные попытки, сброс нагрузки и асинхронные потоки. А опытные архитекторы знают, что реальный радиус поражения (blast radius) часто определяется не числом сервисов или кластеров, а общими коррелированными слоями - образом ОС, CNI, системой доставки или цепочкой поставки. Поэтому для меня это не замена хаос инженерии, а хороший и относительно дешевый этап перед ним. Граф быстро показывает подозрительные цепочки, единичные точки отказа (SPOF) и эффект репликации; живые эксперименты остаются для мест, где топология неполна или поведение системы сложнее бинарного «работает / упал». Работа вошла в ICSE-NIER 2026 и получила отметку Distinguished Paper Award (кстати код к статье опубликован). Но пока это проверка на одном примере (proof by instance) и одном бенчмарке. Практический первый шаг для платформенной команды: связать трассы, граф зависимостей, SLO и число реплик в проверяемый артефакт - а уже из него формировать короткий список chaos-сценариев с наибольшим риском. P.S. Возможно, запишем с автором статьи ее разбор и обсуждение инежнерного продукта, что сделал автор на базе этой идеи. Если вам нравится эта идея, то поставьте 👌 #Software #Engineering #Architecture #DevOps #PlatformEngineering #RnD

AMA Сессия про AI-assisted Engineering с Алексеем Литвиновым (Рубрика #AI4SDLC) В понедельник в 17:00 по Москве вместе с Алексеем Литвиновым в прямом эфире поговорим про AI-Assisted Engineering и про то, как вообще строить AI-Native организацию где сможем обсудить темы от работы с одним агентом до операционной модели целой команды и огранизации. Кстати, у Лёши есть свой tg-канал - @tip_podcast, подписывайтесь на него Мы договорились обсудить - зрелость работы с AI // от «пишу код сам» до экосистемы на принципах - verification debt и цена проверки - почему навык уезжает из кодинга в менеджмент - AI-native организация: операционка, роли, governance - люди и найм, когда рядом агенты И мы с радостью учтем еще и ваши вопросы, что вы можете оставить через Google Forms, где вы сможете рассказать - Кто вы по роли - Что хотите, чтобы мы разобрали - С каким тезисом про AI вы не согласны (опционально) В принципе, вы можете написать интересующие вас темы и в комментариях к этому посту. Самые интересные и популярные темы мы заберем в прямой эфир и разберем их там. #Books #AI4SDLC #AI #Agents #Engineering #Architecture #Leadership

База про Causal AI: сначала граф, потом эффект (Рубрика #RnD) Посмотрел короткий доклад Вадима Порватова из Сбера «Проблемы и перспективы Causal AI» с Data Fest 2026. Это хороший пятнадцатиминутный маршрут по теме, которую часто сводят к фразе «корреляция не означает причинность». Главный тезис здесь практичнее: прежде чем оценивать эффект действия, нужно восстановить хотя бы правдоподобную структуру причин. Вадим начинает с трёх уровней аналитики - Описательная отвечает на вопрос, что произошло - Предсказательная дает ответ о том, что произойдёт - Каузальная подсказывает, а что нужно изменить, чтобы получить нужный результат Золотой стандарт для последней - рандомизированный эксперимент или a/b тест. Кстати, по a/b тестам рекомендую книгу "Доверительное a/b тестирование (Trustworthy Online Controlled Experiments)", о которой я уже рассказывал. Но такие тесты могут быть дорогими, долгими, неэтичными или физически невозможными. Тогда приходится работать с наблюдаемыми данными и явно записывать допущения. Дальше доклад пробегает почти всю карту causal discovery: - От Фишера с рандомизированными экспериментами к potential outcomes Рубина и structural causal models Джудеи Перла; - Два этапа causal inference: сначала identification - какой причинный граф допустим, затем estimation - каков эффект вмешательства; - Два классических семейства поиска структуры: constraint-based и score-based; на входе таблица данных плюс экспертные ограничения на наличие и направление связей; - Допущения об ацикличности, Markov property и faithfulness, а главное - causal sufficiency: все ли общие причины измерены. Именно скрытый confounder способен превратить сильную корреляцию в ложную историю про эффект; - Алгоритмы PC/SGS и семейство FCI. FCI не просто ориентирует рёбра, а отмечает места, где связь может объясняться скрытой переменной; FCI-stable, RFCI и FCI+ улучшают устойчивость, скорость или работу с разреженными графами. Более новые методы пытаются уже восстанавливать структуру latent variables. Отдельный холодный душ - LLM. По приведённой Вадимом работе, модели без специальной настройки плохо решают causal discovery, а fine-tuning даёт хрупкий выигрыш: небольшой сдвиг данных ломает результат. Для сценарного моделирования LLM нужен внешний causal grounding, а не уверенный текст о том, «что на что влияет». В финале Вадим показывает CAIMAN - разрабатываемую в Сбере библиотеку с оптимизированными вариантами PC/FCI, bootstrap-оценкой неопределённости и будущим переносом вычислений на GPU. По словам автора, код планируется опубликовать; публичного репозитория на момент проверки я не нашёл. P.S. Вообще, я в эту тему погрузился когда-то, когда разбирался с современной моделью DORA - её ежегодные исследования тоже начинаются с опросов, то есть с наблюдательных, а не экспериментальных данных. - В ранней методологии DORA использовала теоретические гипотезы, латентные конструкты, факторный анализ и PLS-SEM (про это говорит документ 2021 года) - В отчёте 2024 года подход сформулирован ещё ближе к докладу: исследователи задают DAG, решают, какие факторы учитывать, а затем байесовски оценивают направление, величину и неопределённость эффектов. Но статистика не превращает ответы респондентов в причинность по щелчку. Вывод остаётся условным относительно выбранного графа, качества вопросов и учтённых confounders. И тут мы видим прямую связку с докладом: самая важная часть causal inference происходит до расчёта коэффициентов - когда мы решаем, какие переменные существуют и почему между ними вообще должна быть стрелка. #AI #Data #MachineLearning #CausalInference #Research #DORA

Люблю встречаться с интересными людьми на встречах CxO Community. Такие коммьюнити есть у разных компаний, но у Сбера это часто связано не только с нетворкингом, но и с интересным опытом. В прошлый раз событие было вокруг дегустации вин, а в этот раз мы слушаем Оскара Конюхова, руководителя штаба его отца, Федора Конюхова. Рассказ идет про планирование и реализацию сложных проектов на грани технических и человеческих возможностей. Спасибо организаторам Sber CxO TechCommunity, это реально интересные мероприятия.

Research Insights Made Simple #23 - Экономика AI в разработке (Рубрика #AI4SDLC) Голосование показало, что тема интересна и поэтому завтра в 17:00 в прямом эфире разберём экономику AI в разработке. Суть в том, что токены дешевеют, модели становятся быстрее, но AI-бюджет компании от этого не обязательно уменьшается. Чем больше появляется рабочих сценариев, тем больше становится задач, агентных цепочек, инфраструктуры, проверок и цены ошибок. Поговорим о том: - Почему удешевление фиксированного уровня качества расширяет спрос и способно увеличить общий бюджет; - Как агентная задача превращается в длинный trace с десятками вызовов, повторами и растущим контекстом — и почему ограничения нужны на весь workflow; - Как считать cost per accepted task, включая инструменты, инфраструктуру, человеческую проверку, переделки и цену ошибки; - Зачем сначала вводить общий quality gate и showback, а уже потом chargeback, роутинг и оптимизацию стоимости; - Где возникает vendor lock-in и когда локальная модель действительно выгоднее облачной после учёта качества и эксплуатации. Отдельно покажу рабочий сценарий до 2029 года: цена сегодняшнего уровня качества может снизиться в разы, а бюджет успешного AI-портфеля — вырасти. Это не обещание рынка, а рамка для разговора о том, что именно компания получает за эти деньги. Основной вопрос эфира про то, какая единица связывает качество, стоимость и риск? Токены удобны для счёта поставщика. Для инженерной организации полезнее принятая работа — задача, которая прошла проверку, не потребовала дорогой переделки и дала нужный результат. Материалы к эфиру: дека и лонгрид, а также можете закидывать свои вопросы в комментариях к этому сообщению. #AI #AI4SDLC #Engineering #FinOps #Agents #Management #Metrics

Вчера выступал на Podlodka AI Club и рассказывал свои мысли про экономику AI в разработке. Когда готовился, то собрал вот такой лонгрид и вот такую слайд деку, но само выступление не записывалось. Я могу записать отдельное видео для подписчиков канала, если вы хотите, но давайте соберем 👌 под этим постом, чтобы я понял, что вам эта идея нравится. Если их будет больше двадцати по итогу, то видео выйдет на Youtube, если нет, то останется только текстовые версии.

Грэм Уивер: как придумать игру, в которой хочется победить (Рубрика #Management) Посмотрел последнюю лекцию Грэма Уивера для класса Stanford GSB 2025 года - «How to Design a Winnable Game». Грэм - преподаватель менеджмента в Стэнфорде, основатель и партнер Alpine Investors. Но говорит он не об инвестициях, а о моменте, когда понимаешь: много лет ты успешно играешь не в свою игру. Начинается лекция с личного момента, когда во время кризиса 2008 года, по словам Уивера, фонд потерял 40%, крупнейший инвестор решил уйти, а он ночью считал, на сколько месяцев семье хватит сбережений, пока рядом спала новорожденная дочь. Вместо «как работать лучше, быстрее и больше?» появился другой вопрос: «а в ту ли игру я вообще играю?». И выигрышная игра в его понимании - та, в которой внешний успех не спорит с внутренним ощущением смысла. Ее не находят в готовом виде, а проектируют по четырем правилам. 1️⃣ Выбрать цель, которая по-настоящему зажигает Не ориентир «лишь бы не проиграть», а направление, ради которого хочется вставать утром. Большая цель меняет наши действия и готовность идти долго. 2️⃣ Придумать собственную игру Многие ограничения - не правила, а привычки отрасли. Стоит искать то, что ненавидят клиенты, чего не делают конкуренты, что лично не дает покоя, - и развивать уже работающие сильные стороны. 3️⃣ Играть с людьми, которыми восхищаешься Окружение формирует наши цели, ценности и характер. Важно выбирать людей, рядом с которыми можно оставаться собой и не приносить жизнь в жертву результату. 4️⃣ Начать сейчас «Не сейчас» - удобная форма страха. Жизнь не начинается после кредита, повышения или смены работы. Все, что мы пытаемся поскорее «пройти», и есть наша жизнь. Это очень глубокое и личное выступление. Оно не обещает быстрых ответов, но мотивирует остановиться, честно посмотреть на свою жизнь и начать изменения - не когда-нибудь, а сейчас. Ну и я забрал из этой истории идею о том, что прежде чем становиться эффективнее, стоит проверить саму систему координат. Хочу ли я победить в этой игре? Делает ли участие в ней меня тем человеком, которым я хочу быть? И с теми ли людьми я ее прохожу? P.S. Мне вспоминалась другая последняя лекция примерно того же уровня «Randy Pausch Last Lecture: Achieving Your Childhood Dreams», о которой я рассказывал раньше. Обе эти лекции построены похоже и мотивируют посмотреть на свою жизнь и понять, а занимаешься ли ты тем, что действительно хочешь ... и если нет, то это значит, что пора что-то менять. #Management #Leadership #Career #Goals #Stanford

ArchBench: хороший каркас, слабый лидерборд (Рубрика #Architecture) Прочитал короткую работу "ArchBench: Benchmarking Generative-AI for Software Architecture Tasks". Идея здравая: собрать разрозненные evals для software architecture в одну расширяемую систему. Но на 19 июля 2026 года это скорее каркас будущего бенчмарка, чем рабочий лидерборд для выбора модели (можете сами оценить лидерборд на сайте бенча). Команда SERC из индийского IIIT Hyderabad собрала открытую систему из CLI и React-сайта. Каждая задача - это плагин со своим загрузчиком данных, промптом, парсером и метриками. Общий конвейер проходит стадии загрузки, инференса и оценки, сохраняя промпты, сырые ответы, использование токенов и latency. Результаты и новые задачи предполагается принимать через PR. Но наполнение у самого бенча слабое - всего 5 задач - Генерация ADR (architecture decision records) - Генерация serverless-компонентов - Создание dynamic IoT сервисов - Создание микросервисов - Восстановление traceability Эти задачи не покрывают архитектурный анализ, размышление о зависимостях, масштабный рефакторинг или работу с компромиссами. Причем end-to-end автоматизированы в CLI только написание ADR и восстановление traceability, а еще три таблицы с метриками перенесены из исходных исследований, их пайплайны для оценок пока интегрируются. Метрики смешивают разные вещи - ROUGE и BERTScore измеряют похожесть текста (для написания ADR) - Test pass rate - функциональность кода при генерации сервисов и функций Правда, это далеко от оценки качества архитектуры. Агентных sandbox-окружений для использования инструментов у ребят пока нет пока нет. Набор моделей тоже удивляет: GPT-3.5, старые GPT-4, Flan-T5/T0, CodeQwen и DeepSeek прежних поколений. В генерации микросервисов есть Codex и Claude Code, но без точных версий и конфигураций, а значит сравнивать такие цифры сложно Авторы отмечают, что рассчитывают на коммьюнити рост (вот GitHub бенча, если захотите законтрибьютить), но в публичной истории на 19 июля не видно внешних контрибьютов с новыми задачами или результатами моделей. После статьи менялись интерфейс и код, но не сам измерительный корпус. Итого, этот бенч выглядит как концепт, но он станет реальным бенчом после расширения задач, полной автоматизации, запуска современных версионированных моделей и появления независимых участников. А пока это приглашение строить бенч. #Architecture #AI #AI4SDLC #Evals #Research

Telegram doesn't show this post on the web. Open it in Telegram to see it.

Telegram doesn't show this post on the web. Open it in Telegram to see it.

Theo Browne про AI-разработку: мыслить шире, проектировать строже (Рубрика #AI4SDLC) Посмотрел заключительный keynote Theo Browne «Everything we knew about software has changed» с AI Engineer World's Fair 2026. Theo строит инструменты для разработчиков, поэтому его интересно слушать не как комментатора моделей, а как практика, у которого AI уже изменил масштаб проектов. Главная мысль его доклада: границу «слишком большого» пора провести заново. Сдвиг Theo показывает через собственную лестницу - Reddit scraper был проектом на два-три дня - Ping, сервис для совместных стримов, стал стартапом и прошёл Y Combinator - Full-stack cloud - условный Vercel с базами данных - казался затеей для большой компании. Теперь, считает Theo, вся лестница сдвинулась вниз: вчерашний стартап становится side project, а внутренний сервис - исполняемой инструкцией. Его агент каждое утро разбирает pull requests в четырёх репозиториях, расставляет приоритеты и публикует HTML-отчёт в S3. Вместо отдельного сервиса - Markdown и cron. Переход Theo связывает с тремя поколениями моделей: 1) Sonnet 3.5 для него дал надёжный tool calling 2) Opus 4.5 - длинные самостоятельные задачи 3) Mythos (Fable 5) - оркестрацию с дополнительными агентами. Это его личная карта, а не бенчмарк, но вопрос интересный: выдавая новой модели старую работу размером с Jira-тикет, не пропускаем ли мы возможность ставить задачи другого масштаба? Самая интересная часть - переход от узких продуктов к широким. Theo считает, что маленькая команда теперь может собрать большую поверхность продукта, а недостающую глубину отдать пользователям через расширения. Но разработка всё ещё живёт в «скевоморфной фазе»: мы работаем через естественный язык, сохраняя ограничения времён дорогого кода. Отсюда провокация в финале: почему бы не попробовать конкурировать со Slack, AWS или Salesforce? Здесь нужна инженерная оговорка. Ширина прототипа и зрелость продукта - разные вещи. AI удешевляет реализацию, но не отменяет модель данных, миграции, права доступа и наблюдаемость. Пользователь сможет достроить продукт только там, где есть стабильные контракты и безопасные примитивы. Смотреть доклад стоит не ради прогноза о победе маленьких команд над AWS. Он показывает путь Theo от двухдневного скрипта к проектам, которые раньше он сам отбрасывал как невозможные, и хорошо перенастраивает масштаб мышления. #AI #AI4SDLC #Engineering #Architecture #Product #Agents

Опубликовал лонгрид о конфигурациях агентного стека. Спор обычно сводят к выбору между «своим OpenCode» и «чужим Claude Code или Codex», но это ложная развилка: отдельно выбираются обвязка, модель и инструменты, а контроль нужен над всей цепочкой _ от данных и идентичности до фактического действия в системе. Разобрал восемь вариантов стека: их TCO, lock-in, характерные отказы и границы безопасности. Главный вывод: суверенность и безопасность — свойства всей архитектуры, а не отдельного компонента. Сегодня в 17:00 МСК будем разбирать эти идеи на стриме с Мишей Трифоновым: что выбрать для пилота, корпоративной платформы и регулируемого контура. #AI4SDLC #Agents #Architecture #PlatformEngineering

Бенуа Шиллингс: R&D после кода (Рубрика #AI4SDLC) Посмотрел keynote доклад Бенуа Шиллингса, VP из Google DeepMind на AI Engineer World’s Fair 2026. Его позиция мне интересна - он не лидер продуктового ИТ, внедряющий агента в SDLC, а руководитель R&D. Его команда создаёт технологии, которые понадобятся Gemini на горизонте от месяца до года. Поэтому вместо backlog, CI/CD и SLO он обсуждает, чему должна научиться следующая модель. У истории забавное начало. В 2018 году его команда в X запустила проект Pitchfork про применение ML к коду, но идею почти никто не воспринимал всерьёз. Сам Шиллингс отвергал программирование на естественном языке: для этого уже есть языки программирования. Теперь человек с 45-летним опытом - от ассемблера до Python - признаёт ошибку и использует vibe coding. Главный тезис: генерация кода и software engineering - это разные задачи. По мнению Шиллингса, модели уже генерируют синтаксис лучше человека. Но настоящая разработка начинается, когда нужно изменить систему с 35 миллионами строк PHP, учесть архитектуру, безопасность и последствия решения через десять лет. Узкое место переезжает в постановку задачи, декомпозицию и проверку замысла. Код для DeepMind - это удобная R&D-лаборатория: данных много, результат проверяется компилятором и тестами. Следующий шаг - self-play, где модель сама создаёт задачи, решает и проверяет их, как AlphaZero учился через игру с собой. Ограничением становятся compute и качество среды обучения. Исследовательский roadmap из доклада выглядит так: - Учить модель писать безопасный код сразу, а не только находить уязвимости постфактум; - Развивать планирование, декомпозицию и перенос идей между областями; - Менять evals: проверка «запустилось и выдало ответ» слишком узка для архитектуры; - Выходить за линейную цепочку токенов к мультимодальным представлениям; - Возможно, создавать строгие языки для моделей, даже если человеку их будет неудобно читать. Последний пункт особенно хорошо показывает R&D-оптику: снять ограничение читаемости кода человеком и переложить доказательство корректности на модель и язык. Шиллингс прогнозирует, что код станет почти бесплатным, его объём взорвётся, а через год люди почти перестанут читать результат агента - как сегодня редко проверяют ассемблер после компилятора. Это прогноз, не факт и есть определенная разница между агентом и компилятором - последний работает по строгой спецификации, а агент - в неоднозначном бизнес-контексте. За рамками остаются legacy, ownership, SLO, стоимость inference и rollout. Зато финал уходит в химию и биологию: для Шиллингса coding models - полигон для общего reasoning и научных открытий. Мне это выступление понравилось - это не инструкция по внедрению AI в ИТ (с этим у меня проблем нет), а скорее карта upstream-исследований. Условно - R&D спрашивает: «Что модель сможет открыть и построить?» - Продуктовое ИТ добавляет: «Как доказать, что результат нужен, безопасен и управляем?» #AI #AI4SDLC #Research #Engineering #Architecture #Evals

Telegram doesn't show this post on the web. Open it in Telegram to see it.

Telegram doesn't show this post on the web. Open it in Telegram to see it.

Алексей Миловидов и ClickHouse: от любопытства до компании в $15 млрд (Рубрика #Software) С большим интересом посмотрел большое интервью Елизаветы Осетинской (иностранного агента) с Алексеем Миловидовым, создателем и CTO ClickHouse. Формально это история компании с оценкой $15 млрд. Но мне она показалась интереснее как путь инженерного проекта: от любопытства и внутреннего инструмента до open source и глобального бизнеса. Программировать Алексей начал на советском БК-0010. Игру можно было загрузить с кассеты или вручную набрать десять страниц кода из журнала. Если ошибся, вспоминает он, игра могла работать «чуть-чуть по-другому». Старшие братья в итоге просто выдали ему книгу: «Разбирайся». Позже он поступил на мехмат МГУ, хотя хотел на ВМК, а затем выбрал «Яндекс» — несмотря на меньшую зарплату. В первый же отпуск руководителя система веб-аналитики, которую поддерживали два человека, перестала справляться с трафиком. Алексей её стабилизировал, а затем захотел отчёты в реальном времени с произвольными разрезами. Так из практической боли начал расти ClickHouse. Название сложилось из clickstream и data warehouse. Когда аналитики «Яндекса» вместо многочасовых Perl-скриптов получили ответы за секунды, технология выглядела как магия. При этом её долго почти не замечали — и это оказалось преимуществом: команде не мешали спокойно строить систему. В 2016 году ClickHouse открыли как open source. Алексей называет это способом «проникнуть на рынок, пока никто не видит». Сначала появились пользователи, контрибьюторы и митапы, а уже потом — компания. Бизнес построили вокруг того, чего нет в «голом» движке: масштабирования, резервного копирования, безопасности и интеграций. Самостоятельно можно бесплатно; тем, кто не хочет содержать отдельную экспертизу, продают ClickHouse Cloud. Сам стартап тоже собирался необычно. В 2021 году 12–14 человек переходили из «Яндекса», а трое кофаундеров знали друг друга только по Zoom — онлайн-дейтинг, шутит Осетинская. В компанию уже вложили $50 млн, хотя облачного продукта ещё не было, а у нанятой sales-команды оставался вопрос: «Да что продаём-то?» Роли разделили прагматично: Аарон Кац — бизнес и продажи, Юрий Израилевский — облако и команды, Миловидов — технология. Алексей не стал CEO: без опыта шанс убедить нужных людей он оценивал примерно в 5%. Сейчас в компании больше 600 сотрудников, но формально он не руководит никем, работает со всеми и соглашается с ролью «создателя тревоги». В истории много таких деталей. Квартиру в Амстердаме Алексею сдала хозяйка, чья сестра знала ClickHouse по Китаю. За четыре с половиной года он выучил по-нидерландски главным образом goedemorgen. А AI-сотрудник Groene AI чинит «красные» тесты и уже подружился с особенно угрюмым контрибьютором. Если сокращать, то получаются два основных момента - ClickHouse вырос не из гениального питча, а из цепочки хорошо решённых инженерных проблем (а я помню как лет 10 назад ClickHouse захватывал рынок аналитических решений в России, так как других решений такого класса в opensource не было) - Но одной технологии было мало, ее создателю пришлось увидеть продукт глазами клиентов, доверить продажи и компанию людям с другим опытом и продолжать строить крутой продукт #Software #Data #OpenSource #Engineering #Architecture #Management

Материалы про кодинговых агентов и важность экспертизы (Рубрика #AI4SDLC) Готовы материалы с подкаста Code of Leadership, который был в среду с Евгением Сергеым: - Презнтация: Слайд дека с разбором - Видео: Youtube, VK - Аудио: Podster, Ya Music - Текст: Краткая расшифровка #AI4SDLC #Agents #Architecture #Engineering #Software #Books

The Java Story: как язык стал долгоживущей платформой (Рубрика #Software) Посмотрел вчера в прямом эфире документалку «The Java Story» от CultRepo про историю Java. В кадре были James Gosling, Joshua Bloch, Brian Goetz, создатели Tomcat, Spring, Hibernate и Kotlin, а также инженеры Java-экосистемы. Но для меня это не столько история просто языка, скорее это история про целую технологическую платформу, что пережила собственные ошибки, смену владельца и попытки объявить её мёртвой. И кажется, что причина в том, что эта платформа научилась меняться, не разрывая экосистему. Совместимость, управление платформой и сообщество оказались важнее красоты отдельных языковых решений. Изначально java называлась Oak и ее создавали для бытовых вычислительных устройств. Интерактивное телевидение не взлетело, команда переключилась на веб, а настоящий масштаб Java в итоге нашла на сервере. Уже здесь видна повторяющаяся схема: технология сохраняет ядро, но меняет рынок и задачу вокруг него. Даже знаменитое мотто write once, run anywhere в фильме постепенно перестаёт быть рекламным лозунгом. Конфликт Sun с Microsoft показан как борьба за то, кто контролирует платформенный контракт. Если реализация Java под Windows становится несовместимой с остальными, переносимость исчезает, а вместе с ней - и сама причина существования платформы. Здесь Microsoft тех лет представлен в виде гиганта, что греб все под себя:) Но одной защитой совместимости экосистему не построить. Java Community Process формализовал участие компаний и сообщества в развитии спецификаций. Tomcat показал Sun, что открытый код не обязательно ведёт к хаосу. Позже OpenJDK закрепил ещё более важную мысль: платформу можно открыть, не отказываясь от общего контракта. Здесь история начинает переплетаться с другими фильмами. J2EE пыталась стандартизировать корпоративную разработку сверху, но стала слишком тяжёлой для повседневной работы. Spring и Hibernate ответили снизу: обычные объекты, тестируемость и более прямой контроль над кодом. В фильме это сформулировано довольно жёстко: сообщество открытого кода справилось там, где спецификации и поставщики платформы не услышали разработчиков. А когда после Java 5 развитие языка замедлилось, сама виртуальная машина Java (JVM) не опустела. Scala, Clojure и Kotlin предложили более современные модели, сохранив библиотеки, инструменты и среду выполнения Java. Это сильная платформенная конструкция: недовольство языком не обязательно означает уход из экосистемы. Иногда новая идея сначала появляется рядом, а затем заставляет основную платформу двигаться. Полезно сопоставить эту линию и с .NET. В фильме Microsoft сначала выступает угрозой из мира закрытой Windows-платформы. Но позднее C# и .NET сами прошли путь к открытому коду и кроссплатформенности. Получается не простая история «Java против Microsoft», а две разные траектории к одной задаче: как удержать разработчиков, не запирая их в технологическом тупике. Современная Java продолжает ту же логику. Java 8 добавила лямбды и Stream API, не создавая отдельный «новый Java». Шестимесячный цикл отделил готовность конкретной возможности от большого редкого релиза. А virtual threads в Project Loom меняют внутреннюю механику потоков, сохраняя знакомые API и последовательную модель thread-per-request. Инженерно это красивая часть истории: заменить фундамент дома так, чтобы людям наверху не пришлось учиться ходить заново. У фильма есть понятная оптика: его поддержали компании Java-экосистемы, а историю в основном рассказывают люди, которые эту платформу создавали. Поэтому я бы смотрел его как коллективную инженерную автобиографию, а не как независимое расследование. Особенно там, где участники оценивают решения Sun, Oracle или влияние отдельных проектов. Для меня главный вывод такой: зрелая платформа - это не только язык, среда выполнения и API. Это ещё бюджет совместимости, правила принятия решений, инструменты, открытый код, выпуск обновлений и возможность сообщества исправить платформу, когда её владельцы ошибаются. Практически это означает, что архитектору платформы мало проектировать расширяемое ядро. Нужны путь миграции, предсказуемый цикл релизов и место для альтернатив. Java выжила не потому, что всегда выбирала правильно. Она выжила потому, что экосистема снова и снова получала возможность скорректировать курс. Связанные разборы документалок в System Design Space: - Spring: The Documentary - IntelliJ IDEA и линия Kotlin - C#, TypeScript и эволюция .NET - Clojure как альтернативная линия JVM А вот они же но просто в виде фильмов, если вы решите почилить и продолжить после истории Java просмотр остросюжетных документалок про Spring, IntelliJ IDEA, Clojure и Apache Tomcat #Software #Java #JVM #Architecture #Engineering #OpenSource #History

Research Insights Made Simple #22: как собрать управляемый агентный стек (Рубрика #AI4SDLC) Что компания делает «своим» в агентной платформе: код клиента, модель, контур исполнения, данные или право агента менять внутренние системы? Эти вещи часто смешивают и сводят выбор к спору между «своим OpenCode» и «чужим Claude Code или Codex». В понедельник 20 июля в 17:00 по мск мы с Мишей Трифоновым из Cloud.ru разберём в прямом эфире эту ложную развилку и соберём полное описание агентного стека в рамках 22-м выпуска подкаста Research Insights Made Simple. Миша Трифонов - Директор департамента внутренней платформы разработки Cloud.ru и у него есть свой интересный канал @trifonovit Рабочая формула шире привычной пары «модель + обвязка»: агентный стек = обвязка + модель + инструменты + идентичность + технические границы исполнения. Обвязка управляет циклом работы и контекстом, модель предлагает план, инструменты создают реальный эффект. Идентичность, sandbox и policy engine определяют, от чьего имени и в каких границах действует агент. Поговорим о восьми конфигурациях: от автономного стека и локальной модели до внешнего планировщика, корпоративного tool gateway и полного SaaS. У каждой схемы своя цена контроля, скорости, lock-in и эксплуатации. Отдельно обсудим несколько неочевидных следствий: - open source ≠ local inference; - self-hosted ≠ безопасные действия; - доступы сотрудника ≠ доступы агента - внутренний MCP ≠ узкие полномочия; - внешний API ≠ внешнее право на действие; - multi-model router = отдельная платформа. Ключевая идея — разделить два пути. Модельный шлюз контролирует, какие данные и к какой модели уходят. Инструментальный шлюз решает, кто, что и от чьего имени может изменить. Между ними нужны единые identity, policy, trace и evals. И здесь разговор переходит к безопасности. Атакуют не абстрактную модель, а путь от недоверенного README, issue или tool result до действия с реальными полномочиями. Поэтому ограничения должна обеспечивать инфраструктура, а не системный промпт. В общем, мы обсудим не «какой агент лучше», а какую минимальную конфигурацию выбрать для пилота, корпоративной платформы или регулируемого контура — и кто отвечает за фактическое изменение системы. Добавляйте стрим в ваш календарь, чтобы не пропустить его. #AI4SDLC #AI #Agents #Architecture #PlatformEngineering #Security #Engineering