Книжный куб

Интервью с Максимом Евдокимовым про современных CPO, крутые продукты и сложные решения (Рубрика #Management) Посмотрел с большим интересом интервью с Максимом Евдокимовым, бышим коллегой, который когда-то был CPO в Т-Банке, CPO в hh.ru, большим директором в Сбере, гендиром Okko, а сейчас занимает должность CPMO (Chief Product and Marketing Officer) в Bir Bank, крупнейшем розничном банке Азербайджана. Ниже я выделил основные моменты интервью с моей точки зрения 1. Начало карьеры и опыт в телекоме Максим рассказал о своем первом заработке в качестве дворника еще в школьные годы. Профессионально он начал работать в 1995 году в торговой компании, для работы хватило знания английского языка и компьютера. Позже, в 2001 году, он попал в финскую компанию Sonera, что стало началом его карьеры в телекоме. По словам Максима, телеком-компании в начале 2000-х были главными драйверами развития цифровых технологий, хотя тогда еще не существовало многих современных терминов и фреймворков. Работа в Мегафоне научила его фокусироваться на клиенте и его потребностях, а также формировать пользовательскую потребность, а не просто отвечать на существующие запросы. Интересно, что сейчас телеком компании - это скорее консерваторы:) 2. Опыт в Тинькофф Банке В Тинькофф Банк (ныне Т-Банк) Максим пришел в 2013 году после 12 лет работы в телекоме. Первым его проектом был "Тинькофф Wallet" — мобильный кошелек с входом по номеру телефона, который был запущен в декабре 2013 года. Из-за регуляторных изменений проект пришлось трансформировать, и Максим перешел к управлению клиентской частью мобильной платформы банка. Одним из значимых достижений Максима в Тинькофф было внедрение концепции лайфстайл-банкинга и запуск сторис в банковском приложении. Тинькофф стал первым банком на европейском рынке, использовавшим формат сторис для персонализированных предложений клиентам. 3. Продуктовый подход и управление Максим поделился своим видением продуктового подхода, который он называет "продакт-менеджмент от Евдокимова". Его ключевой принцип: лучше сделать продукт на "твердую четверку" и потом довести до "пятерки", чем выпустить "тройку с минусом" и никогда к ней не вернуться. Он выступает против использования термина MVP (Minimum Viable Product) и предпочитает концепцию MLP (Minimum Lovable Product) — ограниченного, но очень хорошего продукта. По его мнению, для крупной компании неприемлемо делать некачественные продукты, так как это создает репутационные и конкурентные риски. 4. Текущая роль в Bir Bank В Bir Bank Максим отвечает за продукты и маркетинг. Он рассказал о двух основных задачах в своей текущей роли: - Построение эффективных продуктовых процессов, так как банк переживает "болезнь роста" - Развитие экосистемной повестки, чтобы клиенты банка могли увидеть ценностное предложение от других активов экосистемы По оценке Евдокимова, финтех и банкинг в Азербайджане отстают от российского рынка примерно на 5-7 лет, но в некоторых аспектах, например, в цифровом правительстве и связке бизнеса с государством, некоторые вещи сделаны даже лучше. 5. Ключевые выводы и идеи Максим подчеркивает важность "ownership" (чувства собственности) в продуктовых командах. По его мнению, идеальная команда — это единомышленники, где каждый отвечает за весь продукт, а не только за свою зону ответственности. Он считает, что в организации нужно развивать культуру доверия и ответственности, чтобы люди могли проявлять инициативу. Причины неудач в продуктовом подходе часто кроются в головах менеджмента, включая акционеров. Для разных стадий развития организации нужны разные управленческие лидеры, и важно вовремя принимать решения о смене руководства. В общем, подкаст получился достаточно интересным:) #ProductManagement #Management #Leadership #Software #Engineering #Career

What your CEO must know about AI (Рубрика #AI) Посмотрел интересное выступление Хьюберта Мистела, Senior AI Researcher в компании Novartis. Хьюберт руководит командой исследователей искусственного интеллекта в области разработки лекарств, а также преподает машинное обучение и науку о данных в Dublin Business School. Это выступление состоялось на конференции AI Engineer World's Fair 2025 — крупнейшем техническом ИИ-событии года, которое прошло 3-5 июня 2025 года в Сан-Франциско. Ниже представлены ключевые идеи выступления в моей интерпретации 1. Агентское будущее организаций Хьюберт начал с провокационного заявления: через три года организации могут управляться ИИ-агентами. Это следует из темпов развития технологий. Дальше он рассуждает о том, что такое AI агент - по его мнению это приложение на основе больших языковых моделей, обладающее автономным поведением. Ключевая особенность агентов в том, что они выполняют пошаговые действия с динамическим контролем, адаптируя использование инструментов в зависимости от результатов предыдущих шагов. 2. Трансформация рабочих процессов Агентные рабочие процессы — главное отличие от традиционной автоматизации. Если раньше машинное обучение могло автоматизировать отдельные шаги, то ИИ-агенты способны: - Автоматизировать и делегировать несколько шагов одновременно - Действовать как связующее звено между задачами - Работать без человеческого вмешательства, запрашивая обратную связь только при необходимости Дальше автор размышляет об архетипах сотрудников, среди которых он выделяет следующих - Молчаливые исполнители — низкая коммуникация, высокая производительность - Индивидуальные исполнители — сбалансированный профиль - Связующие звенья — соединяют разные команды - Умножители — усиливают работу других участников команды - Центры знаний — предоставляют экспертизу 3. Новая реальность рынка труда Доменные знания и интеллект становятся дешевыми и легкодоступными, а это значит, что - Компаниям и сотрудникам стоит стремиться к мультидисциплинарным знаниям - Появятся новые роли: "майнеры рабочих процессов", "люди-оркестраторы ИИ" - ИИ ускоряет "деятелей" — разница в производительности может достигать не 10x, а 100x (похоже на отсылку к 10x инженерам) 4. Демократизация создания агентов Критически важно дать возможность сотрудникам самостоятельно создавать агентов с помощью no-code/low-code инструментов, для этого нужно следующее - Когнитивная самоосознанность — понимание собственных мыслительных процессов - Способность переводить ментальные шаги в конкретные инструкции - Доступ к инструментам быстрого создания агентов 5. Этические вопросы Есть два критических вопроса, которые надо решить для дальнейшего распространения агентов: - Готовы ли мы не просто делегировать задачи, а позволить ИИ-агентам управлять процессами? - Какие ценности заложить в агентов и как разрешать конфликты между человеком и ИИ? 6. Практические рекомендации для руководителей - Аудит стратегии: если ваша AI-стратегия остается актуальной при замене "AI-агент" на "ML" — она устарела - Картирование рабочих процессов: детальное понимание workflows критично для получения максимальной выгоды - Готовность к трансформации: организационная структура компании может кардинально измениться - Инвестиции в контекст: контекст становится новой нефтью, важнее самих данных В общем, у Хьюберта получилась интересное выступление о революции AI-агентов, которая уже началась и к которой стоит быть готовым. #AI #ML #Software #Engineering #Development #Agents #Architecture

[3/3] Enabling the Study of Software Development Behavior With Cross-Tool Logs (Рубрика #Management) Этим постом я заканчиваю рассказ об этой интересной статье, которую рассмотрел в первых двух частях обзора: 1 и 2. Здесь я приложил иллюстрации из статьи. А для любитилей разбираться с методологиями рекомендую еще более техническую статью длиннее в два раза от этих же авторов, которую они опубликовали в другом журнале - "Enabling the Study of Software Development Behavior with Cross-Tool Logs" #Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

[2/3] Enabling the Study of Software Development Behavior With Cross-Tool Logs (Рубрика #Management) Продолжая рассказ про эту статью, надо рассказать про принципы конфиденциальности, способы валидации, пример исследования, а также про последствия создания методологии InSession и где она дальше засветилась. Ну а начнем мы с принципов конфиденциальности, которым следовали авторы - Сбор данных только от сотрудников - Фокус на рабочих инструментах - Отказ от сбора контента, созданного сотрудниками - Шифрование хранимых данных - Аудируемый доступ к данным - Запрет на отчетность по индивидуальным сотрудникам без согласия (интересно, что на практике соблюдение этого принципа ооочень трудно добиться) - Уничтожение данных после установленного периода хранения (3 года) Для валидации полученных измерений авторы решили сравнить их с поведенческими самоотчетаим (diaries). Авторы провели исследование с 25 инженерами Google, которые создавали дневники своей деятельности, затем сравнили эти дневники с данными сессий, используя показатель согласия PABAK (Prevalence and Bias Adjusted Kappa). Результаты показали высокое согласие для времени рецензирования (0.81), кодирования (0.69) и исследования (0.70). Дальше авторы провели эксперимент для оценки эффекта readability certification инженеров на время рецензирования. Readability certification - это сертфикация о том, что инженер знает идиомы языка и правила написания принятые в Google. Гипотеза была в том, что при получении инженером сертификации по readability - Ревьюверам придется тратить меньше времени на ревью - Инженерам придется тратить меньше времени на доработки по комментариям ревьюверов (shepherding) При анализе влияния процесса читаемости кода они применили линейную регрессию с контролем стажа разработчика, количества рецензентов и размера изменения, а также включили случайный эффект для идентичности автора. И они получили такие результаты - Для C++: время рецензирования сократилось на 4.5%, время shepherding - на 10.5% - Для Java: время shepherding сократилось на 10.0% - 88% инженеров, завершивших процесс читаемости Java, согласились с утверждением о положительном опыте Это исследование значительно повлияло на подходы к измерению продуктивности разработчиков в индустрии. Система InSession стала основой для ответа на долгосрочные вопросы программной инженерии, такие как "делают ли типы разработку более эффективной?". Подход Google к измерению поведения разработчиков через кросс-инструментальные логи вдохновил другие организации на создание аналогичных систем. Методология придуманная авторами упоминалась и в следующих статьях, например - "What Improves Developer Productivity at Google? Code Quality" (2022) - исследование использовало методологию, разработанную в InSession, для изучения панельных данных и установления причинно-следственных связей между качеством кода и продуктивностью разработчиков. Я уже разбирал эту статью - "Predicting developers' negative feelings about code review" (2020) - работа применила данные InSession для предсказания негативных межличностных взаимодействий во время рецензирования кода, используя 90-й процентиль времени рецензирования и сопровождения. - "The pushback effects of race, ethnicity, gender, and age in code review" (2022) - исследование использовало инфраструктуру данных InSession для изучения влияния демографических факторов на процесс рецензирования кода. Окончание разбора с изображениями из статьи будет в последнем посте. #Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

[1/3] Enabling the Study of Software Development Behavior With Cross-Tool Logs (Рубрика #Management) Прочитал наконец-то исследование, вышедшее в 2020 году, где авторы из Google рассказали про создание своей системы InSession, которая позволяет проводить комплексный анализ поведения инженеров путем интеграции логов от множества инструментов разработки. Ценность исследования в том, что разработчики - это одна из самых затратных частей разработки софта, поэтому даже небольшие улучшения продуктивности могут принести значительные результаты. InSession отличалось от других подобных инструментов тем, что собирало не только данные из IDE, но и не требовало установки на рабочие машинки инженеров (данные собирались из существующих облачных инструментов). Если говорить про саму систему, то она состояла из следующих ключевых частей 1. События (Events) Событие - это отдельное использование инструмента или системы разработчиком или от имени разработчика. Для каждого типа логов был свой импортер, который трансформировал данные в общий формат событий. Сами события были разных типов - Фронтенд-события: инициируемые разработчиком активно (например, нажатие кнопки интерфейса) - Бэкенд-события: происходящие асинхронно от имени разработчика (например, cron-задания) - Мгновенные события: с неопределенной конечной точкой - Длительные события: с установленным временем начала и окончания 2. Артефакты Для большинства событий собиралась еще дополнительная метаинформация, которую авторы называли артефактами. Они были двух типов Идентифицирующие задачу артефакты: идентифицируют конкретную задачу разработки для группировки связанных событий Информационные артефакты: предоставляют контекстную информацию о событии 3. Сессии Собственно события объединялись в сессии при помощи группировок, которые - Происходят в один день - В течение временного интервала (10 минут) - Имеют одинаковые идентифицирующие задачу артефакты (или не имеют никакую) 4. Метрики Система выводит семь ключевых метрик поведения разработчиков: - Время кодирования - время написания или maintaining кода - Время рецензирования - время на ревью кода - Время сопровождения (shepherding) - время на доработки кода по результатам обратной связи с code review - Время исследования - время на изучение документации - Время разработки - время на разработческие активности любого типа (что не покрыты другими категориями) - Время работы с электронной почтой - Время, проведенное на встречах Если говорить про источники данных для InSession, то это множество инструментов, включающих - Buganizer - система отслеживания ошибок - Code Search - инструмент поиска и просмотра кода - Cider - веб-IDE - Blaze - распределенная система сборки - Critique - инструмент рецензирования кода - Gmail и Calendar - здесь тянулись ограниченные метаданные - Еще более 90 инструментов командной строки Продолжение обзора этой интересной статьи в следующем посте. #Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

Cursor CEO: Going Beyond Code, Superintelligent AI Agents, And Why Teste Still Matters (Рубрика #AI) Посмотрел интересное интервью Michael Truell с Garry Tan. Они говорили про будущее разработки и это действительно интересно, ведь Майкл — соучредитель и генеральный директор Anysphere, компании, создавшей Cursor, один из самых быстрорастущих AI-инструментов для кодирования. А Гарри — президент и генеральный директор Y Combinator, известного стартап-акселератора. Это интервью было 11 июня и оно проходило во время Demo Day Y Combinator Summer 2025, где представляются новые компании из текущего набора Y Combinator. Ниже представлены ключевые идеи интервью в моей интерпретации 1. Революционное видение будущего программирования Основная цель Cursor — изобрести новый тип программирования, где разработчики смогут просто описывать желаемый результат, а не писать сложный код. Майкл предвидит, что программисты будут становиться "дизайнерами логики", фокусируясь на высокоуровневом проектировании, а не на написании низкоуровневого кода. Интересно, что раньше часто говорили про языки программирования новых поколений, например, третьим поколением были стандартные C, C++, C#, Java и JavaScript, но люди говорили про четвертое поколение. Но оно особо не полетело:) А теперь новым поколением языков программирования похоже будет plain english/russian/whatever text (но лучше с правильными промптами). Интересно, что Майкл считает, что за следующие 5-10 лет произойдет значительное изменение в способах создания софта. 2. Текущее состояние AI в программировании Наибольшие изменения уже заметны в небольших кодовых базах, где разработчики могут работать на более высоком уровне абстракции. В среднем разработчики используют AI для написания 40-50% кода в Cursor, но все еще требуется человеческий контроль и понимание. Майкл говорит о том, что vibe coding пишется без глубокого понимания и не рекомендуется для долгосрочных проектов (а для прототипов он отлично подходит) 3. Технические вызовы и ограничения Ограниченный размер контекстного окна AI затрудняет работу с большими кодовыми базами, содержащими миллионы строк кода (что типично для больших компаний). Существующие модели испытывают трудности с непрерывным обучением и сохранением контекста организации и предыдущих решений. AI-модели пока не имеют четкого представления об эстетике, что требует участия человека-дизайнера. 4. История и эволюция Cursor Команда основателей из MIT первоначально работала над AI для автоматизированного проектирования (CAD), но позже переключилась на программирование. GitHub Copilot и исследования OpenAI о масштабируемости моделей стали ключевыми источниками вдохновения для создания Cursor. Вместо создания расширения для условного VSCode команда решила разработать собственный редактор, что оказалось важным преимуществом. 5. Рост и успех компании Anysphere достигла оценки в 9,9 миллиардов долларов после привлечения 900 миллионов долларов инвестиций. Компания достигла 100 миллионов долларов годового дохода всего за 20 месяцев после запуска, а затем выросла до 300 миллионов за два года и более 500 миллионов к середине 2025 года. Cursor используется в крупных технологических компаниях, включая OpenAI, Stripe, Spotify и других. 6. Будущее AI и программирования Способность создавать программное обеспечение станет доступной гораздо большему числу людей. Появится больше специализированного программного обеспечения для конкретных отраслей благодаря снижению барьеров для разработки. Несмотря на автоматизацию, "чувство вкуса" останется незаменимым человеческим качеством — оно позволяет определить, что именно нужно создать и как это должно работать. Если подводить итоги, то это действительно интересный взгялд на будущее программирование от гостя, который не просто его предсказывает, но и создает своими руками, так как Cursor стремится быть на переднем крае этой трансформации. По мнению Тралла, мы находимся в начале эпохи интеллекта, которая значительно расширит возможности создания для всех. #AI #ML #Software #DevEx #Engineering #Development

Лекция-практикум "Как IDE помогает писать код: от подсветки синтаксиса до ИИ-агентов" (Рубрика #AI) 19 июня в 19:00 в Центральном Университете в Москве пройдет лекция про то, как IDE прошли путь от базы до AI агентов. Выступать будут мои коллеги: - Вадим Гончаров, руководитель разработки игр и платформы геймификации - Денис Артюшин, технический менеджер ИИ-ассистентов для разработчиков С обоими я записывал подкасты: с Вадимом про его путь в Т-Банке, где мы наговорили на две части (1 и 2), а с Денисом мы общались про AI-ассистентов и конкретно нашего Nestor, правда этот эпизод опубликован только внутри Т и снаружи не доступен. Правда, у Дениса есть выступление с апрельской конференции Platform Engineering Night, где он рассказывал про агентов, а я уже разбирал его раньше. Это первая лекция в рамках проекта Computer Renescience, который посвящен переосмыслению актуальной повестки в компьютерных науках. Зарегестрироваться для посещения лекции можно здесь. P.S. Интересно, что я недавно выступал с докладом "Интегрируем AI в процессы разработки большой компании: почему разрешить всем Cursor — не вариант" на CTO Conf X, профессиональной конференции для технических директоров, от компании "Онтико". Там было и про IDE и про AI-фикацию сценариев разработки инженеров, от помощи в рамках них до делегированию работы агентам. #Engineering #AI #Software #Agents #PopularScience

Code of Leadership #40 - Interview with Vladimir Lazarev about media platforms and SDLC (Рубрика #Management) В очередном выпуске подкаста ко мне пришел интересный гость, Владимир Лазарев, бывший технический руководитель Т-Ж. Вова живет сейчас в Белграде и мы с ним обсудили его путь в ИТ, работу в Т, а потом отъезд зарубеж и работу в качестве engineering manager и консультанта по инженерным процессам. За полтора часа мы обсудили много интересных тем - Введение и знакомство с гостем - Влияние семьи и самообразование - Выбор профессии и поступление в вуз - Опыт в менеджменте и работа в диджитал-агентстве - Приход в Т-Банк и работа над проектами - Развитие и модернизация медиа-проектов - Переезд в Белград и опыт работы в TravelTech - Обсуждение ухода из ETG - Советы по саморазвитию и рекомендации по книгам Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music. Статьи и контакты Вовы есть на его сайте: https://laidrivm.com/. Пишите Вове, если ищите engineering management/director, или хотите проконсультироваться о менеджменте команд или веб-разработке. Рекомендации Вовы: - Книга "Designing Data-Intensive Applications", про которую я уже рассказывал - Книга "Теоретический минимум по Computer Science", про которую я уже рассказывал - Книга "Пиши, Сокращай", про которую я уже рассказывал - Школа Менеджеров Бюро Горбунова - Сайт о local-first разработке #Software #Engineering #SRE #Management #Architecture #Processes #Devops #DevEx

Надежность на масштабе 50 млн клиентов: опыт Т-Банка для инженеров (Рубрика #SRE) Сегодня на Хабре вышла статья Алексея Мерсона, бывшего dev advocate нашей платформы Sage. Леша рассказывал про то, как у нас выстроены процессы обеспечения надежности и как они инструментализированы. Ниже я кратко описал основные мысли статьи - Леша начал с базы, рассказав определение надежности по SRE Book от Google, пирамиду качества (надежность -> UX -> Enjoyment), отметив, что без надежной основы нет смысла говорить об удобстве интерфейсов. - Дальше пришла пора тройки: SLI/SLO/SLA, а также бюджета ошибок и его связи с каноническими MTTR и MTBF - Потом Леша рассказал про святую троицу инструментов -- Sage — единая платформа наблюдаемости, заменившая зоопарк инструментов мониторинга -- FineDog — система инцидент-менеджмента для учета SLA и здоровья услуг -- Колобок — инструмент управления релизами с календарем и светофором - Но инструменты обычно поддерживают процессы, поэтому Леша рассказал про работу с инцидентами: от алертинга с принципом "stateless-инженера" до кризис-менеджмент-планов, а также объяснил как мы разгружаем контакт-центр во время инцидентов - Вопросы надежности курирует наш центр надежности, который работает над методологией, процессами, делает deep dive по крупным инцидентам и делится со всеми статистикой и интересными инсайтами Если подводить итог и как-то суммировать то, что полезно сделать в компании почти любого размера и прямо сейчас, то получится следующее - Стоит заниматься наблюдаемостью независимо от размера сервисов - Важно наладить работу с инцидентами и научиться писать постмортемы - Если компания большая, то может потребоваться гибридная схема с центром надежности и ролями chief reliability officers по отдельным бизнес-вертикалям - Важно держать фокус на клиентском опыте — технологии делаются ради решения задач клиентов Если же накинуть масштаб Т, то видно, что - Важна автоматизация всех процессов - нельзя лично поговорить с миллионами клиентов - Важно собирать и анализировать большие объемы данных - Важно проектировать отказоустойчиво свои системы и использовать платформенные сервисы (XaaS) Если говорить про ценность статьи, то она не только разбирает кейс Т в плане надежности, но и демонстрирует комплексный подход к надежности: от технических инструментов до организационных процессов. Это не просто рассказ о том, "как мы мониторим метрики", а системное видение того, как обеспечить работоспособность критически важного сервиса. P.S. Интересно, что я недавно выступал с докладом "Надежность и безопасность — это дополнительные опции или фундамент для современных ИТ-систем?" на PHDays и упоминал процессы и инструменты, которые подробно разбирает Леша в этой статье. #SRE #SystemDesign #Software #Architecture #Metrics #SoftwareArchitecture #Engineering

The 4 Patterns of AI Native Development — Patrick Debois (Рубрика #AI) Вчера посмотрел короткое, но интересное выступление от Патрика Дюбуа, эксперта по DevOps, соавтора "DevOps Handbook", эксперта по интеграции AI в разработку. Это выступление состоялось 4 июня 2025 года на AI Engineer World's Fair 2025 в Сан-Франциско — крупнейшем отраслевом событии, посвященном практическому применению AI в инженерии. Конференция собрала около 1000 основателей, вице-президентов и ведущих инженеров со всего мира (я с большим интересом следил за этой конференцией в прямом эфире, что был доступен на Youtuve). Ключевые идеи Патрика о том, что мы сейчас в состоянии перехода от обычной разработки к AI Native. По его мнению это похоже на то, как мы все двигались в сторону cloud native, но теперь у нас новая волна изменений. А это приводит к тому, что инженеры меняются в 4 направлениях 1. От производителя к менеджеру. Разработчики все меньше пишут код сами, вместо этого управляют AI-агентами, которые генерируют код. Время написания кода сокращается, но время на ревью увеличивается — когнитивная нагрузка растет. 2. От реализации к намерениям Фокус смещается с "как делать" на "что делать". Мы описываем цель и требования, позволяя AI самостоятельно найти решение. Появляются specification-центричные инструменты. 3. От delivery к discovery Стоимость экспериментов резко снизилась. Теперь можно быстро создавать прототипы, тестировать множественные варианты и исследовать новые идеи, прежде чем принимать решения. 4. От контента к знаниям AI дает мотивацию систематизировать и сохранять знания команды. Накопленная экспертиза становится конкурентным преимуществом компании, поскольку создание продуктов становится все более автоматизированным. Если подводить итог, то AI не заменяет разработчиков, а изменяет области, где мы создаем ценность. Понимание этих паттернов поможет инженерам эффективно позиционировать себя и свои команды в меняющемся ландшафте разработки. #AI #Software #Engineering #Architecture #Agents #Leadership

ЦСКА - Зенит (Финальный матч) (Рубрика #Sport) Вчера вместе с сыном и друзьями увидели как баскетбольный ЦСКА стал чемпионом. Чем-то ход противостояния напомнил четвертый матч, который мы посетили до этого и про который я рассказывал. Правда, в этом игра была плотнее до середины второго периода, а дальше ЦСКА начал уходить в отрыв. К концу третьего периода отрыв ЦСКА от Зенита был больше, чем Зенит в среднем забивал в периоде и стало ясно, что ЦСКА - чемпион. Дальше было интересно, а выбьет ли ЦСКА 100 очков - не выбил, но выпустил молодежь на последние минуты. Дальше мы посмотрели церемонию награждения, увидели вручение кубка и довольные пошли по домам. Сыну очень понравилось, что кричалка про то, что ЦСКА будет первым на этот раз оказалась правдой:) #Kids #ForParents #ForKids

Measuring Productivity: All Models are Wrong But Some are Useful (Рубрика #Management) Этот whitepaper от исследователей Google Сьеры Джаспан и Коллина Грина, представляет собой текстовую версию их выступления на DPE Summit (Developer Productivity Engineering). В заглавие статьи они вынесли знаменитую цитату Джорджа Бокса "В сущности, все модели неправильны, но некоторые полезны", которая отлично применима и к вопросам измерения продуктивности инженеров тут к месту. Они рассказывают про принципы и методики, что выработали в Google для преодоления ограничений моделей и получения ценных инсайтов. Эта статья продолжает серию "Developer Productivity for Humans" в журнале IEEE, все статьи из которой рассмотрены в отдельном посте, а дальше поговорим про этот whitepaper. 1. Измерение продуктивности разработчиков — это построение моделей, где необходимо принять, что ни один подход к измерению не способен идеально охватить всю сложность разработки софта. Авторы утверждают, что модели продуктивности часто «опасно избирательны», поскольку опускают важные аспекты работы разработчиков, что приводит к неполным или искажающим оценкам. Важно понимать, что эффективное измерение продуктивности требует комплексного подхода, который охватывает несколько аспектов работы, а не опирается на примитивные метрики вроде количества строк кода или частоты коммитов. 2. Часто такой комплексный подход связан с компромиссами между разными сторонами разработки софта, например, легко ускорить velocity, если выкинуть этап код ревью и тестирования. Для нас это означает, что продуктивность следует рассматривать как баланс между несколькими факторами, в первую очередь скоростью, удобством и качеством, а не как единичный измеряемый результат. Интересно, что в Google этот компромисс представляется в виде треугольника: speed, ease, quality. 3. Исследователи в Google также смотрят и на социологические аспекты, учитывая их совместно с технологическими. Именно этот подход дал название всей серии статей, где измерение продуктивности должно учитывать сложную, творческую природу работы разработчика, а не рассматривать её как чисто механический процесс. 4. В этом исследовании лежит структурированная модель построения систем измерения продуктивности, которая избегает распространённых ошибок. Кажется, авторы используют подход Goals/Signals/Metrics (GSM), про который я уже писал, когда разбирал книгу "Software Engineering at Google", но они прямо об этом не говорят:) 5. Авторы учитывают два противоположных фактора: стремление к простоте (parsymony) и избегание опасной избирательности (worrying selectivity). Парсимония подталкивает к включению меньшего числа компонентов ради простоты, а worrying selectivity требует включения большего числа аспектов для охвата всех важных сторон продуктивности. Исследование советует склоняться к более полному охвату, а не к чрезмерной простоте. 6. Авторы комбинируют в своей методологии качественные и количественные методы, используя данные из инструментальных логов и опросов. Такой смешанный подход отражает их понимание того, что продуктивность разработчиков нельзя полностью охватить только количественными метриками или исключительно субъективными оценками. Вместо этого они предлагают комбинировать разные типы данных для более полного понимания картины. Интересно, что структура их модели учитывает влияние самих измерений на поведение: то, что измеряется, зачастую начинает влиять на поведение сотрудников, иногда вопреки изначальным целям. В общем, авторы предлагают измерять продуктивность инженеров, понимая ограничения моделей измерений, и использовать комплексный, многомерный подход, фиксируя компромиссы и валидируя выводы с помощью разных методов. #Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

GitHib CEO predicts the future of programming (AI) Посмотрел на выходных интервью Thomas Dohmk, CEO GitHub, которое у него брал Matthew Berman — известный AI-блогер. Само общение состоялось уже после MS Build, где GitHub анонсировал open source для своего чата внутри VSCode "GitHub Copilot Chat". Основные мысли интервью ниже 1. Влияние GPT и начало Copilot Генеральный директор GitHub признаёт, что изначально сомневался в работоспособности GPT, но был впечатлён результатами: GPT изменил подход к разработке ПО навсегда. Copilot стал первым массовым инструментом, который завершает код за пользователя, и это оказалось крайне востребованным 2. Статистика и пользовательский опыт Copilot пишет 25% кода в файлах, где он включён, а уровень удовлетворённости пользователей очень высок (NPS — 72). Интеграция с редакторами (VS Code, Visual Studio) и завершение кода на лету стали точкой входа AI в ежедневную работу разработчика 3. Образование и значимость программирования Программирование остаётся важным навыком для понимания современного мира, его нужно преподавать детям и взрослым. Основы информатики и умение читать код — это универсальная грамотность будущего. 4. Роль и ответственность разработчика Даже с появлением copilot агентов инженер должен проверять и подтверждать изменения, чтобы избежать ошибок и проблем с безопасностью. Важно понимать, что делает ИИ-агент, и не терять контроль над кодом 5. Эволюция индустрии и открытый исходный код Открытый исходный код стал стандартом индустрии, а Copilot теперь доступен как open source для интеграции и доработки сообществом (речь идет про расширение для чата). GitHub и Microsoft делают ставку на использование нескольких моделей ИИ для разных задач, а не на одну универсальную (одну для code completion из-за требований к latency, другую для агентских workflow, где latency не так важно и можно использовать модель поумнее и помедленнее) 6. Будущее разработки: агенты и микро-приложения Интересная идея о том, что в будущем персональные агенты могут создавать мини-приложения "на лету" для конкретных задач, а операционная система будет скрыта за ИИ-интерфейсом. Пример: автоматизация семейных задач (управление карманными деньгами детей) с помощью Copilot и персонализированных приложений 7. Vibe Coding и ограничения ИИ Vibe Coding — подход, при котором ИИ помогает быстро воплощать идеи в прототипы, но для серьёзных задач нужны ревью, безопасность и стандарты. ИИ-агенты пока ограничены по объёму обрабатываемого кода, но в будущем смогут работать с большими проектами и тогда вайбкодить станет еще проще. 8. Интеграция и экосистема ИИ-агентов Ожидается появление экосистемы персональных ИИ-агентов, интегрированных с работой и личной жизнью пользователя. Знания, связанные с работой, будут принадлежать компании, а личные — останутся у пользователя. Чем-то этот концепт напоминает сериал "Разделение", который я не смотрел, но про который слышал. 9. Влияние на рынок труда и новые профессии ИИ автоматизирует рутинные задачи, но открывает новые профессии и возможности, даже для тех, кто не владеет английским языком. Как и в прошлые технологические революции, часть профессий исчезнет, но появятся новые роли и специализации. 10. Оптимизм в отношении ИИ Томас выражает оптимизм: ИИ не заменит людей, а поможет решать больше задач, повысит продуктивность и создаст новые возможности для разработчиков В общем, интервью неплохо показывает как быстро развивается сфера AI-assisted programming и какую роль в этом играет GitHub как лидер индустрии. Основной посыл: AI не заменяет программистов, а делает их более продуктивными, позволяя сосредоточиться на креативных и стратегических аспектах разработки. #AI #Software #Engineering #Architecture #Agents #Math #Software #ML #Leadership

Пространство медленной жизни (Рубрика #Culture) Неделю назад мы с женой и друзьями отдыхали на выходных в эко-парке ПМЖ (Пространство Медленной Жизни), отмечая день рождения одного из нас. Празднование прошло отлично из-за нескольких моментов - Отличная компания, которой нам редко удается собраться и душевно пообщаться (как обычно было много физтехов и мы поговорили и про науку, и про технологии и про университетское образование) - Живописное место в Калужской области рядом с арт-парком "Никола-Ленивец", где очень приятно поваляться на пуфиках, пожечь костер и поспать в шатрах на природе - Отличная еда - именинник и владельцы эко-парка позаботились о том, чтобы гостям было вкусно и сытно:) - Достопримечательность в виде арт-парка "Никола-Ленивец", который мы с большим удовольствием посетили и посмотрели на архитектурные артефакты - Спортивные мероприятия - желающие могли съездить и поплавать на сапах во второй день отдыха В общем, отдых был прямо отличный - у нас с женой получилось на выходные переключиться с быстрого темпа Москвы на медленный, обещанный в названии ПМЖ:) P.S. Хотел рассказать еще пару слов про арт-парк Никола-Ленивец, который мы посетили в один из дней. Этот парк является уникальным пространством современного искусства и архитектуры, расположенным на берегу реки Угры. За более чем два десятилетия существования парк вырос до 650 гектаров, на которых расположены более ста ленд-арт инсталляций, созданных художниками и архитекторами из России и зарубежья. В течение уикенда здесь можно не только прогуляться по причудливым арт-объектам, но и познакомиться с историей их создания, принять участие в интерактивных событиях или отведать блюда фермерской кухни. Собственно, парк ПМЖ отлично подходит для тех, кто приехал насладиться современным искусством в парк "Никола-Ленивец", что мы и проверили на своем примере:) #Rest #Culture

Генетическая селекция эмбрионов: От научной фантастики к коммерческой реальности (Рубрика #Science) Наткнулся вчера на пост про стартап Nucleus Genomic, что презентовал революционную платформу Nucleus Embryo, которая позволяет родителям анализировать генетические профили эмбрионов при ЭКО и выбирать наиболее подходящие для имплантации. Это мне напомнили дистопический мир, изображенный в культовом фильме "Гаттака" 1997 года. Но давайте сначала поговорим про продукт, а дальше вспомним Гаттаку Nucleus Embryo — это софт для генетической оптимизации, который позволяет родителям проанализировать до 20 эмбрионов по более чем 900 наследственным заболеваниям, а также по 40 дополнительным параметрам, включающим риски развития рака, хронических заболеваний, физические характеристики, когнитивные способности и даже цвет глаз. Это решение основано на полногеномном секвенировании (WGS) с глубиной покрытия 30x, что обеспечивает анализ 100% ДНК по сравнению с менее чем 0,1% у конкурентов вроде 23andMe. Компания утверждает, что секвенирует в 1000 раз больше ДНК, чем традиционные потребительские тесты, обеспечивая беспрецедентную точность генетического анализа. Если говорить про сам подход, то это полигенный скриннинг эмбрионов (PES), что основан на вычислении полигенных оценок риска (PRS) для каждого эмбриона. Оценки рассчитываются путем суммирования эффектов сотен, тысяч или даже миллионов вариантов ДНК, которые различаются между индивидуумами. Современные исследования показывают, что эффективность такой селекции ограничена, т.к. большинство выборов происходит между эмбрионами одних и тех же родителей, что существенно ограничивает как генетическую, так и средовую вариабельность. А теперь проведем параллели с фильмом "Гаттака", в котором показано как может выглядеть социальная стратификация на основе генетики. В этом мире общество было разделено на "валидных" (генетически усовершенствованных) и "инвалидных" (естественно рожденных), при этом последние ограничены в доступе к образованию, работе и даже браку. Главынй герой фильма, Винсент Фримен, как раз человек второго сорта. Он близорук, имеет врождённый порок сердца, а генетический тест сулит ему примерно 30 лет жизни. Но у Винсента есть мечта — полететь в космос. И мы весь фильм наблюдаем как он идет к своей мечте, преодолевая ограничения окружающего мира за счет своей воли и работы над собой. Если экстраполировать современные технологии (аля Nucleus Embryo), то видно, что они создают предпосылки для аналогичной стратификации. Хотя генетическая дискриминация формально запрещена, экономические барьеры доступа к генетической помощи могут привести к тому, что привилегированные слои общества смогут передавать свои преимущества детям через биологические механизмы. Как отмечают исследователи, это может привести к натурализации привилегий, оправданных научными предсказаниями. Интересно, что услуги полигенной селекции эмбрионов уже предлагаются потребителям как минимум четырьмя компаниями, а 5 лет назад родлился первый ребенок, прошедший через PES. Правда, существующие технологии имеют значительные ограничения. Исследования показывают, что полигенная селекция в целом не очень полезна при нацеливании на сложные характеристики здоровья — возникает проблема с оптимизацией по множеству критериев (генетические риски роста, IQ, цвета глаз и различных заболеваний), а значит принятие решения становится сложным. Думаю, что мы придем к созданию аля профилей вида: "спортсмен", "ученый", "поэт", "долгожитель", в которых будут зашиты комбинации критериев, а также будет отдельно возможность поиграться с фильтрами:)) В заключение хочу сказать, что мир Гаттаки почти здесь, хотя текущие технологии еще и не достигли уровня точности и всеобъемлющего контроля, но они уже позволяют значительное вмешательство в генетический состав будущих поколений. С учетом этого, интересно следить за обсуждением этических рамок развития этих технологий, развитие которых легко может опережать социальные и этические дискуссии вокруг генетических модификаций. #Science #PopularScience #Engineering

MCP vs ACP vs A2A: Comparing Agent Protocols - Laurie Voss (Рубрика #AI) Ироничное выступление Laurie Voss, VP Developer Relations в LlamaIndex, где он за 15 минут рассказал про основные протоколы межагентского взаимодействия. Изначально он хотел рассказать про 3 основных протокола, но в ходе подготовки обнаружил ещё 11:) А в ходе выступления пошутил, что добавил бы еще в список протоколов WTF и LOL просто так... хотя наверняка уже есть протоколы с такими названиями. Основные идеи представлены ниже 1. Создавать протоколы сейчас модно За месяц исследований при подготовке scope доклада вырос с 3 до 14 протоколов, создалось даже впечатление, что почти все сейчас работают над агентскими протоколами 2. Два типа протоколов - Context-oriented: предоставляют контекст LLM (MCP, agents.json) - Inter-agent: обеспечивают взаимодействие между агентами (все остальные) 3. MCP - де-факто стандарт Model Context Protocol от Anthropic доминирует благодаря раннему фокусу на конкретной проблеме. 4. A2A от Google Agent2Agent Protocol от Google фокусируется на асинхронном взаимодействии и долгосрочных задачах. 5. Два ACP протокола - ACP Connect от Agntcy, куда входят Cisco, LangChain, LlamaIndex, Galileo and Glean - с интегрированным реестром агентов - ACP Communication от IBM - форк MCP, развивающийся в сторону A2A 6. Agora - самообновляющийся протокол Agora - это Уникальный подход: начинает с естественного языка и позволяет участникам обновлять протокол во время взаимодействия. 7. Протокол от блокчейн ребят AITP от NEAR Protocol слишком фокусируется на стоимости взаимодействий. Забавно, что спикер пошутил в духе, что "блокчейн пока не решил ни одной проблемы, так что не думаю, что решит и эту" 8. LMOS почти от IBM Eclipse Foundation создаёт LMOS, параллельно с собственным ACP. Здесь была шутка о том, что Eclipse Foundation - это замаскированная IBM. Это ещё одно подразделение IBM, создающее то же самое, что создаёт IBM. И если это кажется вам странным, значит вы мало общались с IBM:) 9. Отсутствие ключевых компонентов Всем протоколам не хватает по мнению автора: централизованного реестра, системы авторизации и системы репутации. 10. MCP как основа будущего Итоговый вывод в том, что MCP завоевал внимание и может расшириться для решения межагентских задач без добавления новых протоколов. P.S. Эта тема с агентами хорошо дополняет историю с вчерашнего доклада про внедрение AI в SDLC, которую я рассказывал на CTO Conf X. #AI #Agents #Engineering #DistributedSystems

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

[3/3] Интегрируем AI в процессы разработки большой компании: почему разрешить всем Cursor — не вариант (Рубрика #Management) Из примеров больших компаний в предыдущем посте видно, что они идут от сценариев расширения возможности людей, а часть из них успешно агентизируют. И если посмотреть на наш подход в Т-Банке, то мы идет примерно этим же путем. На самом деле какой этот путь можно подробно узнать из выступлений моих коллег на Platform Engineering Night - AI и Platform Engineering" от Игоря Маслова - Разработка собственного AI-ассистента для кода: спринт или марафон? от Дениса Артюшина Если кратко, то мы прошли гигиенический первый уровень, сейчас закрыли многие сценарии из второго уровня и вплотную добрались до делегировании работы инженеров агентам. Интересно, что у нас есть централизованная команда, что делает нашего copilot Nestor, но одновременно это зонтичный бренд для остальных инициатив, которые драйвятся у нас рабочими группами по планированию, анализу, проектированию, разработке, тестированию, SRE. Например, вот выступление про внедрение SRE AI-ассистента. В общем, мы со своей observability платформой Sage идем примерно в ту же сторону по AI-фикации, что и Datadog, упомянутый ранее. Интенесно, что это общая тенденция про развитие платформ в мире genAI отлично видна из отчета RedHat от ноября 2024 года "State of platform engineering in the age of AI" (мой обзор), где основные выводы такие - Платформенная инженерия становится стратегической 62% компаний уже имеют выделенные команды платформенной инженерии. Платформенная инженерия — это не просто автоматизация инфраструктуры, а стратегический инструмент для ускорения инноваций и внедрения ИИ. - Влияние искусственного интеллекта 76% организаций уже используют генеративный ИИ для задач разработки (документация, генерация кода, подсказки). 45% считают ИИ центральным элементом своей платформенной стратегии. В итоге, если отвечать на вынесенный в название вопрос "почему разрешить всем Cursor — не вариант?", то можно сказать так Для маленьких компаний это очень и очень вариант, так как - Эти инструменты позволяют быстро выдавать код для лендингов, прототипов, MVP - Они стоят не очень дорого, а также обычно нет особых рисков с intellectual property, данными, санкциями - Все равно нужны инженерные навыки - чтобы не получилось как в истории с тем, как агент снес весь код, а восстановить из git нельзя, так как vibe coder не знал что такое git и что им стоит пользоваться Для больших компаний нужен подход посложнее, как я описывал выше, из-за - Из коробки Copilot, Cursor, Windsurf не умеют работать с платформенными инструментами. Этому можно их научить если реализовать для платформенных продуктов MCP сервера, но ... - Для больших компаний риски вокруг информационной безопасности, интеллектуальной собственности, персональных данных часто слишком велики для использования внешних SaaS решений - В процессе работы над LLM внутри SDLC такие компании хотят потренироваться на кошечках и научиться AI-фицировать продукты, которые безопасны и понятны. А дальше с этой экспертизой идти в сторону customer продуктов компании. - Ну и большие риски возникают из-за санкций, так как внешние SaaS решения могут быть официально недоступны, а получив доступ по другому его легко можно потерять и остаться у разбитого корыта. В итоге, большие компании часто создают свои LLM решения и учатся интегрировать их внутрь своего SDLC и продуктов. Часто это может быть оправдано экономически на их масштабе. Интересно, что этому способствует публикация весов для моделей навроде LLama, DeepSeek, Mistral, что позволяет не слишком сильно отставать от mainstream. А вот средним компаниям приходится сложно - внешние решения могут быть слишком рискованными, а на создание своих может не хватать денег. Но благо сейчас некоторые российские компании пытаются делать свои продукты вокруг SDLC, в которых AI становится жителем первого класса:) #AI #PlatformEngineering #Engineering #Software #Processes #Productivity

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

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

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

Этот тренд подхватили ребята из акселлератора стартапов Y Combinator и уже в марте начали обсуждать эту тему в подкастах: - "Vibe Coding Is The Future" (я его уже разбирал) - "Интервью с CEO Windsurf про будущее программирования" (я его уже разбирал) - и даже "Vibe coding tips в их Startup Schools". Отдельно можно добавить, что хайпа добавляют заявления Сэма Альтмана, CEO OpenAI, или Дарио Амодея, CEO Antrophic. Например, Дарио три месяца назад на выступлении "The Future of U.S. AI Leadership with CEO of Anthropic Dario Amodei", про которое я уже рассказывал, выдал предсказание про будущее разработки

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

Возникает вопрос, а как этого можно добиться? Ответ в использовании агентов: - В прошлом году ребята из Antrophic представили MCP (model context protocol) для предоставления LLM доступа к дополнительным инструментам - А уже в этом году Google представили протокол уже для взаимодействия агентов A2A (Agent2Agent) протокол В общем, тема сейчас хайповая и для создания MVP в стартапах или pet проектов разработчиками этот подход к использованию copilots в режиме vibe coding отлично подходит. А вот для крупных компаний не все так просто и дальше я объясню почему Инженерные процессы в крупных компаниях эволюционировали следующим образом: - Когда-то разработка и эксплуатация была разделена и этот разрыв мешал достигать бизнес-результатов. В итоге, с середины 2000х по конец 2010х евангелировался DevOps подход, который с научной точки зрения был обоснован в книге "Accelerate", про которую я рассказывал раньше в трех частях: 1, 2 и 3. - Этот подход зачастую приводил к гетерогенному ИТ-ландшафту с большим дублированием систем, что не позволяло получить эффект масштаа - крупные компании пошли в сторону разделения stream-aligned команд и platform команд, которые должны были создать платформы, навроде Internal developer platform, которая позволяла бы инженером в формате self service пользоваться инструментами навроде работы с кодом, артефактами, CI/CD пайплайнами, рантаймом, observability и так далее - Дальше платформы стали достаточно сложными и владельцы платформ решили идти в сторону user experience своих пользователей, которыми являются разработчики. Так появилась концепция developer experience, в которую входит flow state, cognitive load, feedback loops (про это можно почитать в whitepaper "DevEx: What Actually Drives Productivity", про которую я рассказывал раньше). Это важно, так как сложность платформ может зашкаливать - этом можно продемонстрировать, взглянув на картинку с CNCF landscape, где количество карточек продуктов зашкаливает и разобраться с тем, что и как обычному человеку крайне сложно. Продолжение в следующем посте. #AI #PlatformEngineering #Engineering #Software #Processes #Productivity