[2/2] Статьи из серии "Developer Productivity for Humans" (Рубрика #Management)

Продолжая рассказ про статьи из этой серии поделюсь разборами оставшихся статей.

8 ) 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

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

Космонавтика (Рубрика #PopularScience)

В выступлении Илона Маска, про которое я рассыказывал в выходные, мне понравилась часть, где он рассказывал про Space X. Я сам когда-то в детстве мечтал полететь в космос, но потом я вырос и понял, что скорее всего у меня не получится. Но я до сих пор люблю читать про космос, астрофизику, а после поездки в Китай я верулся с космонавтом из набора лего, который теперь стоит на моем столе в офисе. А рядом с ним лежит книга "NASA. The Archive" и "Космические туманности 3D", которые иногда можно полистать для получения вдохновения:)

#PopularScience #Photography

Alexander Wang: Building Scale AI, Transforming Work with Agents & Competing with China (Рубрика #AI)

Посмотрел на выходных очень интересное выступление Александра Вана, американо-китайского предпринимателя, родившийся в 1997 году в Лос-Аламосе, Нью-Мексико. В 24 года он стал самым молодым self-made миллиардером в мире. Ван — математический вундеркинд, который участвовал в олимпиадах по математике и программированию с детства. До основания Scale AI работал программистом в Quora в возрасте 17 лет, а также учился в MIT, откуда ушел для развития своего стартапа. Его компания Scale AI — это платформа для аннотирования данных, предоставляющая обучающие данные для моделей машинного обучения (аля Mechanical Turk от AWS или "Толока" от Яндекса). Александр основал ее совместно с Люси Го в 2016 году в рамках акселератора Y Combinator (Александру тогда было 19). Изначально Scale AI позиционировалась как "API для человеческого труда", но быстро сфокусировалась на данных для беспилотных автомобилей (про это Александр рассказывает подробно в подкасте). Сегодня Scale AI стоит $29 миллиардов после недавних инвестиций Meta в размере $14 миллиардов, а Александр возглавит новую лабораторию суперинтеллекта Meta

Если говорить про основные тезисы выступления, то они следующие
1. Эволюция Scale AI: от данных к агентам
Ван рассказал о трансформации компании от простой платформы разметки данных к провайдеру агентных решений. Компания прошла путь от фокуса на беспилотные автомобили до создания ИИ-приложений стоимостью сотни миллионов долларов для крупнейших корпораций и правительства
2. Будущее работы: люди как менеджеры агентов
Александр Ван представил техно-оптимистичное видение будущего работы. По его мнению, конечное состояние экономики — это "крупномасштабное управление людьми и агентами". Люди будут выполнять роль менеджеров, координирующих работу ИИ-агентов, при этом сохраняя контроль над видением и конечными результатами. Забавно, что техно-пессимисты иногда говорят, что агентами будут люди, а менеджерить их будет AGI:)
3. Конкуренция с Китаем в области ИИ
Ван открыто обсудил вызовы конкуренции с китайскими ИИ-лабораториями. Он отметил, что китайские модели хороши частично благодаря промышленному шпионажу, а Китай имеет преимущества в данных и энергетике. США отстают в производстве энергии из-за регуляторных ограничений, в то время как Китай продолжает наращивать мощности. Ирониично было слушать обсуждение конкуренции с Китаем от Гарри Тена, главы Y Combinator, и Александра Вана, главы Scale AI.
4. "Последний экзамен человечества"
Scale AI создала benchmark под названием "Humanity's Last Exam" — набор сверхсложных научных задач, составленных ведущими исследователями. Эти задачи требуют многочасовых размышлений и никогда не появлялись в учебниках. Лучшие модели уже набирают более 20% баллов, что показывает быстрый прогресс ИИ в решении передовых исследовательских задач
5. Законы масштабирования и специализированные модели
Ван подчеркнул важность законов масштабирования, которые стали очевидными с выходом GPT-3 в 2020 году. В будущем каждая компания будет иметь специализированную модель как основной IP, обученную на собственных данных и для решения конкретных бизнес-задач
6. Агентные рабочие процессы
Scale AI активно использует обучение с подкреплением для автоматизации внутренних процессов, преобразуя человеческие рабочие процессы в агентские. Компания применяет эти решения для анализа данных, отчетов о продажах и других операционных задач.

В общем, интервью достаточно глубокое и интересное, причем видно насколько Александр увлечен своей работой и шарит в теме - не зря Марк Цукерберг вложился в компанию Александра и позвал руководить лабораторией.

#AI #Engineering #Management #Leadership #ML #Software

