Книжный куб

...Isms. Understanding Modern Art (...Измы. Как понимать фотографию) (Рубрика #Culture) За неделю неспешного чтения изучил книгу Эммы Льюис 2017 года о том, как понимать фотографию. Эмма - британский куратор и историк фотографии, которая работала на момент написания книги в качестве ассистента куратора международного искусства в галерее Tate Modern в Лондоне, где она занимается фотографическими приобретениями и курирует выставки. Эмма структурировала свою книгу хронологически, выделив пять основных периодов развития фотографии: Часть 1: Изобретение фотографии и документация мира (1826 — 1910) Эта часть охватывает самые ранние этапы развития фотографии, от изобретения фотографического процесса до начала XX века. Часть 2: В сторону модернизма (1850 — 1930) Этот период охватывает раннее развитие фотографии и включает зарождение различных направлений. В рамках этой эпохи особое внимание уделяется пикториализму — движению, которое стремилось доказать, что фотография может быть искусством, подражая живописи. Значительную роль в развитии пикториализма сыграли такие фотографы, как Альфред Стиглиц и группа «Фото-Сецессион». Часть 3: Общество и человечество (1930 — 1970) Эта эпоха знаменита развитием уличной фотографии и документальной съемки. Ключевыми фигурами стали Эжен Атже, который создал тысячи фотографий старого Парижа между 1890 и 1928 годами, а также американские фотографы Уокер Эванс и Хелен Левитт. Часть 4: Постмодернизм (1950 — 1990) Этот период включал эксперименты с формой и содержанием, отход от традиционных представлений о фотографии. Часть 5: Современная фотография (1980 — 2010) Это была эпоха цифровой фотографии и социальных медиа, включая период «от изобретения фотографического процесса до пост-интернет эры. Если бы Эмма писала книгу сейчас, то она точно бы добавила что-то про текущее разлдолье LMM (large multimodal models), которые позволяют генерировать любые изображения и видео, но книга была написана почти 10 лет назад, когда сгенерированные изображения еще не были настолько хороши. В общем, книга мне показалсь очень доступным источником знаний для всех, , кто хочет понимать и чувствовать искусство, которое пронизывает всю нашу жизнь. Сама книга написана доступным языком без специального жаргона, но при этом содержит достоверную информацию. P.S. Я когда-то увлекался фотографией - с тех пор у меня осталось какое-то количество фоток на 500px и с тех пор я люблю читать книги на тему фотографии:) #Culture #Photography

Elon Musk: Digital Superintelligence, Multiplanetary Life, How to Be Useful (Рубрика #Management) Посмотрел интересное выступление Илона Маска на конференции AI Startup School от Y Combinator в Сан-Франциско, что проходила 16-17 июня 2025 года и было приурочено к запуску новой образовательной программы YC для молодых разработчиков и исследователей ИИ. Илон делился своим опытом и рассказал молодым стартаперам и ученым о том, как он начинал свой путь на заре создания интернета, создав Zip2 и участвуя в развитии PayPal, а потом перешел к революционным проектам в области космических технологий и искусственного интеллекта. Ниже я опишу основные идеи выступления 1. First principles thinking Макс много говорил про мышление с опорой на базовые принципы, которое должно быть главным инструментом разработчиков. Он подчеркивает важность разложения сложных задач на фундаментальные элементы и построения решений снизу вверх, а не по аналогии с существующими подходами. Он предпочитает термин "инженерия" вместо "исследования", акцентируя внимание на практическом применении. В своей презентации Маск рассказывает много примеров такого мышления в рамках задач SpaceX, xAI и остальных своих компаний 2. Фокус на полезности Главный совет для разработчиков — стремиться быть максимально полезными для как можно большего числа людей. Маск подчеркивает важность создания продуктов, которые решают реальные проблемы, а не просто впечатляют технически. 3. Управление эго и обратная связь Критически важно поддерживать низкое соотношение эго к способностям. Высокое эго разрывает петлю обратной связи с реальностью, что особенно опасно в разработке, где код и физические законы являются строгими судьями. Я это для себя перевел как оставаться поближе к реальности и не уходить в мечты и самовозвеличивание (иногда такое бывает с достигшими значимого успеха) 4. Взгляд на будущее ИИ Маск прогнозирует появление цифрового сверхразума уже в ближайшие 1-2 года. Для разработчиков ИИ он подчеркивает критическую важность создания систем, максимально приверженных истине, даже если эта истина политически некорректна. 5. Масштабирование инфраструктуры На примере создания тренировочного кластера для xAI с 100,000 GPU Маск демонстрирует подход first principles thinking к решению сложных инженерных задач. Ключ — разбить проблему на составные части (здание, энергия, охлаждение, сетевое оборудование) и решать каждую отдельно. 6. Долгосрочное видение Маск призывает разработчиков думать о долгосрочном воздействии своей работы на человечество. Он видит текущий момент как начало "большого взрыва AI" и подчеркивает роль технологий в обеспечении выживания и процветания цивилизации. Забавно, что во время выступления Макс вспоминал как выглядел "большой взрыв интернета" и проводил параллели с текущими событиями 7. Практические советы для стартапов Макс дал советы следующие - Не отдавайте контроль над советом директоров устаревшим компаниям - Идите напрямую к потребителям, минуя посредников - Будьте готовы к неудачам — первые три запуска Falcon 1 провалились - Инвестируйте практически все обратно в развитие технологий В конце Макс почти перешел к технопроповеди и призвал присоедяться к созданию технологий, которые помогут понять природу Вселенной и обеспечить будущее человечества как мультипланетарного вида. #AI #Engineering #Management #Leadership

[2/2] Статьи из серии "Developer Productivity for Humans" (Рубрика #Management) Продолжая рассказ про статьи из этой серии поделюсь разборами оставшихся статей. 😍 Build Latency, Predictability, and Developer Productivity. Очень интересная статья с описанием того, как была поставлена задача исследователям насчет важности ускорения билдов. Они описывают как они определяли tradeoff между стоимость инфры и бенефитами ускорения, а в итоге поняли, что важна не только скорость, но и предсказуемость сборки для того, чтобы инженеры могли планировать свою работу. Подробный разбор в блоге. 9 ) Hybrid Productivity. Здесь авторы разбирают достаточно холиварную тему продуктивности работы в офисе и удаленной работы. Они показывают в своем исследовании как они это измеряли, а также делятся выводами. Например, из работы видно, что гибридная работа во время ковида приводила к проблемам с онбордингом новых сотрудников по сравнению с офисной работой до ковида. Подробный разбор в блоге 10) Onboarding and Ramp-Up. Статья про то, как ребята измеряли эффективность онбординга, какие метрики использовали. Частично пересекается со второй статьей про гибридную работу, так как разбирается тот же кейс про скорость и качество онбординга во время COVID-19. Подробный разбор отдельном посте в tg 11) Measuring Flow, Focus, and Friction for Developers. Эта статья про человеческую сторону продуктивности, а точнее про восприятие инженеров двух концепций: flow и friction. Для этого авторы проводили опросы и просили инженеров вести дневники, а дальше они матчили эти данные с логами от инструментов, что использовали инженеры. В итоге, у исследователей получилось создать эвристики для трансформации сигналов из логов в метрики, что значимо связаны с flow, focus и friction. Подробный разбор в отдельном посте в tg. 12) Creativity in Software Engineering. Авторы разбирали что такое креативность в разработке, оказалось, что это умное переиспользование, а не полная новизна, как принято в других сферах. Кроме того, это качество присуще крутым инженерам. А дальше они постарались сопоставить креативность и продуктивность и выдвинули гипотезу, что что продуктивность - это про ближайшее время, а креативность про долговременный эффект от качественного кода. Подробный разбор в отдельном посте в tg 13) Measuring Productivity: All Models are Wrong But Some are Useful. Обобщающая работа, где авторы рассказали про принципы и методики, что выработали в Google для преодоления ограничений моделей и получения ценных инсайтов. Разбор есть в отдельном посте в tg #Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

Code of Leadership #42 Interview with Andrew Romanovsky about Сareer as aт engineering manager (Рубрика #Management) В эту среду в 19.00 пройдет live интервью с Андреем Романовским о карьере engineering manager в крупной технологической компании. Андрей руководит продуктовой разработкой Яндекс.Лавки и является CTO Yango.Tech Retail, а кроме того ведет канал Lead’s Notes (@leadsnotes). Мы обсудим вопросы в стиле как дорасти до c-level позиции, заработать свой первый миллион и не сойти с ума, как адаптироваться к росту размера команды и сложности зоны ответственности. Например, мы обсудим - Что входет в роль engineering manager? - Ради чего вообще стоит идти в менеджерский карьерный трек? - Как устроен рост менеджера? - Растет ли сложность работы с продвижением по карьерной лестнице? - Как решать проблемы тайм-менеджмента: перегруз, баланс работы и личной жизни? - Как не потерять технические скиллы и стоит ли за этим гнаться? В общем, приходите на трансляцию и задавайте дополнительные вопросы, на которые мы постараемся ответить. #Software #Engineering #Management #Architecture #Processes

[1/2] Статьи из серии "Developer Productivity for Humans" (Рубрика #Management) Я решил рассказать про статьи из сериии про продуктивность инженеров от Google, так как я недавно рассказывал про "Measuring Productivity: All Models are Wrong But Some are Useful", которая обобщает подходы ребят из Google и приводит принципы для построения моделей продуктивности. Ниже список статей из этой серии, что я уже разбирал 1) A Human-Centered Approach to Developer Productivity. Эта статья начинала серию и в ней авторы описывали почему они смотрят на вопрос продуктивности инженеров не только с точки зрения процесса и техники, а еще с точки зрения людей, что в нем участвуют. Здесь они вспоминают научный менеджмент Тейлора (про эффективность работы у конвейера) и показывают почему сейчас в разработке нужны подходы чуть сложнее:) Подробный разбор в блоге 2) Enabling the Study of Software Development Behavior With Cross-Tool Logs. Статья 2020 года, где авторы из Google рассказали про создание своей системы InSession, которая позволяет проводить комплексный анализ поведения инженеров путем интеграции логов от множества инструментов разработки. Подробный разбор есть в отдельном посте в tg 3) Measuring Developer Experience With a Longitudinal Survey. Рассказ про долговременные исследования в виде опросов, что поводятся с 2018 года. Опросы являются одной из опор для сбора информации о продуктивности, наряду с логами. Авторы делятся инсайтами о том, как выстроить такую программу у себя в компании и что она позволяет измерять. Разбор есть в отдельном посте в tg, а также мы разбирали этот whitepaper в 10 эпизоде подкаста Research Insights Made Simple с Артемом Арюткиным 4) Measuring Developer Goals. В этой статье исследователи рассказывали о том, что понимание и эффективное измерение целей критически важно для улучшения опыта разработчиков и повышения их эффективности. Для ответа на вопросы о продуктивности удобнее привязывать измерения не к конкретным инструментам, а к тем целям, которые разработчики ставят перед собой при использовании инструментов. Это позволяет отвечать на вопросы, похожие на те, что приведены выше, сохраняя метрики ориентированными на пользователя, а не инструмент. Подробный разбор в блоге, а также есть восьмая серия подкаста Research Insights Made Simple, где мы разбирали эту статью с Сашей Кусургашевым, моим коллегой, что руководит разработкой Spirit (наша внутренняя платформа разработки) 5) What Do Developers Want From AI?. Здесь авторы говорят о том, что эволюция AI - это поворотный момент, но с технологическими революциями, что меняют формат работы людей, человечество сталкивается не в первый раз. Поэтому авторы статьи решают провести параллели между AIфикацией и развитием автомобильной промышленности и сфокусироваться на потребностях и целях наших разработчиков. Разбор есть в отдельном посте в tg, а также мы разбирали эту статью в девятом выпуске Research Insights Made Simple с Колей Бушковым, моим коллегой из RnD центра. 6) Software Quality. Крутая статья, где авторы обсуждают холистический подход к измерению продуктивности надо обращать внимание на speed, ease и quality для того, чтобы не получить кратковременные улучшения за счет долговременного негативного влияния. А дальше ребята фокусируются на теме качества, которая затрагивает процессы, код, систему и продукт целиком. Мне эта тема очень близка, так как она очень тесно пересекается с архитектурой и архитектурными характеристиками:) Подробный разбор в блоге 7) Defining, Measuring, and Managing Technical Debt. Интересное обсуждение концепции технического долга, а также пример того, как его измеряли в Google и ккак с ним боролись с хорошими результатами. Подробный разбор есть у меня в блоге, а также мы разбирали этот whitepaper вместе с Димой Гаевским во второй серии подкаста "Research Insights Made Simple Окончание рассказа про статьи из это серии в следующем посте. #Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

Эволюция SRE: внедрение AI-ассистента в Т-Банке (Рубрика #SRE) Посмотрел интересное выступление своего коллеги, Ивана Юрченко, руководителя FineDog Growth в Т-Банке, который занимается развитием платформы инцидент-менеджмента FineDog, которая помогает банку оперативно выявлять сбои в работе сервисов и сокращать время их устранения. Этот доклад был представлен в рамках конференции Platform Engineering Night и он посвящен внедрению AI-ассистентов в работу инженеров по надежности. Кстати, про три доклада с Platform Engineering Night я уже рассказывал: - "AI и Platform Engineering" от Игоря Маслова (VP T-Bank at T-Bank) - "Разработка собственного AI-ассистента для кода: спринт или марафон?" от Дениса Артюшина (tech product & engineer at T-Bank) - "AI-помощники при работе с кодом. Взгляд в будущее" от Евгения Колесникова (tech product at Yandex) Дальше расскажу про основные идеи доклада Ивана. 1. Эволюция инструментов инцидент-менеджмента Иван представил концепцию трехуровневого развития инструментов для работы с инцидентами - Платформизация — объединение разрозненных инструментов в единую экосистему для более эффективного управления инцидентами - Автоматизация — упрощение рутинных действий, что позволяет сократить время реакции на инциденты - Роботизация — автоматизация принятия решений с использованием AI 2. Жизненный цикл инцидента и роль AI Иван подробно описал этапы работы с инцидентом: детекция, работа с инцидентом и пост-анализ. Особое внимание уделил важности сбора контекста для эффективного решения проблем. А AI-ассистент сейчас интегрируется во все этапы этого цикла, помогая не только реагировать на инциденты, но и предсказывать их, анализировать логи и предлагать варианты решения до начала критической ситуации. 3. Инновационные проекты на базе AI Основные проекты, про которые рассказал Иван следующие - Summarizer - система для агрегации информации и автоматической генерации пост-анализов инцидентов. Использует AI для улучшения качества аналитики и выявления закономерностей в инцидентах - LogAnalyzer - продвинутый инструмент для анализа логов и поиска связанных инцидентов. Применяет кластеризацию логов для выделения аномалий. Выглядит это примерно так -- Логи скачиваются из Sage (observability платформы) каждые 5 минут -- Дальше происходит предобработка текста и сегментация на фрагменты -- Потом векторизация с помощью TF-IDF и трансформеров -- В финале данные визуализацируются в трехмерном пространстве для наглядного представления аномалий 4. SRE ассистент и его возможности Иван представил AI-ассистента, разработанного для поддержки SRE-команд, который обладает следующими возможностями - Интеграция с корпоративным мессенджером Time для удобного доступа - Взаимодействие с различными ботами и LLM-агентами - Выполняет ключевые сценарии: -- Работа с инцидентами и генерация пост-анализов -- Получение информации из базы данных -- Поиск по базе знаний с использованием RAG-платформы -- Управление дежурствами через мессенджер 5. Метрики и оценка эффективности AI-ассистента Иван рассказал про ключевые метрики: качество ответа, полнота, галлюцинации, ошибки периодов. Оценки на основе ручной разметки около 600 запросов получились такие - Качество ответа: 0.54 - Полнота: 0.43 Для LogAnalyzer результаты были такие - Precision: 0.64 - Recall: 0.85 6. Перспективы развития В заключительной части выступления Иван обозначил планы на будущее - Запуск новых итераций SRE-ассистента с улучшенными возможностями - Дальнейшее совершенствование метрик и интеграция системы обнаружения аномалий - Постоянный поиск новых идей и обмен опытом с профессиональным сообществом В общем, доклад мне понравился - интересный баланс общей теории и деталей о конкретных сценариях, которые мы пытаемся AI'фицироватьь для наших SRE инженеров. P.S. Если тема показалась интересной, то можно еще почитать мой обзор статьи про общие процессы вокруг надежности в Т-Банке, которую написал Леша Мерсон, ex-dev advocate платформы Sage. #AI #SRE #SystemDesign #Software #Architecture #Metrics #SoftwareArchitecture #Engineering

Открытие набора в Т-Академию (Рубрика #Edu) 🚀 Отрылся набор в Т-Академию, где есть 4 трека: backend, frontend и android разработка а также продуктовая аналитика. Эта академия позволяет получить глубокое погружение в промышленную разработку с изучением современных языков программирования или подходов продуктовой аналитик (метрики, a/b эксперименты, SQL для анализа данных). Программа длится год или полтора (в зависимости от направления) и строится так, чтобы ее можно было совмещать с работой или учебой. Преимущества программы - Лекции от экспертов — ведущие специалисты Т‑Банка - Практические семинары с разбором реальных кейсов из индустрии - Персональное код-ревью от опытных разработчиков - Командные проекты с возможностью попробовать разные роли Подать заявку можно до 31 июля. Все подробности на сайте #Edu #Software #Engineering

Дискуссия на Conversations.AI "RnD на стероидах: автономные агенты с суперпамятью, вызовы vibe coding и новая эра кибербезопасности"(Рубрика #AI) На следующей неделе буду на конференции Conversations.AI в Питере, где 27 июня в 13.40 буду участвовать в дикусиии относительно передовых возможнстей AI в разработке. В обсуждении будут участвовать уважаемые джентельмены, приведенные ниже - Сергей Марков, популяризатор науки, директор по развитию технологий искусственного интеллекта SberAI - Олег Королев, руководитель разработки AI Lab Авито - Евгений Кокуйкин, сооснователь Raft и CEO HiveTrace - Александр Поломодов, технический директор Т-Банк Вести дискуссию будет Илья Карев, Team Lead GenAI Solutions, Just AI. Мне кажется, что дискуссия получится топовой, поэтому, если будете на конфе, то приходите ее послушать. #AI #PlatformEngineering #Engineering #Software #Processes #Productivity

Andrej Karpathy: Software Is Changing (Again) (Рубрика #AI) Посмотрел утром очень интересное и свежеее выступление Andrej Karpathy, одного из основателей OpenAI (2015-2017), директора по ИИ в Tesla (2017-2022). Андрей поделился концепцией Software 3.0 и рассказал про предыдущие этапы развития софтостроения, а также сделал предсказания о том, что ждет нас дальше. Выступление состоялось 16-17 июня 2025 года на первой в истории AI Startup School от Y Combinator в Сан-Франциско. Это было масштабное мероприятие, собравшее 2500 лучших студентов и стартаперов из области компьютерных наук и ИИ. В числе других спикеров выступили Elon Musk, Sam Altman, Andrew Ng и другие лидеры AI-индустрии. Ну а теперь к ключевым идеям выступления. Эры software Андрей выделил три эры разработки софта - Software 1.0 - это традиционный код, написанный программистами - Software 2.0 - это нейронные сети и их веса - Software 3.0 - это промпты на английском языке как программы для LLM В софте 3.0 случилась революция - мы теперь программируем компьютеры на английском языке. Это делает программирование доступным каждому, кто владеет естественным языком (кажется в 1С эта революция давно произошла, только там программировали на русском ✌️) LLM как новая операционная система Андрей провел интересную параллель между LLM и операционными системами - LLM - это CPU, то есть основной вычислительный блок новой парадигмы - Контекстное окно - это RAM (рабочая память системы) - Централизация в облаке - из-за высокой стоимости вычислений, что напоминает эру мейнфреймов - Разделение времени использования - пакетная обработка запросов пользователей В общем, пока момент PC (personal computers) еще не настал Психология LLM Андрей поразмышлял о психологии и привел метаформу "people spirits" по отношению к LLM - Это стохастические симуляции людей, обученные на человеческих данных - Jyb jбладают энциклопедическими знаниями и сверхчеловеческими способностями в некоторых областях - Имеют когнитивные нарушения и ошибки, подобно персонажам из фильмов "Человек дождя", "Помни", "50 первых поцелуев" - Требуют понимания их ограничений для продуктивного сотрудничества Основные возможности для разработчиков продуктов 1. Продукты с частичной автономией Karpathy подчёркивает важность создания приложений с "ползунком автономности", например, в Cursor можно просто пользоваться автодополнением или попросить агента переписать тебе код. В этом плане для работы и аудита AI системы важен правильный GUI (просто чата скорее всего не достаточно). Важно контролировать избыточную активность AI и держать его на поводке 2. Vibe Coding Karpathy популяризировал термин "vibe coding" — создание приложений через естественные описания без глубокого знания языков программирования. Это приводит к - Демократизации разработки софта - Возможности создавать рабочие прототипы за часы вместо недель - Но приносит сложности с интеграцией и развёртыванием реальных продуктов 3. Создание для агентов LLM становятся новой категорией потребителей цифровой информации наряду с людьми и программами. Это приводит к следующим последствиям - Необходимо адаптировать документацию для LLM (переход на Markdown) - Можно заменить мануалы вида "нажмите на кнопку" на мануалы вида сделайте API-вызов - Распространению инструментов типа MCP от Anthropic или A2A от Google для прямого общения с агентами Напоследок Андрей дает рекомендации - Изучайте все три парадигмы: Software 1.0, 2.0 и 3.0 будут сосуществовать - Фокусируйтесь на частичной автономии: не стройте полностью автономных агентов, а создавайте "костюмы Железного человека" - Ускоряйте цикл генерация-верификация: используйте GUI для быстрого аудита работы ИИ - Готовьте инфраструктуру для агентов: делайте ваши продукты доступными для LLM По словам Андрея, мы находимся в уникальный момент истории программирования — "предстоит переписать огромное количество кода". Это создаёт беспрецедентные возможности для новых разработчиков войти в индустрию и принять участие в создании софта 3.0 #AI #PlatformEngineering #Engineering #Software #Processes #Productivity

Code of Leadership #41 - Interview with Pavel Permyakov about T Invest and early days of T-Bank (Рубрика #Management) В очередном выпуске подкаста ко мне пришел интересный гость, Павел Пермяков, технический директор Т-Инвестиций. Паша уже 13 лет работает в Т-Банке, начал он с интеграционных проектов, а потом поучаствовал в создании инвестиций и через некоторое время стал их техническим директором. За полтора часа мы обсудили много интересных тем - Знакомство с гостем - Детство, увлечение информатикой, поступление и учеба в университете - Первая работа, стажировка, задачи и опыт в интеграторе - Карьерный рост, смена ролей, рост от стажера до архитектора - Архитектурные изменения: уход от интеграционной шины, переход к микросервисам - Принятие решения о запуске инвестиций, формирование команды, первые успехи - Трудности с масштабированием сервисов, получение лицензии, реакция конкурентов - Повседневные задачи технического директора, организация встреч, делегирование - Важность чтения, рекомендации по книгам, роль математики и саморазвития Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music. #Software #Engineering #Management #Architecture #Processes

Message from CEO Andy Jassy: Some thoughts on Generative AI Продолжу тему Amazon и расскажу про сегодняшее письмо Энди Джесси с его мыслями про gen AI. Кажется, что оно неплохо продолжает тему интервью про гибкость, AI стратегию, роль менеджеров, о котором я рассказывал утром. Мне показалось, что о структуре сообщения Энди стоит думать в формате: - Текущее состояние AI внутри Amazon в общем - Ключевые проекты: для клиентов, для инженеров, для операци - Последствия, которые видит Энди Джесси (самое интересное в письме) Ну и начнем мы с текущего состояния Gen AI Энди Джесси подчеркивает, что генеративный ИИ активно используется во всех подразделениях Amazon для улучшения клиентского опыта и повышения эффективности работы. Компания осуществляет масштабные инвестиции в эту технологию, считая ее революционной и способной полностью изменить возможности для клиентов и бизнеса. На данный момент Amazon уже разработала или находится в процессе разработки более 1000 сервисов и приложений на базе генеративного ИИ, хотя по масштабам компании это лишь малая часть того, что планируется создать в будущем. Джесси отмечает, что несмотря на значительный прогресс, Amazon находится только в начале пути внедрения генеративного ИИ. Компания планирует в ближайшие месяцы еще активнее развивать это направление, упрощая создание ИИ-агентов и разрабатывая новых агентов для всех бизнес-подразделений. Продолжим проектами Проекты для клиентов (b2c, b2b) - Alexa+ — новое поколение персонального ассистента, который стал значительно умнее - AI-ассистент для покупок (10+ mln клиентов) — у ассистента есть фичи навроде "Lens", "Buy for Me", "Recommended Size" - Инструменты для продавцов (500k sellers) — помощь независимым продавцам в создании страниц товаров. - Решения для рекламодателей (50k advertisers) — набор ИИ-инструментов, упрощающих планирование, создание и оптимизацию рекламных кампаний Проекты для инженеров (AWS) - Trainium2 — специализированные чипы для улучшения обучения/inference моделей - SageMaker — сервисы для упрощения создания базовых моделей - Bedrock — платформа для использования передовых моделей и масштабирования GenAI - Nova — собственная передовая модель Amazon с низкой задержкой и стоимостью - Q и QCLI — copilot для написания кода Внутренние операции - Оптимизация логистической сети с помощью ИИ для улучшения размещения запасов, прогнозирования спроса и эффективности роботов - Обновленный чат-бот для обслуживания клиентов на базе GenAI - Создание более интеллектуальных и привлекательных страниц с описанием товаров Ну и перейдем к самому интересному, а точнее к последствиям, что видит Энди 1) Трансформация работы и жизни через ИИ-агентов — Джесси убежден, что ИИ-агенты (программные системы, выполняющие задачи от имени пользователей) изменят способы работы и жизни людей. Эти агенты смогут выполнять множество задач и в будущем появятся миллиарды таких агентов во всех компаниях и сферах деятельности. 2) Изменение инновационного процесса — агенты изменят масштаб и скорость инноваций для клиентов, позволив сосредоточиться на стратегическом мышлении вместо рутинной работы. Джесси видит агентов как коллег, которые будут становиться мудрее и полезнее с опытом. 3) Изменение структуры рабочей силы — внедрение Gen AI и агентов изменит характер работы в компании. Потребуется меньше людей для выполнения некоторых текущих задач и больше людей для других типов работы. В ближайшие годы Джесси ожидает сокращение общей корпоративной рабочей силы из-за повышения эффективности от широкого использования ИИ. 4) Новые требования к сотрудникам — Джесси призывает сотрудников проявлять любопытство к ИИ, обучаться, посещать семинары и тренинги, экспериментировать с ИИ и участвовать в мозговых штурмах команды. Он подчеркивает, что те, кто примет эти изменения и станет специалистом в области ИИ, будут иметь большое влияние и помогут переизобрести компанию. Заканчивает эту статью Джесси выражением энтузиазма по поводу прогресса Amazon в области генеративного ИИ и планов на будущее. #Management #Leadership #Processes #Bigtech #Software #AI

Amazon CEO Andy Jassy on Agility, AI Strategy, and the Changing Role of Managers (Рубрика #Management) Посмотрел на выходных интервью Andy Jassy, генерального директора Amazon, которое он дал Adi Ignatius, представителю HBR (Harvard Business Review). Сам Джесси работает в Amazon уже 28 лет и занимает должность CEO с 2021 года, сменив основателя компании Джеффа Безоса. Ранее он руководил подразделением Amazon Web Services (AWS). Интервью было интересным и я решил рассказать суммировать основные идеи этого обсуждения 1. Философия "крупнейшего стартапа в мире" Джесси представил концепцию работы Amazon как "крупнейшего стартапа в мире". По его мнению, для сохранения стартап-культуры в крупной корпорации необходимы следующие элементы (очень напоминающие leadership принципы Amazon) - Решение реальных проблем клиентов — нельзя быть просто влюбленными в технологии - Команда строителей — нужны люди, которые умеют анализировать клиентский опыт и изобретать - Мышление владельца — сотрудники должны думать так, как если бы тратили собственные деньги - Скорость — которая имеет непропорционально большое значение для успеха - Готовность к рискам — опасаясь неудач невозможно создать что-то уникальное 2. Борьба с бюрократией Джесси отметил важность борьбы с бюрократией, что распространена в больших компаниях и замедляет их. Он поделился своим опытом конкретных мер для борьбы с ней: - Сокращение управленческих слоев — увеличение соотношения индивидуальных исполнителей к менеджерам минимум на 15% - Почтовый адрес для борьбы с бюрократией — сотрудники могут напрямую сообщать CEO о бюрократических препятствиях - Практические результаты — уже изменено 375 процессов на основе более чем 1000 полученных писем (и прочитанных самим Джесси) 3. Возвращение в офис Нельзя было обойти и обсуждение политики RTO (return to offfice), а точнее возвращения всех сотрудников на 5 дней в офис. Это решение принял Джесси в прошлом сентябре (я про это рассказывал). Он обосновал это следующими причинами - Улучшение изобретательства — личное присутствие способствует более эффективному сотрудничеству и генерации идей - Распространение культуры — корпоративная культура лучше передается при личном общении - Обучение и наставничество — более эффективны при непосредственном контакте 4. Стратегия в области искусственного интеллекта Джасси представил стратегию Amazon в сфере ИИ, основанную на трех макроуровнях: - Нижний уровень — для разработчиков моделей (чипы Trainium, сервис SageMaker) - Средний уровень — для пользователей существующих моделей (сервис Bedrock) - Верхний уровень — приложения (более 1000 генеративных ИИ-приложений Amazon), но в основном их создают пользователи сервисов AWS Особое внимание Джесси уделил помощнику по покупкам Rufus, который призван стать персональным консультантом для онлайн-шопинга на Amazon. 5. Лидерство в эпоху неопределенности Джеси подчеркнул важность сосредоточения на контролируемых факторах в условиях глобальной неопределенности: - Фокус на клиентах — главная задача состоит в том, чтобы делать жизнь клиентов проще и лучше каждый день - Контроль управляемого — нельзя контролировать все, но можно управлять тем, что в твоих силах По мнению Джеси, успешное лидерство XXI века требует: - Отличного клиентского опыта с успешными финансовыми результатами - Внимания к устойчивости, разнообразию и долгосрочному мышлению - Способности адаптироваться к изменяющимся приоритетам 6. Карьерные советы Джасси поделился ключевыми принципами успешной карьеры: - Стоит выбирать работу, которой действительно увлечен и в которой можешь преуспеть - Не надо бояться ошибок, так как самые важные уроки приходят именно из неудач - Важно иметь правильные установки: трудолюбие, надежность, командный дух и позитивное отношение к жизни - Важно уметь непрерывно учиться - в динамичной среде прекращение обучения равносильно началу деградации В общем, хорошее системное интервью, в котором, правда, я не нашел каких-то инсайтов для себя. #Management #Leadership #Processes #Bigtech #Software #AI

Интервью с Андреем Романовским (Рубрика #Management) Недавно я обедал с Андреем Романовским, руководителем продуктовой разработки Яндекс.Лавки и cto Yango.Tech Retail, а также автром канала Lead’s Notes (@leadsnotes). За обедом мы обсуждали кучу интересных вещей - оказалось, что нам есть о чем поговорить. По ходу дискуссии у нас появилась идея провести совместный стрим, в котором мы хотели обсудить одну из трех тем, представленных ниже 1. Стартапы в корпорациях: как и зачем рождаются, чем отличаются от обычных стартапов, как стоит или не стоит их строить 2. Эффективность и мотивация команд в больших компаниях: что это вообще такое, что работает или не работает, эволюция подходов в процессах и технологиях (от код-ревью и скрама до AI-ассистентов в IDE и сложных матричных структур) 3. Менеджерская карьера и жизнь в компании: как дорасти до c-level позиции, заработать свой первый $1 mln и не сойти с ума, как адаптироваться к зоне растущего размера и сложности В итоге, мы так и не выбрали тему, поэтому предлагаем вам выбрать вариант, что вам ближе, а дальше мы сделаем онлайн-стрим и поговорим на выбранную тему, а вы сможете позадавать дополнительные вопросы по ходу нашего общения. #Software #Management #Leadership #Engineering

[3/3] What's DAT? Three Case Studies of Measuring Software Development Productivity at Meta With Diff Authoring Time (Рубрика #Productivity) Немного иллюстраций из интересного whitepaper про метрики продуктивности инженеров от Meta, про который я рассказывал в предыдущих двух частях: 1 и 2. #Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

[2/3] What's DAT? Three Case Studies of Measuring Software Development Productivity at Meta With Diff Authoring Time (Рубрика #Productivity) Продолжая рассказ про этот whitepaper от Meta, чья деятельность запрещена на территории РФ, перейдем к валидации подходом с использованием DAT (Diff Authoring Time). Для этого авторы прповели дополнительные исследования 1. Исследование пользовательского опыта - Создали ground truth датасет через запись реальной работы разработчиков - Использовали случайную выборку для минимизации предвзятости - Получили среднюю точность DAT более 90% по сравнению с реальными данными 2. Крупномасштабный опрос - Сравнили DAT с оценками разработчиков (968 уникальных диффов) - Встроили опросы в инструмент Phabricator, который используется для код ревью. Опрос стартует сразу после завершения диффа 3. Дескриптивная статистика - DAT покрывает 87% всех подходящих диффов - DAT оказалось стабильной метрикой (использовался 99-го перцентиль winsorized mean для отчетности) - Авторы отвалидировали DAT, проведя сравнение с метрикой Time Spent by Diff, которая определяется как "averages coding time in a given period by the number of diffs published in that period" 4. Визуализация временных рядов - Сделали детальную визуализацию того, как сырая телеметрия преобразуется в DAT (изображение будет в финальном посте) - Сделали кросс-валидацию с авторами изменений (с самими разработчиками) Дальше авторы рассказывают про 3 конкретных эксперимента, которые они проводили 1. Типизированное мокирование в Hack Суть эксперимента в том, чтобы внедрить типизацию в инструменты мокирования внутри Hack (внутренняя версия доработанного PHP). Для эксперимента авторы мигрировали часть моков на типы, а часть оставили как есть и дальше сравнили DAT при создании diffs в разных частях кодовой базы. Эксперимент показал как языковые возможности с конкретными показателями продуктивности - 14% улучшение DAT: Первое количественное доказательство влияния типизации на продуктивность в промышленной среде - Статистическая значимость: p < 0.001 для всех размеров диффов 2. Авто-мемоизация в React компайлере Авторы дорабатывали фреймворк React для авто-мемоизации и дальше провели эксперимент, где сравнили DAT при создании diffs с ручной и автоматической мемоизацией. - Они использовали смешанную модель эффектов для учета конфаундеров через регрессионную модель - Для нерандомизированных данных они использовали Wasserstein distance для измерений истинной разницы между граппуми - 33% улучшение DAT: Значительное повышение эффективности при использовании автоматической мемоизации 3. Квантификация эффективности от переиспользования кода Это исследование мне показалось самым интересным, так как авторы оценивали эффект применения кросс-платформенных технологий (у ребя это был React). Правда, для анализа пришлось использовать контрфактический анализ для оценки гипотетического времени разработки без переиспользования кода. На выходе получилось, что - Кроссплатформа дает больше, чем 50% улучшение относительно разработки без переиспользования - А это тысячи часов ежегодной экономии DAT через фреймворки переиспользования кода В итоге, этот подход к использованию метрики DAT привел к следующим эффектам - Переход Infrastructure команд к культуре, ориентированной на a/b эксперименты - Принятие решений на основе данных - DAT используется для планирования и приоритизации разработки - DAT и эксперименты выравняли подходов между продуктовыми и инфраструктурными командами Если говорить про дальнейшие планы авторов исследования, то они планируют расширение - Горизонтально - добавление кроме diffs и других артефактов разработки (documents and tasks). Это позволит создать общий фреймворка измерения времени активностей для экспериментов - Вертикально - поддержка большего количества инструментов (разных IDEs и других инструментов). Это позволит меньше ориентироваться на эвристики и больше на точные измерения. #Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

Выступление в Вышке перед студентами ФКН (Рубрика #SystemDesign) Меня позвали поговорить со студентами про System Design и я не смог отказаться. В итоге, сегодня буду рассказывать истории про то - Как сейчас выглядят процессы разработки внутри компании - со сложными и большими системами и децентрализацией принятия технических решений - Как мы набираем людей и зачем нам System Design Interview - Как дальше выглядят процессы после трудоустройства - расскажу про RFC/ADR, ревью архитектуры, общие инженерные вопросы типа reliability, security и так далее и что не всегда все при проектировании выглядит так просто, как на System Design Interview А в конце я еще планировал поотвечать на вопросы ребят. P.S. До этого я уже рассказывал про процессы найма в большие компании и типы интервью на примере Т-Банка. Про System Design у меня тоже было много материалов. Например можно посмотреть в общем про system design в Tinkoff, больше про то, как мы оцениваем прохождение собеседования и как подготовиться к собеседованию или публичные интервью на ArchDays #Career #HR #Management #Architecture #Software #Leadership #Processes

7 Habits of Highly Effective Generative AI Evaluations (Рубрика #AI) Посмотрел на выходных интересное выступление про evaluations от Джастина Мюллера, Principal Applied AI Architect в Amazon Web Services (AWS). Команда Мюллера в AWS помогает клиентам масштабировать рабочие нагрузки с генеративным ИИ, и за время работы он имел возможность изучить более 100 различных попыток создания фреймворков оценки работы моделей. Это выступление прошло недавно в рамках конференции AI Engineer World's Fair. Ключевой идеей выступление было то, что основная проблема при масштабировани genAI решений в недостаточности оценок (evaluations) качества их работы. Несмотря на то, что многие называют основными проблемами стоимость, галлюцинации, точность и производительность, именно отсутствие подходящих evaluation фреймворков чаще всего препятствует успешному внедрению. Для демонстрации этой идеи Джастин рассказал реальный кейс клиента с проектом обработки документов, где точность составляла всего 22%. После внедрения системы оценки за 6 месяцев удалось достичь 92% точности и запустить проект в массовое производство, сделав его крупнейшим на тот момент по обработке документов на AWS в Северной Америке. Для решения этой проблемы с эффективной оценкой моделей автор предлагает следующие семь привычек высокоэффективных людей высокоэффективных genAI evaluations: 1. Скорость выполения (Fast) - Целевое время выполнения оценки — 30 секунд - Возможность делать сотни изменений и тестов ежедневно вместо 4-8 в месяц 2. Количественно измеримый (Quantifiable) - Оценка должна выражаться в конкретных числовых показателях - Стоит применять усреднение по множественным тест-кейсам для устранения случайных колебаний 3. Объяснимость (Explainable) - Анализ не только результатов, но и процесса рассуждений модели - Важность понимания логики как генерирующей модели, так и оценивающей модели 4. Сегментированность (Segmented) - Разбиение сложных промптов на последовательность простых шагов - Возможность оценки каждого этапа отдельно и выбора подходящей модели для каждой задачи 5. Разнообразие (Diverse) - Покрытие всех сценариев использования - Эмпирическое правило: ~100 тестовых примеров для основных случаев использования 6. Традиционность (Traditional) - Сохранение использования проверенных методов оценки (из ML) - Численные оценки, метрики точности баз данных, измерение стоимости и задержки остаются актуальными 7. Золотые стандарты - Критическая важность создания качественного набора золотых стандартов - Избегание использования генеративного ИИ для создания золотых стандартов во избежание воспроизведения ошибок Ключевыми принципами от Джастина являются следующие - Декомпозиция промптов — разбиение сложных многошаговых промптов на цепочку простых, что позволяет точно определить источник ошибок и оптимизировать каждый этап отдельно. - Семантическая маршрутизация — интеллектуальное направление запросов к подходящим моделям в зависимости от сложности задачи, что повышает точность и снижает затраты. - Фокус на выявлении проблем — главная цель оценок не просто измерение качества, а обнаружение конкретных проблем и предложение путей их решения. В общем, выступления Мюллера - это сборник практических советов о том, как стоит организовывать свой фреймворк оценки GenAI моделей. Эти советы звучат логично, выглядят доступно, а также проверены на опыте работы с крупнейшими рабочими нагрузками в Северной Америке.

[1/3] What's DAT? Three Case Studies of Measuring Software Development Productivity at Meta With Diff Authoring Time (Рубрика #Productivity) На эту интересную статью 2025 года от компании "Meta" я наткнулся во время подготовки обзора статьи "Enabling the Study of Software Development Behavior With Cross-Tool Logs" (мой обзор: 1, 2 и 3). И хоть деятельность организации "Meta" запрещена на территории РФ, но читать их инженерный whitepaper достаточно интересно. Основная идея этого исследования - это измерение продуктивности разработки софта через метрику Diff Authoring Time (DAT), которая представляет собой активное время разработчика на создание изменений в коде (диффов), которые по сути своей напоминают MR (merge requests). Это время собирается при помощи системы телеметрии, интегрированной с системой контроля версий, IDE и операционной системой . Ключевая ценность этого исследования для Meta это - Переход от интуитивных оценок к научному подходу измерения продуктивности на основе DAT - Измерения DAT направлены не на оценку performance конкретных разработчиков, а на оценку эффекта инструментов и процессов на продуктивность - Этот подход дает возможность проведения a/b экспериментов изменения тулинга и процессов - по утверждению авторов они уже ее обкатали на 20 проектах, про три из которых они рассказывают в статье - Важно, что часть экспериментов можно катать с гранулярностью на уровне diffs (эксперименты, что прозрачны для инженеров), а часть на уровне когорт инженеров (те, где изменения явно видны и не позволяют менять подход для разных diffs - например, переключение между версиями IDE) Забавно, что авторы утверждают, что-то в стиле того, что их исследование впервые в индустрии предоставляет количественные доказательства влияния различных инструментов и методов разработки на продуктивность в реальной корпоративной среде. Видимо, они не читали исследований ребят из Google, например, то, что я упоминал выше от 2020 года:) Если говорить про струткру модели, то она состоит из следующих частей 1. Основной алгоритм точного сопоставления Отслеживание активности в IDE: Система фиксирует время работы в интегрированной среде разработки Интеграция с системой контроля версий: Связывает временные сессии с конкретными коммитами через Sapling (система контроля версий Meta) Алгоритм сдвига влево: Каждый коммит CHx приписывается к IDE-сессии s(x-1), которая предшествует ему 2. Дополнительные эвристики Anchor Sessions: Захватывает активность, предшествующую точному совпадению, для более полного покрытия времени разработки Обработка крайних случаев: Автоматическое исключение checkout'ов и фильтрация нерелевантной активности 3. Система телеметрии с защитой приватности OS-уровневая телеметрия: Отслеживание активности на уровне операционной системы Интеграция с инструментами: Плагины для VS Code, Sapling и других инструментов разработки Неперекрывающиеся измерения: DAT гарантирует, что время между различными диффами не пересекается для одного разработчика В итоге, мы получаем следующие ключевые свойства модели - Неперекрываемость: DAT(D123) ∩ DAT(D987) = ∅ для одного пользователя, где D123 и D987 - это два разных diffs - Ограниченность: DAT не может превышать 24 часа в день - Агрегируемость: В отличие от других метрик, DAT можно корректно суммировать Продолжение обзора в следующем посте. #Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

Поездка в Питер на длинные выходные (Рубрика #Rest) Сгоняли семьей на длинные выходные в Питер. Решили съездить на машине и по пути туда жалели о своем решении - ехали вместо предсказанных навигатором шести с половиной часов все десять - на платнике было плотно, были аварии, а все заправки были забиты, пришлось час ожидать заправки недалеко от Питера. Но мы доехали до Лахта Плаза и заселились. В следующие дни удалось - Посетить Гранд Макет Россия и показать его детям - Съездить в Новую Голландию, поползать по детскиой площадке в форме большого корабля, купить книжек в их цилиндрическом здании - Посетить аквапарк "ПитерЛенд", а потом прогуляться по парку 300-летия Санкт-Петербурга - Еще мы насладились едой в о"Вкусно Дорого", а также "Коза Море" - Прикольно, что удалось потусить с моим братом и показать ему племянников Правда, мы решили уехать обратно во второй половине субботы, чтобы доехать обратно комфортно, а не в перманентной пробке на платнике:) #ForKids #ForParents #Rest