[2/2] What's the Use?: The Unreasonable Effectiveness of Mathematics (Это база. Зачем нужна математика в повседневной жизни) (Рубрика #Math)

Продолжая рассказ, об этой научно-популярной книге, расскажу содержание оставшихся глав

4. Почки Кенигсберга - все начинается с задачи о мостах Кёнигсберга, появления теории графов, а дальше их применения для трансплантации органов в UK.
5. Будьте осторожны в киберпространстве - здесь по классике идет речь про шифрование, дальше про ассиметричное шифрование, использование для этого разложения на простые числа, а потом переход к эллиптическим кривым
6. Числовая плоскость - здесь автор рассказывает про натуральные числа, рациональные, иррациональные и комплексные. Он рассказывает как появились комплексные числа и что их представление - это уже не числовая прямая, а числовая плоскость, где интерпретация связана с синусами и косинусами. Интересно, что для многих физических задач использование комплексных чисел позволяет проще описывать и решать задать задачи
7. Папа, ты научился перемножать триплеты - рассказ про квартернионы Гамильтона, которые позволяют проще описывать и решать задачи преобразования положения объектов в трехмерном пространстве. Это очень пригождается в трехмерной графике.
8. Вот это отскок - интересная глава, где автор переходит от расчета параметров пружин к аттракторам Лоренца и теории хаоса
9. Верь мне, я ряд Фурье - здесь автор рассказывает про разложение в ряд Фурье, дальше про преобразование Родона и как все это используется в условных КТ аппаратах для восстановления трехмерного изображения по большому количеству двумерных проекций с разных направлений
10. Улыбнитесь, пожалуйста! - коротенькая глава про сохранение изображений, где есть рассказ про jpeg, а также про использование вейвлетов для хранения изображений отпечатков пальцев в архиве ФБР
11. Мы уже почти приехали? - автор рассказывает про то, как работает GPS и какие области физики и математики нужны для работы геопозиционирования
12. Оттаивание Арктики - рассказ как модель для магнитов была переиспользована для анализа таяния прудов на поверхности льдин. Очень интересный и нетривиальный пример
13. Позовите тополога - базовый рассказ, что начинается с ленты Мебиуса, бутылки Клейна и быстро переходит к инвариантам и рассказом про гомологиям, когомологиям, а также к прикладной топологии, где автор рассказывает про постоянные гомологии, что можно использовать для анализа покрытия некоторой территории датчиками. В общем, эту главу не так уж и просто читать.
14. Лиса и еж - эта глава завершает книгу и в ней автор размышляет о природе математического мышления и его роли в человеческой цивилизации, используя метафору лисы и ежа, а также фантастический образ математикоядных инопланетян. Стюарт опирается на знаменитое высказывание: «Лиса знает много разных вещей, а ёж — одну, но большую». Для иллюстрации он вводит образ «математикоядных инопланетян». Представьте себе цивилизацию, которая охотится на математику, чтобы выжить, и потому вынуждена искать новые математические идеи везде, где только можно. Тут она прилетает в гости к нам и начинает есть нашу математику, начиная с изысков высшей математики. Дальше у нас начинают исчезать общепринятые вещи - телефоны, компьютеры, интернет, геопозиционирование, ... Эти инопланетяне останавливаются, но у нас остается только арифметика, которой они побрезговали, а также каменный век вокруг нас.

Через эту историю Иэн показывает принципиальное значение математики для окружающего нас мира, хотя большая часть людей не знает об этом. Иэн предлагает популяризировать это и увеличивать количество людей занимающихся математикой, где она воспринимается как насыщенная творческая дисциплина, а не примитивная карикатура, какой ее нередко представляют. И завершается книга фразой
Да, лиса знает много секретов, а математики - всего один, но очень большой. Он называется математикой, и он преобразует наш мир.
#PopularScience #Math #Physics