Turbo ML Conf от Т-Банка (Рубрика #AI)

19 июля Т-Банк проведет масштабную конференцию для специалистов в области машинного обучения — Turbo ML Conf. Это уникальная площадка, где соберутся ведущие эксперты для обсуждения самых актуальных тем и прикладных кейсов в сфере искусственного интеллекта. Участников ждут как доклады, ориентированные на продукт и бизнес-метрики, так и глубокие технические разборы из мира R&D и научных исследований. В программе конференции 5 треков

1. NLP (Обработка естественного языка)
Спикеры поделятся опытом в автоматизации клиентской поддержки, обсудят alignment, reasoning, а также мультимодальные большие языковые модели (LLM) и их механистическую интерпретируемость.
2. Research & RnD
Обсуждение того, как устроены исследования в России и кто создает новые направления. Обсуждение alignment, reasoning, LMM и mechanistic interprebability
3. RecSys (Рекомендательные системы)
Эксперты представят свежие инсайты из промышленных A/B-тестов, расскажут о применении нейросетей на разных этапах создания рекомендательных систем и поделятся опытом построения персонализации в крупных проектах. Также будут затронуты техники улучшения бизнес-метрик и применение графовых нейронных сетей (GNN).
4. CV (Компьютерное зрение) и Speech
Этот трек будет посвящен последним достижениям в области синтеза и распознавания речи, генеративным сетям, VLM (Vision-Language Models) и OCR (оптическое распознавание символов).
5. LLM Applications (Применение LLM)
Этот блок будет посвящен практическому использованию больших языковых моделей. Будут рассмотрены LLM-платформы, архитектура решений, инструментарий (тулинг), агентные системы, RAG (Retrieval-Augmented Generation) и применение LLM в разработке программного обеспечения. Отдельное внимание будет уделено низкоуровневым оптимизациям для работы моделей на различных устройствах.

В общем, регистрируйтесь и приходите послушать крутые доклады.

#AI #ML #Engineering #Software #Conference

Архитектура предприятия, управляемая моделью (Рубрика #Architecture)

Я интересуюсь архитектурой во всех ее проявлениях, поэтому иногда смотрю за потугами и корпоративных архитекторов. На недавней конференции Сбера было выступление Олега Захарчука на тему архитектуры, управляемой моделью. Сам Олег закончил МФТИ в далеком 1987 году, а сейчас руководит компанией "АСиС Софт", является экспертом в области архитектуры предприятия и членом-корреспондентом РАЕН. Он известен своими работами в области создания единой метамодели.

Если кратко обобщать идеи выступления, то в нем рассказано про
- Концепцию холархии, что должна прийти на смену традиционным иерархическим структурам
- Четырехуровневую модель: действия, задачи, рабочие группы, организации
- Единую онтологии деятельности и создании цифровых моделей предприятий на базе этой модели
- Цифровых агентах, что должны где-то бултыхаться на уровне действия и отдельных сервисов для их автоматизации (видимо, это отсылка к AI агентам)

В общем, если попробовать проанализировать проблемные места подхода, предложенного в докладе, то
1. Концептуальная сложностью Несмотря на заявления о упрощении, четырехуровневая холархия с множественными связями "обязательств" может оказаться более сложной для понимания и внедрения, чем существующие подходы.
2. Масштабируемости решения на уровень компании. Хотя автор утверждает, что подход позволяет описывать системы различного масштаба, практический опыт показывает, что единые метамодели часто сталкиваются с проблемами при масштабировании на уровень крупных предприятий
3. Интеграция с существующими решениями. Большинство предприятий уже имеют развитую ИТ-инфраструктуру, построенную на различных стандартах и методологиях . Не ясно как эта модель Захарчука может быть интегрирована в существующую компанию
4. Поддержка и развитие модели. В отличие от открытых стандартов типа TOGAF или ArchiMate, которые развиваются международными консорциумами, модель Захарчука является проприетарным решением одной компании.

Дальше я поделюсь своим мнением о подходе автора, который напоминает мне проповеди о светоносном эфире, перед корпусами Физтеха одного старичка.
Автор взял подходы из прошлого:
- Концепцию холархии была сформулирована еще в 1960-х годах философом Артуром Кестлером
- Идею единой онтологии для предприятий активно разрабатывалась в рамках семантического веба в районе двухтысячных
- И так далее
Автор провел ребрендинг и начал продавать их как работающее решение ... и все вроде неплохо, но оно не работает и это проблема не только модели Олега Захарчука, а всего подхода к архитектуре предприятия, где можно выделить следующие проблемы

1. Отсутствие связи с реальностью
Общая тенденция архитектуры предприятий — создавать красивые теоретические модели, которые плохо работают на практике. Приоритет отдается архитектурной чистоте, а не жизнеспособным и эффективным в реальном мире решениям
2. Проблема "моделирования ради моделирования"
Команды создают модели чего-то, но не имеют ясного понимания цели, для которой они моделируют . Архитектура, которая не обращается к набору заинтересованных сторон, часто приводит к низкой воспринимаемой ценности.
3. Фреймворки корпоративной архитектуры бесполезны. Фреймворки вроде Zachman, TOGAF или FEAF являются не более чем типичными управленческими причудами, агрессивно продвигаемыми консалтинговыми компаниями и гуру. Они бесполезны в лучшем случае и вредны в худшем (подробнее в whitepaper)
4. Псевдонаучность корпоративной архитектуры. Системное мышление, как инструмент для архитектуры предприятий, часто восхваляется в публикациях, связанных с архитектурой предприятий, но на практике не способно предоставить какие-либо действенные предложения . Исследования ставят под сомнение научную обоснованность архитектуры предприятий с точки зрения критериев фальсицируемости Поппера (подробнее в whitepaper)

P.S.
Когда я слышу слово онтология в контексте архитектуры, то понимаю, что дальше все будет только хуже.

#Architecture #Software #Engineering #Management #DistributedSystems

Code of Leadership #42 Interview with Andrew Romanovsky about Сareer as an Engineering Manager (Рубрика #Management)

Через 2 часа стартанет live интервью с Андреем Романовским о карьере engineering manager в крупной технологической компании. Андрей руководит продуктовой разработкой Яндекс.Лавки и является CTO Yango.Tech Retail, а кроме того ведет канал Lead’s Notes (@leadsnotes). Мы точно обсудим вопросы ниже, но если вы придете, то сможете спросить что-то свое
- Что входет в роль engineering manager?
- Ради чего вообще стоит идти в менеджерский карьерный трек?
- Как устроен рост менеджера?
- Растет ли сложность работы с продвижением по карьерной лестнице?
- Как решать проблемы тайм-менеджмента: перегруз, баланс работы и личной жизни?
- Как не потерять технические скиллы и стоит ли за этим гнаться?

#Software #Engineering #Management #Architecture #Processes

ML-платформа: всеобщее благо или лучше не надо (Рубрика #AI)

Посмотрел интересное интервью моих коллег на тему ML платформы. Мне нравится и ML и platform engineering, а тут собралось комбо, поэтому я не мог пройти мимо этого выпуска "Желтый AI Club Talks". В нем участвуют два человека:
- Даниил Гаврилов — ведущий, руководитель Research-команды
- Михаил Чебаков — гость, руководитель разработки платформ ML

Вот основные идеи интервью
1. Философия ML-платформы
Михаиил представил концепцию идеальной ML-платформы через метафору канализации — она должна быть незаметной в работе, но критически важной для функционирования. Платформа должна инкапсулировать операционные затраты, связанные с масштабированием, предоставлением ресурсов, мониторингом и обеспечением отказоустойчивости, позволяя разработчикам сосредоточиться на основной работе.
2. Эволюция платформы
Развитие ML-платформы в Т-Банке началось с классической проблемы — кластера серверов с SSH-доступом, который перестал справляться с растущими потребностями команд. Первым решением стало внедрение простого оркестратора, что повысило утилизацию серверов.
3. Самая важная функция
По мнению Михаила, ключевой особенностью платформы стала возможность управления данными — создание папок, доступных из любой точки кластера, с автоматическим резервным копированием. Эта функция позволяет командам легко обрабатывать нестандартные данные, генерировать промежуточные артефакты и переносить работу между кластерами.
4. Проблемы с пользовательским опытом
Миша привел пример фичи, где пользователи просили добавить папки для организации своей работы. Ребята подумали и придумали максимально общую систему организации работы через лейблы — решение получилось технически правильным. Через фильтрацию лейблов можно было делать любые представления, но это было не user friendly с точки discovery этой фичи, а также дальше в процессе использования. В итоге, Михаил подчеркнул важность создания интуитивно понятного интерфейса, где функционал можно найти без изучения документации.
5. Сопротивление переходу на платформу
Многие разработчики предпочитают работать через SSH из-за ощущения контроля, прозрачности процессов и совместимости с большинством open-source проектов. Однако такой подход создает проблемы с воспроизводимостью результатов, потерей данных и масштабированием.
6. Три ключевых домена ML платформы
- Инженерный опыт — интерактивная работа одного разработчика с минимальным циклом обратной связи
- Производственные конвейеры — автоматизация устоявшихся процессов с акцентом на воспроизводимость
- Развертывание и эксплуатация — обеспечение эффективности и полезности готовых решений
7. Принципы проектирования
Основной принцип — делать правильные пути простыми, а неправильные — сложными. Это предотвращает ошибки и направляет пользователей к оптимальным решениям.
8. Методы оценки эффективности
- Базовые метрики: количество пользователей, команд, retention
- Регулярные опросы и замеры удовлетворенности
- Догфудинг — использование платформы для собственных внутренних задач разработки платформы
- Плотное взаимодействие с командами в режиме co-development
9. Разнообразие ML-направлений
Платформа обслуживает десять различных направлений: R&D, RecSys, CV, генерацию изображений, LLMs, прикладное NLP, антифрод, рисковые скоринги, распознавание и синтез речи. Каждое направление имеет уникальные требования к данным, воспроизводимости и аппаратуре.
10. Видение будущего
Михаил видит идеальное будущее платформы в полном воспроизведении опыта работы с SSH-серверами, но с преимуществами платформенного подхода — все необходимые функции должны быть доступны "из коробки" без необходимости изучения документации.

Ключевой вызов заключается в том, что команда разработки платформы работает как "вторая производная" от продукта — они создают инструменты для технологий, которые затем используются для создания продуктов. Это требует постоянного мониторинга индустриальных трендов и опережающего развития функционала.

#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops #DistributedSystems

Measuring AI code assistants and agents (Рубрика #AI)

Прочитал свежий (вчерашний) research на тему измерения эффекта от AI в разработке от Abi Noda, кофаундера и CEO платформы DX для измерения продуктивности разработки. Этот отчет интересен, так как ребята из DX являются одними из законодателей мод в мире developer productivity:
- Они запилили модель DevEx, которую я уже разбирал "DevEx: What Actually Drives Productivity" и "DevEx in Action"
- В команду платформы входит Nicole Forsgren, которая драйвила развитие DORA метрик, была автором книги "Accelerate", приложила руку к фреймворку SPACE

Теперь, когда ясно почему ребят интересно изучать, давайте заглянем в сам отчет и выделим основные идеи

1. Влияние AI на разработку
AI кардинально меняет подход к инженерной деятельности в технологических компаниях - компании больше не ограничены количеством инженеров, а скорее степенью аугментации их возможностей с помощью AI. Упоминаются такие результаты нескольких компаний
- Booking.com, внедрив AI-инструменты для более чем 3500 инженеров, достигла 16% увеличения throughput за несколько месяцев
- Intercom, почти удвоив использование AI-ассистентов кода, добилась 41% увеличения экономии времени разработчиков.
AI также расширяет понятие "разработчика" - продакт-менеджеры, дизайнеры и бизнес-аналитики теперь могут создавать работающее программное обеспечение с помощью AI, размывая границы между техническими и нетехническими ролями. Вспоминаем про vibe coding:)

2. Ключевые метрики для измерения
Авторы отчета расширяют свой DX фреймворк отдельным направлением DX AI, где фокус на трех вещах
- Utilization - отслеживание внедрения и использования AI-инструментов. Исследования показывают, что даже ведущие организации достигают лишь около 60% активного использования AI-инструментов.
- Impact - измерение реального эффекта на производительность. Рекомендуется сочетать:
-- Прямые метрики: экономия времени разработчиков
-- Косвенные метрики: анализ DX Core 4 показателей (PR throughput, percieved rate of delivery, developer experience index)
- Cost - отслеживание затрат, чистой прибыли (сэкономленное время разработчиков - затраты)
Интересно, что у ребят есть бенчмарки по этим метрикам, которые они предоставляют клиентам DX платформы

3. Баланс скорости и качества
Организации должны балансировать метрики эффективности с показателями качества, чтобы избежать подрыва долгосрочной скорости разработки. AI-генерированный код может быть менее интуитивным для понимания человеком, что создает потенциальные проблемы.

4. Измерение AI-агентов
Исследование рекомендует рассматривать автономных агентов как расширения команд разработчиков, а не как независимых участников. Каждый разработчик будет все больше работать как "менеджер" команды AI-агентов, а оценивать его результаты надо будет по результатам работы этой команды AI агентов

5. Подходы к внедрению системы измерений
Важно правильно коммуницировать цели вндерения метрик, связанных с использованием AI. Авторы рекомендуют четко подчеркивать три ключевых момента:
- Метрики не будут использоваться для индивидуальной оценки производительности сотрудников (ведь не будут же?)
- Цель измерения - понять, как AI-assisted работа влияет на опыт разработчиков и качество программного обеспечения, а не микроменеджмент
- Данные необходимы для принятия инвестиционных решений, помогая определить, какие инструменты и рабочие процессы приносят реальную ценность

6. Избежание ловушек
Отчет категорически предостерегает от директивных мандатов сверху или использования метрик для индивидуальной оценки производительности. Такие метрики, как объем генерации кода, особенно подвержены манипуляциям. Проактивная коммуникация является ключевой - без неё спекуляции и страхи могут заполнить информационный вакуум.

В общем, этот отчет показывает важность сочетания AI-специфических рекомендаций с измерением общей производительности разработчиков, чтобы получить полную картину того, как AI влияет на организационную эффективность.

#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops