Книжный куб

The End of Coding: Andrej Karpathy on Agents, AutoResearch, and the Loopy Era of AI (Рубрика #AI) Посмотрел свежий выпуск подкаста "No Priors" с Andrej Karpathy. Эта серия была опубликована 20 марта 2026 и с Андреем общается Sarah Guo, основатель Conviction и ведущая подкаста, а главной мыслью выпуска была тема о том, что software engineering уже сдвигается от написания кода к оркестровке агентов. По словам Андрея, он с декабря почти перестал писать код руками и резко сместился в режим делегирования задач агентам; по его ощущению, у многих инженеров frontier-уровня default workflow уже успел радикально поменяться. Другая интересная мысль в том, что бутылочное горлышко сместилось с IDE и даже вычислительных мощностей в сторону человека - Андрей описывает это как переход от мышления про FLOPS к мышлению про пропускную способность токенов (token throughput). Если агент может автономно 20 минут делать кусок работы, то ценность инженера смещается в правильную декомпозицию задач, параллельный запуск нескольких потоков и review на уровне архитектуры, а не строк кода. Интересна также тема AutoResearch - если у задачи есть объективные метрики, то агент может сам менять код, запускать короткие эксперименты, измерять результат и оставлять только улучшения. В открытом репозитории Karpathy это оформлено почти как минимальная исследовательская ОС: агент правит train.py, работает в фиксированном 5-минутном бюджете и оптимизирует val_bpb; program.md фактически становится “кодом исследовательской организации”. Это и есть его автоматическая работа в цикле эксперимент → метрика → изменение → повтор, где человек уже не нужен. Правда, Андрей отмечает, что такой режим работает не всегда, а только там, где есть верифицируемая награда и понятный способ оценки результата (eval). Там, где нужны вкус, есть неформализованные ожидания и мягкие критерии качества, то модели по-прежнему очень неконсистентны: в одном месте блестящие, в другом - удивительно наивные. Это важная поправка к хайпу про "автономных разработчиков". Также Андрей рассказал про своего домашнего агента Dobby, который через WhatsApp управляет светом, HVAC, шторами, бассейном, спа и безопасностью дома. Из этого он делает жёсткий вывод: возможно, заметная часть сегодняшних приложений - это временный UX-слой, а более правильная архитектура будущего - это API/tool surface + агент как клей. В общем, это действительно интересный подкаст, в котором Андрей делится практикой, а не футуристическими идеями. #Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #SystemDesign

Транспортные протоколы для AI-агентов (Рубрика #AI) За последний год мы наблюдаем интересную эволюцию: AI постепенно перестаёт быть "надстройкой" над существующими интерфейсами и начинает формировать собственный слой взаимодействия. Вспомним путь, которые прошли протоколы MCP, A2A, A2UI - MCP (Model Context Protocol) Это попытка от Antrhropic стандартизировать, как модели получают доступ к контексту (файлы, базы, API). По сути, это про data plane для LLM - A2A (Agent-to-Agent) Это попытка от Google выстроить коммуникации между агентами как между равноправными участниками системы. По сути формализует диалоги, delegation, coordination. Раньше я уже сравнивал MCP и A2A протоколы - A2UI (Agent-to-UI) Предложенный Google протокол вокруг идеи того, что UI становится не primary интерфейсом, а "рендером" агентных действий. В итоге, пользователь взаимодействует с агентом, а не с формой/кнопками. Раньше я уже про него рассказывал Если смотреть на тренды, то мы больше не описываем API для людей - мы описываем намерения для агентов Продолжая эту тенденцию дальше мы приходим к идее собственного транспортного протокола для агентов, так как сейчас агентский мир живет поверх обычного http, который - Заточен под request/response - Плохо выражает intent (всё прячется в JSON) - Не имеет нативной модели identity/authority для агентов - Не оптимизирован под высокочастотный stateful трафик И мы получаем агентные системы, которые выглядят как RPC поверх HTTP с кучей костылей. Дальше появляется мысль вынести агентную коммуникацию в отдельный протокол ««« мы здесь И у нас уже есть два кандидата в такой протокол: AGTP (19 марта 2026 года) и ATP (22 марта 2026 года) 1️⃣ AGTP (Agent Transfer Protocol, Chris Hood) Этот протокол предлагает - Новые методы вместо HTTP verbs: QUERY, EXECUTE, BOOK, ESCALATE А значит intent становится частью протокола - Protocol-level identity: agent_id, authority, delegation chain А значит больше не нужно прятать это в headers/body - Новая система статусов Она отражает результат агентных действий, а не HTTP semantics - Транспорт Приоритет отдается QUIC (стримы, low latency), fallback на TCP/TLS Основная идея в том, чтобы сделать трафик агентов наблюдаемым и управляемым на уровне сети 2️⃣ ATP (Agent Transfer Protocol, Li et al.) Независимая инициатива, с похожими целями: - Специализированные примитивы для agent workflows - Поддержка stateful взаимодействия - Фокус на interoperability между агентами разных систем У протоколов есть как похожие черты, так и отличия Общие черты - Отказ от HTTP как универсального слоя - Intent-driven коммуникация - Встроенные identity/authority модели - Подготовка к high-frequency agent traffic Различия - AGTP - более "операционный" (методы, статусы, observability) и уже предлагает более конкретную структуру протокола - ATP - более "концептуальный" (interoperability и primitives) Но мало ли сколько предложений о новых протоколах бывает. Конкретно эти интересны тем, что мы приходим к разделению интернета на два слоя 1. Human web (HTTP, UI, REST) 2. Agent web (AGTP/ATP, intent, delegation) А это влияет на остальные моменты, например - API gateway будут понимать agent traffic нативно - В observability стеке появятся метрики уровня intent - В security identity агентов станет first-class - А SDK перестанут быть "обёртками над REST" Если эти протоколы взлетят, нас ждёт - Отдельные agent-native API gateways - Маршрутизация по intent, а не по URL - Policy engines на уровне агентных действий - Встроенная экономика взаимодействия агентов (оплата, квоты, ...) - Тесная интеграция с DNS и service discovery Нам как архитекторам придется думать не только про API, но и про семантику действий. Архитектуры будут смещаться от request/response к workflow orchestration. Observability нужно будет строить вокруг intent и outcome, а не только latency, ну и конечно нам придется построить новый платформенный слой под агентов:) #AI #Architecture #DistributedSystems #Network #SystemDesign #Software

Silicon sampling (Рубрика #RnD) Сегодня я общался с коллегой, что занимается у нас платформой для проведения качественных и количественных исследований (привет, Андрей). В ходе общения я вспомнил про этот интересный и быстроразвивающийся подход к их проведению, где LLM получает социодемографическую «биографию» (backstory) персоны и отвечает на вопросы опроса от её имени. Это позволяет воспроизводить мнения тысяч демографических групп без рекрутинга реальных участников. Дальше мне стало интересно, а какие вообще существуют ключевые исследования в этой теме и так я получил подборку ниже - Argyle et al., 2023 - "Out of One, Many" - это классическая основополагающая работа, которая вводит понятие "алгоритмической точности" (algorithmic fidelity). GPT-3 использует backstories из ANES и Pew. (потом еще вышла в Political Analysis от Cambridge) - Aher, Arriaga, Kalai (ICML 2023) - "Using Large Language Models to Simulate Multiple Humans and Replicate Human Subject Studies" — метод репликации классических социологических экспериментов (Milgram, Ultimatum Game и др.) на популяции LLM-персон без единого живого участника. - Santurkar et al. (2023) - "Whose Opinions Do Language Models Reflect?" - создали датасет OpinionQA из 500 спорных вопросов, сравнили 9 LLM с 60 демографическими группами США. Вывод: несоответствие сравнимо с пропастью между демократами и республиканцами по климату. - Hu & Collier (2024) - "Quantifying the Persona Effect" - персона объясняет менее 10% дисперсии, но даёт статистически значимый прирост. Найдена линейная зависимость: чем сильнее корреляция переменных персоны с мнением, тем точнее симуляция. - Tejaswani Dash et al (2025) - "Polypersona: Persona-Grounded LLM for Synthetic Survey Responses" - open-source фреймворк с датасетом из 3 568 ответов по 433 уникальным персонам, предназначен для instruction-tuning - Taday Morocho et al. (2026) - "Assessing the Reliability" - протестировали 70 000+ пар на данных World Values Survey. Persona prompting не даёт стабильного улучшения и в ряде случаев ухудшает результат. Подход выглядит как вундер-вафля, но есть и некоторые проблемки - Ordering bias (модели систематически предпочитают первый вариант ответа - Underrepresented groups - 65+, вдовцы, меньшинства воспроизводятся хуже всего - Корреляционная слепота - fine-tuned модели точнее по маргиналям, но обе техники не восстанавливают латентную структуру корреляций реальной популяции В whitepaper Lin (2024) в "Six Fallacies in Substituting Large Language Models for Human Participants" систематически перечисляются типичные ошибки в интерпретации таких исследований. А вообще, если вы делаете платформу для количественных и качественных исследований, то есть смысл добавить туда "silicon sampling" как один из подходов для проведения исследований:) #AI #Engineering #RnD #Science #Research

Измеряя AI в SDLC: от adoption-метрик к бизнес-ценности и пользовательскому результату (Рубрика #AI) Примерно неделю назад моя коллега Анна Громова выступала на митапе Yandex AI Dev Day. Она руководит продуктовой аналитикой внутренних платформ, процессов SDLC и AI-инструментов, собственно поэтому она и могла лучше всех рассказать эту тему. Выступление было достаточно коротким и имело примерно такую структуру 1️⃣ Что такое SDLC и зачем его мерить Если упрощать, то software development life cycle - это процесс поставки кода в продакшн. Для его оценки в Т-Банке применили три широко известных в узких кругах фреймворка: - DORA - старейший фреймворк, что оценивает скорость и надёжность поставки (вот тут я рассказывал как фреймворк в 2026 году прирос пятой метрикой) - SPACE - фреймворк, что учитывает не только конвейер, но и удовлетворённость, состояние потока разработчика, и еще кучу всего (вот выступление Саши Кусургашева от лета 2025 года, где он рассказал как мы готовим этот фреймворк) - DevEx - фреймворк с фокусом на когнитивной нагрузке, переключении контекста, цикле обратной связи (вот выступление Вовы Калугина про то, как мы готовим DevEx) Применив мысли из этих референсных фреймворков, мы в Т-Банке построили "дерево метрик" (но оно скорее похоже на сеть): верхний уровень - DORA, нижний - DevEx, SPACE -где-то посередине + на нем основан полугодовой опрос тысяч инженеров. Кстати, про все эьт подходы DORA, SPACE, DevEx я уже много раньше рассказывал. 2️⃣ AI-ассистент Т-Банка и его уровень принятия (adoption) Внутренний AI-ассистент внедрён в IDE, Jupyter-ноутбуки, BI-системы, GitLab, observability и поиск. Режимы работы в IDE: подсказки, чат, агентский режим. Метрики принятия - IDE (от пользователей GitLab) - ~70–75% - Инструменты аналитики - ~75% - Все поверхности суммарно - ~57% При таком уровне использования уже можно делать выводы о влиянии AI на метрики SDLC. 3️⃣ От adoption-метрик к пользовательским сценариям Раньше считали только adoption: новые пользователи, отток, доля сгенерированных артефактов, "осмысленность" использования (перегенерация, сброс контекста), лайки/дизлайки. В 2025–2026 году перешли к пирамиде метрик: - Верхний уровень - бизнес-метрики SDLC (time to market, надёжность) - Средний - закрытые пользовательские сценарии (генерация юнит-тестов, помощь в code review и т.д.) - Нижний - технические метрики ассистента (скорость, версия модели) Это позволяет одновременно отвечать на бизнес-вопросы и развивать AI-продукт. 4️⃣ Роль телеметрии Ключевой тезис: сначала определить метрики → потом решить, какие логи собирать, а не наоборот. Это сокращает "приседания" вокруг телеметрии и фокусирует на реальной цели. Единые данные важны, чтобы результаты разных команд (AI-команда, CICD-команда) были консистентны между собой. В докладе есть еще ряд чисел про результаты внедрения в разные сценарии, но я оставлю это тем, кто заинтересовался и готов посмотреть оригинальное видео. А вообще, выступление полезное и интересное, а также оно демонстрирует, что в России мы близки к SOTA по методам измерения влияния AI на разработку (но у нас есть множество идей, как приблизится к SOTA на глобальном уровне). #AI #Metrics #Engineering #Management #Software

State of Code Developer Survey report by SonarSource (Рубрика #AI) Интересный 57-страничный отчет от производителя SonarQube, средства для верификации качества кода. Отчет вышел еще 8 января 2026 года, а основан был на опросе от октября 2025 года. Если обобщить одной фразой основную мысль, то она такая: AI не снял нагрузку с разработки - он просто перенёс бутылочное горлышко из написания в в верификацию кода. Методология исследования выглядела как количественный онлайн-опрос на 1149 респондентов по всему миру. В выборке - взрослые специалисты в tech-ролях, которые пишут код или управляют разработчиками и использовали AI в работе за последний год. Вопросы были не просто "используете ли вы AI", а как именно он меняет инженерную работу: - Где AI реально помогает - Где есть разрыв между принятием (adoption) и эффетивностью (effectiveness) - Доверяют ли разработчики AI-коду - Как меняются безопасность и технический долг - Что происходит с junior/senior инженерами и есть ли разница в их отношении к  AI - Что с использованием AI агентов - Что происходит с управлением всем этим зоопарком инструментов Результаты вышли такие - AI уже не эксперимент, а рутина: 72% тех, кто попробовал AI coding tools, используют их каждый день, а в среднем 42% кода в коммитах уже AI-generated или AI-assisted - Ценность AI распределена неровно: лучше всего AI показывает себя в документации, объяснении существующего кода и генерации тестов; заметно хуже - в рефакторинге и изменении существующего кода (напомню этот опрос был до большого сдвига в возможностях моделей осенью 2025 года) - Параллельно команды жонглируют в среднем 4 AI-инструментами, а 35% разработчиков используют часть из них через личные аккаунты, а не через санкционированный на работе доступ. В итоге, скорость личная выросла, но доверие не появилось. 96% не полностью доверяют функциональной корректности AI-кода. 95% тратят время на review/testing/fixing AI output, 38% говорят, что ревьюить AI-код сложнее, чем человеческий, а только 48% всегда проверяют AI-assisted code перед commit. Неудивительно, что самым важным навыком в AI-era респонденты назвали ревью и валидацию AI-кода на качество и безопасность. Если говорить про больные места, то 57% опасаются утечки чувствительных данных, 47% - появления новых subtle security vulnerabilities. По техническому долгу картина тоже двойственная: 88% увидели хотя бы один негативный эффект AI на долг, чаще всего “код выглядит правильным, но ненадёжен” (53%) и лишний/дублирующий код (40%). Но 93% одновременно увидели и пользу: AI помогает с документацией, тестами/debugging и частью refactoring work. Junior-разработчики чаще опираются на AI и чаще говорят, что проверка такого кода требует больше усилий, чем у senior. Также заметна разница между организациями разного масштаба: - Малые и средние компании (SMB) снимают больше пользы с ускорения поставки и быстрее улучшают time-to-market, а корпораты чаще видят улучшения в качестве кода и поддерживаемости - похоже, за счёт более жёсткой governance и контроля AI-рисков. Выводы авторов отчета простые - процессам разработки нужно понимать происхожение кода, усилить ревью кода, добавить quality gates, статический анализ, и выстроить нормальный governance вокруг AI-инструментов. Иначе ускоряется не поставка, а производство непроверенного кода. Ну и конечно со всем этим может помочь SonarQube от авторов исследования:) #Engineering #Software #DevOps #DevEx #Process #Management #Metrics

От AI-native разработки к AI-native организации (с примерами из опыта бигтехов (Рубрика #AI) Написал статью-продолжение к статье про ai-native разработку "От классического PDLC к AI-native разработке". Основная завязка новой статьи крутится вокруг идеи, что если переход к ai-native разработке меняет сам инженерный процесс, то дальше меняется оргструктура - это видно по анонсам и действиям бигтех компаний, что из больших активнее всего участвуют в гонке AI. А дальше это затронет и остальных. Суть в том, что когда требования, код, тесты и документация начинают собираться в разы быстрее, узким местом становится уже не написание артефактов, а принятие решений, передача контекста и количество организационных слоёв. Отсюда следующий шаг: компаниям мало просто выдать инженерам AI-инструменты. Нужна оргмодель, которая умеет переваривать новую скорость работы. Это обычно означает меньше слоёв управления, больший вес senior+/staff+ IC, сильную внутреннюю платформу, self-service, guardrails и agentic workflows. Важно, что переход к более плоской структуре (flattening) - это не только про срезание затрат. Это попытка повысить выхлоп на сотрудника и убрать организационное трение на единицу результата. Правда, такая модель не работает сама по себе: без сильной платформы, качественного CI/CD, прозрачных policy checks и понятных правил принятия решений AI просто ускорит хаос. В общем, следующим уровнем конкуренции будет не просто сделать AI-native разработку, про которую я писал раньше, а скорее способность построить AI-native организацию вокруг людей, платформ и агентов. #Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #SystemDesign

Распределённые системы без магии: что на самом деле говорят CAP и PACELC (Рубрика #SystemDesign) 19 марта я читал студентам Центрального Университета лекцию на широкий набор тем — мы говорили про широко известные в узких кругах теоремы CAP и PACELC, обсудим чем consistency в этих теоремах отличается от consistency в ACID, поговорим про то, как проверяются заявленные гарантии консистентности( на примере проекта от Jepsen), а в конце лекции обсудили Cassandra как пример распределенной базы данных с tunable consistency. Большая часть изложенной теории была взята из статей с моего сайта system-design.space, а после лекции у ребят был еще семинар, где они могли покрутить Cassandra руками и попробовать работу этих теорем на практике. Мне самому понравилось рассказывать материал, но в этой расшифровке я решил сделать акцент не на теории, а на простой мысли, что в распределённых системах нет волшебства. Хотя мне очень нравится третий закон Артура Кларка

Любая достаточно развитая технология неотличима от магии

Но если быть практиком и инженером, то мжно отметить, что нет такой базы данных, такой сетевой топологии или такой архитектурной диаграммы, которая позволит одновременно быть всегда доступными, всегда согласованными и всегда быстрыми без всякой цены. Архитектура распределённой системы начинается в тот момент, когда мы перестаём искать магию и начинаем честно проектировать компромиссы. CAP, PACELC, модели консистентности, Jepsen и Cassandra — это, по сути, разные способы проговорить одну и ту же реальность. #Architecture #Management #SystemDesign #Software #Engineering #Database

[2/2] Agentic coding at Airbnb (Рубрика #Agents) В прошлом посте мы остановились на том, что у ребят из Airbnb при внедрении агентского подхода к разработке было три цели и теперь интересно посмотреть, а как же они к ним шли. Для того, чтобы реализовать первую цель, а именно "принести агентов в Airbnb", они построили Air Chat - абстракцию-обертку над несколькими движками. Это дало единую входную точку: можно быстро выкатывать новые CLI-агенты и обновления, не привязывая всю платформу к одному вендору или одному инструменту. Дальше они очень рано пошли в MCP, потому что стандарт был близок к их уже существующему tool-calling подходу. В результате Airbnb смогли: завернуть любимые IDE инструменты в MCP сервера, встроить MCP клиентов в IDE-плагины, а конфигурацию и синхронизацию серверов централизовать через Air Chat CLI. Со временем это выросло в экосистему с более чем дюжиной внутренних MCP-серверов, включая аналитические и CI-инструменты. Для того, чтобы реализовать вторую цель, а именно "принести знания Airbnb в агентов" они поменяли свой подход к работе с базой знаний (knowledge base). Раньше у них была "линейная" one-shot схема: запрос → knowledge endpoint → ответ. Для агентного режима это работало плохо. Но они решили не играть в дообучение моделей (fine-tunning) как главный путь, а просто завернули получение знаний из базы знаний (knowledge base) в MCP, а дальше позволили агентам итеративно доуточнять информацию: если первый ответ не подошел, агент сам уточняет поиск, меняет термины и делает deeper research внутри ваших внутренних знаний. Еще они рассказали как пытались строить собственную multi-agent orchestration-модель с planning/coding/validation agents, но рынок двигался слишком быстро, а маленькая команда не успевала наращивать нужную "мышцу". Поэтому Airbnb не уперлись в "мы обязаны написать свой оркестратор", а сделали прагматичный поворот (pivot): основной агент теперь живет как CLI-agent, а сверху у него тонкая прокладка для других поверхностей. Круто, что ребята честно рассказали про свое решение - зачастую синдром NIH (Not Invented Here) не позволяет принять такое решение или даже если оно принято, то не позволяет о его принятии рассказывать:) Если подбивать выводы ребят из их пути, то они примерно такие 1) Agentic coding - это не просто чат в IDE, это новый inner loop, где агент многократно дергает LLM, инструменты и внутренние знания, а на выходе приносит код, который все равно должен быть просмотрен человеком до PR 2) Рост идет не только от auto-approve настройки агента, а от умения инженера управлять несколькими параллельными workspaces; в Airbnb некоторые продвинутые пользователи открывают до пяти агентных сессий одновременно 3) Агент сам по себе ничего не решает: вокруг него нужны sandbox/workspace-инфраструктура, auth, security paved path, шаблоны, установка в одну команду и нормальная review-культура 4) А организационный вывод ребят такой - не надо ломать существующие привычки команд ради модного AI UX. Они прямо говорят, что идея "давайте всех пользователей IntelliJ переведем в VS Code, потому что там лучше agentic tooling" быстро провалилась. Вместо этого нужно убирать барьеры, встречать разработчиков там, где они уже работают, и стандартизировать только то, что действительно стабилизировалось на рынке. При этом качество нельзя опускать "потому что это AI": стандарты остаются прежними, ревью обязателен, тестовый код тоже должен быть готовым к проду, а пользоваться auto-approve без набитой руки - опасно. В общем, основная идея не в том, чтобы купить лучший AI-ассистент (Claude Code, OpenAI Codex, Cursor, выбери свой любимый), а в том, что собрать проторенный путь вокруг агентов: поверхности для взаимодействия, доступ к знаниям, вызов инструментов, стандартизация, измерения и ревью человеком. И только потом ждать реального прироста ключевых метрик разработки, а не локального wow-эффекта. #Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign

[1/2] Agentic coding at Airbnb (Рубрика #Agents) Это очередной интересный доклад с сентябрьского DPE Summit, про который я рассказывал раньше. В нем ребята из Airnbnb рассказывали как они выстроили у себя агентскую модель разработки и двинулись от классического PDLC к AI-native разработке (примерно в ту сторону, что я описывал в одноименной статье). И тут речь не про какие-то игрушечные приложения, создаваемые агентами, а про агентскую разработку в их монорепе со стандартными требованиями по безопасности, комплаенсу и с 1к+ инженерами в ней. Причем авторы для описания подхода использовали метафору из парного программирования, практики XP (extreme programming), где два инженера вместе делали фичи: один был навигатором и думал о стратегии, а второй был пилотом, держал клавиатуру и писал код. В этой метафоре роль пилота забрал агент, а роль навигатора осталась за инженером. В начале 2025 года ребята ожидали, что такой режим распространиться на 20% - 40%, но к сентябрю они уже перевыполнили план и достигли примерно 60% Путь Airbnb к этому выглядит достаточно предсказумым и понятным 1) Сначала у них был IDE-first подход: внутренние плагины с хорошим UX, доступом к контексту редактора и собственной knowledge/RAG-пайплайном для учета специфики Airbnb 2) Потом рынок резко двинулся в сторону CLI-агентов: они оказались сильнее как агентские инструменты, умели сами делать несколько шагов подряд, вызывать инструменты и принимать локальные решения 3) Airbnb адаптировались и попробовали посмотреть на мир как на CLI-first, но быстро увидели проблему: внешние CLI-инструменты давали классные ответы для внешних проектов, но плохо знали их монорепы, внутренние паттерны и кодовую базу компании 4) Дальше они сделали очень зрелый ход: не стали спорить IDE или CLI, а собрали небольшую core-команду и кросс-функциональную рабочую группу, чтобы привести все поверхности к одному уровню. У команды было всего четыре инженера плюс продуктовая поддержка, поэтому они сознательно сузили фокус до трех ставок: - Принести агентов в Airbnb - Принести знания Airbnb в агентов - Стандартизироваться вокруг MCP Параллельно они развернули champion/community-модель через хакатоны, talks и внутреннюю рабочую группу В продолжении я расскажу про то, как ребята шли к выполнению этих целей. #Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign

[2/2] Agentic coding at Airbnb (Рубрика #Agents) В прошлом посте мы остановились на том, что у ребят из Airbnb при внедрении агентского подхода к разработке было три цели и теперь интересно посмотреть, а как же они к ним шли. Для того, чтобы реализовать первую цель, а именно "принести агентов в Airbnb", они построили Air Chat - абстракцию-обертку над несколькими движками. Это дало единую входную точку: можно быстро выкатывать новые CLI-агенты и обновления, не привязывая всю платформу к одному вендору или одному инструменту. Дальше они очень рано пошли в MCP, потому что стандарт был близок к их уже существующему tool-calling подходу. В результате Airbnb смогли: завернуть любимые IDE инструменты в MCP сервера, встроить MCP клиентов в IDE-плагины, а конфигурацию и синхронизацию серверов централизовать через Air Chat CLI. Со временем это выросло в экосистему с более чем дюжиной внутренних MCP-серверов, включая аналитические и CI-инструменты. Для того, чтобы реализовать вторую цель, а именно "принести знания Airbnb в агентов" они поменяли свой подход к работе с базой знаний (knowledge base). Раньше у них была "линейная" one-shot схема: запрос → knowledge endpoint → ответ. Для агентного режима это работало плохо. Но они решили не играть в дообучение моделей (fine-tunning) как главный путь, а просто завернули получение знаний из базы знаний (knowledge base) в MCP, а дальше позволили агентам итеративно доуточнять информацию: если первый ответ не подошел, агент сам уточняет поиск, меняет термины и делает deeper research внутри ваших внутренних знаний. Еще они рассказали как пытались строить собственную multi-agent orchestration-модель с planning/coding/validation agents, но рынок двигался слишком быстро, а маленькая команда не успевала наращивать нужную "мышцу". Поэтому Airbnb не уперлись в "мы обязаны написать свой orchestration layer", а сделали прагматичный поворот (pivot): основной агент теперь живет как CLI-agent, а сверху у него тонкая прокладка для других поверхностей. Круто, что ребята честно рассказали про свое решение - зачастую синдром NIH (Not Invented Here) не позволяет принять такое решение или даже если оно принято, то не позволяет о его принятии рассказывать:) Если подбивать выводы ребят из их пути, то они примерно такие 1) Agentic coding - это не просто чат в IDE, это новый inner loop, где агент многократно дергает LLM, инструменты и внутренние знания, а на выходе приносит код, который все равно должен быть просмотрен человеком до PR 2) Рост идет не только от auto-approve настройки агента, а от умения инженера управлять несколькими параллельными workspaces; в Airbnb некоторые продвинутые пользователи открывают до пяти агентных сессий одновременно 3) Агент сам по себе ничего не решает: вокруг него нужны sandbox/workspace-инфраструктура, auth, security paved path, шаблоны, установка в одну команду и нормальная review-культура 4) А организационный вывод ребят такой - не надо ломать существующие привычки команд ради модного AI UX. Они прямо говорят, что идея "давайте всех пользователей IntelliJ переведем в VS Code, потому что там лучше agentic tooling" быстро провалилась. Вместо этого нужно убирать барьеры, встречать разработчиков там, где они уже работают, и стандартизировать только то, что действительно стабилизировалось на рынке. При этом качество нельзя опускать "потому что это AI": стандарты остаются прежними, ревью обязателен, тестовый код тоже должен быть готовым к проду, а пользоваться auto-approve без набитой руки - опасно. В общем, основная идея не в том, чтобы купить лучший AI-ассистент (Claude Code, OpenAI Codex, Cursor, выбери свой любимый), а в том, что собрать проторенный путь вокруг агентов: поверхности для взаимодействия, доступ к знаниям, вызов инструментов, стандартизация, измерения и ревью человеком. И только потом ждать реального прироста ключевых метрик разработки, а не локального wow-эффекта. #Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign

CAP, PACELC и модели консистентности (Рубрика #DistributedSystems) Сегодня вечером я буду читать лекцию с таким названием студентам Центрального Университета (хорошо, что я успел поправиться к этому моменту). В лекции мы поговорим про широко известные в узких кругах теоремы CAP и PACELC, обсудим чем consistency в этих теоремах отличается от consistency в ACID, поговорим про то, как проверяются заявленные гарантии, а в конце лекции обсудим Cassandra как пример распределенной базы данных с tunable consistency. Потом наступит время семинара, где мы попробуем эту Cassandra в деле, чтобы оценить на практике насколько весело и интересно может работать по настоящему распределенная система. В основном теория основана на статьях с моего сайта system-design.space - CAP (Consistency, Availability, Partition tolerance) - PACELC (if Partition then Availability or Consistency Else Latency or Consistency) - Модели консистентности и проверка гарантий БД от Jepsen - Cassandra Ну и для особых эстетов можно почитать прикольный разбор "MariaDB Galera Cluster 12.1.2" от Kyle Kingsbury (Jepsen), который вышел всего 3 дня назад. Из разбора видно, что верить маркетинговым заявлениям производителей баз данных опрометчиво - надо их тезисы проверять на практике:)) P.S. Картинка получилась у ChatGPT веселая:) #Architecture #Management #SystemDesign #Software #Engineering #Database

Just-in-Time Catching Test Generation at Meta (Рубрика #Engineering) Исследователи запрещенной в России Meta написали интересный whitepaper про новый класс автотестов - regression catching tests. Стандартные hardening тесты должны проходить на текущем коде и страховать от будущих регрессий. Новые catching tests специально должны упасть на конкретном входящем diff и при этом пройти на родительской версии. Идея в том, чтобы не ждать, пока баг всплывет потом, а попытаться поймать его в момент ревью или CI, до вливания кода. Интересно, что сгенерированные авторами тесты должны детектировать регрессии не на основе implicit oracle (что реагирует на очевидные проблемы типа крашей), а на основе общего оракула (general oracle), который представляет собой правильное поведение, зачастую плохо определенное и только частично известное. Авторы отдельно различают weak catch и strong catch: - Weak catch просто тот, что падает на текущей ревизии - Strong catch означает, что тест действительно указывает (true positive) на реальную ошибку в ожидаемом поведении (на основе general oracle) - Strictly weak catch - это false positive, что указывает на проблему с тестовым набором Основная задача в том, чтобы научиться определять, что weak catch на самом деле является strong catch. Это интересно, так как LLM используется не как еще один генератор unit-тестов ради покрытия, а как часть системы раннего перехвата регрессий. В Meta этот контур запускается на высокорисковых diffs (аналог PRs в GitHub) и работает на системах в сотни миллионов строк кода и целится именно в тяжелые, дорогие ошибки, а не в косметические поломки. Основные результаты статьи присустствуют прямо в абстракте (первой части любой статьи). Собственно, цель была в том, чтобы победить замедление разработки из-за false positive тестов. Авторы проанализировали 22,126 сгенерированных тестов и показали, что - Code-change-aware методы улучшают генерацию кандидатов, ловящих проблемы в 4 раза по сравнению с обычными hardening tests и на в 20 раз по сравнению с случайно упавшими тестами - Для борьбы с false positives авторы использовали rule-based and LLM-based ассессоры. Эти подходы уменьшают нагрузку на людей на 70% - Inferential statistical analysis показывает, что human-accepted code changes имеют значительно больше false positives, а human-rejected changes имеют больше true positives - Авторы сообщают о 41 candidate catches на инженере, 8 из которых true positives, а 4 из которых могли привести к значительным проблемам на проде, если бы их не поймали При этом ложные тревоги, по словам авторов, обычно закрывались за минуты и почти не били по developer velocity. Авторы при этом не перегибают палку: они прямо пишут, что выборка пока слишком маленькая, чтобы делать слишком сильные научные выводы о доле тяжелых багов. Но они отмечают, что этот подход масштабируем, применим в индустрии и позволяет предотвращаться серьезные проблемы Главный вывод для меня такой: это не paper про "магическую автоматизацию QA", а paper про рабочий инженерный контур. LLM + мутационное тестирование + дешевый human-in-the-loop уже дают способ спорить с incoming diff’ом и задавать автору очень полезный вопрос: "ты точно хотел изменить поведение именно так?". В следующих сериях авторы планируют добавить лучшее восстановление намерения изменения + брать более богатый контекст diff’а и прийти к более уверенному отделению weak catch от strong catch. #AI #QA #Engineering #Whitepaper #Software #LLM #DevOps

Natural History Museum - Souvenir guide (Рубрика #Travel) С воскресенья я в каком-то сумеречном состоянии - температура, боль в суставах и голове. Большую часть времени проводил в кровати. Но сегодня в перерывах между температурой (после приема нурафена) смог прочитать эту сувенирную книгу из Лондонского музея Естественной истории. Сам музей произвел на меня большое впечатление и я с интересом рассматривал и фотографировал его экспонаты, когда бродил по нему. А теперь читаю эту книгу я вспоминал прогулку, а также лучше понял как он возник и какие цели ставили основатели, какие этапы он прошел и что будет дальше. Отдельно отмечу, что рядом с ним расположен Science Museum, сувенирную книжку которого я решил прочесть в следующую очередь. #History #PopScience

[2/2] Soviet Space Mythologies: Public Images, Private Memories, and the Making of a Cultural Identity (Мифология советского космоса) (Рубрика #Space) Продолжая рассказ об этой книге, я хотел бы рассказать про инсайты, которые у меня всплывали по мере ее прочтения с учетом моего опыта проектирования и текущего фокуса на агентизации разработки и перехода инженеров-разработчиков в иную роль, чем прежде (как когда-то пилоты-космонавты стали скорее космонавтами-инженерами). 1️⃣ Автоматизация - это не только архитектура, но и governance. Как только вы решаете, когда система действует сама, а когда нужен ручное вмешательство, вы распределяете не только функции, но и власть, ответственность и blame. У Славы Геровича это одна из центральных осей книги. 2️⃣ Если публичный нарратив расходится с операционнной реальностью, то организация теряет способность учиться (просто не замыкается цикл обратной связи). Советская космическая история в официальной версии вычищала сбои и сложность. Это хорошо для витрины, но плохо для реального цикла улучшений. Очень современная мысль для любой компании, где PR и реальность расходятся слишком сильно. 3️⃣ У тех, кто строит систему, и у тех, кто ее представляет публике, почти всегда разные стимулы. Инженеры в советской программе имели больше влияния на дизайн, но были невидимы; космонавты были публичными героями, но часто с урезанной способностью влиять на решения. Это почти классический пример про скрытые платформенные команды и публичные бизнесово-продуктовые команды. 4️⃣ Контр-нарративы - это не шум, а телеметрия. Когда автор говорит, что задача историка не только развенчать основной миф, а разбирать основания мифа, то это очень похоже на хороший incident review. В общем, нельзя верить единственной официальной версии, нужно сопоставлять логи, интервью, документы, интересы групп и то, о чем система предпочитает молчать. 5️⃣ Память - это основа культуры и базис для принятия дальнейших решений. То, что организация празднует, замалчивает и повторяет, через несколько лет становится ее архитектурным мифом. А архитектурный миф потом влияет и на найм, и на статус ролей, и на то, какие решения кажутся "естественными". В общем, это отличная книга о том, как сложная технологическая система превращается в смесь архитектуры, власти, пропаганды и коллективной памяти. Для читателей канала она может показать, что дизайн системы, распределение ролей, управление сбоями и официальный нарратив никогда не существуют по отдельности. Я бы даже больше сказал, что это пример того, что бывает когда observability заменяют мифом. #Science #SystemDesign #Architecture #Processes #History #PopScience #Engineering #Culture #Leadership

[1/2] Soviet Space Mythologies: Public Images, Private Memories, and the Making of a Cultural Identity (Мифология советского космоса) (Рубрика #Space) Прочитал превосходную книгу Вячеслава Геровича (Slava Gerovitch), историка науки, senior lecturer MIT. Оригинал вышел в 2015 году в University of Pittsburgh Press, а русский перевод вышел в 2024 году в "Новом литературном обозрении". У этой книги интересное происхождение - автор пришел к этой теме из истории вычислительной техники: его позвали в проект по истории бортового компьютера Apollo, после чего его заинтересовало, как в СССР решали задачи управления в пилотируемой космонавтике. Дальше вопрос сместился от истории компьютеров к более общему вопросу: как распределяются функции человека и машины, кто реально принимает решения, и как дизайн корабля отражает баланс сил внутри программы. В итоге проект превратился в исследование памяти, нарративов и профессиональной идентичности инженеров и космонавтов. Книга стала результатом 13-летней работы, что финансировалась разнообразными американскими грантами: исследование на раннем этапе шло в рамках проекта по Apollo Guidance Computer, поддержанного Sloan Foundation и Dibner Institute; затем были два проекта National Science Foundation, Fellowship in Aerospace History от American Historical Association и проект oral history, поддержанный NASA History Program. Круто, что эти гранты получилось использовать для изучения советской истории космонавтики. Ниже основные идеи книги, которые делают книгу захватывающей 1️⃣ Автор показывает, что советская космическая мифология родилась из конфликта между секретностью и пропагандой. Публичная версия истории вычищала ошибки, аварии и неудачи и оставляла образ безупречных космонавтов на безотказной технике (миф, который развеялся во времена перестройки) 2️⃣ Центральный конфликт книги - космонавт как герой-пилот против космонавта как пассажира автоматизированной системы. Это не просто образный прием: в главах о взаимодействии человека и машины автор показывает, что спор об автоматизации был одновременно техническим, профессиональным и политическим. Иными словами, спорили не только о безопасности и control loop, но и о статусе, ответственности и праве принимать решения. 3️⃣ В книге явно показывается, что дизайн системы оказывается функцией организационной политики. По словам автора, конструкция советских кораблей отражала расстановку сил внутри отрасли; доминирование инженеров закрепило парадигму автоматического управления, а роль космонавтов во многом свелась к резервированию основных систем. Плюс на архитектуру влияла конкуренция конструкторских бюро и их патронов наверху. 4️⃣ Автор рассказывает не только про основной миф, но и о контрмифах. Он специально подчеркивает, что задача историка не просто опровергать красивую легенду, а разбирать, как она вообще собирается и зачем живет. Поэтому в книге много дневников, мемуаров, интервью и сопоставления несовпадающих версий одних и тех же событий - особенно вокруг полета Гагарина. Меня эта часть настолько сильно заинтересовала, что я купил коробку книг издательства "Космоскоп" (на многие из них ссылается автор) 5️⃣ Ну и после распада Советов началась переработка советского космоса в символ национальной идентичности - старый нарратив рухнул, но космос быстро стал удобным источником "истории, которой можно гордиться", уже в новом идеологическом и даже коммерческом контексте. Например, я смотрел с интересом фильмы "Королев" (2007), "Главный" (2015) и "Время первых" (2017). А в продолжении я расскажу что из этого можно забрать разработчикам софта и техническим руководителям на подумать:) #Science #SystemDesign #Architecture #Processes #History #PopScience #Engineering #Culture #Leadership

Аквапарк в Завидово (#Travel) Со второй попытки мы доехали семьей в этот аквапарк и нам тут нравится. Мы должны были сюда приехать на восьмое марта, но младший сын заболел и мы вск перенесли на неделю. А сегодня утром встали, собрались и за полтора часа по платнику Москва-Питер приехали в отель "Рябина", заселились и по подземному переходу отправились в аквапарк прямо в халатах. В самом аквапарке тепло, солнышко много горок и не очень много людей - самое то для наших детей, которые сразу пошли исследовать новое место, что открылось всего несколько месяцев назад. В общем, этот аквапарк отличный - рекомендую его к посещению (надеюсь, что он не испортится, когда посетителей станет в разы больше) #ForKids #ForParents

The Software Development Lifecycle Is Dead (Рубрика #Software) В это интересной февральской статье 2026 Boris Tane делает громкое заявление о смерти SDLC, которое по моему мнению хорошо отражает ситуацию стратегически, но опережает текущие подходы на годик. Сам я думаю, что мы перейдем от классического PDLC к AI-native разработке и эту статью Бориса упомянул @brolnickij в канале @ai4sdlc, где можно обсудить посты из этого канала и не только. Если возвращаться к главному тезису Бориса в его статье, то он такой - Классический SDLC с фазами requirements → design → implementation → testing → code review → deployment → monitoring больше не распадается на отдельные этапы - Вместо этого появляется короткий цикл: intent + context → agent → build/test/deploy → observe → repeat Ну и дальше очень интересен взгляд автора на новый lifecycle по стадиям - Требования больше не замораживаются перед стартом задачи, а уточняются по ходу итераций - System design теперь не предписывается заранее, а обнаруживается в диалоге с агентом - Имплементация изменений в коде почти целиком уходит агенту - Тестирование теперь существует не отдельно, а тесты пишутся вместе с кодом (как многие хотели раньше) - PR/code review как отдельный ритуал должны исчезнуть и стать exception-based (на случай, если автоматика не спрашивала) - Деплои становятся действивтельно continuous и by design отделяются от release через flags/rollbacks - Мониторинг превращается из последнего этапа в главный safety layer всей системы Из этого у него следует довольно жесткий вывод: новый главный навык - context engineering, а новый контур safety - это observability. То есть выигрывает не та команда, у которой больше церемоний, а та, которая лучше умеет собирать контекст, задавать ограничения агенту и быстро замыкать telemetry обратно в цикл изменений. Это хорошо бьется и с DORA: они отдельно выделяют AI-accessible internal data и context engineering как ключевую capability для AI-assisted разработки. Все это выглядит очень реалистично для небольших компаний или на greenfield проектах - инструменты уже реально умеют работать на уровне всего репозитория: читать codebase, менять много файлов, запускать команды и тесты, делать refactoring и code review. OpenAI пишет, что Codex заточен под длинные инженерные задачи и review, а Anthropic показывает, что опытные пользователи со временем дают агенту больше автономии, хотя продолжают активно вмешиваться по ходу работы. Плюс бенчмарки вроде SWE-bench Verified показывают, что agentic systems уже решают заметную долю реальных issue из open-source. А вот что ждет большие компании и как будет выглядеть переход я рассказывал в статье "От классического PDLC к AI-native разработке" #Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign

Как пользоваться System Design Space + треки изучения (Рубрика #SystemDesign) Сделал онбординг для сайта system-design.space. Там я рассказываю, что сайт помогает системно развивать навыки проектирования: от базовых принципов до собеседований и практических архитектурных решений. На сайте есть разные типы материалов - Books - конспекты ключевых книг с практическими выводами и ссылками на оригиналы. - Cases - пошаговые разборы проектирования реальных систем с требованиями и trade-offs. - Films - документальные материалы и интервью с контекстом, таймлайнами и полезными источниками. - Originals - авторские главы по архитектурным подходам, паттернам и инженерной практике. Материалы можно сохранять в закладки, чтобы возвращаться к ним (в страницах настроек). Также есть граф знаний, который позволяет увидеть связи между главами, быстро находить смежные темы и строить маршрут от базовых концепций к более сложным. Также я создал возможность выбора трека обучения исходя из доступного для обучения времени, текущего уровня, а также бекграунда. После прохождения визарда собирается персональный маршрут, по которому дальше учиться. Также есть возможность отслеживать прогресс, который включается в настройках - это позволяет отмечать пройденные главы и видеть, как продвигается учебный маршрут. #SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering

[2/2] Measuring the Impact of AI on Developer Productivity at Meta (Рубрика #AI) Этот пост продолжение разбора отличного выступления ребят из Meta содержит инсайты, которыми они поделились с аудиторией. 1️⃣ У пользователей DevMate (внутренний аналог Claude Code или Cursor) выше среднего Meta наблюдала примерно 6–12% рост DDM (Diffs per developer per month). Это не звучит как "революция в 2 раза", но для большой инженерной организации такой прирост уже выглядит существенным, особенно если он устойчиво воспроизводится на больших массивах внутренних данных. 2️⃣ Эффект использования AI был неравномерным. Пока ИИ генерирует условные 10–30% изменений в диффе, выигрыш по времени почти не виден. А заметные улучшения появлялись, когда AI вносил более 60% кода в diff. Это намекает, что максимальный выигрыш возникает не тогда, когда AI используется "понемногу везде", а когда задача и workflow действительно позволяют передать инструменту большой кусок рутинной работы. То есть AI окупается сильнее в задачах, где можно делегировать значимый объем механического кода, а не только подсказки по мелочам. ​3️⃣ Senior engineers использовали AI эффективнее, чем junior, хотя junior могли обращаться к нему чаще. Это важный анти-интуитивный момент: более частое использование не равно большему эффекту. Похоже, выигрывают те, кто лучше задает контекст, умеет проверять ответ модели и понимает, где AI стоит доверять, а где нет. В итоге, в среднем диффы синьоров содержат заметно больший процент AI‑кода, чем диффы джунов. Тезис ребят в том, что опыт, архитектурное мышление и умение формулировать точные инструкции сильно усиливают эффект от ИИ - синьор как будто просто даёт ТЗ не джуну, а модели. ​ 4️⃣ После внедрения AI сначала может быть просадка, а уже потом рост продуктивности (J-кривая адаптации). По данным Meta наблюдается просадка продуктивности порядка 15%: люди учатся промптить, перепроверяют код, меняют привычный процесс. Уже после адаптации (через несколько месяцев) начинается устойчивый плюс к DDM и сокращение времени кодинга на дифф, что и даёт итоговые 6–12% роста выхода. Практический смысл тут простой: если компания смотрит на эффект AI только в первые недели после rollout, она может ошибочно решить, что инструмент "не работает". ​5️⃣ Телеметрия показала, что инженеры меньше сидят в чатах и документах, потому что ответы и контекст получают прямо в IDE через DevMate. Из‑за этого время "coding time per diff" формально растёт, но авторы считают это хорошим сигналом: меньше дёрганья по ссылкам и мессенджерам, больше фокуса в одном инструменте. ​ 6️⃣ Не все команды выигрывают одинаково - команды с высокой долей ML/ресёрча показывают меньший рост DDM, потому что много времени уходит на ноутбуки, эксперименты и аналитику, которые плохо отражаются в "диффах". Также DDM сильно "шумит" от праздников и внешних факторов, поэтому Meta не использует его в лоб как KPI для людей, а только как агрегированную продуктовую метрику влияния ИИ‑инструментов. ​ Если подводить итог, то я могу порекомендовать это видео и сопутстующие whitepaper тем, кто занимается вопросами измерения эффекта AI в разработке - это хороший методологический и практический подход к этой сложной теме. #Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes #AI #ML #Architecture #DevEx #DevOps

[1/2] Measuring the Impact of AI on Developer Productivity at Meta (Рубрика #AI) Превосходное выступление от ребят из запрещенной в России Meta, которое я пересматривал раза 3, чтобы получше разобраться со всеми деталями. Выступали Payam Shodjai (senior director of product management) и Pavel Avgustinov (techlead) направления developer productivity в Meta и они рассказали кучу интересных подходов + технических деталей того, как они подходят к этому вопросу. После этого выстулпения я гораздо лучше понял концепты из статьи "What's DAT? Three Case Studies of Measuring Software Development Productivity at Meta With Diff Authoring Time" (см. мой разбор). Основная идея доклада крутилась вокруг вопроса "а как измерять влияние AI-инструментов на реальную инженерную продуктивность в большой компании?". И из доклада видно, что Meta построила всеобъемлющий набор метрик, собрала исчерпывающую телеметрию, научилась учитывать сложные операции в системах контроля версий (это обещали пошарить в новом whitepaper, так как базовый git не умеет делать так, как Sapling от Meta). Дальше они искали прямые корелляции между использованием AI и классическими метриками productivity/business value. И речь тут шла не про стандартный code completion, а о более широком наборе AI-инструментов по всему SDLC. Если упрощать, то ребята показали, что без хорошей инструментализации разговор про ROI от AI быстро превращается в мнения и ощущения. Поэтому Meta делает ставку не на опросы как единственный источник, а на связку из телеметрии, diff-метрик, поведенческих данных и проверки этих данных на реальных рабочих сессиях. Это хорошо согласуется с описанной Meta системой Diff Authoring Time (DAT), которая объединяет privacy-aware telemetry из IDE, ОС и version control и затем валидируется наблюдательными исследованиями, опросами и визуализациями. 1️⃣ Умная классификация пулл-реквестов с помощью LLM Долгое время главной метрикой в компании был DDM (Diffs per Developer per Month - количество диффов/коммитов на разработчика в месяц). Однако с внедрением ИИ эта метрика стала уязвима для "закона Гудхарта": разработчики могли искусственно завышать показатели, нарезая задачи на мелкие коммиты, а ИИ генерировал много бойлерплейта (шаблонного кода). Чтобы измерять реальную бизнес-ценность, Meta внедрила метрику Feature DDM. Для этого они используют LLM, которые автоматически анализируют содержимое каждого пулл-реквеста и классифицируют его на: - Feature Diffs: код, создающий новую продуктовую ценность для пользователя. - Non-Feature Diffs: рефакторинг, обновление конфигураций, тесты и документация. ИИ-ассистенты оцениваются именно по тому, насколько они увеличивают количество продуктовых диффов. 2️⃣ Посимвольная телеметрия и внутренние инструменты (Devmate) Meta не полагается на базовую статистику системы контроля версий. Для сбора данных они используют свой внутренний ИИ-инструмент - Devmate (кастомное расширение для IDE). Главный нюанс их телеметрии - посимвольное отслеживание (character-level tracking). Система точно знает происхождение каждого символа в коде. Meta может с абсолютной точностью сказать, какой процент символов в итоговом слитом пулл-реквесте был напечатан инженером вручную, а какой - сгенерирован нейросетью и оставлен без изменений. Отдельно упоминается про то, что Sapling позволяет умно отслеживать transition между commits и правильнее считать как трансформируется код при помощи edit/rebase и остального, а также кем именно (людьми или автоматикой). Помимо этого, телеметрия отслеживает узкие места всего цикла (SDLC): время нахождения задачи на код-ревью, циклы одобрения и прохождение автоматических тестов. В следующем посте я расскажу про основные инсайты, которыми поделились авторы и которые реально интересны. #Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes #AI #ML #Architecture #DevEx #DevOps