[1/3] Интегрируем AI в процессы разработки большой компании: почему разрешить всем Cursor — не вариант (Рубрика #Management)

Сегодня в 17.00 я выступаю с таким докладом на CTO Conf X, профессиональной конференции для технических директоров, от компании "Онтико". Я расскажу о хайповой теме об интеграции искусственного интеллекта в жизненный цикл разработки софта в больших компаниях. Ниже я расскажу про структуру доклада и приведу ссылки на дополнительные материалы, которые я использую для референсов в моем выступлении.
В своем докладе я начинаю выступление с того, что вспоминаю об copilot инструментах разработчиков: GitHub Copilot, Cursor, Windsurf, которые задали некоторый стандарт AI ассистентов для разработчиков и позволили делать многое автоматически. В феврале 2025 года Andrej Karpathy дал начало новому тренду разработки под названием vibe coding

There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.

Этот тренд подхватили ребята из акселлератора стартапов Y Combinator и уже в марте начали обсуждать эту тему в подкастах:
- "Vibe Coding Is The Future" (я его уже разбирал)
- "Интервью с CEO Windsurf про будущее программирования" (я его уже разбирал)
- и даже "Vibe coding tips в их Startup Schools".

Отдельно можно добавить, что хайпа добавляют заявления Сэма Альтмана, CEO OpenAI, или Дарио Амодея, CEO Antrophic. Например, Дарио три месяца назад на выступлении "The Future of U.S. AI Leadership with CEO of Anthropic Dario Amodei", про которое я уже рассказывал, выдал предсказание про будущее разработки

I think we will be there in three to six months, where AI is writing 90% of the code. And then, in 12 months, we may be in a world where AI is writing essentially all of the code

Возникает вопрос, а как этого можно добиться? Ответ в использовании агентов:
- В прошлом году ребята из Antrophic представили MCP (model context protocol) для предоставления LLM доступа к дополнительным инструментам
- А уже в этом году Google представили протокол уже для взаимодействия агентов A2A (Agent2Agent) протокол
В общем, тема сейчас хайповая и для создания MVP в стартапах или pet проектов разработчиками этот подход к использованию copilots в режиме vibe coding отлично подходит. А вот для крупных компаний не все так просто и дальше я объясню почему

Инженерные процессы в крупных компаниях эволюционировали следующим образом:
- Когда-то разработка и эксплуатация была разделена и этот разрыв мешал достигать бизнес-результатов. В итоге, с середины 2000х по конец 2010х евангелировался DevOps подход, который с научной точки зрения был обоснован в книге "Accelerate", про которую я рассказывал раньше в трех частях: 1, 2 и 3.
- Этот подход зачастую приводил к гетерогенному ИТ-ландшафту с большим дублированием систем, что не позволяло получить эффект масштаа - крупные компании пошли в сторону разделения stream-aligned команд и platform команд, которые должны были создать платформы, навроде Internal developer platform, которая позволяла бы инженером в формате self service пользоваться инструментами навроде работы с кодом, артефактами, CI/CD пайплайнами, рантаймом, observability и так далее
- Дальше платформы стали достаточно сложными и владельцы платформ решили идти в сторону user experience своих пользователей, которыми являются разработчики. Так появилась концепция developer experience, в которую входит flow state, cognitive load, feedback loops (про это можно почитать в whitepaper "DevEx: What Actually Drives Productivity", про которую я рассказывал раньше). Это важно, так как сложность платформ может зашкаливать - этом можно продемонстрировать, взглянув на картинку с CNCF landscape, где количество карточек продуктов зашкаливает и разобраться с тем, что и как обычному человеку крайне сложно.

Продолжение в следующем посте.

#AI #PlatformEngineering #Engineering #Software #Processes #Productivity

[2/3] Интегрируем AI в процессы разработки большой компании: почему разрешить всем Cursor — не вариант (Рубрика #Management)

Мы остановились в прошлом посте на платформах и их сложности. А что делать для борьбы с такой сложностью?

- Для работы над сложностью отдельных инструментов ребята в Google пошли в продуктовую сторону и решили понять, а какие цели у инженеров в разработке софта. Свой подход они описали в whitepaper "Measuring developer goals", про которую я рассказывал раньше. Смысл в том, чтобы выделить фазы жизненного цикла разработки софта, а внутри них определить аля jobs to be done сценарии, которые нужны инженерам. Дальше эти сценарии можно оцифровать с помощью телеметрии от платформенных инструментов и при помощи опросов инженеров. Сами сценарии расскладываются на использование нескольких инструментов и дальше можно оптимизировать и AI-фицировать не отдельные инструменты, а весь сценарий (в перспективе его можно попробовать отдать AI агентам)
- Одновременно, интересно взглянуть на ожидания самих инженеров от AI внутри платформ. Ребята из Google летом 2024 года выпустили whitepaper "What Do Developers Want From AI?" (мой обзор), где рассказали про три уровня улучшения AI для инженеров (интересно, что они провели параллели с автомобильной промышленностью и водителями)
1. Enhancing human capabilities - гидроусилитель руля и анти-блокировочная система в машинах, автодополнение кода в IDE
2. Extending human capabilities - камера заднего вида и контроль слепых зон в машинах, чат и code review suggests в разработке
3. Delegating human capabilities - улучшенный круиз-контроль и держание полосы в машинах (включая автопилот от Tesla), агентские workflow в AI, включая автоматическое удаление dead code, а также генерацию тестов
В общем, этот подход неплохо показывает как AI постепенно может проникать в процессы разработки. А дальше интересно глянуть на подходы западных bigtech компаний к реализации второго и третьего уровня
- Google и дизайн API. У ребят из Google были 2 научные статьи в середине 2024 года "API Governance at Scale" (мой разбор) и "AI-Enhanced API Design: A New Paradigm in Usability and Efficiency" (мой разбор). В них они рассказывали про свой подход к дизайну API, который у них отлично стандартизован (подробнее в aip.dev), а дальше они попробовали поверх этих стандартов прикрутить api architect (это LLM модель для генерации спеки по продуктовым требованиям).
- ByteDance и code review. У ребят из ByteDance есть научная статья 2025 года "BitsAI-CR: Automated Code Review via LLM in Practice" (мой разбор: 1, 2 и 3). В ней они рассказывают про свой pipeline для работы с code review, где есть 200+ категорий, моделька для генерации комментов для ревью, моделька для фильтрации сгенерированного, а также feedback loop от инженеров для тюнинга эффективности все системы
- Uber и крупномасштабная миграция с Java на Kotlin. Они рассказывали это докладе "This Year in Uber’s AI-Driven Developer Productivity Revolution" на конференции DPE 2024 (мой разбор: 1 и 2). Если кратко, то у ребят было много Java кода, что они хотели переписать на Kotlin. В децентрализованном варианте команды делали бы это вялотекуще 10+ лет, ребята прикрутили сначала LLM и сократили оценку в 3 раза, а потом скомбинировали LLM и AST и смогли по оценке уложиться в 18 месяцев на всю миграцию кодовой базы.
- Booking и внешнее партнерство с Sourcegraph. Booking решил приобщаться к AI через внешнего партнера (подробнее здесь). Sourcegraph сделали для Uber генерации QraphQL request из API Booking по текстовому описанию запроса, сделали code review, а также вывели из анабиоза проект по миграции кодовой базы, что шел уже 14 лет.
- Datadog и AI oncall engineer. Datadog - это observability платформа, которая решила сделать oncall engineer. Про это они рассказывали в начале этого года, а я писал об этом раньше

В финальном посте мы обсудим как дела обстоят в Т, а также завершим рассказ выводами.

#AI #PlatformEngineering #Engineering #Software #Processes #Productivity

[3/3] Интегрируем AI в процессы разработки большой компании: почему разрешить всем Cursor — не вариант (Рубрика #Management)

Из примеров больших компаний в предыдущем посте видно, что они идут от сценариев расширения возможности людей, а часть из них успешно агентизируют. И если посмотреть на наш подход в Т-Банке, то мы идет примерно этим же путем. На самом деле какой этот путь можно подробно узнать из выступлений моих коллег на Platform Engineering Night
- AI и Platform Engineering" от Игоря Маслова
- Разработка собственного AI-ассистента для кода: спринт или марафон? от Дениса Артюшина
Если кратко, то мы прошли гигиенический первый уровень, сейчас закрыли многие сценарии из второго уровня и вплотную добрались до делегировании работы инженеров агентам. Интересно, что у нас есть централизованная команда, что делает нашего copilot Nestor, но одновременно это зонтичный бренд для остальных инициатив, которые драйвятся у нас рабочими группами по планированию, анализу, проектированию, разработке, тестированию, SRE. Например, вот выступление про внедрение SRE AI-ассистента. В общем, мы со своей observability платформой Sage идем примерно в ту же сторону по AI-фикации, что и Datadog, упомянутый ранее.

Интенесно, что это общая тенденция про развитие платформ в мире genAI отлично видна из отчета RedHat от ноября 2024 года "State of platform engineering in the age of AI" (мой обзор), где основные выводы такие
- Платформенная инженерия становится стратегической
62% компаний уже имеют выделенные команды платформенной инженерии. Платформенная инженерия — это не просто автоматизация инфраструктуры, а стратегический инструмент для ускорения инноваций и внедрения ИИ.
- Влияние искусственного интеллекта
76% организаций уже используют генеративный ИИ для задач разработки (документация, генерация кода, подсказки). 45% считают ИИ центральным элементом своей платформенной стратегии.

В итоге, если отвечать на вынесенный в название вопрос "почему разрешить всем Cursor — не вариант?", то можно сказать так

Для маленьких компаний это очень и очень вариант, так как
- Эти инструменты позволяют быстро выдавать код для лендингов, прототипов, MVP
- Они стоят не очень дорого, а также обычно нет особых рисков с intellectual property, данными, санкциями
- Все равно нужны инженерные навыки - чтобы не получилось как в истории с тем, как агент снес весь код, а восстановить из git нельзя, так как vibe coder не знал что такое git и что им стоит пользоваться

Для больших компаний нужен подход посложнее, как я описывал выше, из-за
- Из коробки Copilot, Cursor, Windsurf не умеют работать с платформенными инструментами. Этому можно их научить если реализовать для платформенных продуктов MCP сервера, но ...
- Для больших компаний риски вокруг информационной безопасности, интеллектуальной собственности, персональных данных часто слишком велики для использования внешних SaaS решений
- В процессе работы над LLM внутри SDLC такие компании хотят потренироваться на кошечках и научиться AI-фицировать продукты, которые безопасны и понятны. А дальше с этой экспертизой идти в сторону customer продуктов компании.
- Ну и большие риски возникают из-за санкций, так как внешние SaaS решения могут быть официально недоступны, а получив доступ по другому его легко можно потерять и остаться у разбитого корыта.
В итоге, большие компании часто создают свои LLM решения и учатся интегрировать их внутрь своего SDLC и продуктов. Часто это может быть оправдано экономически на их масштабе. Интересно, что этому способствует публикация весов для моделей навроде LLama, DeepSeek, Mistral, что позволяет не слишком сильно отставать от mainstream.

А вот средним компаниям приходится сложно - внешние решения могут быть слишком рискованными, а на создание своих может не хватать денег. Но благо сейчас некоторые российские компании пытаются делать свои продукты вокруг SDLC, в которых AI становится жителем первого класса:)

#AI #PlatformEngineering #Engineering #Software #Processes #Productivity

10к подписчиков на канале

Вчера нас в этом канале стало 10 тысяч, что, как я считаю, очень круто. Спасибо всем, кто подписан на канал, я надеюсь, что вы находите для себя здесь иногда интересную информацию. Думаю, что по поводу юбилея надо устроить еще одну AMA (ask me anything) серию, как была в прошлом августе. В общем, если есть что спросить, то не держите в себе, а пишите комменты в тред под этим постом.

MCP vs ACP vs A2A: Comparing Agent Protocols - Laurie Voss (Рубрика #AI)

Ироничное выступление Laurie Voss, VP Developer Relations в LlamaIndex, где он за 15 минут рассказал про основные протоколы межагентского взаимодействия. Изначально он хотел рассказать про 3 основных протокола, но в ходе подготовки обнаружил ещё 11:) А в ходе выступления пошутил, что добавил бы еще в список протоколов WTF и LOL просто так... хотя наверняка уже есть протоколы с такими названиями.

Основные идеи представлены ниже

1. Создавать протоколы сейчас модно
За месяц исследований при подготовке scope доклада вырос с 3 до 14 протоколов, создалось даже впечатление, что почти все сейчас работают над агентскими протоколами
2. Два типа протоколов
- Context-oriented: предоставляют контекст LLM (MCP, agents.json)
- Inter-agent: обеспечивают взаимодействие между агентами (все остальные)
3. MCP - де-факто стандарт
Model Context Protocol от Anthropic доминирует благодаря раннему фокусу на конкретной проблеме.
4. A2A от Google
Agent2Agent Protocol от Google фокусируется на асинхронном взаимодействии и долгосрочных задачах.
5. Два ACP протокола
- ACP Connect от Agntcy, куда входят Cisco, LangChain, LlamaIndex, Galileo and Glean - с интегрированным реестром агентов
- ACP Communication от IBM - форк MCP, развивающийся в сторону A2A
6. Agora - самообновляющийся протокол
Agora - это интересный подход, где все начинается с естественного языка и дальше он позволяет участникам обновлять протокол во время взаимодействия.
7. Протокол от блокчейн ребят
AITP от NEAR Protocol слишком фокусируется на стоимости взаимодействий. Забавно, что спикер пошутил в духе, что "блокчейн пока не решил ни одной проблемы, так что не думаю, что решит и эту"
8. LMOS почти от IBM
Eclipse Foundation создаёт LMOS, параллельно с собственным ACP. Здесь была шутка о том, что Eclipse Foundation - это замаскированная IBM, создающее то же самое, что создаёт IBM. И если это кажется вам странным, значит вы мало общались с IBM:)
9. Отсутствие ключевых компонентов
Всем протоколам не хватает по мнению автора: централизованного реестра, системы авторизации и системы репутации.
10. MCP как основа будущего
Итоговый вывод в том, что MCP завоевал внимание и может расшириться для решения межагентских задач без добавления новых протоколов.

P.S.
Эта тема с агентами хорошо дополняет историю с вчерашнего доклада про внедрение AI в SDLC, которую я рассказывал на CTO Conf X.

#AI #Agents #Engineering #DistributedSystems

Генетическая селекция эмбрионов: От научной фантастики к коммерческой реальности (Рубрика #Science)

Наткнулся вчера на пост про стартап Nucleus Genomic, что презентовал революционную платформу Nucleus Embryo, которая позволяет родителям анализировать генетические профили эмбрионов при ЭКО и выбирать наиболее подходящие для имплантации. Это мне напомнили дистопический мир, изображенный в культовом фильме "Гаттака" 1997 года. Но давайте сначала поговорим про продукт, а дальше вспомним Гаттаку

Nucleus Embryo — это софт для генетической оптимизации, который позволяет родителям проанализировать до 20 эмбрионов по более чем 900 наследственным заболеваниям, а также по 40 дополнительным параметрам, включающим риски развития рака, хронических заболеваний, физические характеристики, когнитивные способности и даже цвет глаз. Это решение основано на полногеномном секвенировании (WGS) с глубиной покрытия 30x, что обеспечивает анализ 100% ДНК по сравнению с менее чем 0,1% у конкурентов вроде 23andMe. Компания утверждает, что секвенирует в 1000 раз больше ДНК, чем традиционные потребительские тесты, обеспечивая беспрецедентную точность генетического анализа. Если говорить про сам подход, то это полигенный скриннинг эмбрионов (PES), что основан на вычислении полигенных оценок риска (PRS) для каждого эмбриона. Оценки рассчитываются путем суммирования эффектов сотен, тысяч или даже миллионов вариантов ДНК, которые различаются между индивидуумами. Современные исследования показывают, что эффективность такой селекции ограничена, т.к. большинство выборов происходит между эмбрионами одних и тех же родителей, что существенно ограничивает как генетическую, так и средовую вариабельность.

А теперь проведем параллели с фильмом "Гаттака", в котором показано как может выглядеть социальная стратификация на основе генетики. В этом мире общество было разделено на "валидных" (генетически усовершенствованных) и "инвалидных" (естественно рожденных), при этом последние ограничены в доступе к образованию, работе и даже браку. Главынй герой фильма, Винсент Фримен, как раз человек второго сорта. Он близорук, имеет врождённый порок сердца, а генетический тест сулит ему примерно 30 лет жизни. Но у Винсента есть мечта — полететь в космос. И мы весь фильм наблюдаем как он идет к своей мечте, преодолевая ограничения окружающего мира за счет своей воли и работы над собой.

Если экстраполировать современные технологии (аля Nucleus Embryo), то видно, что они создают предпосылки для аналогичной стратификации. Хотя генетическая дискриминация формально запрещена, экономические барьеры доступа к генетической помощи могут привести к тому, что привилегированные слои общества смогут передавать свои преимущества детям через биологические механизмы. Как отмечают исследователи, это может привести к натурализации привилегий, оправданных научными предсказаниями. Интересно, что услуги полигенной селекции эмбрионов уже предлагаются потребителям как минимум четырьмя компаниями, а 5 лет назад родлился первый ребенок, прошедший через PES. Правда, существующие технологии имеют значительные ограничения. Исследования показывают, что полигенная селекция в целом не очень полезна при нацеливании на сложные характеристики здоровья — возникает проблема с оптимизацией по множеству критериев (генетические риски роста, IQ, цвета глаз и различных заболеваний), а значит принятие решения становится сложным. Думаю, что мы придем к созданию аля профилей вида: "спортсмен", "ученый", "поэт", "долгожитель", в которых будут зашиты комбинации критериев, а также будет отдельно возможность поиграться с фильтрами:))

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

