Книжный куб

[2/2] The 7 Most Powerful Moats For AI Startups (Рубрика #Startup) Продолжая рассказ про этот подкаст поделюсь ключевыми идеями, что можно вытянуть из обзора книги, которую обсуждали подкастеры из Y Combinator 1. Не начинать со «рва», начните с продукта. Сначала решите реальную проблему клиента и найдите product-market fit (соответствие продукта рынку). Не стоит отбрасывать идею стартапа только потому, что вы не видите сразу долгосрочного конкурентного преимущества - оно может сформироваться по мере роста через технологии, данные, бренд и т.д. Иначе говоря, «moat» – вещь защитная, сперва нужно что защищать. Эту мысль подчеркивают и цитатой Питера Тиля: Competition is for loser в смысле, надо стремиться найти уникальность, но не парализоваться страхом конкуренции на старте 2. Скорость и фокус – оружие стартапа. Главный козырь малой команды – быстрота решений и отсутствие бюрократии. Делайте упор на скорость разработки, частые итерации, тесную связь с пользователями. Это язык, понятный каждому инженеру: меньше совещаний – больше кода в продакшн. Применяя agile в экстремум (ежедневные релизы, как у Cursor), стартап может наработать большое отрывное преимущество, пока гиганты раскачиваются. Идея «Speed as a Moat» особенно резонирует для технических команд, где культура быстрых экспериментов и деплоя может решить судьбу продукта. 3. Классические “силы” никуда не делись – учитесь их распознавать. Инженерам и менеджерам важно понимать, какое преимущество формируется у их продукта: сеть, масштаб, lock-in, бренд или др. Например, создавая API или платформу, вы можете строить network effect – с каждым новым интегрированным клиентом ценность вашей платформы для всех растет. Разрабатывая сложную инфраструктуру, можно заложить process power, как это сделал Plaid или Palantir, где ценность в отлаженном процессе интеграции данных. Добавляя функционал, повышающий издержки переключения, вы удержите клиентов (пример – персонализация и память в AI-сервисах создают привязку пользователей). Руководителям продуктов стоит мыслить в этих категориях при развитии стратегии. 4. Новые времена – новые проявления moat. Менеджерам полезно осознать, что с появлением ИИ появились и новые источники данных и эффектов, усиливающих классические moats. Например, данные пользователей стали топливом для алгоритмов, и те компании, кто собирает больше данных (не жертвуя качеством), получают экспоненциальный рост преимущества (их модели умнеют быстрее). Это своего рода data network effect. Также, AI позволяет стартапам сразу выходить на глобальный рынок (меньше барьеров локализации), что ускоряет брендовый эффект – вспомним взрывную известность ChatGPT. Таким образом, техдиректорам и CTO стоит держать руку на пульсе этих трендов, чтобы понимать, куда вкладываться: в сбор данных, в улучшение алгоритмов, в создание экосистемы вокруг продукта и т.п. В итоге, знание этих терминов про конкурентные преимущества дает общий язык инженерам и бизнесу. Термины вроде network effect, switching cost, moat перестают быть непонятными абстракциями. Для инженерных команд это шанс лучше понять стратегию компании, а для руководителей – донести её «на языке шаблонов». Такой взаимопонимание повышает шансы, что стартап не только быстро выстрелит, но и сумеет закрепиться, выстроив надежный ров вокруг своего «замка» #AI #Engineering #Software #Management #Leadership

[1/2] The 7 Most Powerful Moats For AI Startups (Рубрика #Startup) Интересный выпуск ребят из Y Combinator, в котором они разбирают книгу «Seven Powers: The Foundations of Business Strategy» (2016) авторства экономиста Хамильтона Хелмера. В этой книге описана концепция «moat» (конкурентного «рва») – устойчивого преимущества, защищающего бизнес от конкурентов, по аналогии с рвом вокруг замка. Несмотря на то, что книга вышла в 2016 году на примерах компаний вроде Oracle, Facebook и Netflix, ее идеи о типах moat остаются актуальными и для современных стартапов (в частности, AI-стартапов). Хелмер выделяет семь видов устойчивых источников преимущества, которые позволяют компаниям долго удерживать высокую эффективность и защищаться от конкуренции 1. Scale Economies (эффект масштаба) – снижение издержек на единицу продукции по мере роста объёмов. Пример: компания с огромной инфраструктурой, как Amazon или UPS, может доставлять товары дешевле за счет массовости операций 2.Network Effects (сетевые эффекты) – ценность продукта растёт с увеличением числа пользователей. Классический пример – соцсети: они становятся ценнее, когда в них больше друзей. Аналогично платёжные системы (например, Visa) выигрывают, если их принимают больше магазинов 3. Counter-Positioning (контр-позиционирование) – стратегия, при которой новая компания предлагает такую модель или продукт, что лидеру рынка трудно скопировать из-за конфликта с его текущим бизнесом. Например, AI-стартапы могут брать плату за выполненную работу вместо лицензий на пользователя, подрывая модель SaaS-компаний 4. Switching Costs (издержки переключения) – пользователю дорого или сложно перейти к конкуренту, что удерживает его. Например, когда все данные и логика компании завязаны на Oracle, то миграция на другую СУБД крайне сложна и затратна. В эпоху SaaS таким же «липким» оказался, например, корпоративный CRM Salesforce 5. Branding (сила бренда) – клиенты выбирают продукт благодаря бренду, даже если есть аналог. Бренд формирует доверие и узнаваемость, что конкуренты не могут быстро воспроизвести. Интересно, что OpenAI показал Google силу бренда: у Google огромная аудитория и технологии (модели Gemini), но OpenAI с нуля сумела построить доминирующий бренд в AI благодаря ChatGPT, обогнав по популярности продукты Google. 6. Cornered Resource (эксклюзивный ресурс) – компания получает эксклюзивный доступ к ценному ресурсу, который трудно или невозможно заполучить другим. Примеры: патенты, уникальные алгоритмы, договоры. Например, Nintendo защищается эксклюзивными персонажами/играми, а в современном AI-пространстве примером служат компании с доступом к уникальным данным или контрактам: Palantir за годы работы получила особые контракты с правительством и доступ к секретным данным – такой ресурс недоступен новичкам (кстати, я уже рассказывал про книгу CEO Palantir). 7. Process Power (процессное преимущество) – долгосрочное преимущество от уникального бизнес-процесса или организационной практики, крайне сложно копируемой. Обычно формируется со временем и редко встречается.. Классический пример – Toyota со своей системой бережливого производства: ее производственные процессы десятилетиями давали фору конкурентам. Отдельно ребята из Y Combinator добавляют еще speed (скорость). Они считают, что для стартапа на ранней стадии важнейшим «moat» является скорость исполнения (speed). Этого фактора нет в списке Хелмера, но он «должен был бы там быть». В начале пути скорость разработки и доставки продукта – фактически единственное защитное преимущество стартапа. Пока большая компания раскачивается, стартап, работая в авральном темпе, успевает завоевать рынок.В крупной корпорации множество согласований, уровней менеджмента и бюрократии, из-за чего выпуск новой фичи занимает месяцы. Стартап же способен релизить улучшения за дни или часы. Пример – AI-стартап Cursor (интеллектуальный редактор кода): его команда практиковала «one-day sprints» – полный цикл разработки за один день! Практические выводы из подкаста будут в продолжении. #AI #Engineering #Software #Management #Leadership

Вафельное сердце (Рубрика #ForKids) Вчера с детишками был на спектакле "Вафельное сердце" в Домике Фанни Белл, что поставило творческое объединение ТО9. И хоть спектакль заявлен для детей от 8 до 14 лет, но наш почти пятилетний Кирилл и уже десятилетний Максим оба отлично попали под чары этого моноспектакля. В какой-то момент я поймал себя на мысли, что главный и единственный актер отлично отыгрывает все роли, а его образ и харизма напоминают Джима Керри (можете сами оценить, посмотрев тизер спектакля). Но если возвращаться к самой постановке, то историю мы видим глазами 9-летнего мальчика Трилле, который дни напролет проводит со своей одноклассницей и соседкой Леной, а все вместе они живут в вымышленной бухте Щепки-Матильды. Они крепко дружат, хотя у Лены шило в одном месте, а Трилле достаточно вдумчивый и оценивает последствия их совместных поступков. В итоге, парочка постоянно влипает в неприятности, за которыми интересно наблюдать. Кроме того, последняя треть постановки поднимает важные вопросы расставания с близкими. А вообще, это постановка первой повести Марии Парр, которая принесла ряд наград автору, а также сравнение с Астрид Линдгрен. В общем, рекомендую спекталь к просмотру. P.S. А еще в саду Баумана была выставка Пикассо и Дали для взрослых, которую успешно посетила моя жена пока мы с детишками были на детском спектакле:) Так что можно идти всей семьей, а потом разделяться на тех, кто хочет оценить искусство для взрослых, а кто вместе с детишками пойдет на их спектакль. #ForKids #ForParents #Culture #Theater

🤖 Это наша роборука тестирует банкоматы! Ручное тестирование банкоматов занимало значительную часть проверок перед релизом. При этом действия часто повторялись, и QA выполнял одни и те же тест-кейсы. Мы решили автоматизировать ручные проверки с помощью роборуки, но ее родной SDK оказался слишком ограниченным. Пришлось заменить его на связку ROS2 и MoveIt2 и научить робота автономной калибровке по 3D-камере. Теперь мы можем освободить до 100 человеко-часов в месяц для более творческих задач. 🖊 В карточках — весь технический путь: от неудачного пилота до работающего решения. А еще больше подробностей — в статье на Хабре.

Вот пример того, как роботы помогают в quality assurance. Пока я рассказывал про генерацию тест-кейсов агентами, повышение test coverage через генерацию юнит тестов, коллеги рассказали про настоящую робо-руку, что занимается настоящим ручным тестированием банкоматов:)

Программирование смыслов (Рубрика #AI) Посмотрел вчера интересное выступление Алексея Гусакова, CTO бизнес‑группы «Поиск и рекламные технологии» в Яндексе. Алексей рассказывал об изменениях в подходах к созданию продуктов - они активно развивают ML и LLM‑стек и внедряет нейросети в ключевые сервисы (Поиск, Алиса, Браузер и др.). Если кратко, то фокус разработки смещается от детального кодирования алгоритмов к проектированию намерений и смыслов: вы формулируете задачу, ограничения, источники знаний и метрики качества, а поведение системы «программируете» комбинацией промптов, данных, инструментов и вознаграждения (reward). В такой модели ценность создаётся не одиночным микросервисом, а циклом: гипотеза → прототип → измерение → дообучение/тонкая настройка → интеграция. Внутренний стек и процессы должны это поддерживать. Собственно, доклад Алексея отлично рассказывает переход к программированию смыслов по шагам 1) Как всё началось В 2022 Яндекс запустил диалоговый эксперимент «Гуру по товарам» - это была попытка превратить поиск в помощника по выбору: задаёшь вопросы (“какой телек взять?”), система уточняет параметры и ведёт к покупке. Но пользователям не зашло - общение с гуру ощущалось как заполнение скучной анкеты. Команда потратила много ресурсов, наделала ошибок, но получила важные сигналы о том, какой диалог “продаёт”, а какой — раздражает. 2) Поворотный момент В конце 2022 года вышел ChatGPT и появились генеративные ответы в Bing. Перед командой Yandex появилась дилемма: пилить “большую сложную штуку” (аля как у Bing) или идти инкрементально. Выбрали второе - быстрые, приземлённые улучшения вокруг текущей выдачи. 3) Что именно сделали (и где) - Начали собирать ответы на основе сниппетов и инфоконтекста; обучили собственную LLM для абзацев‑ответов. - Перешли к структурированным ответам из нескольких источников: модель планирует, какие документы использовать и как сшивать факты. Балансировали стабильность vs. риск: не выпускать “магический” ответ любой ценой, а двигаться ступеньками, проверяя качество. Сместили фокус с “идеальной рекомендации” к системе ограничений: не повторяться, сохранять разнообразие, поддерживать новичков и т. п. Оптимизация таргета происходила внутри набора правил, а не поверх “чёрной коробки”, - так проще контролировать поведение. - Пошли в ассистенты, но абстрактные описания вроде “будь умным и полезным” не собирают дают продукт. Выработали принципы, которые действительно работают: ответы не слишком длинные/короткие, правдивые, персонализированные, без вымышленных товаров/свойств; форму ответа модель выбирает, глядя на онлайн‑сигналы. 4) Машинное обучение как конвейер Запустили повторяемый цикл: AI-тренеры размечают и оценивают ответы → обучаются генеративная модель и модель вознаграждения (RM) → катим улучшения → снова собираем обратную связь. Стали на встречах “мудрецов” обсуждать работу моделей - Использовали пайплайны с несколькими моделями на один запрос: даже с “замороженными” параметрами можно сильно вырасти за счёт правильной оркестрации и большего вычисления. 5) Какие проблемы были и как их лечили - Reward‑хаккинг: после первого цикла RM модель “учится” радовать оценщик - внезапно удлиняет ответы, начинает копировать куски источников, вставляет лишние дисклеймеры. - Фиксы: в модель rewards добавили регуляризацию на длину, штрафы за копипасту/канцелярит; отдрессировали стилистику. Был прикольный пример про дисклеймеры, которые оставили только там, где они реально помогают. - В итоге, продуктовая и ML‑разработка смешались - промпты, RM, правила и метрики стали такими же артефактами продукта, как код. 6) Принципы ранжирования и ответов Ссылки в выдаче — это смесь офлайн‑оценки релевантности и онлайн‑вероятности успеха. Ассистенты строят ответы поверх этих ссылок, а не “из воздуха”, чтобы сохранять верифицируемость. #Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems

Что происходит, когда продукт строится не из метрик, а из идеи. История «Сфер» (Рубрика #ProductManagement) Этот доклад рассказал мой коллега, Иван Турлаев, который уже больше 8 лет развивает мобильные приложения в Т-Банке. Доклад был посвящен созданию и внедрению новой концепции банковского приложения – «Сферы». Предпосылка проста: современные банковские приложения устроены одинаково. Счета, карты, платежи, кредиты – все разложено по привычным категориям. Банки, ориентируясь на метрики и копируя друг друга, выпускают однотипные решения. Но мы решили взглянуть на приложение не со стороны компании, а со стороны клиента и подумать, а что если сгруппировать сервисы не по банковским продуктам, а по жизненным потребностям человека? Так возникла идея «Сфер». Эта концепция родилась не на основе цифр или бизнес-планов - она появилась из стремления сделать сервис понятным и полезным для человека. Придумать смелую идею мало, ее нужно реализовать. Разработка «Сфер» потребовала объединить усилия множества разрозненных команд. В T‑Банке разные направления (карты, кредиты, платежи, страховки, путешествия и др.) имели свои цели и метрики. Объединить их вокруг новой концепции оказалось непросто. Нужно было убедить менеджеров и разработчиков принять общую идею и найти с ними общий язык. При этом бросить текущие проекты было нельзя. Проекту помог единый vision, который был подготовлен командой в качестве наглядного концепта нового интерфейса. Увидев цельный образ будущего продукта, разработчики и менеджеры смогли эффективнее взаимодействовать. Обсуждения сместились с узких показателей на пользовательский опыт: фокус на том, как сделать удобнее человеку. Единый дизайн-концепт выступил «клеем», объединяющим команды. Важно было регулярно сверяться с изначальным замыслом и быть настойчивым. Основой был дизайн-концепт. Команда сознательно отошла от банковских шаблонов интерфейса. Цель - сделать так, чтобы интерфейс говорил на языке жизненных ситуаций, а не банковских продуктов. Дизайнеры экспериментировали с навигацией и визуальным стилем, уходя от перегруженных списков и меню. На главном экране пользователь сразу видит ключевые сферы своей жизни вместо длинного перечня услуг. В итоге, на первом этапе в приложении T‑Банка появились четыре первые «Сферы»: «Шопинг», «Дом», «Авто» и «Путешествия». Каждая стала единым центром для своей темы, объединяя все связанные сервисы банка и партнеров. Например, «Дом» собрал в одном месте оплату коммунальных услуг, страховку жилья и покупки для дома. А «Авто» объединил все для автовладельцев: от штрафов и заправки до страховок и ТО. Такой подход резко отличался от традиционного: прежде эти операции были разбросаны по разным разделам, а теперь клиент решает задачу целиком, не переключаясь между вкладками. Для инженеров проект «Сферы» тоже стал испытанием. Нужно было интегрировать множество разных систем – внутренних и внешних – в единое целое. Фактически команда создала платформу по принципу супераппа, где разнородные модули работают согласованно ради общего сценария. Архитектуре потребовалась гибкость: унифицированные API, общая навигация, единая система уведомлений - всё для цельного UX. Решения по backend и frontend принимались с оглядкой на задуманный пользовательский опыт, чтобы техническая реализация не испортила UX. Если говорить про извлеченные уроки, то я бы отметил для себя следующие - Большие изменения рождаются из смелых гипотез и тут не всегда решают метрики, а вот дальше оптимизировать идею без них не получится - Сценарии работы пользователей важнее структуры компании. Приложения части компаний отражают их внутреннюю структуру (у каждого отдела свой раздел). В сферах мы пошли от сценариев пользователя, а потом уже пришли и к реорганизации структуры подразделений внутри компании (я про это уже как-то писал) - Для больших изменений важен единый vision и коммуникации вокруг него. Без единой цели не получится объединить работу многих команд #Management #Design #Engineering #Leadership #Project #Metrics #Philosophy

[2/2] Monarch: Google's Planet-Scale In-Memory Time Series Database (Рубрика #Architecture) Но на этом история монарха не закончилась. Уже в 2023 году на конфе ICSE‑SEIP’23 ребята из Google опубликовали whitepaper-продолжение (что я уже разбирал). Тезисно этот paper можно сократить до следующих пунктов 1) Причина: двукратный рост год‑к‑году QPS и числа рядов, проблемы с поддержкой и дальнейшим попаданием в SLO 2) Команда решила провести редизайн с опорой на quality‑attribute сценарии + лёгкие UML‑модели 3) Фактически, декомпозицировали Leaf на Leaf (KV‑хранилище), Leaf Index Server и Leaf Mixer. 4) Это повлияло в плюс на доступность и сопровождаемость, а latency выросла умеренно, хотя хопов стало больше на 2  (рост с ~12–14 до 16–18 RPC) Но и это было не все - принципы Monarch легли в основу облачного Managed Service for Prometheus: это сервис на том же бэкенде Monarch, которым Google мониторит свои сервисы. Запросы PromQL частично вычисляются на стороне Monarch. Для инженерных команд это даёт из коробки «глобальный» Prometheus‑опыт. Кстати, вопрос масштабирования отдельных Prometheus возникает у крупных компаний часто и для решения этого вопроса появился проект Thanos. Еще можно глянуть на VIctoriaMetrics, этот проект тоже борется с ограничениями Prometheus, но по другому (можно глянуть мой разбор подкаста где автор проекта про это рассказывал) Если подбивать уроки из истории Monarch, то стоит - Собирать метрики ближе к источнику, аггрегировать рано (уменьшение кардинальности и стоимости) - Дешёвый предикатный индекс → дешевле распределённые запросы (урезать fanout до выполнения) - Строго разделять stateful и stateless части (проще сопровождать, легче выдерживать SLO при росте) - фокус на этом во втором whitepaper про редизайн - Шардирование по бизнес‑ключу (target) - локальные агрегации/джойны дешевле. #Software #Architecture #DistributedSystems #SRE #Engineering #Databases #Data

[1/2] Monarch: Google's Planet-Scale In-Memory Time Series Database (Рубрика #Architecture) Наконец-то я дочитал оригинальный whitepaper про эту интересную систему для работы с time-series данными от Google. Идея появилась после моего погружения в архитектурный whitepaper, где эту систему перепроектировали с использованием quality-based подхода и UML диаграмм. Если кратко, то суть примерно такая, что в 2020 году вышла статья на VLDB Endowment про эту самую масштабную в мире базу для временных рядов 1) Monarch - это глобально распределённая, мультитенантная in‑memory БД временных рядов для мониторинга почти всех пользовательских и инфраструктурных сервисов Google. Ежесекундно принимает терабайты метрик и обрабатывает миллионы запросов. Архитектура - разделенная по регионам с глобальным plane запросов и конфигурации. 2) Ключ к масштабу: лексикографическое шардирование по “target”, агрегация на этапе сбора, компактные индексы подсказок (Field Hints Index), двухуровневые исполнители запросов (Root/Zone Mixers). 3) На июль 2019: почти 950 млрд рядов в оперативной памяти (~петабайт сжатых данных); средняя агрегация при сборе 36:1 (до 1 000 000:1); индексы позволяют срезать fan-out до десятков тысяч лишних leaf‑узлов. Как это примерно работало - Система мультитенантная и глобальная. Региональные зоны автономно принимают и хранят данные в памяти, а глобальные плоскости обеспечивают единый запрос и конфигурацию. Это снижает зависимость от внешней персистентности и повышает доступность мониторинга во время инцидентов. - Модель данных и запросов отличается от предшественника Borgman (кстати, именно Borgman стал прототипом Prometheus - об этом можно глянуть в документалке, о которой я рассказывал). В отличие от “строчных ключей” прежних систем, Monarch использует типо‑насыщенную реляционную модель метрик (включая распределения/гистограммы) и выразительный язык запросов, что упрощает статический анализ и оптимизации. - Архитектура обработки выглядела примерно так -- Ингест: клиенты → ingestion routers → зона → leaf router → Leaves (in‑memory). Уже здесь может работать collection aggregation. -- Запросы: Root Mixer распределяет по зонам (Zone Mixers); Index Servers (в т.ч. Field Hints Index) заранее исключают нерелевантные узлы, резко уменьшая фан‑аут. - Отдельно были сделаны оптимизации -- Collection aggregation: в среднем 36 входных рядов → 1; в экстремуме до 10⁶:1. Экономит память/CPU и трафик. -- Field Hints Index (FHI): зоны с >10 000 leaves и триллионами ключей; FHI позволяет отсечь ~73 000 нерелевантных leaves для сложных выборок. -- Лексикографическое шардирование по target: все метрики одного объекта попадают на один leaf → локальные агрегации/джойны, меньше fanout. В продолжении я расскажу, а что было с этой системой дальше. #Software #Architecture #DistributedSystems #SRE #Engineering #Databases #Data

Review of Book "AI Engineering" #3 - Chapter 3 & 4: Evaluation Methodology и Evaluate AI Systems(Рубрика #AI) Вышла третья серия подкаста с разбором крутой книги "AI Engineering", которая дает представление об оценке как самих foundation models, так и приложений на их основе. Книгу разбирает Александр Поломодов, технический директор Т-Банка, а также Евгений Сергеев, engineering director в Flo. Собственно, в этой серии мы обсудили две главы: "Chapter 3: Evaluation Methodology" и "Chapter 4: Evaluate AI Systems". Ну а если раскладывать по темам, то они представлены ниже - Введение и тема выпуска - Почему оценка ИИ‑приложений сложна; рост важности валидации - Валидация в пайплайнах и сложности доменов - Ограничения бенчмарков и переход к продуктовой валидации - Риски неконтролируемой генерации - Теория информации: энтропия как база метрик - Кросс‑энтропия и KL‑дивергенция для оценки моделей - Перплексия и влияние контекста на уверенность модели - Функциональная корректность vs нефункциональные требования - От лексической к семантической близости; эмбеддинги - Паттерны валидации и AI as a judge - Попарные сравнения и ранжирование моделей; транзитивность и голосования - Каркас системы: критерии → выбор моделей → сборка пайплайнов - Факт‑чек и референс‑чек; доверенные источники; человеческий бейзлайн - Дизайн пайплайна: независимые тесты, гайдлайны, разметка; финальные выводы Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music. #Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems

Vite: The Documentary (Рубрика #Frontend) На прошлой неделе вышел документальный фильм про Vite или как один побочный проект Эвана Ю (автора Vue.js) за несколько лет изменил весь фронтенд. Начать стоит с того, а почему Vite так важен. Он появился в ответ на то, что Webpack стал слишком медленным и громоздким. В этот момент Эван Ю, автор Vue.js пытался улушить DevEx инженеров, что писали на Vue и он попробовал радикально другой подход: запускать dev-сервер без бандлинга, отдавая модули прямо в браузер через ESModules. Так появился Vite - инструмент, который: - Стартует почти мгновенно; - Обновляет код без перезагрузки страницы (hot module replacement, HMR); - Компилирует зависимости через esbuild и Rollup, обеспечивая скорость на уровне Rust-решений. В начале фильма звучит фраза «если вы пишете на современном JS-фреймворке, вы, скорее всего, используете Vite» и это уже не преувеличение. На нем работают Vue, SvelteKit, Nuxt, Astro, Remix, Qwik, Laravel, Shopify Hydrogen и десятки других фреймворков. Авторы фильма рассказывают про таймлайн развития технологии, который выглядит примерно так - 2020 - Первая версия как dev-сервер для Vue. - 2021 - Vite 2.0 — мультифреймворк, переход SvelteKit и Laravel. - 2022 - Экосистема взрывается: ViteConf, Vitest, интеграции с Nuxt 3 и Astro. - 2023 - Remix и RedwoodJS переходят на Vite; анонс Rust-бандлера Rolldown. - 2024 - Основана компания VoidZero; Vite 6.0, 17 млн скачиваний в неделю. - 2025 - Премьера фильма и планы на Rust-реализацию всего стека. Ключевые факторы DevEx, за которые инженеры полюбили Vite - Скорость: дев-сервер стартует за секунды, HMR - почти мгновенный. - Простота: минимальная конфигурация и плагинная архитектура. - Расширяемость: единая база для React, Vue, Svelte, Qwik и др. - Интеграции: тестирование (Vitest), Storybook, E2E (Cypress, Playwright), Laravel, Rails. - Сообщество: 850+ контрибьюторов, десятки компаний (Google, Shopify, Cloudflare, NASA, OpenAI). Но Vite не стоит на месте и окмпания VoidZero уже пишет на Rust собственные инструменты: - Rolldown - замена Rollup внутри Vite; - Oxc - быстрый парсер и линтер; - Есть планы на «Vite +» - единый стек для сборки, тестирования и форматирования. - Есть движение в сторону AI - на ViteConf 2025 уже обсуждали агентов, помогающих создавать приложения на Vite. Фильм получился не только про технологию, но и про сообщество: как инженерный «побочный проект» стал точкой объединения фронтенда. Раньше я уже рассказывал про другие документальные фильмы из этой же серии и могу рекомендовать их любителям технологий и историй про их создание и развитие. - Kubernetes Documentary - eBPF Documentary - Inside Envoy - GraphQL: The Documentary - Node.js Documentary - Python: The Documentary - Ruby on Rails: The Documentary - React.js: The Documentary - Angular: The Documentary #Software #Documentary #Engineering #Architecture #Management #SoftwareDevelopment

Как продакты, аналитики и дизайнеры создают ценность через мышление (Рубрика #ProductManagement) Интересное выступление Кирилла Николаева, моего коллеги, директор по аналитике в Т-Банке. Кирилл разбирает, что на самом деле стоит за jobs to be done (JTBD) и почему не всегда цель продукта - "снять трение": иногда продукт должен намеренно заставлять пользователя подумать, если это повышает качество решения и снижает риски. Если выделять ключевые идеи, то в разрезе ролей они выглядят так - Product manager задает рамку смысла: он формулирует «работу» (JTBD) и желаемое изменение поведения, а не список фич. Цель - ценность, а не “проще любой ценой”. - Аналитик переводит гипотезу в проверяемые критерии, выбирает метрики качества решения (не только CTR): ошибки, возвраты, LTV‑эффекты, время принятия решения. - Дизайнер (когнитивный интерфейс): проектирует правильное трение - подсказки, подтверждения, микро‑обучение - там, где «подумать» критично (финансы, безопасность, ответственность). Почему не всегда надо упрощать - упрощая без разбора, легко ускорить неверные решения. Добавленное «осмысленное усилие» иногда повышает доверие, снижает ошибки и улучшает долгосрочные метрики. Что это значит для инженеров/техлидов: - Инфраструктура экспериментов: feature‑flags, канареечные релизы, дешёвая постановка A/B системы, единая схема событий. - Телеметрия качества решения: события «я понял/подтвердил риски», отмены, возвраты, ошибочные действия, dwell/time‑to‑decide. - Доступ к объяснимости: журнал «критических точек мышления» (какие подсказки/правила сработали) для дебага и аудита. - Ритуалы: единый JTBD‑бриф на 1 страницу; общий план экспериментов; еженедельный «decision review» по качественным и количественным сигналам. Антипаттерны: - "Оптимизация на клики": растит метрики, но ухудшает решения. - "Простота ради простоты": убивает безопасность/ответственность там, где пользователю нужно разобраться. - Feature-driven без JTBD: лечим симптомы, а не работу пользователя. В итоге, ценность возникает на стыке мышления пользователя и инженерной дисциплины принятия решений. JTBD задаёт смысл, аналитика - критерии качества, дизайн - нужную когнитивную нагрузку, а инженерия - инструменты измерения и быстрых проверок. #Software #Metrics #ProductManagement #Software #Design

[2/2] Designing Your Work Life (Дизайн работы мечты) (Рубрика #Career) Продолжая рассказ про книгу дизайна работы мечты, можно показать как советы авторов разложить на 4 недели 1) Неделя 1 - Диагностика и рефрейм - Начать вести энергодневник (5 дней). Отмечайте задачи, которые «заряжают/высасывают». Найдите 2‑3 быстрых улучшения (автоматизация, шаблоны, таймбоксы в расписании) - Сделать рефрейминг топ‑боли. Например, "Слишком много митингов" можно превратить в задачу "за 2 недели сократить суммарно с 10ч до 6ч через 15‑мин стендапы и ассинк‑апдейты". Это и есть MAP (минимально осуществимая проблема), которую перед собой предлагают ставить авторы - Разделите гравитацию и задачи. "Акции идут на рынке вниз" - это гравитация; а "у нас нет тестов" - это задача. 2) Неделя 2 - Мини‑эксперименты (bias to action) - Составьте job backlog: выпишите 10 гипотез, что сделает работу лучше/ценнее; выберите 1 с максимальным эффектом - Раскатите прототип, например, поставьте добавьте no‑meeting block 2×90 мин в своем расписании, или внедрение pre‑commit hooks с прогоном проверок. Только надо определить метрику успеха заранее. - Проведите несколько инфо‑интервью. Это могут быть 30‑мин разговоры с людьми из интересных команд/ролей. Просите рассказать истории, а не спрашивайте "есть ли вакансии". Зафиксируйте навыки/артефакты, которые реально ценят. 3) Неделя 3 - Remodel/Relocate - Составьте 1‑пейджер для изменения в своей работе. Что вы убираете/делегируете, что берёте взамен, выгода для команды, риски, план проверки через 2 недели. - Попробуйте shadow‑ротацию. Попроситесь на 1–2 технических шэдоу‑слота в соседнюю команду (обзор инцидентов, демо). Это безопасный "relocate‑прототип". 4) Неделя 4 - углубление анализа - Проведите ARC‑скан. Оцените работу по шкале 1–5: автономия/связность/компетентность и проанализируйте, удовлетворены ли эти потребности в его текущей работе, и как можно улучшить ситуацию. - Оцените как вы хотели бы выглядеть баланс денег, смысла и саморазвития в работе. В долгосрочной перспективе карьеру нельзя измерять одним показателем (например, только зарплатой) - Внедрите WIP‑лимиты. Не более 2 параллельных задач; остальное в очередь. - Практикуйте ритуалы роста. Еженедельный короткий пост‑анализ без обвинений: что попробовать иначе в следующем спринте. Если улучшения не происходит, то можно начинать думать про "созидательное увольнение", где нужно максимально круто завершить текущую работу, параллельно занимаясь обновлением портфолио/репо/кейсы, собром референсов, составлением историю перехода ("что я изменил и чему научился"). Общий посыл в том, что надо уходить красиво, чтобы текущая работа стала трамлином к новым высотам, а уход не выглядел побегом #Career #Software #Design

[1/2] Designing Your Work Life (Дизайн работы мечты) (Рубрика #Career) Недавно прочитал книгу Билла Бернетта и Дэйва Эванса из Стэнфорда, что создали курс Designing Your Life. В своей книге авторы переносят принципы дизайн-мышления в область карьеры, где ключевой идеей становится тезис, что работу мечты не «находят» - её проектируют. А значит если вам что-то не нравится в текущей работе, то не обязательно увольняться - часто достаточно сделать рефрейминг и задизайнить роль по другому:) TL;DR для инженеров выглядит примерно так - Думайте как дизайнер и используйте цикл: понять → сгенерировать варианты → прототипировать → внедрять. - Bias to action: меньше «обсждайте» и проводите больше небольших экспериментов. - Reframing: формулируйте минимально осуществимую проблему вместо общих «всё плохо». - Good enough for now: перестаньте ждать идеала, улучшайте 1–2 вещи уже сейчас. - Различайте гравитационные проблемы и реальные задачи. Первые нельзя изменить (так устроен мир) - надо это принять и обойти, а вот вторые можно решить по настоящему. - Счастье на работе = баланс A‑R‑C: autonomy (автономия), relatedness (связи), competence (компетентность) Авторы предлагают заменить решение "я увольняюсь" на 4 стратегии - Re‑enlist - переосмыслить «зачем» в текущей роли (обновить цели/метрики/обратную связь). - Remodel - перестроить обязанности: убрать «песок», добавить «энерго‑фичи», взять мини‑проект. - Relocate - сменить команду/продукт внутри компании. - Reinvent - сменить трек в той же организации (например, из Backend → Platform/SRE/ML). Как этот подход авторов связан с привычными нам в IT вещами - Это похоже на рефакторинг легаси систем: сначала маленькие безопасные шаги, затем - архитектурные изменения. - Прототи работы похож на небольшой a/b тест за фичефлагом. - Пользовательские интервью напоминают предложенные авторами разговоры с людьми из целевых команд/ролей (инфо‑интервью) - Backlog продукта напоминает список гипотез, которые повышают вашу ценность и удовлетворённость. В следующем посте я расскажу как все эти советы могут выглядеть в реальности и укладываться в месяц. #Career #Software #Design

AI в SDLC: путь от ассистентов к агентам (Рубрика #AI) Записал расширенную версию доклада, который продолжает мое предыдущее "Интегрируем AI в процессы разработки в большой компании". Тогда я задал рамку и рассказал про то, как подходить к внедрению AI в крупной компании. А на этот раз я сделал фокус на переходе к агентским сценариям и обсудил следующие темы - Введение и обсуждение темы доклада - История ассистентов (GitHub Copilot, Cursor) - Переход к агентам и почему они выглядят как революция - Примеры агентов и инструменты (Claude Code от Anthropic, OpenAI Codex) - Инфраструктура и протоколы (MCP, A2A) - Экономические предпосылки агентского хайпа - Примеры успешных кейсов от Google AlphaEvolve - Будущее работы и уровни агентности в исследовании от Stanford - Управление и регулирование агентов в исследовании от Google Deepmind - Эволюция SDLC к агентскому Software Engineering 3.0 - Демо агентского режима внутри Т-Банка на примере игры "5 букв" - Экосистема разработки и цели инженеров в исследовании "Measuring Developer Goals" от Google - Внутренняя платформа разработки и Spirit и наш подход к AIфикации разработки - Агентский режим и работа с данными внутри python notebook - Агентский режим для обеспечения качества и создания тест-кейсов - Агент для код-ревью - Агент для поиска уязвимостей (safeliner) - Измерение эффективности и фреймворки оценки - Фреймворк для оценки ассистентов и агентов от платформы DX - Результаты использования ассистентов/агентов в Т-Банке Разбор и ссылки на все источники для изучения доступны в моем tg-канале - https://t.me/book_cube/3925 - https://t.me/book_cube/3931 Выпуск подкаста доступен в Youtube, VK Video.

Жемчужины программирования (Рубрика #Engineering) Первое издание этой книги Джона Бентли вышло почти 40 лет назад, как раз в год моего рождения. Но я читал уже второе издание, что вышло в начале 2000х годов. Это была книга, которая отличалась от других - она учила думать как инженер, а не просто писать код. Автор книги - исследователь из Bell Labs и Carnegie Mellon, соавтор алгоритма k-d деревьев и усовершенствованного quicksort. Но известен он больше колонкой в журнале "Communications of the ACM", из которой выросла эта книга. Это было в 1980-х годах, эпохе, когда 1 МБ памяти считался роскошью. Бентли писал для практиков, которые хотели не просто “работающий код”, а *красивое решение*. Он сравнивал алгоритм с жемчужиной: реальная проблема - это песчинка раздражения, а изящное решение - результат терпения и формы. Каждая глава - это короткое эссе с задачей, размышлением и выводом. Они покрывают следующие темы - Как формулировать задачу и искать ага!-решение; - Оценка на салфетке, где автор рассказывает про оценку времени и памяти алгоритмов буквально на пальцах; - Алгоритмические трюки: сортировка, выборка, поиск, оптимизация; - Как писать корректные и понятные программы. Интересно, что Бентли написал еще и книгу продолжение "More Programming Pearls", где он добавил следующие темы - Философия инженерного мышления (“исповеди кодера”); - Маленькие языки - предтечи DSL и скриптов внутри систем; - Афоризмы и практические советы вроде “плохую программу ухудшить не грех”. Если говорить про значимость книги в далекие времена, то автор в ней показал, что программирование - это не набор трюков, а искусство видеть структуру задачи. Когда-то книгу использовали в курсах по алгоритмам и дизайну программ. Сейчас большинство примеров устарело, но подход - нет. В итоге, книги Джона Бентли по праву считаются сокровищницей знаний для программистов. Они объединяют поколение инженеров 1980-х и современных разработчиков общими ценностями - страстью к изящным решениям и глубокому пониманию задач. «Жемчужины программирования» до сих пор сияют и продолжают вдохновлять новых читателей на поиск красоты в коде. #Engineering #Software #Architecture #SystemDesign

Code of Leadership #56 - Interview with Alexey Gorbov about system administration & databases (Рубрика #Engineering) Интервью с Алексеем Горбовым, моим коллегой, который в Т-Банке занимается базами данных и разивает нашу Cassandra as a Service. Параллельно этому Леша курирует нашу секцию собеседований по траблшутингу для SRE, которую я когда-то курировал сам, а также рассказывал про нее на конференциях. За полтора часа мы обсудили множество тем - Введение и представление гостя - Детство, образование и первые шаги в IT - Работа в «Одноклассниках»: начало карьеры - Инцидент в ОК и переосмысление надежности - Переход к системной надежности - Работа с Cassandra и автоматизация процессов - Новые технологии и взаимодействие команд - Миграция дата-центра: проект и организация - Уход из «Одноклассников»  - Первые шаги с Cassandra в новой роли - Развитие Cassandra как сервиса в Т-Банке - Проблемы архитектуры и декомпозиции кода - Практические выводы и преимущества Cassandra - Рекомендации инженерам по поводу развития и роста Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music. #SRE #Architecture #Reliability #Management #Staff #Engineering #Processes #Databases #DistributedSystems

Водоходъ (Рубрика #ForKids) Решили прокатиться на кораблике в Нижнем Новгороде. Пришли вчера в кассы компании "Водоходъ" купить билеты, но их на вчера уже не было. Мы решил попробовать покататься сегодня и купили комфорт билеты на сайте Водоходъ. Пришли на посадку, но нам объяснили, что даже с билетами мы не покатаемся на кораблике. На сайте было указано, что для детей до 5 лет включительно билет нужен, но он бесплатный. Опции получить этот бесплатный билет на сайте не было и мы решили получить его в кассах. А в кассах нам сказали, что этот бесплатный билет для детей есть только в тарифе билетов стандарт, а в комфорт надо покупать билеты на всех (но на сайте этой инфы не было). Докупить билет мы не смогли - мест в комфорт не было. Сдать билеты на комфорт нормально тоже не получилось - в кассе сказали "где билет покупали, туда и идите", а на сайте Водохода предлагают заполнять документ и ножками приносить его в офис компании (или присылать письмом Почтой России). Классно, что у нас в Т-Банке есть возможность оспорить любую операцию, по которой не предоставили услугу.

Гуляя с семьей по парку Швейцария в Нижнем Новгороде, наткнулся на "Отель для книг" и "Отель для насекомых". Креативный тут подход у ребят:) А чуть позже мы поедем на нашу конфу "Сезон кода".

Дискуссия — «GenAI и dev платформы – как меняется разработка» (Рубрика #AI) На летнем IT Пикнике мой коллега Дима Гаевский вел дискуссию на эту тему, где участвовали уважаемые джентельмены - Иван Пузыревский, CTO Yandex Cloud - Александр Лукьянченко, руководитель разработки платформы в Авито - Станислав Сычев, руководитель разработки платформы в Т-Банке Ребята обсуждали следующие темы 1. Роль разработчика меняется ИИ перестал быть только частью IDE. AI пишет код, предлагает оптимизации, генерирует тесты - а инженер становится ревьюером и архитектором решений, а не только исполнителем. Сильные инженеры теперь курируют и людей, и AI-агентов. Джуны растут быстрее - у них под рукой “AI-ассистент”, который подсказывает, как писать код. Главный навык будущего - уметь ставить задачи ИИ и проверять результат, а не просто знать синтаксис языка. 2. AI становится частью платформ разработки - Платформы (CI/CD, IDE, облака) интегрируют AI-помощников, которые анализируют код, собирают метрики, предлагают фиксы. - AI-модели дообучаются на данных из внутренних репозиториев, понимают корпоративный стиль кода и стандарты. Как итог: внутренние dev-платформы становятся “живыми системами”, где ИИ не только помогает людям, но и сам учится на их паттернах. 3. Автономность AI пока не так велика - Ни один из участников не верит в «AI-разработчика без человека». - Сейчас граница ясна: AI можно доверить рутину (генерацию шаблонов, тестов, фиксов), но не архитектуру и продакшен-код. - Везде действует правило: «AI предлагает, инженер утверждает» (условно, есть human in the loop). Это связано со стоимостью ошибок 4. Новые роли и процессы - Появляются новые профессии: AI-инженеры, промпт-дизайнеры, ревьюеры моделей. - Некоторые частично детерминированные сценарии работают лучше: генерация тест-кейсов, юнит-тестов, агенты для код-ревью, миграции кода - DevEx-платформы превращаются в экосистемы для людей и агентов: оба учатся на общих данных и повышают эффективность. 5. Что дальше - AI-first-платформы станут стандартом: без встроенного помощника IDE или CI/CD скоро не обойтись. - Команды станут меньше и междисциплинарнее - рутину берут машины, людям остаются дизайн, логика и ответственность за свою работу и работу AI-агентов - AI-грамотность станет новой базовой компетенцией инженера. - Появятся агентные среды, где несколько AI-сервисов будут решать задачу “от ТЗ до деплоя” под присмотром тимлида-человека. Если подводить итоги, то ребята - Не верят, что AI не заменит инженеров - скорее инженеры станут тимлидами команды AI-агентов - Платформы разработки становятся умнее, интегрируя AI-возможности в себя #Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership #Economy