Research Insights Made Simple (Рубрика #Engineering)
Наконец-то у меня дошли руки для подготовки расшифровок подкастов, которые посвящены разбору всяких научных работ в области software engineering. Правда, у меня получилось пока сделать краткие саммари по первым шести выпускам research insights made simple:
1. Разбор whitepaper "API Governance at Scale" от ребят из Google. В разборе мне помогал Даниил Кулешов, staff+ инженер в Т-Банке, что ведет несколько больших архитектурных проектов и участвует в процессах архревью на всю компанию. Саммари разбора есть в статье на моем сайте tellmeabout.tech
2. Разбор whitepaper "Defining, Measuring, and Managing Technical Debt" от ребят из Google. В разборе мне помогал Дмитрий Гаевский, staff+ инженер и технический CPO платформы Spirit в Т-Банке. Саммари разбора есть в статье на моем сайте
3. Разбор whitepaper "Security by Design at Google" от ребят из Google. В разборе мне помагал Артем Меретц, staff+ инженер и архитектор безопасности в Т-Банке. Саммари разбора есть в статье на моем сайте
4. Разбор whitepaper "AI-Enhanced API Design" от ребят из Google. В разборе мне помогал Павел Каравашкин, staff+ инженер в Т-Банке. Саммари разбора есть в статье на моем сайте
5. Разбор подходов к продуктивности разработки: DORA Metrics, SPACE, DevEx, Human Approach to Dev Productivity. В разборе мне помогал Артем Арюткин, руководитель проектного и продуктового офиса в RideTech & e-com Яндекса. Саммари разбора есть в статье на моем сайте
6. Интервью с Николаем Головым про эволюцию data platform от начала времен и до текущего момента. Саммари разбора есть в статье на моем сайте
P.S.
Осталось расшифровать еще 6 выпусков, а потом новые выпуски подкаста я смогу публиковать сразу с текстовой версией для удобства.
#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes
Наконец-то у меня дошли руки для подготовки расшифровок подкастов, которые посвящены разбору всяких научных работ в области software engineering. Правда, у меня получилось пока сделать краткие саммари по первым шести выпускам research insights made simple:
1. Разбор whitepaper "API Governance at Scale" от ребят из Google. В разборе мне помогал Даниил Кулешов, staff+ инженер в Т-Банке, что ведет несколько больших архитектурных проектов и участвует в процессах архревью на всю компанию. Саммари разбора есть в статье на моем сайте tellmeabout.tech
2. Разбор whitepaper "Defining, Measuring, and Managing Technical Debt" от ребят из Google. В разборе мне помогал Дмитрий Гаевский, staff+ инженер и технический CPO платформы Spirit в Т-Банке. Саммари разбора есть в статье на моем сайте
3. Разбор whitepaper "Security by Design at Google" от ребят из Google. В разборе мне помагал Артем Меретц, staff+ инженер и архитектор безопасности в Т-Банке. Саммари разбора есть в статье на моем сайте
4. Разбор whitepaper "AI-Enhanced API Design" от ребят из Google. В разборе мне помогал Павел Каравашкин, staff+ инженер в Т-Банке. Саммари разбора есть в статье на моем сайте
5. Разбор подходов к продуктивности разработки: DORA Metrics, SPACE, DevEx, Human Approach to Dev Productivity. В разборе мне помогал Артем Арюткин, руководитель проектного и продуктового офиса в RideTech & e-com Яндекса. Саммари разбора есть в статье на моем сайте
6. Интервью с Николаем Головым про эволюцию data platform от начала времен и до текущего момента. Саммари разбора есть в статье на моем сайте
P.S.
Осталось расшифровать еще 6 выпусков, а потом новые выпуски подкаста я смогу публиковать сразу с текстовой версией для удобства.
#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes
❤7🔥3👍2
Patrick Collinson on programming languages, AI, and Stripe's biggest engineering decisions (Рубрика #AI)
Посмотрел на выходных интересное интервью Патрика Коллинсона, со-основателя Stripe и энтузиаста языков программированния. Это интервью у него брал Майкл Трюэлл, сооснователь и генеральный директор Anysphere, компании, которая создала Cursor. Ребята обсуждали широкий список тем, включая будущее языков программирования, разработки в целом, как дела в Stripe и не только:) Основные идеи как обычно я привел ниже
1. Эксперименты с Smalltalk и Lisp
Первый стартап Патрика был написан на Smalltalk, который предлагал интерактивную среду разработки с возможностью редактирования кода в режиме реального времени. Найм сотрудников не был проблемой - умные люди быстро изучают новые языки. На Lisp Патрик делал бота для MSN Messenger с использованием байесовского предсказателя (он мог болтать с людьми). Также он экспериментировал с генетическими алгоритмами для оптимизации раскладки клавиатуры (подтвердил эффективность Dvorak). Но все эти side-проекты были далеки от текущих возможностей AI
2. Философия программирования и сред разработки
Патрик выступает за объединение времени выполнения, редактирования текста и среды исполнения кода. В качестве примера он упоминает Mathematica (сейчас это просто Wolfram). Патрик хочет в IDE видеть информацию профилирования при наведении курсора на код, а также logs и error messages. Здесь Патрик вспоминает еще некомерческую компанию Dynamicland, что занимается пространственными вычислениями. Он восхищается работой Брета Виктора в этой компании, но он не уверен, что этот подход применим к произвольным системам.
3. Технические решения в Stripe
Здесь Патрик обсуждает влияние закон Конвея на архитектуру, подчеркивая важность API и моделей данных для формирования организации. Странно, что Патрик при этом вспоминает про экосистему iOS и говорит, что она превосходит Android благодаря лучшему дизайну API - как по мне, экосистема iOS выглядит хорошо для потребителя, а инженерно это просто дно.
4.Выбор технологий
MongoDB и Ruby остаются фундаментальными технологиями Stripe с 2010 года (для меня это legaсу технологии ). Правда, ребята переписали часть сервисов на Java для повышения производительности. Интересно, что в 2022 году стартанул масштабный проект по унификации абстракций Stripe API v2, который сейчас постепенно выкатывается на прод. Патрик достаточно подробно рассказывает про сложности больших миграций
5. Будущее программирования с AI
Патрик использует LLM в основном для фактических вопросов и программирования через Cursor. А дальше своим видением делился Майкл, что разраатываевает Cursor
- Языки программирования могут стать менее формальными и более ориентированными на результат
- AI может помочь в рефакторинге кодовых баз и улучшении архитектуры
- Cursor планирует создать более интегрированную среду разработки с AI в фоновом режиме
6. Экономические аспекты и исследования прогресса
Здесь ребята обсужали разные тезисы и мнения, забавно, что касались и whitepaper "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", но Патрик его еще не успел изучить (а я уже изучил и разобрал для вас: 1 и 2). Если суммировать их мысли, то пока нет чётких доказательств роста производительности от LLM
7. Исследования прогресса и пример с биомедициной
Патрик считает, что потребность в исследованиях прогресса возросла из-за увеличения степеней свободы. Например, Патрик соосновал Arc Institute в 2021 году для биомедицинских исследований. Они работают над базовыми моделями для биологии с использованием ДНК, а также пытаются создать виртуальную клетку для понимания сложных заболеваний, чтобы бороться со сложными заболеваниями типа рака и нейродегенерации
В общем, это интервью показалось мне очень интересным - много футуристичных тем и идей было затронуто, а также были рассмотрены приземленные вопросы вокруг Stripe и Cursor.
#AI #ML #Management #Leadership #Software #SoftwareDevelopment #Architecture #Processes
Посмотрел на выходных интересное интервью Патрика Коллинсона, со-основателя Stripe и энтузиаста языков программированния. Это интервью у него брал Майкл Трюэлл, сооснователь и генеральный директор Anysphere, компании, которая создала Cursor. Ребята обсуждали широкий список тем, включая будущее языков программирования, разработки в целом, как дела в Stripe и не только:) Основные идеи как обычно я привел ниже
1. Эксперименты с Smalltalk и Lisp
Первый стартап Патрика был написан на Smalltalk, который предлагал интерактивную среду разработки с возможностью редактирования кода в режиме реального времени. Найм сотрудников не был проблемой - умные люди быстро изучают новые языки. На Lisp Патрик делал бота для MSN Messenger с использованием байесовского предсказателя (он мог болтать с людьми). Также он экспериментировал с генетическими алгоритмами для оптимизации раскладки клавиатуры (подтвердил эффективность Dvorak). Но все эти side-проекты были далеки от текущих возможностей AI
2. Философия программирования и сред разработки
Патрик выступает за объединение времени выполнения, редактирования текста и среды исполнения кода. В качестве примера он упоминает Mathematica (сейчас это просто Wolfram). Патрик хочет в IDE видеть информацию профилирования при наведении курсора на код, а также logs и error messages. Здесь Патрик вспоминает еще некомерческую компанию Dynamicland, что занимается пространственными вычислениями. Он восхищается работой Брета Виктора в этой компании, но он не уверен, что этот подход применим к произвольным системам.
3. Технические решения в Stripe
Здесь Патрик обсуждает влияние закон Конвея на архитектуру, подчеркивая важность API и моделей данных для формирования организации. Странно, что Патрик при этом вспоминает про экосистему iOS и говорит, что она превосходит Android благодаря лучшему дизайну API - как по мне, экосистема iOS выглядит хорошо для потребителя, а инженерно это просто дно.
4.Выбор технологий
MongoDB и Ruby остаются фундаментальными технологиями Stripe с 2010 года (
5. Будущее программирования с AI
Патрик использует LLM в основном для фактических вопросов и программирования через Cursor. А дальше своим видением делился Майкл, что разраатываевает Cursor
- Языки программирования могут стать менее формальными и более ориентированными на результат
- AI может помочь в рефакторинге кодовых баз и улучшении архитектуры
- Cursor планирует создать более интегрированную среду разработки с AI в фоновом режиме
6. Экономические аспекты и исследования прогресса
Здесь ребята обсужали разные тезисы и мнения, забавно, что касались и whitepaper "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", но Патрик его еще не успел изучить (а я уже изучил и разобрал для вас: 1 и 2). Если суммировать их мысли, то пока нет чётких доказательств роста производительности от LLM
7. Исследования прогресса и пример с биомедициной
Патрик считает, что потребность в исследованиях прогресса возросла из-за увеличения степеней свободы. Например, Патрик соосновал Arc Institute в 2021 году для биомедицинских исследований. Они работают над базовыми моделями для биологии с использованием ДНК, а также пытаются создать виртуальную клетку для понимания сложных заболеваний, чтобы бороться со сложными заболеваниями типа рака и нейродегенерации
В общем, это интервью показалось мне очень интересным - много футуристичных тем и идей было затронуто, а также были рассмотрены приземленные вопросы вокруг Stripe и Cursor.
#AI #ML #Management #Leadership #Software #SoftwareDevelopment #Architecture #Processes
YouTube
Patrick Collison on programming languages, AI, and Stripe's biggest engineering decisions
Michael Truell (CEO of Cursor) sits down with Patrick Collison (CEO of Stripe) to discuss programming languages, the role of AI in programming, and building long-lasting software.
00:00 Patrick's first startup in Smalltalk
03:35 LISP chatbots
06:09 Ideas…
00:00 Patrick's first startup in Smalltalk
03:35 LISP chatbots
06:09 Ideas…
👍8❤4🔥3
Does AI Actually Boost Developer Productivity? (100k Devs Study) (Рубрика #AI)
Посмотрел интересное 20 минутное выступление Yegor Denisov-Blanch из Stanford University про измерение продуктивности инженеров. Егор представил результаты трёхлетнего исследования Стэнфорда по производительности 100k разработчиков из 600 компаний. Результаты исследования такие: AI повышает продуктивность в среднем лишь на 15-20%, причём эффект резко варьируется в зависимости от контекста задачи, зрелости кода, популярности языка и размера репозитория. Ниже представлены основные мысли из этого выступления + странички исследования
1. Почему существующие оценки продуктивности ненадёжны?
- Большинство опубликованных работ финансируются поставщиками инструментов (GitHub Copilot, Sourcegraph Cody), что искажает выборку и метрики.
- Фокус на счётчике коммитов/PR без учёта размера и качества задач приводит к ложному росту "output" (условно у нас больше выход кода, но вот насколько он полезен?)
- Оценки greenfield и игрушечных проектов завышают выгоду ИИ: LLM легко сгенерирует boilerplate, но реальный корпоративный код редко стартует с нуля
- У опросов насчет продуктивности есть проблемы - самооценка продуктивности редко бывает точной, хотя другие факторы типа satisfaction или well-being опросами можно собрать хорошо
2. Как выглядела методология ребят из Stanford?
- Подключение git-репозиториев, среди которых были преимущественно частные репо, это позволяло замкнуть контекст команды
- Оценка кода группой экспертов, где 10-15 архитекторов ставят баллы за качество, поддерживаемость, сложности (кстати, их оценки хорошо кореллировали между собой) - по-факту, это создание разметки для дальнейшего supervised learning
- Обучение модели для воспроизведения экспертной оценки с высокой корреляцией для оцененой экспертами выборки проектов - это позволяет дальше масштабировать эту модель без дорогостоящего ревью
- Классификация изменений - авторы хотели классифицировать изменения на группы "добавление функционала", "удаление", "рефакторинг", "rework" (переделка свежего кода)
- Дальше эту модель применять ретроспективно с 2019 по 2025 год для того, чтобы отследить влияние COVID, LLM-внедрения и т.д
3. Главные численные выводы исследования
- Сырой прирост кода после внедрения ИИ +30-40% - это включает полезный и «rework»-объём
- Уточнённый прирост продуктивности +15-20% - это с поправкой на баг-фиксы
- На сложных задачах прирост чуть больше 0% с большой дисперсией (иногда вместо прироста убыль)
- Если это представлять в виде матрицы 2x2,как любят консультанты , то получим "сложность задачи× зрелость проекта"
- На эффективность влияет размер кодовой базы, причем выгода падает логарифмически с ростом объема. Гипотеза в том, что на это влияет ограничения контекстного окна LLM, рост шума и большого количества зависимостей внутри кода (coupling)
Если попробовать вынести практические советы, то они кажутся такими
- Оцените типовую сложность и зрелость своего проекта перед масштабным внедрением LLM-ассистентов
- Старайтесь использовать популярные технологии - по ним обучены лучшие модели и качество подсказок выше
- Для legacy-монолитов проведите пилот на небольших модулях - продуктивность может не повышаться при использовании ассистентов из коробки (аля базовый Cursor)
- Мониторьте "rework"-долю: резкий рост количества кода может создавать иллюзию продуктивности
- Комбинируйте количественный git-анализ с качественным ревью, а не ссылайтесь только на "опрос удовлетворённости команды"
P.S.
Yegor Denisov-Blanch является автором исследования про "ghost" разработчиков, что нашумело в прошлом году. Правда, самого исследования мне найти не удалось, зато есть посты о нем в большом количестве мест.
P.P.S.
Сравните с дизайном эксперимента от METR:)
#Engineering #AI #Metrics #Software #DevEx #Productivity
Посмотрел интересное 20 минутное выступление Yegor Denisov-Blanch из Stanford University про измерение продуктивности инженеров. Егор представил результаты трёхлетнего исследования Стэнфорда по производительности 100k разработчиков из 600 компаний. Результаты исследования такие: AI повышает продуктивность в среднем лишь на 15-20%, причём эффект резко варьируется в зависимости от контекста задачи, зрелости кода, популярности языка и размера репозитория. Ниже представлены основные мысли из этого выступления + странички исследования
1. Почему существующие оценки продуктивности ненадёжны?
- Большинство опубликованных работ финансируются поставщиками инструментов (GitHub Copilot, Sourcegraph Cody), что искажает выборку и метрики.
- Фокус на счётчике коммитов/PR без учёта размера и качества задач приводит к ложному росту "output" (условно у нас больше выход кода, но вот насколько он полезен?)
- Оценки greenfield и игрушечных проектов завышают выгоду ИИ: LLM легко сгенерирует boilerplate, но реальный корпоративный код редко стартует с нуля
- У опросов насчет продуктивности есть проблемы - самооценка продуктивности редко бывает точной, хотя другие факторы типа satisfaction или well-being опросами можно собрать хорошо
2. Как выглядела методология ребят из Stanford?
- Подключение git-репозиториев, среди которых были преимущественно частные репо, это позволяло замкнуть контекст команды
- Оценка кода группой экспертов, где 10-15 архитекторов ставят баллы за качество, поддерживаемость, сложности (кстати, их оценки хорошо кореллировали между собой) - по-факту, это создание разметки для дальнейшего supervised learning
- Обучение модели для воспроизведения экспертной оценки с высокой корреляцией для оцененой экспертами выборки проектов - это позволяет дальше масштабировать эту модель без дорогостоящего ревью
- Классификация изменений - авторы хотели классифицировать изменения на группы "добавление функционала", "удаление", "рефакторинг", "rework" (переделка свежего кода)
- Дальше эту модель применять ретроспективно с 2019 по 2025 год для того, чтобы отследить влияние COVID, LLM-внедрения и т.д
3. Главные численные выводы исследования
- Сырой прирост кода после внедрения ИИ +30-40% - это включает полезный и «rework»-объём
- Уточнённый прирост продуктивности +15-20% - это с поправкой на баг-фиксы
- На сложных задачах прирост чуть больше 0% с большой дисперсией (иногда вместо прироста убыль)
- Если это представлять в виде матрицы 2x2,
Complexity/Type. Greenfield Brownfield- На эффективность влияет язык - для популярных языков LLM работают лучше, а для эзотерических хуже.
Low-complexity 30-40% выгод 15-20% выгод
High-complexity 10-15% выгод 0-10% выгод, иногда убыток
- На эффективность влияет размер кодовой базы, причем выгода падает логарифмически с ростом объема. Гипотеза в том, что на это влияет ограничения контекстного окна LLM, рост шума и большого количества зависимостей внутри кода (coupling)
Если попробовать вынести практические советы, то они кажутся такими
- Оцените типовую сложность и зрелость своего проекта перед масштабным внедрением LLM-ассистентов
- Старайтесь использовать популярные технологии - по ним обучены лучшие модели и качество подсказок выше
- Для legacy-монолитов проведите пилот на небольших модулях - продуктивность может не повышаться при использовании ассистентов из коробки (аля базовый Cursor)
- Мониторьте "rework"-долю: резкий рост количества кода может создавать иллюзию продуктивности
- Комбинируйте количественный git-анализ с качественным ревью, а не ссылайтесь только на "опрос удовлетворённости команды"
P.S.
Yegor Denisov-Blanch является автором исследования про "ghost" разработчиков, что нашумело в прошлом году. Правда, самого исследования мне найти не удалось, зато есть посты о нем в большом количестве мест.
P.P.S.
Сравните с дизайном эксперимента от METR:)
#Engineering #AI #Metrics #Software #DevEx #Productivity
YouTube
Does AI Actually Boost Developer Productivity? (100k Devs Study) - Yegor Denisov-Blanch, Stanford
Forget vendor hype: Is AI actually boosting developer productivity, or just shifting bottlenecks? Stop guessing.
Our study at Stanford cuts through the noise, analyzing real-world productivity data from nearly 100,000 developers across hundreds of companies.…
Our study at Stanford cuts through the noise, analyzing real-world productivity data from nearly 100,000 developers across hundreds of companies.…
👍7❤6🔥2
Small AI Teams with Huge Impact (Рубрика #AI)
Посмотрел на выходных интересное выступление Викаса Паручури, основателя и генерального директора Datalab, компании, специализирующейся на создании ИИ-моделей для анализа документов. В своем выступлении Викас делится старой истиной о том, что лучше меньше, да лучше, причем это работает с AI командами:) А если серьезно, то вот основные мысли выступления
1. Философия малых команд
Паручури представил радикальную идею о том, что количество сотрудников не равно продуктивности. Он поделился опытом своей предыдущей компании Dataquest, где после двух раундов увольнений (с 30 до 15, затем до 7 человек) производительность и удовлетворённость сотрудников парадоксально выросли.
2. Проблемы больших команд
Викас выделил четыре основные проблемы, возникающие при масштабировании (sad but true)
- Специализация - узкие специалисты не могут гибко решать ключевые проблемы компании
- Процессная нагрузка - удалённая работа требует множества синхронизаций и встреч
- Перегрузка встречами - особенно с появлением среднего менеджмента
- Неэффективное использование senior-сотрудников - они тратят время на управление junior-персоналом
3. Философия Джереми Ховарда
Паручури поделился подходом Джереми Ховарда из Answer.AI. Суть в том, чтобы нанимать менее 15 универсальных специалистов, заполнять пробелы с помощью ИИ и внутренних инструментов, использовать простые технологии. Этот подход требует высокой культурной планки, доверия и фокуса на клиентах.
4. Практический пример: модель Surya OCR
Datalab обучила модель Surya OCR с 500 миллионами параметров, поддерживающую 90 языков с точностью 99%. Весь процесс — от общения с клиентами до интеграции в продукты - выполняли всего два человека, что в крупной компании потребовало бы несколько команд.
5. Принципы работы малых команд
5.1 Найм и культура
- Нанимать senior-универсалов (зрелость важнее опыта)
- Избегать переусложнения
- Работать лично для быстрой коллаборации
- Платить зарплаты выше рынка
- Минимальное эго, фокус на результат
5.2 Архитектура и процессы
- Агрессивное переиспользование компонентов
- Простые технологии (без React, серверный HTML с HTMX)
- Модульный код, понятный для ИИ
- Минимальная бюрократия, высокое доверие
В итоге, в Datalab команда из 4 человек достигла семизначного годового дохода (ARR) с ростом в 5 раз за 2025 год. Компания недавно привлекла seed-раунд в размере $3,5 млн от основателей OpenAI, FAIR и Hugging Face. Клиентами являются AI-лаборатории первого уровня, университеты, Fortune 500 и правительства. Отдельно Викас рассказал про их процесс найма из трех этапов
- Беседа с коллегой - обсуждение реальной проблемы
- Платный проект - 10 часов работы за $1000
- Культурное соответствие (cultural fit) - оценка совместимости
Интересно, что в этот процесс уже попадают кандидаты, что с высокой вероятностью подходят компании.
Если кратко, то Викас неплохо показал как собирать мобильную и перформящую команду для стартапа, где ключ к успеху — правильные люди, простые процессы и умелое использование ИИ для автоматизации рутинных задач
#AI #Leadership #Engineering #Software #Processes #Productivity
Посмотрел на выходных интересное выступление Викаса Паручури, основателя и генерального директора Datalab, компании, специализирующейся на создании ИИ-моделей для анализа документов. В своем выступлении Викас делится старой истиной о том, что лучше меньше, да лучше, причем это работает с AI командами:) А если серьезно, то вот основные мысли выступления
1. Философия малых команд
Паручури представил радикальную идею о том, что количество сотрудников не равно продуктивности. Он поделился опытом своей предыдущей компании Dataquest, где после двух раундов увольнений (с 30 до 15, затем до 7 человек) производительность и удовлетворённость сотрудников парадоксально выросли.
2. Проблемы больших команд
Викас выделил четыре основные проблемы, возникающие при масштабировании (sad but true)
- Специализация - узкие специалисты не могут гибко решать ключевые проблемы компании
- Процессная нагрузка - удалённая работа требует множества синхронизаций и встреч
- Перегрузка встречами - особенно с появлением среднего менеджмента
- Неэффективное использование senior-сотрудников - они тратят время на управление junior-персоналом
3. Философия Джереми Ховарда
Паручури поделился подходом Джереми Ховарда из Answer.AI. Суть в том, чтобы нанимать менее 15 универсальных специалистов, заполнять пробелы с помощью ИИ и внутренних инструментов, использовать простые технологии. Этот подход требует высокой культурной планки, доверия и фокуса на клиентах.
4. Практический пример: модель Surya OCR
Datalab обучила модель Surya OCR с 500 миллионами параметров, поддерживающую 90 языков с точностью 99%. Весь процесс — от общения с клиентами до интеграции в продукты - выполняли всего два человека, что в крупной компании потребовало бы несколько команд.
5. Принципы работы малых команд
5.1 Найм и культура
- Нанимать senior-универсалов (зрелость важнее опыта)
- Избегать переусложнения
- Работать лично для быстрой коллаборации
- Платить зарплаты выше рынка
- Минимальное эго, фокус на результат
5.2 Архитектура и процессы
- Агрессивное переиспользование компонентов
- Простые технологии (без React, серверный HTML с HTMX)
- Модульный код, понятный для ИИ
- Минимальная бюрократия, высокое доверие
В итоге, в Datalab команда из 4 человек достигла семизначного годового дохода (ARR) с ростом в 5 раз за 2025 год. Компания недавно привлекла seed-раунд в размере $3,5 млн от основателей OpenAI, FAIR и Hugging Face. Клиентами являются AI-лаборатории первого уровня, университеты, Fortune 500 и правительства. Отдельно Викас рассказал про их процесс найма из трех этапов
- Беседа с коллегой - обсуждение реальной проблемы
- Платный проект - 10 часов работы за $1000
- Культурное соответствие (cultural fit) - оценка совместимости
Интересно, что в этот процесс уже попадают кандидаты, что с высокой вероятностью подходят компании.
Если кратко, то Викас неплохо показал как собирать мобильную и перформящую команду для стартапа, где ключ к успеху — правильные люди, простые процессы и умелое использование ИИ для автоматизации рутинных задач
#AI #Leadership #Engineering #Software #Processes #Productivity
YouTube
Small AI Teams with Huge Impact — Vik Paruchuri, Datalab
We scaled Datalab 5x this year - to 7-figure ARR, with customers that include tier 1 AI labs. We train custom models for document intelligence (OCR, layout), with popular repos surya and marker.
I'll talk about a new approach to building AI teams, including…
I'll talk about a new approach to building AI teams, including…
🔥15❤9👍6
Да будет свет... и тепло! Сколько стоит энергия (Рубрика #PopularScience)
В наше время роста AI технологий и связанного с этим взрывного увеличения энергопотребления, понимание принципов работы электросетей стало необходимостью ... поэтому я решил прочитать научно-популярную книгу Андрея Косько на эту тему. Книга была опубликована в далеком 2019 году, когда AI датацентры еще не были на повестке дня, но ее актуальность только стала выше. Так как это научпоп, то книга на пальцах отвечает на вопросы вида
- Что представляет собой энергия и откуда она берется?
- Когда на самом деле закончится нефть?
- Пересядем ли мы в электроавтомобили с солнечными панелями?
- Что такое атомная и возобновляемая энергетика
- Насколько реально глобальное потепление и какие бывают энергетические кризисы
Интересно, что после выпуска первой книги Андрей написал продолжение "Большая энергетика. Что почем и как с этим жить?", которая была опубликована в 2022 году (я заказал ее себе после прочтения первой книги).
Если выделить ключевые идеи, полезные для технических руководителей, то они такие
1. Основы энергосистем
Автор систематично объясняет базовые принципы работы электросетей, которые критически важны для понимания инфраструктурных ограничений.
- Балансировка спроса и предложения: ключевая задача управления любой электросетью - постоянное поддержание баланса между производством и потреблением энергии. Любые дисбалансы вызывают серьезные проблемы, которые обычно проявляются в изменении частоты сети. Когда частота внезапно повышается или понижается, это может привести к повреждению электрооборудования и, в конечном итоге, к отключениям электроэнергии.
- Трехуровневая структура электросистемы: генерация, передача энергии и ее распределения. Автор интересно объясняет как это работает в масштабе.
2. Вызовы для электросетей от AI нагрузок
- Нестабильность потребления: AI workloads (особенно deep learning) могут создавать колебания мощности в сотни мегаватт в течение секунд. Эти быстрые изменения в спросе создают уникальные проблемы для операторов сетей.
- Ограничения сетевой инфраструктуры: большинство линий передачи в США старше 25 лет, а 70% приближаются к концу своего полезного срока службы. Отключения электроэнергии и связанные с ними проблемы становятся все более частыми из-за устаревшей инфраструктуры. В России вроде с этим тоже есть проблемы
3. Планирование инфраструктуры
- Выбор локации дата-центров: понимание региональных ограничений электросетей становится критически важным. Некоторые регионы могут испытывать давление и сталкиваться с потенциальным дефицитом резервов. Интересно, что не всегда просто унести рабочие нагрузки к дешевому электричеству, но те, у кого получается получают конкуретные преимущества (вспоминаем майнеров)
- Понимание smart grid технологий: они позволяют управлять потреблением электричества для сдвига наиболее ресурсоемких задач на периоды низкого спроса, что может привести к экономии эффективности и снижению нагрузки на энергосистемы.
В общем, это интересный топик для изучения хотя бы в таком научно-популярном виде.
#PopularScience #Physics #Engineering
В наше время роста AI технологий и связанного с этим взрывного увеличения энергопотребления, понимание принципов работы электросетей стало необходимостью ... поэтому я решил прочитать научно-популярную книгу Андрея Косько на эту тему. Книга была опубликована в далеком 2019 году, когда AI датацентры еще не были на повестке дня, но ее актуальность только стала выше. Так как это научпоп, то книга на пальцах отвечает на вопросы вида
- Что представляет собой энергия и откуда она берется?
- Когда на самом деле закончится нефть?
- Пересядем ли мы в электроавтомобили с солнечными панелями?
- Что такое атомная и возобновляемая энергетика
- Насколько реально глобальное потепление и какие бывают энергетические кризисы
Интересно, что после выпуска первой книги Андрей написал продолжение "Большая энергетика. Что почем и как с этим жить?", которая была опубликована в 2022 году (я заказал ее себе после прочтения первой книги).
Если выделить ключевые идеи, полезные для технических руководителей, то они такие
1. Основы энергосистем
Автор систематично объясняет базовые принципы работы электросетей, которые критически важны для понимания инфраструктурных ограничений.
- Балансировка спроса и предложения: ключевая задача управления любой электросетью - постоянное поддержание баланса между производством и потреблением энергии. Любые дисбалансы вызывают серьезные проблемы, которые обычно проявляются в изменении частоты сети. Когда частота внезапно повышается или понижается, это может привести к повреждению электрооборудования и, в конечном итоге, к отключениям электроэнергии.
- Трехуровневая структура электросистемы: генерация, передача энергии и ее распределения. Автор интересно объясняет как это работает в масштабе.
2. Вызовы для электросетей от AI нагрузок
- Нестабильность потребления: AI workloads (особенно deep learning) могут создавать колебания мощности в сотни мегаватт в течение секунд. Эти быстрые изменения в спросе создают уникальные проблемы для операторов сетей.
- Ограничения сетевой инфраструктуры: большинство линий передачи в США старше 25 лет, а 70% приближаются к концу своего полезного срока службы. Отключения электроэнергии и связанные с ними проблемы становятся все более частыми из-за устаревшей инфраструктуры. В России вроде с этим тоже есть проблемы
3. Планирование инфраструктуры
- Выбор локации дата-центров: понимание региональных ограничений электросетей становится критически важным. Некоторые регионы могут испытывать давление и сталкиваться с потенциальным дефицитом резервов. Интересно, что не всегда просто унести рабочие нагрузки к дешевому электричеству, но те, у кого получается получают конкуретные преимущества (вспоминаем майнеров)
- Понимание smart grid технологий: они позволяют управлять потреблением электричества для сдвига наиболее ресурсоемких задач на периоды низкого спроса, что может привести к экономии эффективности и снижению нагрузки на энергосистемы.
В общем, это интересный топик для изучения хотя бы в таком научно-популярном виде.
#PopularScience #Physics #Engineering
❤5👍4🔥3
Иллюстрации для книги "Да будет свет... и тепло! Сколько стоит энергия"
🔥11👍5❤3
Measuring the impact of AI on software engineering (Рубрика #AI)
Посмотрел очередную серию подкаста "The Pragmatic Engineer", который ведет Гергели Орош (Gergely Orosz). К нему в гости пришла Лаура Тако (Laura Tacho), технический директор платформы для измерения продуктивности инженеров DX. Интересно, что мы только недавно с Женей Сергеевым, engineering director из Flo Health, разбирали в подкасте Research Insights Made Simple DX Core 4 фреймворк для измерения продуктивности, и новенький whitepaper "Measuring AI Code Assistants and Agents" тоже от платформы DX. Но если возвращаться к этому подкасту и его ключевым идеям, то вот они
1. Критика медийной шумихи вокруг ИИ
Лаура подчеркивает, что большинство медийных заголовков об ИИ крайне преувеличены и вводят в заблуждение. Они не подтверждаются реальными данными из сотен компаний, с которыми работает DX. Основные проблемы с такими новостями такие
- Упрощение сложных инженерных процессов до неузнаваемости (работа инженеров не только в написании кода)
- Смешивание показателя "принятия AI suggests" с "кодом, написанным AI"
2. Фреймворк DX AI для измерения влияния ИИ
Лаура представила фреймворк для измерения влияния AI (я его уже разбирал). В нем есть три вида параметров, которые перечислены в порядке простоты измерений
- Утилизация (Utilization) - как активно используются инструменты
- Влияние (Impact) - какое реальное воздействие на производительность
- Стоимость (Cost) - экономическая эффективность внедрения
3. Реальные данные об использовании ИИ-инструментов
Исследование DX на основе 180+ компаний выявило наиболее эффективные сценарии использования ИИ разработчиками (в порядке убывания)
- Анализ трассировок стека
- Рефакторинг существующего кода
- Генерация кода в процессе разработки
- Генерация тестов
Этот результат противоречит общепринятому мнению о том, что ИИ прежде всего полезен для генерации нового кода.
4. Кейс-стади: Booking.com
Booking.com провел масштабное внедрение ИИ-инструментов с следующими результатами:
- 65% разработчиков используют инструменты еженедельно (выше среднего по отрасли в 50%)
- 16% повышение частоты слияния пул-реквестов у активных пользователей
- 31% рост производительности инженерных команд
Инвестиции в обучение и поддержку оказались критически важными для успеха
5. Парадокс удовлетворенности разработчиков
Одно из самых неожиданных открытий исследования DORA: многие разработчики сообщают о снижении времени на meaningful задачи
Причина: ИИ ускоряет те части работы, которые разработчикам нравятся (написание кода), оставляя больше времени на рутину, встречи и административные задачи.
Кстати, дальше у меня будет целая серия постов про DORA, где я подробнее расскажу про исследования и инсайты из них
6. Влияние на архитектуру и документацию
Команды, успешно внедряющие ИИ, вносят архитектурные изменения:
- Возврат к чистым интерфейсам между сервисами
- Создание документации, ориентированной на ИИ (с примерами кода, без визуальных зависимостей)
Компании вроде Vercel и Clerk создают "AI-first" документацию, которая работает как для людей, так и для ИИ-ассистентов
7. Структурированные подходы к внедрению
Высокорегулируемые отрасли (финансы, страхование) показывают лучшие результаты благодаря структурированному подходу к внедрению ИИ.
8. Рекомендации для технических лидеров
Лаура дает следующие советы руководителям:
- Данные важнее ажиотажа - основывайтесь на фактах, а не на медийных заголовках
- Рассматривайте использование ИИ как эксперимент - оценивайте эффективность систематически
- Инвестируйте в обучение и поддержку - это критично для успешного внедрения
- Измеряйте опыт разработчиков до внедрения ИИ - это создает baseline для сравнения
9. Будущее разработки с ИИ
Лаура предсказывает, что дорожные карты (roadmaps) уходят в прошлое и команды переходят к более гибким, экспериментальным подходам для адаптации AI
Итого, Лаура вместе с Гергели очень интересно пообщались на тему влияния AI, фокусирясь на практике, а не маркетинговых заголовках:)
#AI #Software #Engineering #Management #Metrics #ML #Leadership
Посмотрел очередную серию подкаста "The Pragmatic Engineer", который ведет Гергели Орош (Gergely Orosz). К нему в гости пришла Лаура Тако (Laura Tacho), технический директор платформы для измерения продуктивности инженеров DX. Интересно, что мы только недавно с Женей Сергеевым, engineering director из Flo Health, разбирали в подкасте Research Insights Made Simple DX Core 4 фреймворк для измерения продуктивности, и новенький whitepaper "Measuring AI Code Assistants and Agents" тоже от платформы DX. Но если возвращаться к этому подкасту и его ключевым идеям, то вот они
1. Критика медийной шумихи вокруг ИИ
Лаура подчеркивает, что большинство медийных заголовков об ИИ крайне преувеличены и вводят в заблуждение. Они не подтверждаются реальными данными из сотен компаний, с которыми работает DX. Основные проблемы с такими новостями такие
- Упрощение сложных инженерных процессов до неузнаваемости (работа инженеров не только в написании кода)
- Смешивание показателя "принятия AI suggests" с "кодом, написанным AI"
2. Фреймворк DX AI для измерения влияния ИИ
Лаура представила фреймворк для измерения влияния AI (я его уже разбирал). В нем есть три вида параметров, которые перечислены в порядке простоты измерений
- Утилизация (Utilization) - как активно используются инструменты
- Влияние (Impact) - какое реальное воздействие на производительность
- Стоимость (Cost) - экономическая эффективность внедрения
3. Реальные данные об использовании ИИ-инструментов
Исследование DX на основе 180+ компаний выявило наиболее эффективные сценарии использования ИИ разработчиками (в порядке убывания)
- Анализ трассировок стека
- Рефакторинг существующего кода
- Генерация кода в процессе разработки
- Генерация тестов
Этот результат противоречит общепринятому мнению о том, что ИИ прежде всего полезен для генерации нового кода.
4. Кейс-стади: Booking.com
Booking.com провел масштабное внедрение ИИ-инструментов с следующими результатами:
- 65% разработчиков используют инструменты еженедельно (выше среднего по отрасли в 50%)
- 16% повышение частоты слияния пул-реквестов у активных пользователей
- 31% рост производительности инженерных команд
Инвестиции в обучение и поддержку оказались критически важными для успеха
5. Парадокс удовлетворенности разработчиков
Одно из самых неожиданных открытий исследования DORA: многие разработчики сообщают о снижении времени на meaningful задачи
Причина: ИИ ускоряет те части работы, которые разработчикам нравятся (написание кода), оставляя больше времени на рутину, встречи и административные задачи.
Кстати, дальше у меня будет целая серия постов про DORA, где я подробнее расскажу про исследования и инсайты из них
6. Влияние на архитектуру и документацию
Команды, успешно внедряющие ИИ, вносят архитектурные изменения:
- Возврат к чистым интерфейсам между сервисами
- Создание документации, ориентированной на ИИ (с примерами кода, без визуальных зависимостей)
Компании вроде Vercel и Clerk создают "AI-first" документацию, которая работает как для людей, так и для ИИ-ассистентов
7. Структурированные подходы к внедрению
Высокорегулируемые отрасли (финансы, страхование) показывают лучшие результаты благодаря структурированному подходу к внедрению ИИ.
8. Рекомендации для технических лидеров
Лаура дает следующие советы руководителям:
- Данные важнее ажиотажа - основывайтесь на фактах, а не на медийных заголовках
- Рассматривайте использование ИИ как эксперимент - оценивайте эффективность систематически
- Инвестируйте в обучение и поддержку - это критично для успешного внедрения
- Измеряйте опыт разработчиков до внедрения ИИ - это создает baseline для сравнения
9. Будущее разработки с ИИ
Лаура предсказывает, что дорожные карты (roadmaps) уходят в прошлое и команды переходят к более гибким, экспериментальным подходам для адаптации AI
Итого, Лаура вместе с Гергели очень интересно пообщались на тему влияния AI, фокусирясь на практике, а не маркетинговых заголовках:)
#AI #Software #Engineering #Management #Metrics #ML #Leadership
YouTube
Measuring the impact of AI on software engineering – with Laura Tacho
There’s no shortage of bold claims about AI and developer productivity, but how do you separate signal from noise?
In this episode of The Pragmatic Engineer, I’m joined by Laura Tacho, CTO at DX, to cut through the hype and share how well (or not) AI tools…
In this episode of The Pragmatic Engineer, I’m joined by Laura Tacho, CTO at DX, to cut through the hype and share how well (or not) AI tools…
6👍7🔥6❤3
[1/2] Как собираются отчеты DORA (DevOps Research and Assessment)?
Если вы опытный разработчик или технический руководитель, то с большой вероятностью вы слышали про магические DORA метрики, использование которых часто является baseline для оценки эффективности разработки. Но вы когда-нибудь интересовались откуда они появились и как собирается бенчмарк по группам эффективности? В общем, сегодня я решил поговорить об этом.
DORA (DevOps Research and Assessment) - это крупнейшее долгосрочное исследование в области оценки эффективности процессов разработки и эксплуатации ПО (в прошлом году ребята отмечали десятилетний юбилей). Каждый год команда DORA рассылает опросник профессионалам из технических и смежных областей. В 2024 году их было порядка 3 тысяч, причем топ-три представленные области это технологии (36%), финтех (16%) и ритейл (9%). Для большей репрезентативности выборки DORA ориентируется на отраслевые исследовательские базы (например, Stack Overflow Developer Survey) и старается охватить максимально разнообразные команды, типы организаций и географии (в самом отчете есть отсылка, что распределение участников DORA опроса похоже на распределение опроса от Stack Overflow).
В отчете 2024 года есть подробное описание методологии, проверяемых моделей, а также задаваемых вопросов. Кстати, с 2023 года авторы ушли от одной большой модели к нескольким маленьким, где проще строить взаимосвязи между факторами и проверять их корелляции. Для анализа результатов используется кластерный анализ: ответы респондентов группируются по четырем ключевым производственным метрикам: change lead time, deployment frequency, change failure rate, failed deployment recovery time. Сами кластеры формируются на основе собранных данных без заранее заданных "идеальных" значений: например, границы между группами (low, medium, high, elite) каждый год меняются, потому что определяются статистической обработкой свежих данных.
Продолжение в следующем посте.
#AI #DevOps #DevEx #Metrics #Processes #Management
Если вы опытный разработчик или технический руководитель, то с большой вероятностью вы слышали про магические DORA метрики, использование которых часто является baseline для оценки эффективности разработки. Но вы когда-нибудь интересовались откуда они появились и как собирается бенчмарк по группам эффективности? В общем, сегодня я решил поговорить об этом.
DORA (DevOps Research and Assessment) - это крупнейшее долгосрочное исследование в области оценки эффективности процессов разработки и эксплуатации ПО (в прошлом году ребята отмечали десятилетний юбилей). Каждый год команда DORA рассылает опросник профессионалам из технических и смежных областей. В 2024 году их было порядка 3 тысяч, причем топ-три представленные области это технологии (36%), финтех (16%) и ритейл (9%). Для большей репрезентативности выборки DORA ориентируется на отраслевые исследовательские базы (например, Stack Overflow Developer Survey) и старается охватить максимально разнообразные команды, типы организаций и географии (в самом отчете есть отсылка, что распределение участников DORA опроса похоже на распределение опроса от Stack Overflow).
В отчете 2024 года есть подробное описание методологии, проверяемых моделей, а также задаваемых вопросов. Кстати, с 2023 года авторы ушли от одной большой модели к нескольким маленьким, где проще строить взаимосвязи между факторами и проверять их корелляции. Для анализа результатов используется кластерный анализ: ответы респондентов группируются по четырем ключевым производственным метрикам: change lead time, deployment frequency, change failure rate, failed deployment recovery time. Сами кластеры формируются на основе собранных данных без заранее заданных "идеальных" значений: например, границы между группами (low, medium, high, elite) каждый год меняются, потому что определяются статистической обработкой свежих данных.
Продолжение в следующем посте.
#AI #DevOps #DevEx #Metrics #Processes #Management
❤6🔥3👍2
The Software Engineer's Guidebook (Разработчик ПО: Путеводитель по карьерной лестнице для будущих сеньоров, техлидов и стаффов)
Сегодня мне пришла книга Gergely Orosz, известного инженера и автора "The Pragmatic Engineer", самого популярного технического новостного бюллетеня на Substack, посвящённого вопросам инженерных команд, управления, технологий и карьерного развития в IT. Вообще, от книги я ожидаю много, так как мне нравится материалы Гергели - я смотрел большое количество интервью и выступлений Gergely, о которых рассказывал в канале раньше
- Интервью с James Stanier, автором книги "Become an Effective Software Engineering Manager" в рамках книжного клуба goto
- Выступление на LeadDev с докладом "Software engineering with LLMs in 2025: reality check"
- Интервью с Farhan Thawar, head of engineering в Shopify "How AI is changing software engineering at Shopify"
- Интервью со Steve Huynh, бывший principal инженер Amazon "What is a Principal Engineer at Amazon"
- Интервью с Лаурой Тако, CTO платформы DX "Measuring the impact of AI on software engineering"
Как прочту книгу, поделюсь своими впечатлениями.
#Engineering #Management #Leadership #Processes #Software #Career #Staff
Сегодня мне пришла книга Gergely Orosz, известного инженера и автора "The Pragmatic Engineer", самого популярного технического новостного бюллетеня на Substack, посвящённого вопросам инженерных команд, управления, технологий и карьерного развития в IT. Вообще, от книги я ожидаю много, так как мне нравится материалы Гергели - я смотрел большое количество интервью и выступлений Gergely, о которых рассказывал в канале раньше
- Интервью с James Stanier, автором книги "Become an Effective Software Engineering Manager" в рамках книжного клуба goto
- Выступление на LeadDev с докладом "Software engineering with LLMs in 2025: reality check"
- Интервью с Farhan Thawar, head of engineering в Shopify "How AI is changing software engineering at Shopify"
- Интервью со Steve Huynh, бывший principal инженер Amazon "What is a Principal Engineer at Amazon"
- Интервью с Лаурой Тако, CTO платформы DX "Measuring the impact of AI on software engineering"
Как прочту книгу, поделюсь своими впечатлениями.
#Engineering #Management #Leadership #Processes #Software #Career #Staff
👍23🔥12❤7
Code of Leadership #46 Interview with Vladimir Kalugin about Platform Engineering (Рубрика #Management)
В очередном выпуске подкаста ко мне пришел интересный гость, Владимир Калугин, технический продакт менеджер в Т-Банке, что отвечает за развитие IDP (внутренней платформы разработки) и точнее за developer experience. До Т-Банка Владимир успел поработать в Туту.ру, Тинькофф, МТС Тревел. За два часа мы обсудили много вопросов, среди которых основные указаны ниже
- Знакомство с гостем, обсуждение образования и выбора IT
- Важность фундаментальных знаний для IT
- Карьерный рост: разработчик → тимлид → менеджер
- Принципы компании и корпоративная культура
- Работа над мультимодальными перевозками и технические решения в Tutu
- Смена работы, поиски и мотивация
- Платформа «Спирит» и платформ инжиниринг
- Интеграции, архитектурные решения и развитие платформ
- Переход в МТС, запуск нового travel-продукта
- Контент, агрегация и масштабирование продукта
- Бюрократия и взаимодействие с архитекторами в крупных компаниях (на примере МТС)
- Метрики, данные и улучшение платформ
- Физический и ментальный баланс, лайфхаки для продуктивности
- Советы по развитию и заключение
Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.
#Software #Engineering #Management #Architecture #Processes
В очередном выпуске подкаста ко мне пришел интересный гость, Владимир Калугин, технический продакт менеджер в Т-Банке, что отвечает за развитие IDP (внутренней платформы разработки) и точнее за developer experience. До Т-Банка Владимир успел поработать в Туту.ру, Тинькофф, МТС Тревел. За два часа мы обсудили много вопросов, среди которых основные указаны ниже
- Знакомство с гостем, обсуждение образования и выбора IT
- Важность фундаментальных знаний для IT
- Карьерный рост: разработчик → тимлид → менеджер
- Принципы компании и корпоративная культура
- Работа над мультимодальными перевозками и технические решения в Tutu
- Смена работы, поиски и мотивация
- Платформа «Спирит» и платформ инжиниринг
- Интеграции, архитектурные решения и развитие платформ
- Переход в МТС, запуск нового travel-продукта
- Контент, агрегация и масштабирование продукта
- Бюрократия и взаимодействие с архитекторами в крупных компаниях (на примере МТС)
- Метрики, данные и улучшение платформ
- Физический и ментальный баланс, лайфхаки для продуктивности
- Советы по развитию и заключение
Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.
#Software #Engineering #Management #Architecture #Processes
YouTube
Code of Leadership #46 Interview with Vladimir Kalugin about Platform Engineering
В очередном выпуске подкаста ко мне пришел интересный гость, Владимир Калугин, технический продакт менеджер в Т-Банке, что отвечает за развитие IDP (внутренней платформы разработки) и точнее за developer experience. До Т-Банка Владимир успел поработать в…
1❤6👍3🔥1
[2/2] Как собираются отчеты DORA (DevOps Research and Assessment)?
Продолжая рассказ про методологию DORA, хотелось сказать, что в 2024 году авторы нашли пятую метрику rework rate, для которой прокси метирикой является change failure rate. Для проверки они добавили вопрос про количество незапланированных deployment, которые были нужны для фикса багов. В итоге, гипотеза подтвердилась и исследователи сгуппировали четыре предыдущих фактора и новый пятый по двум группам software delivery: throughput и stability
- Throughput: change lead time, deployment frequency, failed deployment recovery time
- Stability: change failure rate, rework rate
Но дальше авторы решили сохранять свою прошлю структуру с кластеризацией и группировкой уровней по четырем категориям:)
Если говорить про методологию 2024 года, то ребята выделили 3 отдельных пути для прохождения опроса (куда рандомно определяли участников)
- AI (для определения влияния gen AI)
- Platform engineering Влияние платформенной инженерии
- Workplace (для опрпеделения влияния трансформационного лидерства
Дальше провели опрос и проверили внутреннюю и внешнюю валидность измерений:
- Внутренняя валидность показывала, что ответы на разные вопросы про один концепт дают консистентные результаты. Для этого авторы использовали confirmatory factor analysis (CFA) с применением lavaan R package.
- Внешняя валидность показывала, что конструкт, собранный исследователями, связан с реальным миром через взаимосвязи. Например, у авторов были ожидания по связи конструктов между собой и некоторой корелляции, которую можно было проверить на практике (и если находились противоречия, то они требовали новых гипотез для объяснений).
Для causal inference авторы использовали Directed acyclic graphs (DAGs) и инструмент DAGitty, который позволяет построить модель взаимосвязей разных факторов, а также попробовать устранить влияние третьих переменных и смимикрировать a/b эксперименты. А дальнейший анализ эффектов авторы делали с использованием баейсовских подходов
Отдельно надо отметить, что авторы отказались от одной большой модели и сдеелали много маленьких моделей, где связывали capabilities (условно инжнерные практики) с результатами (outcomes). Дальше они при помощи ответов на вопросы проверяли связь между capabilities и outcomes, пытаясь отделить влияние третьих переменных. Проделав это, они делали не просто выводы о корелляциях, а постулировали наличие причинно-следственных связей.
В общем, методология получилась определенно интересная, а следующий выпуск подкаста Code of Leadership будет посвящен ее детальному разбору.
#AI #DevOps #DevEx #Metrics #Processes #Management
Продолжая рассказ про методологию DORA, хотелось сказать, что в 2024 году авторы нашли пятую метрику rework rate, для которой прокси метирикой является change failure rate. Для проверки они добавили вопрос про количество незапланированных deployment, которые были нужны для фикса багов. В итоге, гипотеза подтвердилась и исследователи сгуппировали четыре предыдущих фактора и новый пятый по двум группам software delivery: throughput и stability
- Throughput: change lead time, deployment frequency, failed deployment recovery time
- Stability: change failure rate, rework rate
Но дальше авторы решили сохранять свою прошлю структуру с кластеризацией и группировкой уровней по четырем категориям:)
Если говорить про методологию 2024 года, то ребята выделили 3 отдельных пути для прохождения опроса (куда рандомно определяли участников)
- AI (для определения влияния gen AI)
- Platform engineering Влияние платформенной инженерии
- Workplace (для опрпеделения влияния трансформационного лидерства
Дальше провели опрос и проверили внутреннюю и внешнюю валидность измерений:
- Внутренняя валидность показывала, что ответы на разные вопросы про один концепт дают консистентные результаты. Для этого авторы использовали confirmatory factor analysis (CFA) с применением lavaan R package.
- Внешняя валидность показывала, что конструкт, собранный исследователями, связан с реальным миром через взаимосвязи. Например, у авторов были ожидания по связи конструктов между собой и некоторой корелляции, которую можно было проверить на практике (и если находились противоречия, то они требовали новых гипотез для объяснений).
Для causal inference авторы использовали Directed acyclic graphs (DAGs) и инструмент DAGitty, который позволяет построить модель взаимосвязей разных факторов, а также попробовать устранить влияние третьих переменных и смимикрировать a/b эксперименты. А дальнейший анализ эффектов авторы делали с использованием баейсовских подходов
We use Bayesian statistics to calculate a posterior, which tries to capture “the expected frequency that different parameter values will appear.” The “simulation” part is drawing from this posterior more than 1,000 times to explore the values that are most credible for a parameter (mean, beta weight, sigma, intercept, etc.) given our data.
Отдельно надо отметить, что авторы отказались от одной большой модели и сдеелали много маленьких моделей, где связывали capabilities (условно инжнерные практики) с результатами (outcomes). Дальше они при помощи ответов на вопросы проверяли связь между capabilities и outcomes, пытаясь отделить влияние третьих переменных. Проделав это, они делали не просто выводы о корелляциях, а постулировали наличие причинно-следственных связей.
В общем, методология получилась определенно интересная, а следующий выпуск подкаста Code of Leadership будет посвящен ее детальному разбору.
#AI #DevOps #DevEx #Metrics #Processes #Management
Telegram
Книжный куб
[1/2] Как собираются отчеты DORA (DevOps Research and Assessment)?
Если вы опытный разработчик или технический руководитель, то с большой вероятностью вы слышали про магические DORA метрики, использование которых часто является baseline для оценки эффективности…
Если вы опытный разработчик или технический руководитель, то с большой вероятностью вы слышали про магические DORA метрики, использование которых часто является baseline для оценки эффективности…
❤6👍1🔥1
Trends Across the AI Frontier (Рубрика #AI)
Посмотрел недавно короткое выступление George Cameron, соучредителя и CPO компании Artificial Analysis, независимой компании по бенчмаркингу ИИ, основанной в октябре 2023 года. Ребята специализируются на независимом тестировании более 150 различных моделей ИИ по широкому спектру метрик, включая интеллект, производительность, стоимость и скорость, публикуя результаты на сайте artificialanalysis.ai. Сам доклад был коротким, но насыщенным аналитикой и прогнозами, а ключевые идеи представлены ниже
1. Множественность границ в ИИ
Георг подчеркивает центральную идею своего выступления: в ИИ существует не одна, а несколько границ (frontiers), и разработчики не всегда должны использовать самую интеллектуальную модель. Доклад исследует четыре ключевые границы:
- Модели рассуждения (Reasoning Models)
- Открытые веса (Open Weights)
- Стоимость (Cost)
- Скорость (Speed)
2. Граница моделей рассуждения: компромиссы производительности
Георг показывает аналитику с резличиями на порядок между обычными и reasoning-моделями:
- Вербальность моделей
-- GPT-4.1: 7 миллионов токенов для запуска индекса интеллекта
-- O4 Mini High: 72 миллиона токенов (в 10 раз больше)
-- Gemini 2.5 Pro: 130 миллионов токенов
- Задержка ответа
-- GPT-4.1: 4,7 секунды для полного ответа
-- O4 Mini High: более 40 секунд
Это критично для агентных систем, где 30 последовательных запросов могут занять 5 минут вместо 30 секунд.
3. Граница открытых весов: сокращение разрыва
Георг демонстрирует драматическое сокращение разрыва между открытыми и проприетарными моделями. Особую роль играют китайские лаборатории ИИ:
- DeepSeek лидирует как в reasoning, так и в non-reasoning моделях
- Alibaba с серией Qwen 3 занимает второе место в reasoning
- Meta и Nvidia также конкурируют с моделями на базе Llama
DeepSeek R1, выпущенная в январе 2025 года, показывает производительность, сравнимую с лидирующими проприетарными моделями, достигая 79.8% на AIME 2024 против 79.2% у O1.
4. Граница стоимости: драматическое снижение
Порядковые изменения в стоимости:
- O3: $2,000 для запуска их бенча индекса интеллекта
- 4.1: в ~30 раз дешевле O1
Стоимость доступа к новому уровню интеллекта снижается вдвое за несколько месяцев (так стоимость доступа к уровню интеллекта GPT-4 упала более чем в 100 раз с середины 2023 года). По данным исследований, стоимость обучения frontier-моделей растет в 2,4 раза в год с 2016 года.
5. Граница скорости: значительный рост производительности
Рост скорости вывода токенов: GPT-4 в 2023 году: ~40 токенов в секунду. Тот же уровень интеллекта сейчас: более 300 токенов в секунду. Такие изменения скорости завязаны на технологические улучшения
- Mixture of Experts (MoE) модели - активируют только часть параметров при инференсе
- Дистилляция - создание более интеллектуальных моделей меньшего размера
- Оптимизация софта - flash attention, speculative decoding
- Улучшения аппаратуры - B200 достигает более 1000 токенов в секунду
Главные выводы
1. Несмотря на повышение эффективности и снижение стоимости, Камерон прогнозирует продолжение роста спроса на вычисления:
- Более крупные модели - DeepSeek имеет более 600 миллиардов параметров
- Ненасытный спрос на интеллект
- "Болтливые" reasoning-модели требуют больше вычислений при инференсе
- Агенты с 20-30-100+ последовательными запросами
2. Стратегические рекомендации
- Измеряйте tradeoffs в своих приложениях, а не полагайтесь только на цену за токен
- Стройте с учетом будущего снижения стоимости - что невозможно сегодня, может стать доступным через 6 месяцев
- Учитывайте структуру затрат приложения при выборе моделей
В общем, Георг показывает интересные результаты бенчмарков, по которым видны интересные тренды. А я лично после выступления еще с интересом потыкал другие исследования с сайта Artificial Analysis.
#AI #Software #Engineering #Management #Metrics #ML #Leadership
Посмотрел недавно короткое выступление George Cameron, соучредителя и CPO компании Artificial Analysis, независимой компании по бенчмаркингу ИИ, основанной в октябре 2023 года. Ребята специализируются на независимом тестировании более 150 различных моделей ИИ по широкому спектру метрик, включая интеллект, производительность, стоимость и скорость, публикуя результаты на сайте artificialanalysis.ai. Сам доклад был коротким, но насыщенным аналитикой и прогнозами, а ключевые идеи представлены ниже
1. Множественность границ в ИИ
Георг подчеркивает центральную идею своего выступления: в ИИ существует не одна, а несколько границ (frontiers), и разработчики не всегда должны использовать самую интеллектуальную модель. Доклад исследует четыре ключевые границы:
- Модели рассуждения (Reasoning Models)
- Открытые веса (Open Weights)
- Стоимость (Cost)
- Скорость (Speed)
2. Граница моделей рассуждения: компромиссы производительности
Георг показывает аналитику с резличиями на порядок между обычными и reasoning-моделями:
- Вербальность моделей
-- GPT-4.1: 7 миллионов токенов для запуска индекса интеллекта
-- O4 Mini High: 72 миллиона токенов (в 10 раз больше)
-- Gemini 2.5 Pro: 130 миллионов токенов
- Задержка ответа
-- GPT-4.1: 4,7 секунды для полного ответа
-- O4 Mini High: более 40 секунд
Это критично для агентных систем, где 30 последовательных запросов могут занять 5 минут вместо 30 секунд.
3. Граница открытых весов: сокращение разрыва
Георг демонстрирует драматическое сокращение разрыва между открытыми и проприетарными моделями. Особую роль играют китайские лаборатории ИИ:
- DeepSeek лидирует как в reasoning, так и в non-reasoning моделях
- Alibaba с серией Qwen 3 занимает второе место в reasoning
- Meta и Nvidia также конкурируют с моделями на базе Llama
DeepSeek R1, выпущенная в январе 2025 года, показывает производительность, сравнимую с лидирующими проприетарными моделями, достигая 79.8% на AIME 2024 против 79.2% у O1.
4. Граница стоимости: драматическое снижение
Порядковые изменения в стоимости:
- O3: $2,000 для запуска их бенча индекса интеллекта
- 4.1: в ~30 раз дешевле O1
Стоимость доступа к новому уровню интеллекта снижается вдвое за несколько месяцев (так стоимость доступа к уровню интеллекта GPT-4 упала более чем в 100 раз с середины 2023 года). По данным исследований, стоимость обучения frontier-моделей растет в 2,4 раза в год с 2016 года.
5. Граница скорости: значительный рост производительности
Рост скорости вывода токенов: GPT-4 в 2023 году: ~40 токенов в секунду. Тот же уровень интеллекта сейчас: более 300 токенов в секунду. Такие изменения скорости завязаны на технологические улучшения
- Mixture of Experts (MoE) модели - активируют только часть параметров при инференсе
- Дистилляция - создание более интеллектуальных моделей меньшего размера
- Оптимизация софта - flash attention, speculative decoding
- Улучшения аппаратуры - B200 достигает более 1000 токенов в секунду
Главные выводы
1. Несмотря на повышение эффективности и снижение стоимости, Камерон прогнозирует продолжение роста спроса на вычисления:
- Более крупные модели - DeepSeek имеет более 600 миллиардов параметров
- Ненасытный спрос на интеллект
- "Болтливые" reasoning-модели требуют больше вычислений при инференсе
- Агенты с 20-30-100+ последовательными запросами
2. Стратегические рекомендации
- Измеряйте tradeoffs в своих приложениях, а не полагайтесь только на цену за токен
- Стройте с учетом будущего снижения стоимости - что невозможно сегодня, может стать доступным через 6 месяцев
- Учитывайте структуру затрат приложения при выборе моделей
В общем, Георг показывает интересные результаты бенчмарков, по которым видны интересные тренды. А я лично после выступления еще с интересом потыкал другие исследования с сайта Artificial Analysis.
#AI #Software #Engineering #Management #Metrics #ML #Leadership
YouTube
Trends Across the AI Frontier — George Cameron, ArtificialAnalysis.ai
The entire AI stack is developing faster than ever - from chips to infrastructure to models. How do you sort the signal from the noise? Artificial Analysis an independent benchmarking and insights company dedicated to helping developers and companies pick…
❤5👍5🔥2
Абстракция данных и решение задач на C++. Стены и зеркала (Data Abstraction & Problem Solving with C++: Walls and Mirrors)
Пришло время еще одной ретро-книги из моего прошлого. Третье издание книги про стены и зеркала Фрэнка М. Каррано и Джанет Дж. Причард вышла в 2003 году. В этом году я как раз купил эту книгу для изучения языков программирования на первом курсе. Забавно, что корни книгиуходят к книге 1986 года "Intermediate Problem Solving and Data Structures: Walls and Mirrors", которая была издана в год моего рождения. Свзяь книг была через ключевые концепции "стен и зеркал", которая пронизывает всю книгу:
- "Стены" символизируют абстракцию данных - скрытие деталей реализации модуля от остальной программы, подобно тому, как стена может изолировать и скрыть
- "Зеркала" представляют рекурсию - повторяющуюся технику решения проблем путём решения меньших версий той же проблемы, подобно тому, как изображения в обращённых друг к другу зеркалах становятся всё меньше с каждым отражением
Сама книга состоит из двух основных частей
1. Методы решения задач - принципы программирования, рекурсия, абстракция данных, связанные списки
2. Решение задач с помощью абстрактных типов данных - стеки, очереди, эффективность алгоритмов, сортировка, деревья, таблицы, графы
Я помню, что в книге рассказывалось про важные моменты, которые тогда еще мне казались нетривиальными
- Различие между спецификацией и реализацией - так вво основа объектно-ориентированного подхода
- Инкапсуляция, наследование и полиморфизм как ключевые понятия ООП
- Абстрактные типы данных как базовые кубики разработки
- Рекурсивные методы решения задач
Книга стала популярной в академической среде США и она была переиздана 8 раз, причем воьсмое издание вышло в 2024 году, но я не видел переводов новых изданий на русский язык. Сейчас третье издание книги интересно только с исторической точки зрения, но когда-то она мне действительно помогла понять базовые концепции, но на C++ я писать профессионально не стал:)
P.S.
Книга уехала в букшеринг уголок в нашем офисе.
#Software #Engineering
Пришло время еще одной ретро-книги из моего прошлого. Третье издание книги про стены и зеркала Фрэнка М. Каррано и Джанет Дж. Причард вышла в 2003 году. В этом году я как раз купил эту книгу для изучения языков программирования на первом курсе. Забавно, что корни книгиуходят к книге 1986 года "Intermediate Problem Solving and Data Structures: Walls and Mirrors", которая была издана в год моего рождения. Свзяь книг была через ключевые концепции "стен и зеркал", которая пронизывает всю книгу:
- "Стены" символизируют абстракцию данных - скрытие деталей реализации модуля от остальной программы, подобно тому, как стена может изолировать и скрыть
- "Зеркала" представляют рекурсию - повторяющуюся технику решения проблем путём решения меньших версий той же проблемы, подобно тому, как изображения в обращённых друг к другу зеркалах становятся всё меньше с каждым отражением
Сама книга состоит из двух основных частей
1. Методы решения задач - принципы программирования, рекурсия, абстракция данных, связанные списки
2. Решение задач с помощью абстрактных типов данных - стеки, очереди, эффективность алгоритмов, сортировка, деревья, таблицы, графы
Я помню, что в книге рассказывалось про важные моменты, которые тогда еще мне казались нетривиальными
- Различие между спецификацией и реализацией - так вво основа объектно-ориентированного подхода
- Инкапсуляция, наследование и полиморфизм как ключевые понятия ООП
- Абстрактные типы данных как базовые кубики разработки
- Рекурсивные методы решения задач
Книга стала популярной в академической среде США и она была переиздана 8 раз, причем воьсмое издание вышло в 2024 году, но я не видел переводов новых изданий на русский язык. Сейчас третье издание книги интересно только с исторической точки зрения, но когда-то она мне действительно помогла понять базовые концепции, но на C++ я писать профессионально не стал:)
P.S.
Книга уехала в букшеринг уголок в нашем офисе.
#Software #Engineering
❤6🔥4👍1
Code of Leadership #47-Interview with Daniil Kuleshovabout Engineering, Architecture & Ad Tech (Рубрика #Management)
В очередном выпуске подкаста ко мне пришел интересный гость, Даниил Кулешов, staff engineer, который развивает вместе со мной в Т-Банке архитектурную функцию на уровне всей компании. За полтора часа мы успели поговорить про разработку, менеджмент, архитектуру и рекламные технологии, а детальнее темы представлены ниже
- Знакомство с гостем
- Образование и начало пути в IT
- Предпринимательский опыт и создание проектов
- Цифровизация справочников и специфика рекламы
- Переход на сложные технологические задачи, мотивация
- Работа в стартапе: Real Time Bidding и рекламные технологии (инженерка, опыт управления командой)
- Переход в крупную компанию: культура, рекрутинг, уроки
- Архитектура высоконагруженных систем, проблемы масштабирования
- Проект авторизации физлиц и причем здесь Google Zanzibar
- Самообразование, work-life balance и советы зрителям
Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.
P.S.
Краткая расшифровка доступна в моем блоге на Medium.
#Software #Engineering #Management #Architecture #Processes
В очередном выпуске подкаста ко мне пришел интересный гость, Даниил Кулешов, staff engineer, который развивает вместе со мной в Т-Банке архитектурную функцию на уровне всей компании. За полтора часа мы успели поговорить про разработку, менеджмент, архитектуру и рекламные технологии, а детальнее темы представлены ниже
- Знакомство с гостем
- Образование и начало пути в IT
- Предпринимательский опыт и создание проектов
- Цифровизация справочников и специфика рекламы
- Переход на сложные технологические задачи, мотивация
- Работа в стартапе: Real Time Bidding и рекламные технологии (инженерка, опыт управления командой)
- Переход в крупную компанию: культура, рекрутинг, уроки
- Архитектура высоконагруженных систем, проблемы масштабирования
- Проект авторизации физлиц и причем здесь Google Zanzibar
- Самообразование, work-life balance и советы зрителям
Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.
P.S.
Краткая расшифровка доступна в моем блоге на Medium.
#Software #Engineering #Management #Architecture #Processes
YouTube
Code of Leadership #47 Interview with Daniil Kuleshovabout Engineering, Architecture & Ad Tech
В очередном выпуске подкаста ко мне пришел интересный гость, Даниил Кулешов, Staff Engineer, который развивает вместе со мной в Т-Банке архитектурную функцию на уровне всей компании. За полтора часа мы успели поговорить про разработку, менеджмент, архитектуру…
1❤8👍2🔥1🫡1
Когда мы перестали понимать мир (Un Verdor Terrible) (Рубрика #PopularScience)
Эта книга Бенхамина Лабатута, чилийского писателя, показалась мне крайне интересной. Сегодня утром я снял ее с полки и оторвался только дочитав:) Этот роман из уникального жанра, что автор определил как "художественное произведение, основанное на реальных событиях". Она переведена на 22 языка и стала финалистом Международной Букеровской премии в 2021 году. Речь в книге про реальные события из жизни великих математиков и физиков, среди которых
- Фриц Габер - химик, создатель химического оружия и азотных удобрений
- Карл Шварцшильд - астроном, теоретически предсказавший существование черных дыр
- Нильс Бор - один из основателей квантовой механики
- Вернер Гейзенберг - физик-теоретик, автор принципа неопределенности
- Эрвин Шрёдингер - создатель волновой механики
- Александр Гротендик - выдающийся математик XX века с широкомасштабным влиянием на всю математику
- Синъити Мотидзуки - японский математик, доказавший abc-гипотезу
Бенхамин так закручивает свое повествование, что оно читается как динамичнейший триллер о науке и гранях безумия. Его стиль описывают как многослойный и сложный, создающий ощущение, что он сам по себе - отдельный жанр. Ученые, вышедшие из под его пера, кажутся живыми и эмоциональным. Автор показывает не только их открытия, но и сны, галлюцинации, внутренние переживания. В итоге мы видим разные грани, включающие
- Тревога и страх, сопутствующие великим открытиям
- Психические страдания ученых, сталкивающихся с непознаваемым
- Трагические судьбы: самоубийство жены Фрица Габера, безумие Александра Гротендика
- Экзистенциальный ужас от понимания последствий своих открытий
В итоге, титаны науки предстают перед нами глубоко несчастными людьми, которые сталкиваются с темной стороной великих научных открытий, например,
- Гейзенберг "словно выколол себе оба глаза, чтобы видеть дальше"
- Александр Гротендик, "возможно, самый важный математик XX века", закончил жизнь отшельником, считая математику "величайшей угрозой человеческому существованию"
В книге есть философская глубина и она как бы задает вопрос о том, а есть ли вещи, которые нам не стоит знать.
Итого, это дейтсвительно стоящее произведение, которое демонстрирует не просто великих ученых, а страдающих людей, которым открытия даются дорогой ценой - ценой психического здоровья, человеческих отношений, а иногда и жизни самих ученых.
#PopularScience #Physics #Math #Science
Эта книга Бенхамина Лабатута, чилийского писателя, показалась мне крайне интересной. Сегодня утром я снял ее с полки и оторвался только дочитав:) Этот роман из уникального жанра, что автор определил как "художественное произведение, основанное на реальных событиях". Она переведена на 22 языка и стала финалистом Международной Букеровской премии в 2021 году. Речь в книге про реальные события из жизни великих математиков и физиков, среди которых
- Фриц Габер - химик, создатель химического оружия и азотных удобрений
- Карл Шварцшильд - астроном, теоретически предсказавший существование черных дыр
- Нильс Бор - один из основателей квантовой механики
- Вернер Гейзенберг - физик-теоретик, автор принципа неопределенности
- Эрвин Шрёдингер - создатель волновой механики
- Александр Гротендик - выдающийся математик XX века с широкомасштабным влиянием на всю математику
- Синъити Мотидзуки - японский математик, доказавший abc-гипотезу
Бенхамин так закручивает свое повествование, что оно читается как динамичнейший триллер о науке и гранях безумия. Его стиль описывают как многослойный и сложный, создающий ощущение, что он сам по себе - отдельный жанр. Ученые, вышедшие из под его пера, кажутся живыми и эмоциональным. Автор показывает не только их открытия, но и сны, галлюцинации, внутренние переживания. В итоге мы видим разные грани, включающие
- Тревога и страх, сопутствующие великим открытиям
- Психические страдания ученых, сталкивающихся с непознаваемым
- Трагические судьбы: самоубийство жены Фрица Габера, безумие Александра Гротендика
- Экзистенциальный ужас от понимания последствий своих открытий
В итоге, титаны науки предстают перед нами глубоко несчастными людьми, которые сталкиваются с темной стороной великих научных открытий, например,
- Гейзенберг "словно выколол себе оба глаза, чтобы видеть дальше"
- Александр Гротендик, "возможно, самый важный математик XX века", закончил жизнь отшельником, считая математику "величайшей угрозой человеческому существованию"
В книге есть философская глубина и она как бы задает вопрос о том, а есть ли вещи, которые нам не стоит знать.
Итого, это дейтсвительно стоящее произведение, которое демонстрирует не просто великих ученых, а страдающих людей, которым открытия даются дорогой ценой - ценой психического здоровья, человеческих отношений, а иногда и жизни самих ученых.
#PopularScience #Physics #Math #Science
Ad Marginem
Когда мы перестали понимать мир - Бенхамин Лабатут - Ad Marginem
Роман чилийского писателя Бенхамина Лабатута о тревоге, сопутствующей великим научным открытиям. Топ-100 лучших книг XXI века по версии The New York Times.
❤13👍7🔥3