#Science #PopularScience #Engineering

GitHub CEO predicts the future of programming (AI)

Посмотрел на выходных интервью Thomas Dohmk, CEO GitHub, которое у него брал Matthew Berman, известный AI-блогер. Само общение состоялось уже после MS Build, где GitHub анонсировал open source для своего чата внутри VSCode "GitHub Copilot Chat". Основные мысли интервью ниже

1. Влияние GPT и начало Copilot
Генеральный директор GitHub признаёт, что изначально сомневался в работоспособности GPT, но был впечатлён результатами: GPT изменил подход к разработке ПО навсегда. Copilot стал первым массовым инструментом, который завершает код за пользователя, и это оказалось крайне востребованным
2. Статистика и пользовательский опыт
Copilot пишет 25% кода в файлах, где он включён, а уровень удовлетворённости пользователей очень высок (NPS — 72). Интеграция с редакторами (VS Code) и code completion стали точкой входа AI в ежедневную работу разработчика
3. Образование и значимость программирования
Программирование остаётся важным навыком для понимания современного мира, его нужно преподавать детям и взрослым. Основы информатики и умение читать код — это универсальная грамотность будущего.
4. Роль и ответственность разработчика
Даже с появлением copilot агентов инженер должен проверять и подтверждать изменения, чтобы избежать ошибок и проблем с безопасностью. Важно понимать, что делает ИИ-агент, и не терять контроль над кодом
5. Эволюция индустрии и открытый исходный код
Открытый исходный код стал стандартом индустрии, а Copilot теперь доступен как open source для интеграции и доработки сообществом (речь идет про расширение для чата). GitHub и Microsoft делают ставку на использование нескольких моделей ИИ для разных задач, а не на одну универсальную (одну для code completion из-за требований к latency, другую для агентских workflow, где latency не так важно и можно использовать модель поумнее и помедленнее)
6. Будущее разработки: агенты и микро-приложения
Интересная идея о том, что в будущем персональные агенты могут создавать мини-приложения "на лету" для конкретных задач, а операционная система будет скрыта за ИИ-интерфейсом. Пример: автоматизация семейных задач (управление карманными деньгами детей) с помощью Copilot и персонализированных приложений
7. Vibe Coding и ограничения ИИ
Vibe Coding — подход, при котором ИИ помогает быстро воплощать идеи в прототипы, но для серьёзных задач нужны ревью, безопасность и стандарты. ИИ-агенты пока ограничены по объёму обрабатываемого кода, но в будущем смогут работать с большими проектами и тогда вайбкодить станет еще проще.
8. Интеграция и экосистема ИИ-агентов
Ожидается появление экосистемы персональных ИИ-агентов, интегрированных с работой и личной жизнью пользователя. Знания, связанные с работой, будут принадлежать компании, а личные — останутся у пользователя. Чем-то этот концепт напоминает сериал "Разделение", который я не смотрел, но про который слышал.
9. Влияние на рынок труда и новые профессии
ИИ автоматизирует рутинные задачи, но открывает новые профессии и возможности, даже для тех, кто не владеет английским языком. Как и в прошлые технологические революции, часть профессий исчезнет, но появятся новые роли и специализации.
10. Оптимизм в отношении ИИ
Томас выражает оптимизм: ИИ не заменит людей, а поможет решать больше задач, повысит продуктивность и создаст новые возможности для разработчиков

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

