Can you prove AI ROI in Software Engineering? (Рубрика #AI)

Буквально недавно Егор Денисов-Бланш (Yegor Denisov-Blanch) выступил на конференции AI Engineer Code Summit 2025 в Нью-Йорке с таким провокационным докладом:) По-факту, это тизер результатов двухлетнего исследования влияния AI-инструментов на продуктивность разработчиков, охватывающего 120 000+ разработчиков в 600+ компаниях (такой охват как минимум внушает доверие). Кстати, предыдущее выступление Егора "Does AI Actually Boost Developer Productivity?" я уже разбирал и часть тезисов полностью повторяются, а точнее вопросы вида
1. Почему существующие оценки продуктивности ненадёжны?
2. Как выглядела методология ребят из Stanford?
3. Главные численные выводы исследования

Но в этом докладе есть и новенькие результаты

1. Медианный прирост продуктивности составляет ~10%, но разброс между лидерами и отстающими постоянно увеличивается.
2. Качество использования AI важнее объёма. Корреляция между количеством потраченных токенов и ростом продуктивности слабая (R² = 0.20). Более того, наблюдается эффект "долины смерти" на уровне 10 млн токенов на инженера в месяц - команды, использующие такой объём, показывают результаты хуже, чем те, кто использует меньше.​
3. Чистота кодовой базы критична для AI. Индекс "чистоты окружения" (Environment Cleanliness Index), учитывающий тесты, типы, документацию, модульность и качество кода, показывает корреляцию R² = 0.40 с приростом продуктивности от AI. Чистый код усиливает эффект от AI, а технический долг его нивелирует.​
4. AI ускоряет энтропию кодовой базы. Бесконтрольное использование AI ускоряет накопление технического долга, что сдвигает кодовую базу в зону, где AI менее эффективен. Требуется активное управление качеством кода для сохранения преимуществ.​
5. Доступ к AI ≠ эффективное использование. В кейсе с двумя бизнес-юнитами одной компании при равном доступе к инструментам использование было сильно разное. Важно измерять не только факт использования, но и как инженеры применяют AI.

Ну и собственно автор предлагает свою методологию для измерения ROI из двух частей
1. Измерение использования
Access-based (кто получил доступ) vs usage-based (телеметрия API). Usage-based - золотой стандарт, позволяющий ретроспективный анализ через git-историю.​
2. Измерение инженерных результатов
- Primary metric: Engineering Output - ML-модель, реплицирующая оценку панели из 10-15 независимых экспертов по сложности, времени реализации и поддерживаемости​
- Guardrail metrics: Rework & Refactoring, Code Quality & Risk, People & DevOps - метрики, которые нужно держать на здоровом уровне, но не максимизировать​

Забавно, что автор категорически против использования PR counts, lines of code и даже DORA как основных метрик продуктивности.​

Ну и если анализировать подход автора, то он содержит сильные и слабые стороны
(+) Исследовательская методология выглядит солидно. ML-модель, реплицирующая экспертные оценки, проверенная на корреляцию с реальными панельными данными - это правильный подход к измерению сложных качественных аспектов кода.
(+) Понимание системных эффектов. Концепция управления энтропией кодовой базы, связь между чистотой кода и эффективностью AI, понимание, что инженеры должны знать, когда не использовать AI
(+) Критика DORA как primary metric обоснована. DORA - это индикаторы процесса, а не результата. Их максимизация может вредить (вспомним Goodhart's Law)
(+)AI Practices Benchmark с уровнями зрелости (от личного использования до агентной оркестрации) показывает понимание эволюции практик.​
(-) Background автора не в чистой разработке - у него отсутствует опыт и образование как инженера
(-) ML-модель как чёрный ящик. Хотя утверждается, что модель коррелирует с экспертными оценками, детали методологии, датасет для обучения, метрики качества модели не раскрыты в докладе
(-) Environment Cleanliness Index экспериментальный. Как именно взвешиваются компоненты индекса? Как он валидирован кроме корреляции с продуктивностью?​

#Engineering #AI #Metrics #Software #DevEx #Productivity

Code of Leadership #58 - Interview with Vladimir Malov about tech management and vibe coding (Рубрика #Management)

Интервью с Владимиром Маловым, исполнительным директором финтех‑сервиса рассрочек +7 pay, который прошёл путь от iOS‑разработчика до СТО/СРО в e‑grocery и собрал крупные ИТ‑команды. В этом интервью мы обсудили с Владимиром его карьеру в общем, а также поговорили про подход к вайб-кодингу новых продуктов, а также Владиимир показал мини-демку создания приложения в Lovable. Итого, за полтора часа мы успели обсудить следующие темы

- Введение и знакомство с гостем
- Ранние карьера и "зигзагообразный" путь: Санлайт, Перекрёсток, Лента, Утконос и ценность горизонтальных переходов
- Детство, семья и образование
- Университет и первые уроки ответственности
- Вход в мобайл и первая продуктовая практика в Санлайт.
- Ритейл и онлайн‑доставка: Санлайт, Перекрёсток и Лента
- Переход из разработки в продакт‑менеджмент
- Роли техдира, предпринимательство и риск
- Бигтехи, ожидания и "синдром троечника"
- Любовь к созданию продуктов и появление новых инструментов
- Вайб‑кодинг в продакшене и демо
- Будущее вайб‑кодинга и агентский режим
- Личное, здоровье, фокус и нетворкинг

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

P.S.
Владимир ведет интересный канал https://t.me/malov_tech/

#Career #Engineering #Software #Management #Leadership

[1/2] AI, DevOps, and Kubernetes: Kelsey Hightower on What's Next (Рубрика #PlatformEngineering)

Посмотрел интервью Келси Хайтауэра с командой JetBrains про состояние индустрии в 2025 году. Помню как лет 7 назад изучал Kubernetes по его репозиторию Kubernetes The Hard Way, который был не прост, но помог мне сдать лабы для получения шилдика CKA (Certified Kubernetes Administrator) первым в компании. Это было в те времена, когда мы с моим коллегой Стасом (гостем из первого выпуска подкаста Code of Leadership), Андреем (гостем 43 выпуска Code ...) и Антоном (гостем 17 выпуска Code ..) продумывали как будем переезжать в Kubernetes с виртуалок:)

Но если возвращаться к Келси, то он уже завершил активную карьеру в Google и теперь может философски размышлять про devops и не только. Я выделил 5 тем, что были интересны мне в этом обсуждении

1️⃣ DevOps: Эволюция или провал?
Келси критически оценивает то, во что превратился DevOps во многих компаниях.
- "Футболка вместо навыков": Многие компании просто переименовали системных администраторов в DevOps-инженеров, не изменив суть работы. "О, теперь я DevOps-инженер, дадут ли мне за это футболку?" — иронизирует Келси.
- Правильная имплементация: DevOps был задуман как "чертеж" (blueprint), предполагающий расширение компетенций. Сисадмины должны были научиться программировать, а разработчики - понимать, как работает операционная система (например, тюнить JVM под ядро Linux).
- Проблема опыта: Келси упоминает людей, у которых "20 лет опыта, состоящих из одного и того же года, повторенного 20 раз" (20 years of one-year experience). Это те, кто просто чинит серверы, не пытаясь автоматизировать или изменить подход.
- Platform Engineering: Это не что-то принципиально новое, а эволюция DevOps. Это переход от "я починю сервер, когда он сломается" к созданию продукта (платформы) для внутренних клиентов.

2️⃣ Kubernetes и «скучные» технологии
- Kubernetes - это скучно (и это хорошо): Для stateless (веб) приложений Kubernetes стал скучным еще 6-7 лет назад. Келси сравнивает инфраструктуру с полетом на самолете: "Самолеты интересны только тогда, когда они делают не то, что мы ожидаем. Если при посадке люди хлопают - значит, что-то пошло не так. Мы хотим просто выйти из самолета и не думать о полете".
- Инфраструктура не должна вызывать восторг: Если ваша инфраструктура вызывает у вас сильные эмоции, значит, вы боретесь с поломками или трением. Восторг должен вызывать продукт, который вы строите поверх неё.
- Будущее Kubernetes: Если через 20–30 лет мы всё еще будем обсуждать Kubernetes, это будет провалом индустрии. Мы должны придумать что-то лучшее. Kubernetes должен стать просто деталью реализации (как BIOS или машинный код), скрытой под более удобными абстракциями.

3️⃣ API, Silos (Колодцы) и взаимодействие команд
Келси делает контринтуитивное заявление: "Мне нравятся silos (изолированные команды)", но при наличии четкого API.
- Аналогия с авиабилетом: Когда вы летите в другую страну, вы не идете в кабину пилота обсуждать маршрут. Вы покупаете билет. Билет - это API (контракт). Вы садитесь в кресло, засыпаете и просыпаетесь в другом месте.
- API как контракт: Платформенная команда и разработчики не должны сидеть рядом и постоянно разговаривать. Они должны взаимодействовать через четкий контракт (API): "Мне нужно столько-то памяти, такой-то регион, такая-то версия".
- Когда нужно общение: Разговаривать нужно только тогда, когда вы хотите изменить API или добавить новую фичу в платформу. Для рутинного деплоя общение - это лишние накладные расходы.
Забавно, что примерно эти же моменты про взаимодествие команд мы разбирали со Стасом Халупом в первом выпуске Code of Leadership.

Оставшиеся темы про AI и важность soft skills обсудим в продолжении разбора этого крутого интервью.

#Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes

[2/2] AI, DevOps, and Kubernetes: Kelsey Hightower on What's Next (Рубрика #PlatformEngineering)

В продолжении разбора интервью Келси нужно упомянуть темы AI и важности soft skills

4️⃣ Искусственный интеллект (AI)
Хайтауэр скептичен к хайпу, но видит фундаментальную пользу.
- AI как новый DSL: Келси смеется над "Prompt Engineering", когда люди чекинят в git 500 markdown-файлов с промптами и версионируют их. По сути, мы изобрели еще один, очень нестабильный язык программирования.
- Недетерминированность: Всю карьеру инженеры боролись за предсказуемость (тесты, идемпотентность), а теперь мы внедряем AI, который по своей природе вероятностный ("Зачем гадать, если можно знать наверняка?").
- Главная польза AI: Он заставил вендоров и разработчиков наконец-то написать нормальные API и документацию, чтобы LLM могли с ними работать. То, что мы должны были сделать для людей (хорошие доки и интерфейсы), мы теперь делаем для роботов.
- Guardrails (Ограничения): В итоге все равно все сводится к созданию жестких рамок (guardrails), чтобы заставить AI выдавать предсказуемый, "скучный" результат.

5️⃣Развитие: Человек vs Инженер
В конце интервью фокус смещается на soft skills и личностный рост.
- Командный спорт: Келси сравнивает работу в IT с баскетболом или футболом, а не с легкой атлетикой. В беге ты побеждаешь или проигрываешь один. В IT, каким бы крутым инженером ты ни был, ты зависишь от команды.
- Эмпатия: Это не просто "быть милым". Это понимание того, что если разработчик боится деплоить в пятницу, проблема может быть не в его трусости, а в ненадежности платформы, которую вы построили.
- Профессионализм и «Ящик с инструментами»: Не будьте просто «коллекционером» инструментов. Профессионал регулярно перебирает свой ящик с инструментами (toolbox), чистит их и выбрасывает ненужные.
- Дисциплина важнее любопытства: В профессиональной среде нельзя тащить в продакшн Rust или новую технологию только потому, что вам "любопытно". Выбирайте инструменты, которые решают задачу бизнеса, а не тешают эго инженера.

#Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes

Искусственный интеллект в России — 2025: тренды и перспективы (Рубрика #AI)

В эти выходные я внимательно прочитал полный отчет, который подготовили консалтинговая компания «Яков и Партнёры» совместно с Яндексом (бизнес-взгляд + технологическая экспертиза). Отчет опирается на три источника данных: опрос 150 технических директоров крупных компаний (из 16 отраслей), опрос 150 вендоров AI решений, опрос 3500+ жителей России. Кроме этого были проведены глубинные интервью с лидерами индустрий - чтобы заглянуть под поверхность цифр. Краткий разбор результатов есть на лендинге организаторов, где есть цитаты вида

Согласно опросу СТО, за два года генеративный ИИ вышел далеко за рамки точечных экспериментов: среднее количество функций, где запущены пилоты или полное внедрение, выросло с 2,4 в 2023 г. до 3,1 в 2025-м, а сама технология используется уже в 80% ключевых бизнес-функций

Про восприятие таких цитат я уже упоминал в посте "Опросы руководителей и связь с реальностью", но сегодня я расскажу про общую структуру отчета и те моменты, что показались мне интересными:
- Авторы исследовали четыре ключевых направления развития ИИ к 2025 году: genAI, NLP & Speech, CV, RecSys. Эти технологии используются в компаниях и являются драйверами роста. В самом отчете разюираются тренды по каждому из этих направлений
- Структура отчета примечательна
-- Сначала приводится картина общего состояния рынка AI в России и уровня внедрения технологий, с оценкой экономических эффектов от внедрения ИИ
-- Далее следуют детальные главы по каждой из 4 технологий: где используются, как прогрессируют, какие кейсы наиболее популярны
-- В заключении авторы делятся общим саммари и своим взглядом на будущее, а также приводят рекомендации для всех
Основные выводы можно почерпнуть из заключения и я попробую их тезисно рассказать

Генеративный ИИ - это горизонтальная платформа
Авторы подчёркивают, что GenAI теперь рассматривается не как отдельная технология, а как горизонтальная основа, которая пронизывает и преобразует все остальные направления (NLP, CV, RecSys). GenAI становятся универсальной средой, на базе которой можно решать самые разные задачи.

Эра foundation-моделей и агентных систем.
Рынок вступает в новую фазу, где на сцене доминируют базовые модели (foundation models) и автономные ИИ-агенты. Современные большие модели больше не пассивные хранилища знаний - они превращаются в активных исполнителей. Появляются протоколы взаимодействия между ними, и вместо привычных приложений мы всё чаще будем работать с умными сервисами, которые действуют от нашего имени.

Барьеры внедрения AI уже на только в “железе”
Если раньше главными ограничениями были технологии и доступ к мощностям, то теперь ключевые барьеры - организационные и инфраструктурные. Внедрению ИИ мешают не отсутствующие алгоритмы, а стоимость масштабирования (инфраструктура, инференс, перестройка процессов) и консерватизм компаний и пользователей.

Будущее AI в РФ по версии авторов: перспективы весьма оптимистичные
Российская AI-экосистема входит в фазу масштабирования. По оценкам, к 2030 году эффект от ИИ для экономики РФ может достигнуть 7,9–12,8 трлн ₽ в год (≈5,5% ВВП) - это сопоставимо с прибылью всей банковской отрасли! При этом дело не только в снижении затрат, но и в росте выручки за счёт новых продуктов и персонализации сервисов. Авторы уверены: через несколько лет внедрение ИИ станет вопросом выживания для большинства компаний

В конце авторы отчета раздали советы всем
- Бизнесу - строить единые AI-платформы для моделей/данных/инструментов, по возможности в облаке для гибкости. Фокусироваться на нескольких приоритетных кейсах внедрения и трезво планировать эффект (12–24 мес на окупаемость, а не ждать чудес завтра).
- Государству - расширить меры поддержки AI-инициатив: гранты, субсидии на R&D, налоговые льготы и доступное финансирование, ...
- Пользователям - не отставать: системно осваивать AI-инструменты в учёбе и работе, прокачивать навыки работы с данными и критически оценивать результаты работы моделей.

#Engineering #AI #Metrics #Software #Productivity #Economics

Code World Model: Building World Models for Computation (Рубрика #Software)

Посмотрел интересный доклад Jacob Kahn, исследователя из FAIR (что является частью запрещенной в России компании Meta). В этом докладе Якоб представляет сдвиг парадигмы в обучении моделей для генерации кода: переход от обучения на синтаксисе к обучению на семантике через world modeling. Расширенную версию этого концепта можно почитать в whitepaper, а также потрогать в репо на GitHub. Если же говорить про ключевые идеи выступления, то они такие

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

2️⃣ World modeling для кода
CWM (code world model) воплощает подход, где модель обучается не только на статическом коде, но и на данных исполнения программ (observation-action trajectories). Это включает трейсы выполнения Python (где действия - это Python-выражения, а наблюдения - содержимое локальных переменных) и агентные взаимодействия в Docker-окружениях.

3️⃣ Архитектура модели и ее обучение
Модель имеет 32 миллиарда параметров с уникальной системой чередующегося внимания (local attention с окном 8192 токена и global attention с окном 131072 токена в соотношении 3:1). Обучение состоит из трёх этапов: pre-training, mid-training на 5 триллионах токенов данных world modeling, и post-training с reinforcement learning через GRPO на ~172 миллиардах токенов.

4️⃣ Новые возможности
CWM может служить "нейронным отладчиком" - симулировать исполнение кода шаг за шагом, предсказывать значения переменных без реального запуска, самостоятельно тестировать и исправлять код.

Меня заинтересовала история амбициозного названия про "world model" и оказалось, что это название обусловлено несколькими причинами
- Название отсылает к классической работе Ha & Schmidhuber (2018) "World Models", которая предложила обучать модели на сжатых пространственных и временных представлениях среды в reinforcement learning. CWM переносит эту идею в область кода - среда теперь это вычислительная система.
- Доклад и статья позиционируют CWM как "фундамент для будущих исследований и прототипирования в AI-driven software systems". Это заявка на создание новой исследовательской парадигмы, а не просто улучшенной модели.
- Meta активно продвигает концепцию world models через разные проекты команды - от Chameleon (multimodal early-fusion модели) до Transfusion (комбинация language modeling и diffusion). Причем Jacob Kahn, спикер этого доклада, был соавтором обоих этих проектов:)

Если добавить немного дегтя во все саммари, то пока неясно насколько возможности world modeling capabilities переносятся на языки программирования, что модель не видела, на сложные кодовые базы и на долгосрочную поддержку созданного кода.Необходимость трёхэтапного RL с self-bootstrapping для достижения заявленных результатов поднимает вопрос: это фундаментальное преимущество или просто следствие масштаба и тщательной работы с данными. Но в любом случае это интересная научная работа, которая обладает большим потенциалом и будет интересно следить за развитием этой идеи.

#Engineering #AI #Software #ML #Whitepaper

Meta’s Yann LeCun targets €3bn valuation for AI start-up (Рубрика #AI)

В статье рассказывается про новый стартап Яна Лекуна, одного из двух главных учёных по ИИ в запрещенной в России компании Meta. С 2013 года он возглавлял исследовательскую лабораторию FAIR в Facebook/Meta, которая под его руководством стала одной из ведущих в мире, но в конце этого года он уходит. А уходит он в свой стартап Advanced Machine Intelligence Labs (AMI Labs) и поднимает на него €500 млн при оценке порядка €3 млрд. Основной замысел - построить "следующее поколение" ИИ, которое будет лучше понимать физический и причинно-следственный мир, а не просто предсказывать следующий токен, как это делают современные LLM.

Интересно, что уход Лекуна происходит на фоне крупной реорганизации внутри Meta, которую я уже разбирал. Если кратко, то Марк Цукерберг переориентировал Meta AI с долгосрочных исследований на быструю коммерциализацию ИИ-продуктов. Летом 2025 года в компании появилось новое подразделение - Meta Superintelligence Labs под руководством приглашенного извне специалиста Александра Вана. А дальше Meta направила огромные ресурсы на разработку больших языковых моделей, активно переманивая ведущих экспертов. Одновременно было сокращено или переведено около 600 сотрудников исследовательского подразделения, и компания лишилась нескольких ключевых ученых. В такой обстановке фундаментальные проекты Лекуна отошли на периферию, и ему стало значительно труднее получить ресурсы на свою работу. Его уход символизирует конфликт между погоней за мгновенным результатом и долгосрочными амбициями в исследованиях ИИ
​
Если говорить про Advanced Machine Intelligence Labs, то стартап планирует официально объявить о себе публично в начале 2026 года и стать одним из ключевых игроков нового поколения в AI-индустрии, конкурируя не только технологиями, но и видением того, каким должен быть интеллект в машинах.

P.S.
Кстати, Code World Model, про которую я писал сегодня - это пример работы FAIR на тему "world model", за которые топит Ян Лекун

#AI #ML #Software #Economics #Engineering #Management #Leadership #Future #Startup