Книжный куб

[1/2] Hands-On Large Language Models (Рубрика #AI) В свой отпуск я захватил с собой этот визуальный путеводитель по большим языковым моделям или просто LLM:) Так как я воспринимаю информацию визуально на порядок лучше, чем на слух, а также сам строю схемы для визуализации сложных тем, то эта книга мне показалась просто блестящей - она не просто объясняет сложные темы, она показывает их через визуализации и код. Книгу написали два эксперта в ML/AI: - Джей Аламмар - engineering fellow в Cohere, автор культовых визуальных гайдов по ML и NLP. Его диаграммы разбирают в документации NumPy, pandas и на курсах deeplearning.ai. У него есть свой топовый блог - Маартен Гротендорст - дата-сайентист, автор open-source библиотек (BERTopic, KeyBERT), специалист в теме тематического моделирования и эмбеддингов. У него есть свой топовый блог Они придерживаются философии обучения, когда сначала развивается интуиция (через качественное понимание концепций), а уже затем подкреплять его формальным описанием и примерами. Для этого используется формат визуального повествования: книга содержит почти 300 оригинальных иллюстраций и диаграмм, созданных специально для этого издания. Посредством наглядных схем, графиков и рисунков сложные механизмы LLM (например, механизм self-attention в трансформерах, работа токенизаторов, многомерные пространства эмбеддингов и т.д.) разъясняются постепенно и доступно. Помимо визуализации, авторы делают акцент на практической стороне применения языковых моделей (об этом говорит hands-on в названии книги). Они приводят много примеров кода, сценариев и практических кейсов (код доступен на GitHub). Книга отлично подойдет для всех - Начинающих и продвинутых специалистов в ML/NLP - Разработчиков и аналитиков, внедряющих LLM в проекты - Всех, кто хочет уверенно ориентироваться в современных моделях вроде ChatGPT, Mistral или Claude В продолжении будет немного про содержимое всех трех частей книги. #Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems

[1/2] The Effective Software Engineer (Рубрика #Staff) Продолжая рассказ о книге, стоит отметить, что в ней 13 глав, где автор идет поступательно от базовых принципов к тому, а что ждет IC в будущем, учитывая стремительное развитие AI. Ниже кратко о каждой главе 1. Foundations of Effectiveness - переход от «сколько сделали» к «какой эффект получили»: outcomes vs outputs, мыслить бизнес‑контекстом, измерять влияние, собирать обратную связь. 2. Understanding the Fundamentals (L3–L4) - поддерживаемый код, тесты, дисциплина отладки, Git, «писать, чтобы другим было понятно» - все это фундамент, на котором строится рост. 3. Technical Depth vs Breadth (L5+) - модель T‑shape: глубокая экспертиза + рабочая широта. Как проектировать на масштабе, оценивать компромиссы и управлять техдолгом, не теряя фокус продукта. 4. Collaboration & Cross‑Functional Influence - работа с PM/дизайном, как влиять без полномочий и "управлять вверх": проактивная коммуникация, согласование целей, приходить к менеджеру не с проблемами, а с решениями. 5. Anti‑Patterns That Limit IC Effectiveness - каталог антипаттернов: силосы знаний, «герой‑комплекс», овер‑инжиниринг vs YAGNI, несостоятельность делегирования, «невидимая работа», паралич анализа, NIH, перфекционизм, переключение контекстов, scope‑creep, отрицание техдолга, перегруз митингами, сопротивление фидбеку, «охота за тулзами», синдром самозванца. 6. Career Growth & Leveling Up - про системный рост и переход на следующий уровень — от понимания ожиданий до того, а как сделать вклад в результат видимым окружающим 7. Leadership as an IC - лидерство без должности руководителия: как вести инициативы, менторить, умножать эффект команды. Связанные принципы подробно раскрыты в главах про сотрудничество и влияние 8. Strategic Thinking for Engineers - как сместить фокус с «как реализовать» на «что и почему реализовывать»: приоритизация high‑impact работы, баланс долгосрочных улучшений и быстрых результатов, опора на данные. 9. Avoiding Burnout & Sustaining Long‑Term Success - границы, энерго‑менеджмент, "сказать нет", культура, где выгорание не героизируется. Консистентность > спурты. Кейсы и конкретные практики. 10. Individual Effectiveness Anti‑Patterns - "героизм" в последний момент, «накопительство кода», бесконечный рефакторинг и распухание скоупа, self‑merge и "вечные PR". Тут не только описание антипаттернов, но и способы того, как их распознать и заменить на зрелые практики. 11. Team‑Level Effectiveness Anti‑Patterns - тут уже не персональные проблемы, а про системную динамику: силосы, проблемы на ревью, перекосы приоритизации и пр. Автор рассказывает о том, как это чинить процессами и культурой. 12. Thriving in Modern Work Environments - как быть эффективным в распределенных командах: «перекоммуницировать правильно», явная видимость работы, режимы, договариваться про каналы/часы, качать письменную речь и публичные выступления. 13. The Future of Individual Contributors - глава о будущем: как ИИ усиливает IC, про то, что ценность фундаментальных навыков растет, а также о том, что карьера IC жизнеспособна на долгой дистанции. По итогу, это актуальная книга для инженеров, которые осознанно подходят к развитию своей карьеры. #Engineering #Leadership #Software #Career #Architecture

[1/2] The Effective Software Engineer (Рубрика #Staff) Я наткнулся на эту книгу, когда меня спросил достойна ли она перевода. Для этого мне пришлось внимательно изучить оглавление, а дальше прочитать по диагонали все 200+ страниц. Если сокращать, то это книга для эффективных инженеров, которые стремятся приносить больше ценности: делать правильные вещи правильно, а не просто быстрее писать код. Книгу написал Addy Osmani из команды Google Chrome (лид направления DevEx), а сама книга уже доступна как early release на O’Reilly. Сама книга несет пользу для индивидуальных разработчиков (IC) всех уровней - от джуна до Staff/Principal. И главная идея в том, чтобы отличать понятия efficiency и effectiveness: - Efficiency - это про то, как делать вещи правильно - Effectiveness - это про то, делать правильные вещи У effective software engineers акцент на outcomes, а не outputs, то есть они причиняют пользу и дают ценный результат для пользователей и бизнеса. Ключевой подход, который продвигает автор в том, чтобы - Системно развивать фундамент: хорошая архитектура, качественный код, тесты, отладка, документация, коммуникации - Учиться влиять без должности руководителя: кросс‑функционально работать с продуктом/дизайном, "управлять вверх". - Использовать ИИ как рычаг и приоритизировать работу с максимальным эффектом (это прямо в подзаголовке книги). - Осознанно применять паттерны и избегать антипаттернов — от «героизма» и постройки силосов до овер‑инжиниринга, NIH, перфекционизма и «залипания» на созвонах. Стоит прочитать книгу, так как она - Помогает перевести карьеру с "делаю много" на "делаю важное", подкрепляя это понятными метриками и решениями - Показывает, как масштабировать вклад без менеджерского титула и выращивать влияние через сотрудничество - Дает трезвый взгляд на будущее IC‑карьеры: "длинная дистанция" плюс усиление за счет ИИ и непрерывного обучения P.S. Книга похожа по содержанию на "The Software Engineer's Guidebook". #Engineering #Leadership #Software #Career #Architecture

Как мы искали экосистемные эффекты: метод проб и ошибок (Рубрика #Metrics) Посмотрел интересный доклад от Владимира Абазова, директора по аналитике нефинансовых сервисов Т‑Банка. В это докладе Владимир рассказал о том, как ребята из нефинансовых сервисов Т-Банка проверяли, а дают ли нефинансовые сервисы (в частности, шопинг‑сервисы) заметный вклад в классические банковские продукты и поведение клиентов. Вова делится тем, как они формулировали гипотезы, чем и как измеряли «экосистемные эффекты», что работало, а что нет. В общем, доклад прямо очень интересен и практичен, но основные идеи можно сформулировать так 1. Экосистемные эффекты ≠ вера: их надо мерить и подтверждать, а не подгонять под красивую историю. 2. Гипотезы → метрики → эксперименты: без общего слоя событий/идентификаторов и корректной атрибуции эффекты «теряются». 3. Не всё - честные A/B тесты: когда «чистый» эксперимент невозможен, важны дизайн эксперимента, контроль сезонности/каннибализации и здравый скепсис к корреляциям. 4. Ошибки - часть метода: команда системно пересобирала метрики и дизайн, пока сигналы не стали устойчивыми (отсюда и «метод проб и ошибок»). Доклад может бы полезен 1. Инженерам, чтобы понять какие данные и события действительно нужны для кросс‑сервисной атрибуции; зачем унифицировать user‑ID/схему событий; где «узкие места» экспериментальных тогглов и трекинга событий. 2. Аналитикам/ML, чтобы получить практический взгляд на измеримость экосистемных гипотез, работу с шумом/смещениями, выбор устойчивых бизнес‑метрик. 3. Руководителям, чтобы понять как договориться о владении метриками между продуктами в экосистеме, как строить приоритизацию и не тратить месяцы на «эффекты», которых нет. В общем, это хороший доклад, чтобы синхронизировать продукт, аналитику и платформу и начать говорить на одном языке. #Data #Metrics #Software #Engineering #DS

Охота на электроовец: большая книга искусственного интеллекта (Рубрика #AI) За квартал я справился с первым томом этой книги Сергея Маркова, в которой он решил описать откуда взялись нейросети, как они устроены и куда всё идёт:) Отмечу, что многие истории из книги я уже знал, но в более сокращенном варианте (из-за чего часто история воспринималась более плоско и в черно-белом стиле). Интересно, что за время моего чтения по вечерам этой книги ей присудили Беляевскую премию 2025 года в номинации «за лучшую оригинальную научно‑популярную/научно‑художественную книгу на русском языке». Если попробовать фрагментарно описать за что ее стоит прочитать, то за - За глубокое погружение в анналы истории: от античных механизмов и первых вычислительных устройств до компьютерных шахмат, AlexNet и «революции глубокого обучения». - За рассказ о людях, что стояли за нейросетями: от Мак‑Каллока и Питтса и перцептрона Розенблатта до бэкпропа, Хинтона и современного DL - За отличные иллюстрации и дизайн книги - в цветном издании это все смотрится превосходно - За изложение математических основ понятно и без зубодробительных формул - За историю «думающих машин», где игры выступали как двигатель ИИ (шахматы/го) Книга есть в электронном виде бесплатно на сайте автора, а также можно купить бумажное издание от ДМК Пресс. #PopularScience #AI #DS #Data #Math #History #Economics

Why Growth Playbooks Are Crumbling - and What’s Next (Рубрика #ProductManagement) С интересом посмотрел выступление с ProductCon SF 2025 от Elena Verna, Head of Growth в Lovable. Ранее Елена руководила/консультировала ростом в SurveyMonkey, Miro, Amplitude, Dropbox. Тезисно она рассказывала о следующих темах 1. Классический рост ломается. SEO, перформанс‑реклама и линейные воронки теряют эффективность. Новая точка входа - answer engines (LLM‑поисковики, ассистенты), где пользователи получают ответ сразу, без клика. 2. AEO вместо только SEO. Нужны стратегии Answer Engine Optimization: как подготовить данные и контент, чтобы ассистенты “знали” о вас и цитировали. Подробнее про это можно посмотреть в серии подкаста Лении "Why ChatGPT will be the next big growth channel" (см. мой разбор) 3. Защита через growth‑петли, а не воронки. Нам надо связать продукт, контент и сигналы пользователей, чтобы запускать самоподдерживающийся рост. 4. Партнёрства с AI‑платформами. Надо работать с провайдерами моделей и экосистемами, чтобы закрепить присутствие бренда/продукта в выдаче ответ‑движков. Важно, что это не просто про маркетинг, а про инженерную дистрибуцию продукта, которую можно улучшить через следующие шаги - Структурирование знаний: схемы, разметка, machine‑readable справка/доки, вики/репозитории знаний - чтобы модели могли извлекать и цитировать. - Интеграции с LLM/поиском: фиды, API, RAG‑коннекторы и разрешения на повторное использование контента. - Наблюдаемость и метрики AEO: отслеживание доли упоминаний/цитаций в ответах ассистентов, качество извлечения и “замыкание петли” в продукте. - Эксперименты поверх контента/схем: быстрые итерации как по продукту, так и по документации и семантике. #AI #Data #Software #Marketing #Economics

[3/3] How States Think: The Rationality of Foreign Policy (Как мыслят государства: рациональность внешней политики) (Рубрика #Politics) В последней части обзора книги (1 и 2) мы поговорим про применимость подходов авторов на земле, а точнее в работе обычного технического директора 1. Требуйте «достоверную теорию» перед крупным решением. В терминах архитектуры: чёткие допущения, причинно-следственная логика, ссылки на эмпирические данные/историю эксплуатации. Это не «максимизация KPI» по красивой формуле, а валидность модели. 2. Не путайте риск и неопределённость. Если у вас нет качественных базовых частот (например, для редких инцидентов SRE или влияния геополитики на поставки), ожидаемая ценность - ловушка уверенности. Лучше сценарии, стресс‑тесты, pre‑mortem, «что если всё пойдёт по худшему пути». 3. Открытое обсуждение как стандарт. Обязательные дизайн‑ревью, red team, «критик без санкций», протокол, где запрещено скрывать плохие новости. Формально фиксируйте, какая теория «под капотом» у решения. 4. Оценивайте процесс, а не только результат. Провал ≠ глупость, если теория была качественной, а обсуждение - честным. И наоборот: успех ≠ оправдание, если процесс был испорчен. Если суммировать все, то рациональность государств - это не «всегда выигрывать» и не «всегда считать EV». Это про то, чтобы опираться на валидную модель мира и не ломать процесс обсуждения. В ИТ‑командах это означает: модель‑прежде‑чем‑метрика и ревью‑прежде‑чем‑решение P.S. Отдельно надо отметить, что это все про дорогие one-way door decision, когда фарш обратно не провернуть:) А вот two-way door decision хорошо бы научиться принимать без долгих размышлений и эскалаций. По этому поводу можно почитать письмо Джеффа Безоса акционерам, где он еще в 1997 году описывал этот фреймворк для принятия решений. #Economics #Leadership #Management #Data

[2/3] How States Think: The Rationality of Foreign Policy (Как мыслят государства: рациональность внешней политики) (Рубрика #Politics) Продолжая рассказ о книге, надо отметить, что модель рациональности авторов содержат два слоя 1. Рациональность целей (goal rationality). Почти всегда на первом месте - выживание государства; остальные цели подчинены этому. 2. Рациональность стратегий (strategic rationality). В итоге, стратегические решений - Опирается на достоверную теорию (реалистичные допущения, непротиворечивая каузальная логика, поддержка в данных/истории), и - Появилось из открытой и «неподавляющей» процедуры обсуждения (без умолчаний, давления, искажения информации). Оценивать нужно процесс, а не только результат. Ключом к их школе мыслей является разница между риском и неопределенностью. В международной политике чаще нет надёжных частот/базовых вероятностей, поэтому чистые расчёты EV/Expected Utility неприменимы - здесь имеет смысл построения надежных теорий + сценарный анализ и «проверка на худший случай». Вот как выглядит критика стандартных подходов от авторов книги 1. Против expected utility. Модели, где рациональность = расчёт ожидаемой полезности, предполагают измеримые вероятности и стабильные предпочтения, а во внешней политике это редкость. Поэтому требовать от государств «считать EU в голове» - неправильно; разумнее оценивать качество применённой теории и качество процесса. 2. Против «все вокруг в bias’ах». Политпсихология/поведенческая экономика часто объявляет отклонения от expected utility «нерациональностью» (bias), упирая в аналогии, эвристики, «групповое мышление». Авторы отвечают: - Эвристики ≠ нерациональность, если они встроены в внятную теорию и - Групповые процедуры в госаппарате нередко сглаживают индивидуальные искажения. И главное - эти подходы почти не объясняют, как индивидуальные мнения агрегируются в государственные решения. Если говорить про инженерную интерпретацию, то авторы предлагают сменить метрику оценки рациональности с «считал ли агент правильный expected value» на «была ли у агента валидная модель мира + нормальный review‑процесс принятия решения». Свою модель авторы подтверждают разбором ситуаций, которые по мнению авторов были несправедливо названы нерациональными - Начинается все с СВО в 2022 году - в предисловии книги разбирается как кейс, где на Западе быстро повесили ярлык «безумия», но авторы считают решение теоретически мотивированным (баланс сил, НАТО) и обсуждённым на уровне элиты. - Германия, вступление в Первую мировую (1914) - превентивная логика против растущей мощи соперников и окна уязвимости. - Япония, удар по Пёрл‑Харбору (1941) - попытка вывести из игры Тихоокеанский флот США и обеспечить ресурсы; рискованная стратегия, но не «иррациональный порыв». - Германия, «Барбаросса» (1941) - авторы показывают, что ключевые лица рассуждали в терминах жёсткого силового реализма (разделение ресурсов СССР/Великобритании и т. п.). Спорно, но в их метрике это рациональная теория + процесс. - Расширение НАТО после Холодной войны - при том что сам Миршаймер критиковал расширение, в книге это - рациональное решение, опирающееся на легитимные либеральные теории (демократический мир, институционализм, интердепенденция). - и так далее Также есть примеры действительно нерациональных решений (где связка «теория + процесс» нарушены) - «Стратегия риска» Германии до Первой мировой - организационные и когнитивные искажения, пробелы/закрытие ключевой информации, не обеспечена качественная проверка теории. - Вторжение на Кубу ака Залив Свиней, США (1961) - малый «клуб» перехватил процесс, критические сигналы игнорировались → нет нормального обсуждения. - Ирак, вторжение США (2003) - подавление альтернатив, слабая эмпирическая база теории (WMD/демократизация через силу), искажения в процессе. А что из этого можно почерпнуть для работы, мы обсудим в следующем посте. #Economics #Leadership #Management #Data

[1/3] How States Think: The Rationality of Foreign Policy (Как мыслят государства: рациональность внешней политики) (Рубрика #Politics) С большим интересом прочитал книгу Джона Дж. Миршаймера и Себастьяна Розато, в которой авторы спорят с модной идеей, что государства часто ведут себя «нерационально». Они предлагают прикладное определение рациональности, ближе к инженерному мышлению: - Решения опираются на достоверную теорию причин‑следствий, и - Решения принимаются через содержательную, несиловую дискуссию (deliberation). В мире внешней политики не хватает данных и вероятностей (это не «риск», а неопределённость), поэтому «максимизация ожидаемой полезности» и многие выводы поведенческой экономики дают сбой. По их критериям большинство решений государств - рациональны, даже если исход оказался неудачным. Подробнее про книгу поговорим в следующих частях. #Economics #Leadership #Management #Data

Техношоу «Дропнуто»: выпуск 1 (Рубрика #SRE) Посмотрел вчера интересный выпуск нового шоу "Дропнуто" от моих коллег из Т-Банка. В этом шоу ребята говорят об инцидентах на дата‑платформах, с честным разбором причин и выводов. Интересно, что шоу идет в прямом эфире, что должно вселять надежду в минимум редактуры и зап...ния. Формат выдержан в духе blameless postmortems, где мы подходим к постмортемам без обвиненений и даже с прицелом на обучение - чель поговорить про то, а почему отказы случаются, как их предотвратить и что изменить в процессах/архитектуре для повышения надежности (кстати, про надежность в Т-Банке хорошо рассказывал Леша Мерсон в статье, о которой я писал раньше). В первом выпуске подкаста гостем был Александр Крашенинников из Т‑Банка, практик в области платформ данных/ETL/DWH, а также просто человек с хорошим чувством юмора и навыками импровизации, что можно увидеть из его рассказа о двухнедельном инциденте в датаплатформе, о котором он рассказывает в этом эпизоде. Цепочка инцидента выглядит кратко примерно так: удаление/потеря метаданных → падение чтения в Trino → нет бэкапа/медленное CDC‑восстановление → критичный инцидент → разворот на новую Kafka‑архитектуру + контракты → унификация схем, параллельные загрузки → валидация и исправление расхождений → восстановление сервиса с возможной частичной потерей → восстановление сервиса из бекапов и дозагрузка исторических данных. Инженерам может понравитсья этот «боевой» разбор инцидента - Эксплуатация CDC (change data capture): где Debezium удобен, его архитектурные варианты, типовые грабли - Паттерны целостности: outbox‑подход для надёжного обмена событиями между сервисами и границы применимости. - Наблюдаемость пайплайнов: какие SLI поднимать для «скорости данных» (freshness/latency), целостности (дупликаты/пропуски), устойчивости коннекторов. Руководителям эпизод полезен для управленческой оптики: - Единый язык риска: связать цвет/серьёзность инцидента с бюджетам ошибок и фризом релизов - Культура обучения на сбоях: blameless‑постмортемы как системный инструмент качества и коммуникации между командами данных/продукта/SRE. - Управление SLO: перевод пользовательских метрик (например, «данные в витрине свежи ≤ X минут 99,9% времени») в алерты и план/факт по риску. #SRE #SystemDesign #Software #Architecture #Metrics #SoftwareArchitecture #Engineering #Databases #Data

Маленький принц Недавно коллеги подарили мне фигурку Маленького Принца и его Розы, а также очень красивую книгу про эту историю. Сегодня я собрал Принца и Розу и теперь он оберегает мой рабочий стол вместе с космонавтом, который делал это в одиночку:)

Research Insights Made Simple #18 Review of "AI in SDLC report" by IT One & Skolkovo (Рубрика #AI) Обсудили исследования от IT One и Сколково вместе с Дмитрием Немовым, директором по развитию и продуктам IT ONE. Дима - один из авторов этого исследования, что позволило копнуть в цели исследования, методологию, результаты. В общем, мне было очень интересно общаться с Димой и я надеюсь, что вам тоже понравиться выпуск. И если он вам зайдет, то поучаствуйте в исследовании про влияние AI на SDLC от Т-Банка Кстати, сами результаты исследования от IT One и Сколково доступны здесь, плюс есть мой разбор в двух постах: 1 и 2. А в этом выпуске мы обсудили следующие темы - Введение и тема выпуска - Предпосылки: зачем это исследование - Структура и методология исследования - Мировая практика и этапы SDLC - Сквозные инструменты и внутренняя платформа - Автоматизация задач и роль доменных специалистов - Как мерить продуктивность: опросы vs метрики активности - Ассистенты и автодополнение - норма в 2025 году - Платформенные решения: ИИ как ядро стратегии - 2024→2025: адаптация и ожидания vs реальность - Российские тренды: централизованный ModelOps и пилоты - Агентные и мультиагентные подходы - Изменение ролей в командах и доверие к коду - Платформа для измерения эффектов (утилизация, impact, cost‑benefit analysis) - Переход от пилотов к продукту и выбор кейсов Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music. #AI #Engineering #Architecture #ML #Software #Economics #Software

За гранью реальности: игровой фестиваль прямо в офисах Т-Банка В воскресенье 9 ноября в офисах Т-Банка в Москве и в Питере пройдет гик-фестиваль настольных и ролевых игр.В этот день соберутся герои ролевых игр, мастера и любители настолок, чтобы разгадывать загадки, побеждать и много смеяться. Фестиваль проходит для - IT-специалистов, которые хотят поиграть в настольные игры, пообщаться и найти единомышленников - Тех, кто слышал про D&D и другие настольные игры, но пока не пробовал - Тех, кто любит смотреть на косплей или участвовать в косплей конкурсах - Тех, кому исполнилось 18 леи Для желающих попасть на фестиваль, кто не является счастливым сотрудником Т-Банка, надо заполнить форму (сотрудникам можно зарегаться через внутренний Т-Календарь). В Москве и Питере будут следующие активности - Настольные игры и настольно-ролевые игры - Тематические фотозоны - Ярмарка игровых товаров в Москве и квиз про настольные и ролевые игры в Питере - Косплей дефиле в Москве и бинго для гостей в Питере - Мастер-класс по покраске фигурок в Москве и по покрасу миниатюр в Питере - и многое многое другое Чат фестиваля доступен в telegram: https://t.me/tluck_fest Количество мест ограничено — всего 300. После регистрации надо будет дождаться подтверждения участия, что придет на почту Кстати, я бы сам с удовольствием заглянул на фестиваль, но буду в Португалии на WebSummit, но вместо меня на фестиваль придет мой сын, что учится на геймдизанера уже на втором курсе. P.S. Полгода назад у нас уже проходил фестиваль настолок. #Games #Culture #Software

2 гига спустя - эпизод четвертый (Рубрика #Podcast) Вышел четвертый выпуск подкаста с лайтовым обсуждением интересных тем двумя ведущими из Т-Банка: Антоном Костериным и автором этого канала. Мы успели обсудить следующие моменты - Мягкая сингулярность от Сэма Альтмана (эссе Сэма, что я уже разбирал раньше) - Просвещение и ИИ (научная статья, что я уже разбирал) - Конец эры мегаработодателей (см. мой разбор) - Чат-боты как новый канал роста и монетизации (см. мой разбор) - Реорганизация AI в Meta, запрещенной в России организации (см. мой разбор) Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music. #Management #AI #Software #Engineering #Reliability #Processes #Productivity

Meet For Charity & Нить Добра (Рубрика #Charity) Уже традиционно я решли поучаствовать в аукционе Meet For Charity, где предметом аукциона является встреча со мной. За обедом/ужином я готов буду поговорить на разные темы, включая +/- любые из тех, что я поднимаю в этом канале. Сама встреча будет в Москве и я постарюсь, чтобы это было в первую рабочую неделю ноября:) Собранные по итогам аукциона средства будут направлены в фонд "Нить добра". В итоге, если вам интересная личная встреча со мной с возможностью выбрать обсуждаемую тему, а также вы не чужды благотворительности, то можете сделать ставку на сайте MeetForCharity и если победите в аукционе, то мы точно встретимся и поговорим. #Charity

[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 через генерацию юнит тестов, коллеги рассказали про настоящую робо-руку, что занимается настоящим ручным тестированием банкоматов:)