#AI #Software #Engineering #Architecture #Agents #Math #Software #ML #Leadership

Measuring Productivity: All Models are Wrong But Some are Useful (Рубрика #Management)

Этот whitepaper от исследователей Google Сьеры Джаспан и Коллина Грина, представляет собой текстовую версию их выступления на DPE Summit (Developer Productivity Engineering). В заглавие статьи они вынесли знаменитую цитату Джорджа Бокса "В сущности, все модели неправильны, но некоторые полезны", которая отлично применима и к вопросам измерения продуктивности инженеров тут к месту. Они рассказывают про принципы и методики, что выработали в Google для преодоления ограничений моделей и получения ценных инсайтов. Эта статья продолжает серию "Developer Productivity for Humans" в журнале IEEE, все статьи из которой рассмотрены в отдельном посте, а дальше поговорим про этот whitepaper.

1. Измерение продуктивности разработчиков — это построение моделей, где необходимо принять, что ни один подход к измерению не способен идеально охватить всю сложность разработки софта. Авторы утверждают, что модели продуктивности часто «опасно избирательны», поскольку опускают важные аспекты работы разработчиков, что приводит к неполным или искажающим оценкам. Важно понимать, что эффективное измерение продуктивности требует комплексного подхода, который охватывает несколько аспектов работы, а не опирается на примитивные метрики вроде количества строк кода или частоты коммитов.
2. Часто такой комплексный подход связан с компромиссами между разными сторонами разработки софта, например, легко ускорить velocity, если выкинуть этап код ревью и тестирования. Для нас это означает, что продуктивность следует рассматривать как баланс между несколькими факторами, в первую очередь скоростью, удобством и качеством, а не как единичный измеряемый результат. Интересно, что в Google этот компромисс представляется в виде треугольника: speed, ease, quality.
3. Исследователи в Google также смотрят и на социологические аспекты, учитывая их совместно с технологическими. Именно этот подход дал название всей серии статей, где измерение продуктивности должно учитывать сложную, творческую природу работы разработчика, а не рассматривать её как чисто механический процесс.
4. В этом исследовании лежит структурированная модель построения систем измерения продуктивности, которая избегает распространённых ошибок. Кажется, авторы используют подход Goals/Signals/Metrics (GSM), про который я уже писал, когда разбирал книгу "Software Engineering at Google", но они прямо об этом не говорят:)
5. Авторы учитывают два противоположных фактора: стремление к простоте (parsymony) и избегание опасной избирательности (worrying selectivity). Парсимония подталкивает к включению меньшего числа компонентов ради простоты, а worrying selectivity требует включения большего числа аспектов для охвата всех важных сторон продуктивности. Исследование советует склоняться к более полному охвату, а не к чрезмерной простоте.
6. Авторы комбинируют в своей методологии качественные и количественные методы, используя данные из инструментальных логов и опросов. Такой смешанный подход отражает их понимание того, что продуктивность разработчиков нельзя полностью охватить только количественными метриками или исключительно субъективными оценками. Вместо этого они предлагают комбинировать разные типы данных для более полного понимания картины. Интересно, что структура их модели учитывает влияние самих измерений на поведение: то, что измеряется, зачастую начинает влиять на поведение сотрудников, иногда вопреки изначальным целям.

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

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes