Книжный куб

DORA 2025 - State of AI-assisted Software Development - Общая информация по отчету (Рубрика #Devops) Я уже как-то кратко рассказывал про исследование "DORA Research: 2025" в одном из прошлых постов. Тогда я внимательно прочитал отчет, но тогда рассказал про его результаты очень кратко. А сейчас мне потребовался более подробный разбор для нашего исследования влияния AI на инженерную культуру и я решил расписать его и для своих подписчиков. Отчет “State of AI-assisted Software Development 2025” подготовлен исследовательской командой программы DORA (DevOps Research and Assessment), что является частью Google Cloud. Ведущими авторами стали специалисты Google Cloud при участии приглашенных экспертов. Партнерами исследования были IT Revolution, GitHub, GitLab, SkillBench и Workhelix. Кроме того инициативу поддержал ряд спонсоров (Swarmia, Thoughtworks, Deloitte, Atlassian и др.). В рамках исследования был проведен глобальный опрос почти 5 000 технических специалистов из разных стран и компаний. Респонденты включали инженеров-разработчиков, DevOps/SRE, тимлидов, продакт-менеджеров. Опрос охватил широкий спектр тем: от степени и способов использования ИИ (какие инструменты и LLM-модели применяются, для каких задач, сколько времени тратится, как часто доверяют советам ИИ) до характеристик команд и процессов (архитектура и платформы разработки, культура обучения, Value Stream Management, практики контроля версий, размер батчей изменений и т.п.). Также оценивались результаты работы команд: классические метрики DORA (например, скорость доставки и стабильность выпуска ПО), качество кода, продуктивность разработчиков, частота фрикций в работе и выгорание сотрудников. Для углубления анализа исследователи собрали и более 100 часов качественных данных – интервью и разборов практик, чтобы дополнить цифры живыми инсайтами. Интересно, что полгода назад я рассказывал про то, как работает методология DORA для составления таких отчетов, но для отчета 2025 авторы отдельно описали "Measurement Framework" и то, как это можно использовать для управления изменениями в своей компании. Если же говорить про самих ребят и их отчет DORA 2025, то обработка данных сочетала статистические и аналитические методы. Масштабный опрос позволил провести корреляционный анализ и регрессионные модели, выявляя взаимосвязи между практиками и итоговыми показателями эффективности. В итоге, получился отчет состоящий из следующих частей - "Beyond the tools": обсуждается, почему успешное внедрение ИИ – это системная задача, а не просто выбор инструмента. - Анализ текущего состояния AI-assisted разработки: представлены результаты опроса об уровне адаптации ИИ в индустрии, о практиках использования и влиянии на ключевые показатели. - "Understanding your teams: 7 profiles": в этом разделе DORA представляет обнаруженные семь архетипов команд разработки - "DORA AI Capabilities Model": центральная глава, вводящая новую модель способностей для успеха с ИИ. Здесь подробно перечисляются семь технических и культурных практик (системных факторов), которые статистически усиливают положительное влияние ИИ на эффективность команд - "Directing AI’s potential": раздел, посвященный тому, как направить усилия по внедрению ИИ в правильное русло. В частности, разбирается роль Value Stream Management (VSM) как механизма, позволяющего конвертировать локальные улучшения от ИИ в конечный результат для бизнеса - Рекомендации и выводы для лидеров: заключительная часть отчета переводит результаты в практическую плоскость. Здесь дается “дорожная карта” для внедрения ИИ – на каких направлениях сфокусироваться в первую очередь. В отчете прямо говорится, что руководители должны рассматривать внедрение AI как трансформацию организации, а не просто ИТ-проект P.S. В комментариях приложу сам PDF с отчетом. #AI #Software #Engineering #Management #Whitepaper

Вот теперь вид по утрам из окна напоминает зимний, хотя снега все равно маловато будет:)

Leadership in AI Assisted Engineering (Рубрика #AI) Интересный доклад Justin Reock, Deputy CTO компании DX (ее недавно купила Atlassian за $1 млрд). Reock известен своей работой по измерению и оптимизации developer productivity, что делает его одним из ведущих голосов в индустрии по вопросам внедрения AI в разработку. В этом докладе он рассказывал про продуктивность инженеров и приводил много отсылок к исследованиям, о которых я уже раньше рассказывал. Ниже я привел основные тезисы доклада 1️⃣ Парадокс AI-продуктивности: огромная вариативность результатов Вопреки хайпу, реальное влияние AI на продуктивность крайне неоднородно. Например, Сундар Пичай, CEO Google, в июне 2025 рассказывал про 10% увеличения engineering capacity. И тем же летом исследование METR показало 19% замедление работы с AI - хотя разработчики чувствовали себя на 20% быстрее. Я разбирал это исследование в постах 1 и 2 и даже в подкасте RIMS, где показано, что само исследование задизайнено под конкретный результат + представляет очень узкий кейс. Если ориентироваться на данные платформы DX, где представлены 300+ компаний, то средние показатели выглядят скромно: +7.5% качество документации, +3.4% качество кода, +2.6% confidence в изменениях, -1% change failure rate. Но если смотреть на вариативность результатов, то некоторые видят +20% улучшение метрик, другие 20% ухудшение метрик. Кажется, что это обусловлено подходом к внедрению AI и измерению эффектов 2️⃣ Психологическая безопасность - фундамент AI-трансформации Автор презентации вспомнил про Project Aristotle от Google, которому почти 15 лет. Тогда ребята из Google решили провести исследование команд и ответить на вопрос "What makes a team effective at Google?". Ответом стал такой фактор как psychological safety. Подробнее про исследование я уже рассказывал. Фактор психологической безопасности важен при внедрении AI - Страх замены AI приводит к саботажу внедрения - Без доверия люди не экспериментируют с инструментами - Необходима прозрачная коммуникация: AI дополняет, а не заменяет 3️⃣ W. Edwards Deming: 95% - система, 5% - люди Эдвард Деминг говорил о том, что 90-95% производительности определяется системой (процессы, инструменты, культура). А вот остальное зависит от индивидуальных качеств работника. Если это переносить на процессы разработки, то - Performance reviews, individual coaching - работа на 5%, трата человеческого таланта - Фокус должен быть на оптимизации системы: инфраструктура, workflows, developer experience - Если что-то идёт не так - ищите проблемы в системе, а не в людях 4️⃣ DX AI Measurement Framework: три измерения успеха Спикер рассказал подход про измерение эффектов AI по трем осям - Utilization (Использование) - Impact (Влияние) - Cost (Стоимость) Подробнее я рассказывал про подход ребят раньше в разборе + в моем подкасте вместе с Женей Сергеевым. Но если говорить про мысли спикера, то он говорит, что baseline в виде стандартных метрки developer productivity (DORA, SPACE) важнее AI-специфичных метрик - они показывают реальное влияние на outcomes. 5️⃣ Интеграция AI по всему SDLC, а не только в coding Для большинства организаций написание когда никогда не было узким местом - часто они были в других местах: поиске информации и контекста, задержек code reviews, сложностей координации, работы с инцидентами и легаси кодом. Дальше автор привел ряд примеров внедрения AI в разных компаниях: Morgan Stanley, Zapier, Spotify, Booking. 6️⃣ Топ-5 приоритетов для лидеров 1. Снизить страх AI через прозрачность 2. Вложиться в образовании сотрудников + выделить время на эксперименты 3. Вндерить измерения и начать открытую дискуссию о метриках 4. Unblock usage - внедрить креативный подход к compliance 5. Создать цтиклы обратной связи для непрерывного улучшения #Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership #Economy #Metrics

Топ-3 книги издательства Питер, что я могу порекомендовать в этом году (Рубрика #Software) Все три приведенные ниже книги я считаю стоящими, но надо отметить, что читал я их еще в оригинале и в тот момент, когда они были опубликованы (на русском я их пока не перечитывал) 1️⃣ AI-инженерия. Построение приложений с использованием базовых моделей Последние годы проходят во многом под знаком AI. Уровень хайпа просто бомбический, но это не значит, что за хайпом ничего не стоит, а сами технологии ничего не дают. Напротив, результаты есть и они масштабные, но только у тех, кто умеет пользоваться инструментом правильно. А эта книга как раз про то, как строить приложения с использованием фундаментальных моделей. Я уже рассказывал про эту книгу раньше и считаю, что она будет полезна инженерам 2️⃣ Паттерны проектирования API Про эту книгу я тоже рассказывал раньше, но в рамках хайпа про AI она мне кажется становится важнее. Суть в том, что 2025 год прошел под знаком AI агентов и эта движуха дальше будет только разгоняться - осенью 2024 года был представлен протокол MCP (model context protocol), который описал формат API вызова инструментов моделями, весной 2025 года Google представил A2A протокол (agent to agent), но все эти штуки живут поверх хороших подходов к управлению API. А эта книга как раз про это, причем автор, Джей Джей Гивакс, работал в Google и был соавтором статьи "API Governance at Scale" про подходы в Google (см. мой разбор). Он же был сооснователем ресурса aip.dev и одним из главных идеологов процесса AIP (API Improvement Proposals), про который я рассказывал раньше. Интересно, что с момента издательства книги Джей Джей уже успел перейти в Meta (видимо там тоже нужно поработать над API Governance). 3️⃣ Распределенные данные. Алгоритмы работы современных систем хранения информации Про эту книгу "Database Internals" я уже рассказывал и мы даже ее разбирали в подкасте "Code of Architecture". Если подвязывать эту книгу к теме AI, то можно много сказать про хранение данных, про важность их для контекста ... Но я не буду этого делать - я выбрал эту книгу, потому что она хорошо рассказывает про движки для хранения данных, а также про архитектуру распределенных систем. Автор книги, Алекс Петров, контрибьютил в Cassandra, поэтому у него релевантный опыт для рассказа об этих темах. В общем, книги достойные - я получил большое удовольствие, когда их изучал:) #Databases #Software #Engineering #Architecture #AI #ML #DistributedSystems #Architecture #API

The Infinite Software Crisis (Рубрика #AI) Посмотрел на выходных интересный доклад Джейка Нэйшнса (Jake Nations), staff engineer из Netflix. Джейк занимается встраиванием AI инструментов в процессы разработки в Netflix, а в этом докладе он делится трезвым взглядом инженера о том, как генеративный код ломает архитектуру. Если говорить про ключевые тезисы, то они такие 1️⃣ Бесконечный кризис софта Исторически (от Дейкстры в 60-х до Cloud Native) каждый новый инструмент обещал решить проблему сложности, но лишь позволял нам строить еще более запутанные системы. AI просто разогнал этот процесс до предела. 2️⃣ Vibe Coding => Tech Debt Разработка через чат-интерфейс (conversational interface) - это ловушка. Архитектура начинает зеркалить вашу беседу: каждое уточнение "а поправь еще это" наслаивается поверх предыдущего, создавая спагетти-код с мертвыми ветками логики. Интересно, что я сейчас пробую разрабатывать в Lovable и вижу как мои запросы приводят к появлению архитектуры (правда, я еще и в привязанном GitHub вижу как и какой код появляется) 3️⃣ Simple vs Easy Джейк цитирует Рича Хики: - Easy - это то, что под рукой: скопировать со StackOverflow или попросить AI сгенерить портянку кода - Simple - это отсутствие переплетений (entanglement) AI делает часть про "easy" почти бесплатным, но убивает "simple", так как агенты не умеют отличать "существенную" сложность задачи от "случайной" (наследия костылей) 4️⃣ Решение что предлагает Джейк Использовать трёхфазный метод, чтобы не утонуть в хаосе, нужно вернуть инженерную строгость и разделить процесс: - Research. Скормить агенту доки и диаграммы, чтобы он составил карту системы. Обязательно вычитать и поправить вручную - Planning. Написать спецификацию изменений (вплоть до сигнатур функций). План должен быть настолько детальным, чтобы джун мог реализовать его механически (paint-by-numbers). - Implementation. Только теперь запускать генерацию. Вы ревьюите соответствие плану, а не пытаетесь угадать, что там нафантазировал AI. Если подумать об этом, то мы входим в эпоху, где написание кода стоит примерно 0. И главным дефицитом становится понимание системы (context & understanding. Если раньше вы могли "прочитать" код и понять, как он работает, то в мире, где джун генерирует 10к строк за вечер, это становится невозможным. Техлидам придется сместить фокус с код-ревью на дизайн-ревью и валидацию планов. Те, кто продолжит просто "чатиться с кодом", скоро обнаружат у себя в проде системы, которые невозможно поддерживать и безопасно изменять. В докладе Джейк опирается на классику Software Engineering, которую стоит перечитать: - Fred Brooks, "No Silver Bullet" (1986) - Rich Hickey, "Simple Made Easy" (2011) - Edsger W. Dijkstra, "The Humble Programmer" (1972) #DevOps #AI #Architecture #Culture #Engineering #ML #Future #Software

Atlassian покупает платформу DX (developer experience) за $1 млрд - причины и последствия (Рубрика #DevEx) 18 сентября 2025 года компания Atlassian официально объявила о приобретении платформы DX (Developer Experience) приблизительно за $1 млрд с оплатой наличными средствами и акциями Atlassian (крупнейшее поглощение в истории Atlassian). DX представляет собой платформу инженерной аналитики, которая позволяет организациям оценивать продуктивность команд разработки и выявлять "узкие места" в их процессах. Мне это поглощение интересно тем, что среди создателей DX есть авторы подходов DORA, SPACE, DevEx, про которые я много рассказывал. Руководство Atlassian объясняет покупку DX стратегическим стремлением помочь своим клиентам эффективнее использовать инвестиции в ИИ и улучшить работу инженерных команд. Компания отмечает, что всё больше предприятий вкладываются в инструменты искусственного интеллекта, но сталкиваются с вопросом, приносят ли эти вложения реальную отдачу в ускорении разработки (DX недавно опубликовали методологию "Measuring AI code assistants and agents") Дополнительным обоснованием сделки стал синергетический эффект: около 90% клиентов DX уже используют продукты Atlassian (Jira, Confluence, Bitbucket и др.), что сделало DX очевидным кандидатом для присоединения. Кэннон-Брукс, соучредитель и CEO Atlassian, отмечал, что Atlassian несколько лет пыталась создать собственный инструмент для анализа продуктивности инженеров, однако в итоге решила приобрести готовое решение (сам стартап DX был основан 5 лет назад) Atlassian планирует глубоко интегрировать DX в свою экосистему. В октябре 2025 года CTO Atlassian представил новый комплект Atlassian Software Collection, куда DX вошла в качестве новейшего компонента: платформа DX дополняет существующие решения, объединяя качественные опросы разработчиков с количественными метриками такими, как время прохождения pull request, частота сбоев сборки и уровень использования AI-инструментов. Данные DX будут напрямую доступны в продуктах Atlassian, а также DX продолжит поддерживать интеграции и с сторонними инструментами, чтобы клиенты могли извлекать пользу из DX независимо от стека Atlassian. В будущем пользователям Atlassian станут доступны следующие возможности благодаря интеграции DX - Измерение продуктивности и узких мест: система автоматически собирает ключевые показатели развития софта (скорость цикла код-ревью, частоту неудачных билдов, время внедрения фич) и выявляет узкие места в процессе - Аналитика использования ИИ: DX позволяет отслеживать, как активно и с каким эффектом разработчики применяют AI-инструменты (код-ассистентов, агентов и пр.), отсекая шум и показывая реальную отдачу от AI-внедрений. - Оценка опыта разработчиков: Помимо технических метрик, DX регулярно собирает качественные данные об опыте инженеров (опросы удовлетворённости, индексы Developer Experience). Совмещая цифры с мнением самих разработчиков, платформа определяет, что мешает людям работать продуктивно, и где возникают точки напряжения в взаимодействии команд В целом, покупка DX сигнализирует о появлении в линейке Atlassian нового класса функций - “инженерной аналитики” - благодаря которому разработчики и менеджеры смогут совместно измерять и улучшать продуктивность, основываясь на данных, а не интуиции. Atlassian позиционирует этот шаг как часть более широкой стратегии по созданию интегрированной платформы для управления разработкой в эпоху ИИ, где связаны воедино планирование (Jira/Confluence), выполнение (код и CI/CD) и анализ эффективности (DX) для непрерывного совершенствования процесса создания софта #AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops

From Vibe Coding To Vibe Engineering (Рубрика #AI) Посмотрел юморное выступление Kitze (Кристияна Ристовски), состоявшееся в конце 2025 года на саммите AI Engineer. Спикер - заметный в сообществе фронтенд-разработчик и предприниматель, что известен своим саркастичным подходом к современной веб-разработке, которую он критикует излишнюю сложность инструментов (Webpack, конфигурации) и пропагандирует подход "Just Ship It". В этом докладе Kitze утверждает, что "vibe coding" веселый способ создания пет-проектов, но для реальной работы нужно превратить это в "vibe engineering. Если говорить про тезисы, то вот они 1️⃣ Спираль смерти (The Doom Loop) Проблема с vibe coding в том, что как только вы начинаете вручную править код, написанный ИИ, вы ломаете «вайб». Вы тратите время на чтение чужого (машинного) кода, пытаетесь его понять, вносите правку, а потом при следующей генерации ИИ может затереть ваши изменения или перестать понимать контекст. Решение от Kitze в том, что если ИИ написал баг, не чините его руками. Заставьте ИИ починить его. Это требует дисциплины, но это единственный способ сохранить скорость. Вы должны стать менеджером, который не делает работу за стажера, а заставляет стажера переделать задачу правильно. 2️⃣ Контекст - это всё Обычный vibe doding ломается на больших проектах, потому что ИИ «забывает» или не знает структуру всего проекта. А "vibe engineering" - это уже построение инфраструктуры вокруг LLM, которая автоматически скармливает модели весь актуальный контекст проекта (структуру файлов, типы, документацию) перед каждым запросом. Kitze показывает, что вместо написания кода он теперь пишет скрипты и промпты, которые собирают контекст для ИИ. Это и есть новая инженерия. 3️⃣ От синтаксиса к семантике Разработчик перестает быть "писателем кода" и становится "архитектором намерений". Ваша задача - четко описать что должно произойти, а как это будет написано (на React, Vue или чистом JS) - становится вторичным. Интересно, что автор предлагает эволюцию названия и подходов: - "Vibe coding": "Я попросил Claude сделать змейку, и оно работает. Прикольно". Это хаотичный процесс, случайный результат. - "Vibe engineering: "Я построил конвейер, где ИИ имеет доступ ко всей моей базе кода, знает мои линтеры и тесты, и я могу надежно генерировать сложные фичи, управляя процессом через промпты и тесты". Это уже похоже на инженерию Kitze аргументирует, что мы должны перейти от стадии "игры" с ИИ к стадии профессионального встраивания ИИ в инженерные процессы. Если подумать о том, а как предложенные изменения влияют на индустрию, то получим следующее - Vibe coding опасен для новичков. Если ты не можешь верифицировать результат (не понимаешь архитектуру), ты создашь монстра. Новички теперь должны учиться не синтаксису for loop, а системному дизайну и проверке качества. - Опытный инженер - становится супер-продуктивен. Если он знает что хочет получить, то с помощью vibe engineering может заменить целую команду из 3-5 человек. Kitze приводит пример, как он переписал огромные куски Sizzy за дни, а не месяцы (sizzy - это браузер для разработчиков и qa-инженеров) - DevEx меняется - раньше мы оптимизировали подсветку синтаксиса и автодополнение. Теперь DX - это то, насколько легко ваш проект "читается" нейросетью. Если ваш код непонятен для LLM, вы проиграли. Ну и однострочные выводы из доклада звучат так - Не пишите код, управляйте им. Лучший код - тот, который вы не писали руками. - Инвестируйте в контекст. Научитесь создавать инструменты, которые позволяют ИИ "видеть" ваш проект целиком. - Сопротивляйтесь желанию "быстро поправить руками". Это ловушка, которая возвращает вас в старую парадигму и замедляет в долгосрочной перспективе. - Код становится эфемерным. Мы привыкли беречь код. В эпоху vibe engineering код можно легко удалить и сгенерировать заново, если он перестал соответствовать требованиям. Ценность - в описании задачи, а не в файле с кодом. #Engineering #AI #Software #ML #DevEx #Productivity #IDE

AI-инженерия. Построение приложений с использованием базовых моделей (AI Engineering) (Рубрика #AI) Книгу "AI Engineering" уже перевели и скоро выпустят в издательстве Питер. А я эту книгу прочитал на английском еще в начале года и она мне супер зашла (мы ее вместе с Женей Сергеевым из Flo почти целиком разобрали за три серии подкаста: 1, 2 и 3). Собственно, книга отлична подходит инженерам, что строят GenAI‑продукт прямо сейчас, например, чат‑бот, copilot, RAG, ... Книгу написала Chip Huyen, которая - Преподавала Machine Learning Systems Design в Stanford (CS329S), а значит умеет объяснять системно и доступно - Написала книгу "Designing Machine Learning Systems" (O’Reilly), которую многие считают must‑read для инженеров из ML/Platform команд - Работала на стыке AI + инфраструктуры (NVIDIA, Snorkel AI), сейчас - Voltron Data (GPU‑ускорение аналитики) Есть несколько факторов почему "AI Engineering" стала бестселлером 1. Попала в боль 2024–2025: команды массово интегрируют базовые модели, и нужен инженерный фреймворк, а не очередной набор промптов 2. Большой фокус был на evaluation: не “vibe check”, а измеримые метрики, регрессионные наборы, LLM‑as‑a‑judge, тестирование на деградации 3. Закрывает прод‑реальность: стоимость и латентность инференса, мониторинг, качество данных/фидбек‑лупы, безопасность и риск‑менеджмент 4. Даёт карту паттернов (prompting, RAG, fine‑tuning, tools/function calling, agents) и отвечает на главный вопрос: когда что выбирать 5. У книги есть публичные материалы/ресурсы (репо на 12.5к звездочек), поэтому вокруг неё быстро выросла “экосистема” практик Вот чем может быть полезна эта книга инженерам, которые уже пилят GenAI - Превращает "демку на фреймворке" в проект: требования → архитектура → eval harness → релиз → наблюдаемость - Помогает говорить на одном языке с Product/Platform: какие SLO/SLI у LLM‑фичи, что логируем, где делаем гейтинг качества, как считаем cost‑per‑request - Хороша для техлидов: много про компромиссы (качество vs цена, контекст vs retrieval, детерминизм vs креативность) и про то, где чаще всего “ломается” система Мини‑чеклист из книги, который можно использовать хоть завтра: - Golden кейсы + негативные кейсы (и регулярные регрессионные eval’ы) - Версионирование промптов/моделей/ретривера + логирование контекста - Метрика "стоимость ответа" + бюджет на фичу - Eval гейты в CI перед деплоем (как unit/integration, только для LLM) В общем, книга определенно заслуживает прочтения. Кстати: пока книга еще в предзаказе на нее действует скидка в 35% при использовании промокода "Предзаказ" #Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems

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

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

Основы глубокого обучения (Fundamentals of Deep Learning) (Рубрика #AI) Недавно я дочитал первое изданние этой книги, что вышла на английском еще в далеком 2017 году:) Автор в 20 лет закончил MIT, в 2016 стартанул компанию Remedy для применения ИИ в здравоохранении, а в 2020 году - Ambience Healthcare, разрабатывающую «ambient AI» платформу, помогающую врачам автоматизировать рутинную документацию. Еще он известен в сообществе ИИ как автор одной из первых популярных книг по глубокому обучению. Если говорить про книгу, то я прикупил ее лет 5 назад, потому, что мне понравилось доступность изложения, я полистал ее, а потом отложил, прочитав половину книги и дальше никак не мог дочитать. За время "чтения" вышло второе обновленное издание книги в мае 2022 года, а я дочитал ее только вчера. В первом издании книги хорошо раскрыты многие начальные моменты и "state of the art" до момента появления "Attention is all you need", поэтому с одной стороны она серьезно подустарела, а с другой она неплохо охватывает уже классические темы от основ математического аппарата до построения и обучения разных типов нейросетей. В начале рассматриваются необходимые элементы линейной алгебры и теории вероятностей, после чего вводится понятие нейронных сетей и алгоритм обратного распространения ошибки. После этотго автор знакомит читателей с классическими архитектурами: полносвязные сети и вопросы их обучения (градиентный спуск, проблема переобучения и т.п.), сверточные нейронные сети для анализа изображений, модели для анализа последовательностей (рекуррентные сети, обработка естественного языка), а также методы снижения размерности (например, автоэнкодеры). Отдельные главы посвящены генеративным моделям (включая основы GAN/Variational Autoencoder), интерпретируемости моделей и даже обсуждаются базовые идеи обучения с подкреплением. Книга носит прикладной характер: ключевые идеи подкреплены примерами кода на Python. В первом издании (2017) для иллюстраций использовалась библиотека TensorFlow, а во втором издании 2022 года примеры обновлены на PyTorch (что отражено в добавленной главе об имплементации сетей в PyTorch). Код примеров открыт - читатель может не только изучить теорию, но и сразу попробовать реализовать основные модели нейросетей своими руками. В целом, тематический охват книги достаточно широкий, позволяя получить цельное представление о глубоком обучении: от базовой математики до основных типов нейросетевых архитектур и их применения на практике. В 2017 году книга была хорошо принята аудиторией и общее мнение было таким, что Будума смог объяснить сложные вещи простым языком. Но если говорить про актуальность информации, то даже второе издание не содержит обзора cutting-edge технологий 2020-х годов. С другой стороны, имея фундаментальные знания из "Основ глубокого обучения", читателю будет гораздо легче освоить и трансформеры по материалам интернета или специализированным главам других книг. В общем, для начинающих второе издание книги от 2022 года может быть полезно. #AI #ML #Data #Engineering #Software

Утром я рассказывал про отчет "Искусственный интеллект в России — 2025: тренды и перспективы", который у бывших ребят из McKinsey и Yandex вышел на целых 120 страниц. Размер конечно внушает, но полный отчет редко кто читает - обычно читают краткое саммари с лендинга. А вот я люблю читать оригинальные версии, чтобы понимать методологию, сами результаты и самому составлять мнение о выводах. Иногда такая методичность позволяет находить абсурдное содержимое (иногда в методологии, иногда в неакурратном копи-пастинге). В этот раз copy-paste был кривоват и в разделе про NLP был приведен абсурдный кейс "Поиск товаров по фото (маркетинг и продажи)" с описанием вида

Система с помощью ИИ анализирует тексты отзывов и обращений, выявляет темы, эмоции и причины недовольства. Отчеты формируются автоматически и помогают выявлять проблемные зоны и точки роста сервиса

Явно видно, что тут был кейс про выделение интентов, но copy paste прошел неудачно - забыли заменить название кейса из раздела CV, что приведен через 15 страниц с правильным описанием. Похожая проблема есть и в других частях, где график показывает финансовые эффекты от внедрения технологий, а заголовок описывает график как сложности, которые видит компании во внедрении технологий. В общем, читайте расширенные версии отчетов и анализируете что именно делают авторы и не ограничивайте себя executive summary с лендингов:) #Engineering #AI #Metrics #Software #Productivity #Economics

Искусственный интеллект в России — 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

Вселенная. Путешествие во времени (Рубрика #PopularScience) Прочитал с большим удовольствием эту книгу Сергея Арктуровича Язева, российского астронома, что много лет руководит Астрономической обсерваторией Иркутского государственного университета и связан с Институтом солнечно‑земной физики СО РАН. Интересно, что Сергей - потомственный астроном и практически живет в своей предметной области, умеет ее популяризировать и держать дисциплину научного метода. Сама книга вышла в 2020 году в издательстве Питер и была задумана как путешествие по разным научным парадигмам восприятия космоса от древнего мира к текущим концепциям:) Автор умеет показывать как менялись взгляды человечества, и отдельно проговаривает, почему базовым физическим законам имеет смысл доверять (смысл примерно как в поговорке "доверяй, но проверяй"). Сама книга обладает рядом плюсов - Онасостоит из двух частей и развивается от простого к сложному - Через весь текст проходит таймлайн, связывающий события мировой истории и астрономические открытия - В книге превосходные иллюстрации Евгения Муретова, которые отлично поддерживают повествование Вообще, история и усложнение концепций напоминает мне progressive jpeg, когда детали картины отрисовываются постепенно. Часть 1: от Вселенной древнего мира к Вселенной, управляемой физикой Первая часть - это путь от концепций мира древних и философских конструкций к миру, где начинают работать: - Наблюдение и измерение (вместо авторитетов и мифов) - Математика как язык модели - Универсальные законы (одни и те же правила для яблока, Луны и планет -это ключевой перелом мышления). Книга буквально ставит вехи от главы «Вселенная Древнего мира» к главе "Вселенная, управляемая физикой", причем если проводить параллели, то - Древняя картина мира - это “монолит”, где объяснение часто неотделимо от культуры и веры - Научная картина выглядит модульно, состоя из цикла: измерения → гипотеза → модель → предсказания → проверка → рефакторинг модели Отдельно круто, что Язев не просто перечисляет открытия, а показывает почему без научного метода тысячелетиями нельзя было достоверно узнать устройство мира - то есть объясняет сам механизм прогресса, а не только результаты. Часть 2: от относительной Вселенной к разгоняющейся - и дальше, к открытым вопросам Вторая часть начинается с качественного скачка сложности: мы больше не пытаемся "подкрутить старую модель", а меняем базовые предпосылки, что похоже на смену платформы (на эту тему можно почитать книгу Томаса Куна "Структура научных революций"). Начинается все с главы "Вселенная относительная", а дальше история проходит через ключевые “релизы” современной космологии - расширение, горячее начало (Большой взрыв), инфляция - и выходит к главе "Вселенная разгоняющаяся", а финализируется все Вселенной открытых вопросов. Здесь особенно хорошо ощущается логика - Относительность меняет то, что считаем “базовым API” пространства‑времени - Расширение переводит космологию из статической картинки в динамическую систему (с параметрами, которые нужно измерять, а не “объявлять”) - Инфляция - попытка закрыть конкретные баги стандартной модели (плоскостность/горизонт и т. п.) с помощью гипотезы, которая должна быть совместима с наблюдениями - Ускоренное расширение (“разгоняющаяся Вселенная”) добавляет в модель компоненту, природа которой понятна не до конца - и это честно выводит читателя к границе знания В итоге, книга мне безусловно понравилась - автор интересно, последовательно и понятно объясняет сложные концепции. Я бы хотел уметь в таком стиле рассказывать их своим детям:) #PopularScience #Physics #Science #Math

[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

[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

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

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

У меня даже собака тянется к знаниям:) Ей нравится мое кресло в библиотеке

Moving away from Agile. What's next? (Рубрика #Processes) Посмотрел претенциозный доклад ребят из McKinsey с недавноей конфы AI Engineer, в котором они раскрывали несколько ключевых мыслей - Текущие операционные модели (Agile based) плохо раскрывают потенциал AI‑инструментов - "AI‑native" команды отличаются другими workflow, ролями и метриками - Переход от Agile - это в первую очередь организационные и культурные изменения, а не использование инструментов Тезисы, что поддерживают их мысли основаны на следующем - У нас есть разрыв между индивидуальным бустом инженеров и эффектом на компанию: отдельные разработчики получают ускорение "дни → минуты", а в среднем по компании видят лишь 5–15% прироста продуктивности, потому что остальной процесс остался старым. - AI создаёт новые бутылочные горлышки: распределение задач между людьми и агентами, ручной код‑ревью при лавине сгенерированного кода, ускоренное накопление техдолга и сложности.​ - Старый agile‑сетап (8–10 человек, двухнедельные спринты, story‑driven dev, раздельные роли frontend, backend, qa, ...) оптимизирован под "чисто человеческую" разработку и плохо сочетается с использованием агентов Интересно, что название самого доклада выглядит как байтинг - авторы на самом деле не предлагают "выкинуть agile", скорее они предлагат уйти от конкретной реализации со спринтами по две недели, командами формата "two-pizza teams" и остальными ритуалами. На замену этому они предлагают "AI native подход": короткие циклы, более мелкие команды, spec‑driven development, ну и изменение роли product manager и инженеров​​. Вообще забавно смотреть на выступления консультантов про разработку - не уверен, что они сами когда-то писали код, поэтому они базируют свой helicopter view анализ на куче различных исследований и кейс study. Ну и мыслят они не с уровня команды, а с уровня портфеля из сотен команд: много говорят про change management, измерения, роль обучения, перестройку орг‑структуры. Это консалтинговый взгляд, но он полезен, если говорить про крупные корпорации:)​​ Если говорить подробнее про изменения, то они предлагают - Перейти от квартального планирования к continuous planning - Перейти от story‑driven к spec‑driven разработке - PM/lead сначала "выбивают" нормальную спецификацию вместе с агентом, а уже потом команда/агенты пилят код, чтобы сократить рефакторы и перегенерации.​​ - Перейти к командам по 3-5 человек, где участники больше напоминают fullstack инженеров, а также оркестрируют агентов и отвечают за части архитектуры, а не только за свой слой - Перейти к продактам, что сами начинают прототипировать с coding agent, а не только писать длинные PRD (product requirement definitions) Авторы говорят и про метрики для измерения эффекта, предлагая многоуровневую систему - Инвестиции в инструменты, обучение, коучинг - Adoption, velocity, capacity, MTTR по критичным багам, безопасность и качество кода - Бизнес‑результаты: time‑to‑revenue, cost-benefit analysis, возможность реинвестировать в greenfield/brownfield.​ В общем, консультанты предлагают поменять весь процесс, а не просто навесить агентов и copilot на старые agile‑процессы #Engineering #AI #Metrics #Software #DevEx #Productivity #Management #Leadership