[2/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Аспекты инженерной культуры (Рубрика #Infrastructure)
В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta и поговорим про аспекты инженерной культуры, которая позволяет быть компании успешной. Если сокращать, то эти аспекты звучат так
- Принцип "Move fast"
- Открытость технологий
- Research in production
- Единая инфраструктура и стандартизация
А теперь давайте поговорим про каждый пункт подробнее.
Принцип "Move fast"
С первых дней в Facebook закрепилась культура быстрого развития и итераций. Это выражается в агрессивной практике непрерывного развёртывания ПО - новый код доставляется в продакшн как можно скорее. Большинство продуктовых сервисов пишутся в виде serverless функций на простых языках вроде PHP, Python, Erlang, что упрощает и ускоряет цикл разработки и деплоя изменений. Команды могут легко менять приоритеты и запускать новые продукты без долгих бюрократических процессов.
Открытость технологий
Meta придерживается открытой инженерной культуры как внутри, так и вне компании. Внутри действует единый монорепозиторий для всего кода, причём в большинстве проектов нет жёстко закреплённых владельцев - любой инженер может внести улучшения непосредственно, что поощряет переиспользование решений и кросс-командный вклад.Внешне компания делится разработками с сообществом: Meta открыто публикует аппаратные дизайны через проект Open Compute и открывает исходный код ключевых систем (таких как фреймворк ИИ PyTorch, база данных RocksDB, библиотека рекомендаций ReAgent и др.)
Research in production
В Meta нет отдельной академической исследовательской лаборатории по системам, а все инновации рождаются прямо в продуктах. Команды инфраструктуры постоянно внедряют новые решения и затем оформляют опыт в научные статьи. Такой подход гарантирует, что исследования сфокусированы на реальных проблемах и проверены в боевых условиях, что повышает практическую ценность и надёжность предлагаемых решений. Интересно, что во многих классических компаниях в отличие от Meta сделано по другому. Там отдельные RnD лабы публикуют материалы о космических результатах, которые найдены на кончике пера и еще не доехали на продакшен, а может никогда не доедут (так как все понимают, что в продакшен окружении они просто не работают )
Единая инфраструктура и стандартизация
В Meta стараются избегать разрозненных групп технологий - вместо этого продвигается глобальная оптимизация. На уровне аппаратуры все сервисы работают на унифицированном парке серверов: для вычислительных (не AI) нагрузок выбран один тип стандартного сервера (ранее с 64 ГБ RAM, теперь 256 ГБ). В отличие от облачных провайдеров, предлагающих множество конфигураций под любые клиентские нужды, Meta может сама оптимизировать своё ПО под ограниченный набор оборудования, избегая распыления на зоопарк железа. То же с софтом: разные продукты, бывало, применяли разные хранилища (Cassandra, HBase и собственный ZippyDB), но со временем все консолидировались на одном решении - ZippyDB для хранения пар «ключ-значение». Для каждой распространённой потребности (деплой, конфигурации, service mesh, тестирование производительности и т.д.) используется единый инструмент, принятый повсеместно внутри компании. Стандартизация дополняется модульностью: Meta предпочитает строить системы из переиспользуемых компонентов, а не как монолиты.
Все эти принципы демонстрируются через пример с запуском приложения Threads (конкурента Twitter/X) - 5 месяцев на разработкку небольшой командой и подготовка инфры за 2 дня до запуска, что прошел успешно.
В конце этой части приводится первый инсайт
В следующем посте мы поговорим про подходы к обработке пользовательских запросов.
#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps
В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta и поговорим про аспекты инженерной культуры, которая позволяет быть компании успешной. Если сокращать, то эти аспекты звучат так
- Принцип "Move fast"
- Открытость технологий
- Research in production
- Единая инфраструктура и стандартизация
А теперь давайте поговорим про каждый пункт подробнее.
Принцип "Move fast"
С первых дней в Facebook закрепилась культура быстрого развития и итераций. Это выражается в агрессивной практике непрерывного развёртывания ПО - новый код доставляется в продакшн как можно скорее. Большинство продуктовых сервисов пишутся в виде serverless функций на простых языках вроде PHP, Python, Erlang, что упрощает и ускоряет цикл разработки и деплоя изменений. Команды могут легко менять приоритеты и запускать новые продукты без долгих бюрократических процессов.
Открытость технологий
Meta придерживается открытой инженерной культуры как внутри, так и вне компании. Внутри действует единый монорепозиторий для всего кода, причём в большинстве проектов нет жёстко закреплённых владельцев - любой инженер может внести улучшения непосредственно, что поощряет переиспользование решений и кросс-командный вклад.Внешне компания делится разработками с сообществом: Meta открыто публикует аппаратные дизайны через проект Open Compute и открывает исходный код ключевых систем (таких как фреймворк ИИ PyTorch, база данных RocksDB, библиотека рекомендаций ReAgent и др.)
Research in production
В Meta нет отдельной академической исследовательской лаборатории по системам, а все инновации рождаются прямо в продуктах. Команды инфраструктуры постоянно внедряют новые решения и затем оформляют опыт в научные статьи. Такой подход гарантирует, что исследования сфокусированы на реальных проблемах и проверены в боевых условиях, что повышает практическую ценность и надёжность предлагаемых решений. Интересно, что во многих классических компаниях в отличие от Meta сделано по другому. Там отдельные RnD лабы публикуют материалы о космических результатах, которые найдены на кончике пера и еще не доехали на продакшен, а может никогда не доедут (
Единая инфраструктура и стандартизация
В Meta стараются избегать разрозненных групп технологий - вместо этого продвигается глобальная оптимизация. На уровне аппаратуры все сервисы работают на унифицированном парке серверов: для вычислительных (не AI) нагрузок выбран один тип стандартного сервера (ранее с 64 ГБ RAM, теперь 256 ГБ). В отличие от облачных провайдеров, предлагающих множество конфигураций под любые клиентские нужды, Meta может сама оптимизировать своё ПО под ограниченный набор оборудования, избегая распыления на зоопарк железа. То же с софтом: разные продукты, бывало, применяли разные хранилища (Cassandra, HBase и собственный ZippyDB), но со временем все консолидировались на одном решении - ZippyDB для хранения пар «ключ-значение». Для каждой распространённой потребности (деплой, конфигурации, service mesh, тестирование производительности и т.д.) используется единый инструмент, принятый повсеместно внутри компании. Стандартизация дополняется модульностью: Meta предпочитает строить системы из переиспользуемых компонентов, а не как монолиты.
Все эти принципы демонстрируются через пример с запуском приложения Threads (конкурента Twitter/X) - 5 месяцев на разработкку небольшой командой и подготовка инфры за 2 дня до запуска, что прошел успешно.
В конце этой части приводится первый инсайт
Insight 1 : Despite many challenges, it is feasible for a large organization to maintain a culture of moving fast, using a common infrastructure, and sharing a monorepo without strictly enforcing code ownership.
В следующем посте мы поговорим про подходы к обработке пользовательских запросов.
#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps
Telegram
Книжный куб
[1/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Общее содержание статьи (Рубрика #Infrastructure)
В январе 2025 года вышла интересная статья об инфраструктуре компании Meta, чья деятельность запрещенна в России. Статья представляет собой…
В январе 2025 года вышла интересная статья об инфраструктуре компании Meta, чья деятельность запрещенна в России. Статья представляет собой…
❤10👍3🔥3
[3/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Сквозная обработка пользовательских запросов (Рубрика #Infrastructure)
В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1 и 2). Мы поговорим про обработку пользовательских запросов, которая спроектирована end-to-end для достижения нужного уровня качества (latency, scalability, reliability, ...) и стоимости.
Глобальная сеть и точки присутствия (PoP)
Чтобы минимизировать задержки, Meta динамически направляет запросы пользователя к ближайшему своему узлу. Когда пользователь открывает, например, facebook.com, DNS Meta возвращает IP ближайшего point of presence (PoP) - небольшого edge датацентра, который завершает входящее соединение от пользователя и проксирует трафик в основные регионы датацентров Meta по заранее установленным долгоживущим соединениям (внутри своей WAN сети). Это позволяет сократить время установления соединения и сбалансировать нагрузку между регионами
CDN и кеширование статичного контента
Если пользовательский запрос касается статического контента, то ответ может быть дан напрямую на уровне PoP, если там содержится свежий кеш. Meta также размещает кеш-серверы внутри сетей интернет-провайдеров при большом объёме трафика.
Маршрутизация динамических запросов
Если запрос не относится к статическому контенту (то есть требует генерации ответа на лету), PoP перенаправляет его во внутреннюю сеть Meta. Специальный балансировщик нагрузки в выбранном регионе ЦОД принимает входящий поток и распределяет запросы по фронтенд-серверам. В Meta фронтенд реализован как масштабируемый serverless слой: каждый пользовательский запрос обрабатывается отдельной фронтенд-функцией, которая может вызывать множество бэкенд-сервисов для составления ответа. Здесь появляется второй инсайт от автора статьи
Асинхронная обработка и офлайн-вычисления
Для задач, не критичных к мгновенному ответу, широко применяется асинхронная обработка. Фронтенд-функции могут ставить события в очередь, которые будут обработаны отдельно специальными фоновыми функциями без блокировки ответа пользователю. Такие event-driven функции запускаются параллельно, их выполнение оптимизировано под пропускную способность (throughput), а не задержки (latency), и они не влияют на время ответа основного запроса. В то же время всё, что происходит при обработке запросов, генерирует огромные объёмы данных, которые непрерывно сбрасываются в хранилище данных (data warehouse). Дальше офлайн-системы Meta используют накопленные данные для пакетных и стриминговых вычислений, которые потом используются онлайн-сервисами при обработке новых пользовательских запросов. Здесь появляется третий инсайт от автора статьи
Это является ключевым принципом устойчивости и эффективности при гипермасштабе.
Топология и масштаб инфраструктуры
Масштаб инфраструктуры примерно следующий
- Регионов в компании десятки, в каждом регионе множество датацентров, в каждом из которых сотни тысяч серверов
- PoPs сотни, в каждом из них от сотен до тысяч серверов
- CDN site тысячи, в каждом из них типично десятки серверов, но иногда бывают и сотни
- MSB (main switchboards) - штука для секционирования питания внутри датацентров, их дюжины в датацентрах, типично MSB обслуживает десятки тысяч серверов
В следующем посте мы поговорим про подходы, что обеспечивают продуктивность инженеров Meta.
#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps
В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1 и 2). Мы поговорим про обработку пользовательских запросов, которая спроектирована end-to-end для достижения нужного уровня качества (latency, scalability, reliability, ...) и стоимости.
Глобальная сеть и точки присутствия (PoP)
Чтобы минимизировать задержки, Meta динамически направляет запросы пользователя к ближайшему своему узлу. Когда пользователь открывает, например, facebook.com, DNS Meta возвращает IP ближайшего point of presence (PoP) - небольшого edge датацентра, который завершает входящее соединение от пользователя и проксирует трафик в основные регионы датацентров Meta по заранее установленным долгоживущим соединениям (внутри своей WAN сети). Это позволяет сократить время установления соединения и сбалансировать нагрузку между регионами
CDN и кеширование статичного контента
Если пользовательский запрос касается статического контента, то ответ может быть дан напрямую на уровне PoP, если там содержится свежий кеш. Meta также размещает кеш-серверы внутри сетей интернет-провайдеров при большом объёме трафика.
Маршрутизация динамических запросов
Если запрос не относится к статическому контенту (то есть требует генерации ответа на лету), PoP перенаправляет его во внутреннюю сеть Meta. Специальный балансировщик нагрузки в выбранном регионе ЦОД принимает входящий поток и распределяет запросы по фронтенд-серверам. В Meta фронтенд реализован как масштабируемый serverless слой: каждый пользовательский запрос обрабатывается отдельной фронтенд-функцией, которая может вызывать множество бэкенд-сервисов для составления ответа. Здесь появляется второй инсайт от автора статьи
Insight 2 : Meta’s global infrastructure consists of CDN sites, edge datacenters, and main datacenters. Because of the high volume of our internal cross-datacenter traffic, we have built a private WAN to connect our datacenters, rather than relying on the public Internet.
Асинхронная обработка и офлайн-вычисления
Для задач, не критичных к мгновенному ответу, широко применяется асинхронная обработка. Фронтенд-функции могут ставить события в очередь, которые будут обработаны отдельно специальными фоновыми функциями без блокировки ответа пользователю. Такие event-driven функции запускаются параллельно, их выполнение оптимизировано под пропускную способность (throughput), а не задержки (latency), и они не влияют на время ответа основного запроса. В то же время всё, что происходит при обработке запросов, генерирует огромные объёмы данных, которые непрерывно сбрасываются в хранилище данных (data warehouse). Дальше офлайн-системы Meta используют накопленные данные для пакетных и стриминговых вычислений, которые потом используются онлайн-сервисами при обработке новых пользовательских запросов. Здесь появляется третий инсайт от автора статьи
Insight 3 : Using a data warehouse as an intermediate layer to decouple online and offline processing simplifies the architecture and enables independent optimizations.
Это является ключевым принципом устойчивости и эффективности при гипермасштабе.
Топология и масштаб инфраструктуры
Масштаб инфраструктуры примерно следующий
- Регионов в компании десятки, в каждом регионе множество датацентров, в каждом из которых сотни тысяч серверов
- PoPs сотни, в каждом из них от сотен до тысяч серверов
- CDN site тысячи, в каждом из них типично десятки серверов, но иногда бывают и сотни
- MSB (main switchboards) - штука для секционирования питания внутри датацентров, их дюжины в датацентрах, типично MSB обслуживает десятки тысяч серверов
В следующем посте мы поговорим про подходы, что обеспечивают продуктивность инженеров Meta.
#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps
Telegram
Книжный куб
[1/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Общее содержание статьи (Рубрика #Infrastructure)
В январе 2025 года вышла интересная статья об инфраструктуре компании Meta, чья деятельность запрещенна в России. Статья представляет собой…
В январе 2025 года вышла интересная статья об инфраструктуре компании Meta, чья деятельность запрещенна в России. Статья представляет собой…
❤6👍6🔥3
State of Developer Ecosystem 2025 от JetBrains (Рубрика #DevEx)
Наконец-то дошли руки прочитать отчет по результатам ежегодного опроса от JetBrains. Этот ежегодный отчет входит в список тех, что я отслеживаю и в которых рассказывается интересная инфа про developer productivity и влиянии AI на него (вот тут я рассказывал про эту подборку). Но если возвращаться к самому отчету JetBrains, то вот основные моменты, которые показались мне интересными (кстати, результаты интересно сравнивать с прошлогодним отчетом, доступным здесь)
🤖 ИИ – новая норма
85% разработчиков регулярно используют AI-инструменты (против ~80% год назад). 62% применяют хотя бы одного AI-ассистента при кодинге, хотя 15% всё ещё работают без ИИ. 68% опрошенных ожидают, что скоро знание ИИ станет обязательным требованием работодателей. Разработчики охотно доверяют нейросетям рутинные задачи (например, генерацию шаблонного кода, перевод между языками, автодокументацию), но творческие и сложные задачи предпочитают выполнять самостоятельно. Среди главных опасений, связанных с ИИ: непостоянное качество кода, риски безопасности и приватности, а также возможная деградация собственных навыков.
⚙️ Языки и технологии
TypeScript продолжает стремительно расти и вместе с Rust и Go входит в тройку самых перспективных языков 2025 года (в 2024 вместо Go в лидерах был Python). Больше всего разработчиков хотят выучить Go и Rust как следующий язык. Одновременно PHP, Ruby и Objective-C продолжают терять популярность. Scala вновь выделяется как язык с самыми высокими зарплатами: среди разработчиков с самыми высокими доходами 38% используют Scala, при том что лишь 2% программистов называют её своим основным языком.
📊 Продуктивность и DX
В 2024-м компании фокусировались на технических метриках эффективности (скорость сборки, деплой, время восстановления и пр.), но в 2025-м подход сместился. Теперь внимание уделяют общей продуктивности разработчиков и качеству их опыта (Developer Experience): важны не только инструменты и процессы, но и коммуникация, прозрачность целей, обратная связь в команде. 66% инженеров не верят, что текущие KPI отражают их реальный вклад. Руководство всё так же хочет снижать tech debt и улучшать сотрудничество, а разработчики ценят ясность задач и конструктивный фидбек — метрики успеха приходится переосмысливать.
🌍 Рынок и реальность
Восприятие рынка труда сильно различается: 57% разработчиков в Японии считают его благоприятным, тогда как в Канаде 66% говорят о сложностях. Новичкам сложнее: 61% джунов оценивают рынок как трудный (против 54% среди сеньоров). С ростом опыта меняются и ежедневные проблемы: на смену чисто техническим задачам приходят вопросы координации (переключение контекста и пр.). Несмотря на все вызовы, программисты любят своё дело: 52% даже пишут код для удовольствия в свободное время (57% делают это под музыку, а 25% предпочитают тишину). И неизменный факт: котиков разработчики любят не меньше, чем собачек 😸🐶.
#AI #Software #Engineering #Processes #Metrics #Management #Survey
Наконец-то дошли руки прочитать отчет по результатам ежегодного опроса от JetBrains. Этот ежегодный отчет входит в список тех, что я отслеживаю и в которых рассказывается интересная инфа про developer productivity и влиянии AI на него (вот тут я рассказывал про эту подборку). Но если возвращаться к самому отчету JetBrains, то вот основные моменты, которые показались мне интересными (кстати, результаты интересно сравнивать с прошлогодним отчетом, доступным здесь)
85% разработчиков регулярно используют AI-инструменты (против ~80% год назад). 62% применяют хотя бы одного AI-ассистента при кодинге, хотя 15% всё ещё работают без ИИ. 68% опрошенных ожидают, что скоро знание ИИ станет обязательным требованием работодателей. Разработчики охотно доверяют нейросетям рутинные задачи (например, генерацию шаблонного кода, перевод между языками, автодокументацию), но творческие и сложные задачи предпочитают выполнять самостоятельно. Среди главных опасений, связанных с ИИ: непостоянное качество кода, риски безопасности и приватности, а также возможная деградация собственных навыков.
TypeScript продолжает стремительно расти и вместе с Rust и Go входит в тройку самых перспективных языков 2025 года (в 2024 вместо Go в лидерах был Python). Больше всего разработчиков хотят выучить Go и Rust как следующий язык. Одновременно PHP, Ruby и Objective-C продолжают терять популярность. Scala вновь выделяется как язык с самыми высокими зарплатами: среди разработчиков с самыми высокими доходами 38% используют Scala, при том что лишь 2% программистов называют её своим основным языком.
В 2024-м компании фокусировались на технических метриках эффективности (скорость сборки, деплой, время восстановления и пр.), но в 2025-м подход сместился. Теперь внимание уделяют общей продуктивности разработчиков и качеству их опыта (Developer Experience): важны не только инструменты и процессы, но и коммуникация, прозрачность целей, обратная связь в команде. 66% инженеров не верят, что текущие KPI отражают их реальный вклад. Руководство всё так же хочет снижать tech debt и улучшать сотрудничество, а разработчики ценят ясность задач и конструктивный фидбек — метрики успеха приходится переосмысливать.
🌍 Рынок и реальность
Восприятие рынка труда сильно различается: 57% разработчиков в Японии считают его благоприятным, тогда как в Канаде 66% говорят о сложностях. Новичкам сложнее: 61% джунов оценивают рынок как трудный (против 54% среди сеньоров). С ростом опыта меняются и ежедневные проблемы: на смену чисто техническим задачам приходят вопросы координации (переключение контекста и пр.). Несмотря на все вызовы, программисты любят своё дело: 52% даже пишут код для удовольствия в свободное время (57% делают это под музыку, а 25% предпочитают тишину). И неизменный факт: котиков разработчики любят не меньше, чем собачек 😸🐶.
#AI #Software #Engineering #Processes #Metrics #Management #Survey
Please open Telegram to view this post
VIEW IN TELEGRAM
The JetBrains Blog
The State of Developer Ecosystem 2025: Coding in the Age of AI, New Productivity Metrics, and Changing Realities | The Research…
What’s the most popular programming language? Are devs happy about their jobs in 2025? Find out answers to these and many other questions in our latest Developer Ecosystem report.
👍6❤5🔥2
[4/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Повышение продуктивности разработки (Рубрика #Infrastructure)
В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1, 2 и 3). Мы поговорим про то, какие аспекты позволяют быть разработчикам внутри Meta более продуктивными.
Continuous deployment и автоматизация
Одной из главных целей общей инфраструктуры Meta является ускорение работы разработчиков. В компании довели до экстрима подходы CI/CD, добившись практически полного автоматического выпуска обновлений. 97% сервисов Meta разворачиваются без ручного участия инженеров - изменения поставляются через автоматические пайплайны деплоя (более 30к пайплайнов следят за обновлениями). Около 55% сервисов используют реально непрерывный деплой, остальные ~42% - развёртываются роботами по расписанию (как правило, ежедневно или еженедельно). Например, фронтенд-платформа Meta (serverless-функции, обслуживающие пользовательские запросы) релизится каждые три часа, а она работает на 500к+ серверов и ее код ежедневно меняют 10к+ разработчиков.
Конфигурация как код и мгновенные изменения
В Meta разграничение между “кодом” и “настройками” практически стёрто - конфигурационные изменения обрабатываются теми же конвейерами, что и программный код. Каждый день более 100к изменений конфигураций автоматически применяется на продакшене с помощью внутренней системы управления настройками. Они затрагивают порядка 10к различных сервисов и 1M+ запущенных процессов по всему миру (настройки параметров балансировки нагрузки, включение feature flags, настройки A/B тестов, ...). Практически каждый инженер Meta, пишущий код, также вносит правки в “живые” конфиги:
- Они хранятся в репе как код
- Проходят peer-review
- Раскатываются через CD pipelines
- Агенты по принципу publish-subscribe раскатывают изменения на сервисы
- Приложения применяют новые параметры на лету, без перезапуска процессов
Из этого следует четвертый инсайт статьи
Инструменты для качества и быстрого отката
Стремление “выпускать сразу” неизбежно повышает риски сбоев, поэтому в Meta разработаны многоуровневые средства для безопасного развертывания. Перед полным выкатом новый код проходит автоматические тесты и канареечные прогоны. В случае обнаружения проблем хорошо отлажены механизмы мгновенного отката до предыдущей стабильной версии.
Serverless functions как основа разработки
Более 10 000 разработчиков Meta используют FaaS ежедневно, а это устраняет необходимость в управлении инфраструктурой: код автоматически масштабируется и разворачивается и оптимально использует инфру. Использование FaaS интегрировано в IDE (облегчен доступ к социальному графу и бэкенд‑системам). FaaS - это stateless архитектура, которая опирается на внешние кэш‑системы и базы данных, что обеспечивает предсказуемое поведение и простоту горизонтального масштабирования.У Meta есть две FaaS платформы:
- FrontFaaS для обработки пользовательских запросов (PHP, Python, Erlang, Haskell) с low latency
- XFaaS для обработки асинхронных, событийных функций с резкими пиковыми нагрузками. Они оптимизируются через глобальный балансировщик, отложенное выполнение и квот‑троттлинг, чтобы избежать оверпровижининга.
Эту часть обобщает пятый инсайт
В следующем посте мы поговорим про то, как Meta уменьшает свои затраты на инфраструктуру.
#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps
В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1, 2 и 3). Мы поговорим про то, какие аспекты позволяют быть разработчикам внутри Meta более продуктивными.
Continuous deployment и автоматизация
Одной из главных целей общей инфраструктуры Meta является ускорение работы разработчиков. В компании довели до экстрима подходы CI/CD, добившись практически полного автоматического выпуска обновлений. 97% сервисов Meta разворачиваются без ручного участия инженеров - изменения поставляются через автоматические пайплайны деплоя (более 30к пайплайнов следят за обновлениями). Около 55% сервисов используют реально непрерывный деплой, остальные ~42% - развёртываются роботами по расписанию (как правило, ежедневно или еженедельно). Например, фронтенд-платформа Meta (serverless-функции, обслуживающие пользовательские запросы) релизится каждые три часа, а она работает на 500к+ серверов и ее код ежедневно меняют 10к+ разработчиков.
Конфигурация как код и мгновенные изменения
В Meta разграничение между “кодом” и “настройками” практически стёрто - конфигурационные изменения обрабатываются теми же конвейерами, что и программный код. Каждый день более 100к изменений конфигураций автоматически применяется на продакшене с помощью внутренней системы управления настройками. Они затрагивают порядка 10к различных сервисов и 1M+ запущенных процессов по всему миру (настройки параметров балансировки нагрузки, включение feature flags, настройки A/B тестов, ...). Практически каждый инженер Meta, пишущий код, также вносит правки в “живые” конфиги:
- Они хранятся в репе как код
- Проходят peer-review
- Раскатываются через CD pipelines
- Агенты по принципу publish-subscribe раскатывают изменения на сервисы
- Приложения применяют новые параметры на лету, без перезапуска процессов
Из этого следует четвертый инсайт статьи
Insight 4 : Even for a large organization with O(10,000) services, it is feasible to adopt continuous deployment at extreme scales and speeds. Specifically, 97% of our services adopt fully automated deployments without manual intervention, and 55% deploy every code change instantly.
Инструменты для качества и быстрого отката
Стремление “выпускать сразу” неизбежно повышает риски сбоев, поэтому в Meta разработаны многоуровневые средства для безопасного развертывания. Перед полным выкатом новый код проходит автоматические тесты и канареечные прогоны. В случае обнаружения проблем хорошо отлажены механизмы мгновенного отката до предыдущей стабильной версии.
Serverless functions как основа разработки
Более 10 000 разработчиков Meta используют FaaS ежедневно, а это устраняет необходимость в управлении инфраструктурой: код автоматически масштабируется и разворачивается и оптимально использует инфру. Использование FaaS интегрировано в IDE (облегчен доступ к социальному графу и бэкенд‑системам). FaaS - это stateless архитектура, которая опирается на внешние кэш‑системы и базы данных, что обеспечивает предсказуемое поведение и простоту горизонтального масштабирования.У Meta есть две FaaS платформы:
- FrontFaaS для обработки пользовательских запросов (PHP, Python, Erlang, Haskell) с low latency
- XFaaS для обработки асинхронных, событийных функций с резкими пиковыми нагрузками. Они оптимизируются через глобальный балансировщик, отложенное выполнение и квот‑троттлинг, чтобы избежать оверпровижининга.
Эту часть обобщает пятый инсайт
Insight 5 : Serverless functions have become the primary coding paradigm for product development at Meta. More than 10,000 Meta engineers write code for serverless functions, exceeding the number of engineers writing regular service code by 50%.
В следующем посте мы поговорим про то, как Meta уменьшает свои затраты на инфраструктуру.
#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps
Telegram
Книжный куб
[1/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Общее содержание статьи (Рубрика #Infrastructure)
В январе 2025 года вышла интересная статья об инфраструктуре компании Meta, чья деятельность запрещенна в России. Статья представляет собой…
В январе 2025 года вышла интересная статья об инфраструктуре компании Meta, чья деятельность запрещенна в России. Статья представляет собой…
❤7👍5🔥4
[5/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Снижение затрат на оборудование (Рубрика #Infrastructure)
В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1, 2, 3 и 4) и обсудим снижение затрат на инфру.
All global datacenters as a computer
Подход Meta к восприятию своей инфры отлично описывается очередным инсайтом
Hardware and software co-design
Но при этому появляется потребность в совместном проектировании софта и железа для него
- Graceful degradation: эффективная инфраструктура должна уметь адаптивно деградировать при экстремальных ситуациях, чтобы не держать постоянный избыточный запас мощности про запас. В Meta система Defcon умеет отключать функциональность по уровням приоритетности, освобождая ресурсы для ключевых сервисов
- Экономия на proxy в service mesh: в индустрии распространена архитектура service mesh с sidecar proxy per service, который перехватывает и маршрутизирует запросы. Meta разработала свою систему ServiceRouter (~1% RPC-запросов проходят через proxy, а 99% - маршрутизируются напрямую с помощью встроенной в каждый сервис библиотеки). Это экономит 100k+ серверов
- Многоуровневое хранение данных: чтобы оптимизировать расходы на хранение, данные разделяются на категории по частоте доступа и допустимой задержке
-- Горячие данные (соцграф, ленты, кеши) хранятся в высокопроизводительных системах (RAM + SSD)
-- Тёплые данные (фото/видео пользователей, кликстрим) хранятся в распределенной файловой системе Tectonic на обычных HDD-дисках (1 server ~36 HDD + 2SSD для metadata)
-- Холодные данные (оригинальные видео высокого качества) архивируются на ультраплотных storage-серверах с большим числом медленных дисков (1 server ~216 HDD)
- Локальные SSD вместо сетевых хранилищ: в индустрии облачных сервисов считается хорошей практикой выносить хранение отдельно на блочное устройство для простоты миграций и балансировки нагрузки. Но в Meta ради экономии и низкой latency предпочитают локальные SSD даже для stateful-сервисов, где это возможно. От этого возникают сложности, которые Meta решает централизованно через систему управления шардированием (Shard Manager), которая абстрагирует размещение фрагментов данных и обеспечивает автоматический ребаланс
- Дешёвое оборудование с надёжностью через софт: в публичных облаках оборудование часто дублируется, потому что приложения клиентов могут быть не готовы к сбоям. Meta выбрала противоположный подход - использовать более простое и дешёвое железо, но заставить всё ПО быть устойчивым к отказам. В итоге, очередной инсайт звучит так
In-house hardware design
Для всего описанного выше Meta сама разрабатывает конструкции ЦОДов (Open Compute датацентры), а также значительную часть оборудования. Контроль над дизайном позволяет убирать всё лишнее и повышать эффективность (особенно эффективность использования электроэнергии, что сейчас является бутылочным горлышком для ДЦ)
В следующем посте мы поговорим про то, как инженеры в Meta проектируют свои системы.
#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps
В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1, 2, 3 и 4) и обсудим снижение затрат на инфру.
All global datacenters as a computer
Подход Meta к восприятию своей инфры отлично описывается очередным инсайтом
Insight 6 : Meta is evolving from the practice of “the datacenter as a computer” to the vision of “all global datacenters as a computer.” In this model, the infrastructure autonomously determines and migrates deployments across global datacenters in response to workload changes, eliminating the need for user involvement. We have successfully demonstrated this approach for databases, ML systems, and diverse services operating at the scale of O(100,000) servers and O(100,000) GPUs.
Hardware and software co-design
Но при этому появляется потребность в совместном проектировании софта и железа для него
- Graceful degradation: эффективная инфраструктура должна уметь адаптивно деградировать при экстремальных ситуациях, чтобы не держать постоянный избыточный запас мощности про запас. В Meta система Defcon умеет отключать функциональность по уровням приоритетности, освобождая ресурсы для ключевых сервисов
- Экономия на proxy в service mesh: в индустрии распространена архитектура service mesh с sidecar proxy per service, который перехватывает и маршрутизирует запросы. Meta разработала свою систему ServiceRouter (~1% RPC-запросов проходят через proxy, а 99% - маршрутизируются напрямую с помощью встроенной в каждый сервис библиотеки). Это экономит 100k+ серверов
- Многоуровневое хранение данных: чтобы оптимизировать расходы на хранение, данные разделяются на категории по частоте доступа и допустимой задержке
-- Горячие данные (соцграф, ленты, кеши) хранятся в высокопроизводительных системах (RAM + SSD)
-- Тёплые данные (фото/видео пользователей, кликстрим) хранятся в распределенной файловой системе Tectonic на обычных HDD-дисках (1 server ~36 HDD + 2SSD для metadata)
-- Холодные данные (оригинальные видео высокого качества) архивируются на ультраплотных storage-серверах с большим числом медленных дисков (1 server ~216 HDD)
- Локальные SSD вместо сетевых хранилищ: в индустрии облачных сервисов считается хорошей практикой выносить хранение отдельно на блочное устройство для простоты миграций и балансировки нагрузки. Но в Meta ради экономии и низкой latency предпочитают локальные SSD даже для stateful-сервисов, где это возможно. От этого возникают сложности, которые Meta решает централизованно через систему управления шардированием (Shard Manager), которая абстрагирует размещение фрагментов данных и обеспечивает автоматический ребаланс
- Дешёвое оборудование с надёжностью через софт: в публичных облаках оборудование часто дублируется, потому что приложения клиентов могут быть не готовы к сбоям. Meta выбрала противоположный подход - использовать более простое и дешёвое железо, но заставить всё ПО быть устойчивым к отказам. В итоге, очередной инсайт звучит так
Insight 7 : To reduce hardware costs, we use software solutions to overcome the limitations of lower-cost hardware. Although this approach adds complexity to the software stack, we consider the trade-off worthwhile due to the significant cost savings.
In-house hardware design
Для всего описанного выше Meta сама разрабатывает конструкции ЦОДов (Open Compute датацентры), а также значительную часть оборудования. Контроль над дизайном позволяет убирать всё лишнее и повышать эффективность (особенно эффективность использования электроэнергии, что сейчас является бутылочным горлышком для ДЦ)
Insight 8 : To reduce hardware costs and power consumption, Meta designs its own datacenters, servers, racks, and network switches, and shares these designs through open source.
В следующем посте мы поговорим про то, как инженеры в Meta проектируют свои системы.
#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps
Telegram
Книжный куб
[1/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Общее содержание статьи (Рубрика #Infrastructure)
В январе 2025 года вышла интересная статья об инфраструктуре компании Meta, чья деятельность запрещенна в России. Статья представляет собой…
В январе 2025 года вышла интересная статья об инфраструктуре компании Meta, чья деятельность запрещенна в России. Статья представляет собой…
🔥7❤5👍3
[6/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Проектирование масштабируемых систем (Рубрика #Infrastructure)
В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1, 2, 3, 4 и 5) и обсудим как ребята подходят к проектированию масштабируемых приложений.
Централизация vs децентрализация
Инфраструктура планетарного масштаба исторически ассоциируется с децентрализованными архитектурами (BGP, BitTorrent, и т.п.). Они хорошо масштабируются без SPOF (single point of failure). Однако опыт Meta показал, что в пределах датацентра, где ресурсы относительно надёжны и управляются одной организацией, централизованные контроллеры зачастую упрощают систему и при этом обеспечивают достаточную масштабируемость. А часто это еще позволяет принимать более глобально оптимальные решения, чем множество локальных агентов. Поэтому Meta сознательно отошла от многих изначально распределённых дизайнов в сторону управляемых централизованно. Например,
- Внутренняя сеть ЦОД (Fabric) по-прежнему использует протокол BGP для совместимости, но маршрутизацией управляет центральный контроллер, который при перегрузках или обрыве линков переоптимизирует пути трафика взамен медленной сходящейся динамики BGP
- В магистральной глобальной сети (WAN) Meta изначально применяла децентрализованный протокол резервирования полосы (RSVP-TE), но затем перешла на центральный контроллер, рассчитывающий оптимальные пути для потоков между датацентрами и заранее прокладывающий резервные каналы на случай типовых отказов. Это позволило значительно эффективнее использовать пропускную способность каналов и упростило управление сетью.
В общем случае подход Meta можно сформулировать таким инсайтом
В качестве примера подробнее разбирается гибридный service mesh под названием ServiceRouter (попытка получить “лучшее из двух миров”). ServiceRouter обслуживает миллиарды вызовов в секунду между микросервисами, распределёнными по миллионам программных маршрутизаторов уровня L7. В традиционных решениях service mesh (например, Istio) каждое приложение сопровождается локальным прокси, через который проходят все исходящие и входящие вызовы. В ServiceRouter Meta от этой схемы отказались (как упоминалось, ~99% запросов идут без sidecar-прокси). Вместо этого
- Control plane централизован - он агрегирует всю информацию о сервисах и глобальных метриках сети, вычисляет оптимальные правила маршрутизации и сохраняет их в RIB (outing Information Base), построенной поверх распределенной базы данных Delos с Paxos протоколом (то есть она распределена и отказоустойчива). Таким образом, центральные контроллеры ServiceRouter ответственны только за вычисление глобальных решений, а непосредическая работа по маршрутизации лежит на data plane.
- Data plane в виде отдельных L7 routers децентрализован - они автоматически подтягивают из RIB нужные им сведения (кэшируют небольшой необходимый поднабор) и работают автономно, без постоянного участия центрального координатора
Благодаря такому дизайну достигаются
- Простота управления - центрально видна вся картина
- Масштабируемость - нет узкого места, через которое прошёл бы весь трафик
В итоге, удаётся обеспечить полный функционал сервис-меша (балансировка, retries, discovery, мониторинг) при минимальном расходе ресурсов и с возможностью глобального оптимального распределения нагрузки.
В последнем посте из серии мы поговорим про будущие направления развития инфраструктуры и архитектуры Meta (это одна из самых интересных частей)
#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps
В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1, 2, 3, 4 и 5) и обсудим как ребята подходят к проектированию масштабируемых приложений.
Централизация vs децентрализация
Инфраструктура планетарного масштаба исторически ассоциируется с децентрализованными архитектурами (BGP, BitTorrent, и т.п.). Они хорошо масштабируются без SPOF (single point of failure). Однако опыт Meta показал, что в пределах датацентра, где ресурсы относительно надёжны и управляются одной организацией, централизованные контроллеры зачастую упрощают систему и при этом обеспечивают достаточную масштабируемость. А часто это еще позволяет принимать более глобально оптимальные решения, чем множество локальных агентов. Поэтому Meta сознательно отошла от многих изначально распределённых дизайнов в сторону управляемых централизованно. Например,
- Внутренняя сеть ЦОД (Fabric) по-прежнему использует протокол BGP для совместимости, но маршрутизацией управляет центральный контроллер, который при перегрузках или обрыве линков переоптимизирует пути трафика взамен медленной сходящейся динамики BGP
- В магистральной глобальной сети (WAN) Meta изначально применяла децентрализованный протокол резервирования полосы (RSVP-TE), но затем перешла на центральный контроллер, рассчитывающий оптимальные пути для потоков между датацентрами и заранее прокладывающий резервные каналы на случай типовых отказов. Это позволило значительно эффективнее использовать пропускную способность каналов и упростило управление сетью.
В общем случае подход Meta можно сформулировать таким инсайтом
Insight 9 : In a datacenter environment, we prefer centralized controllers over decentralized ones due to their simplicity and ability to make higher-quality decisions. In many cases, a hybrid approach - a centralized control plane combined with a decentralized data plane-provides the best of both worlds.
В качестве примера подробнее разбирается гибридный service mesh под названием ServiceRouter (попытка получить “лучшее из двух миров”). ServiceRouter обслуживает миллиарды вызовов в секунду между микросервисами, распределёнными по миллионам программных маршрутизаторов уровня L7. В традиционных решениях service mesh (например, Istio) каждое приложение сопровождается локальным прокси, через который проходят все исходящие и входящие вызовы. В ServiceRouter Meta от этой схемы отказались (как упоминалось, ~99% запросов идут без sidecar-прокси). Вместо этого
- Control plane централизован - он агрегирует всю информацию о сервисах и глобальных метриках сети, вычисляет оптимальные правила маршрутизации и сохраняет их в RIB (outing Information Base), построенной поверх распределенной базы данных Delos с Paxos протоколом (то есть она распределена и отказоустойчива). Таким образом, центральные контроллеры ServiceRouter ответственны только за вычисление глобальных решений, а непосредическая работа по маршрутизации лежит на data plane.
- Data plane в виде отдельных L7 routers децентрализован - они автоматически подтягивают из RIB нужные им сведения (кэшируют небольшой необходимый поднабор) и работают автономно, без постоянного участия центрального координатора
Благодаря такому дизайну достигаются
- Простота управления - центрально видна вся картина
- Масштабируемость - нет узкого места, через которое прошёл бы весь трафик
В итоге, удаётся обеспечить полный функционал сервис-меша (балансировка, retries, discovery, мониторинг) при минимальном расходе ресурсов и с возможностью глобального оптимального распределения нагрузки.
В последнем посте из серии мы поговорим про будущие направления развития инфраструктуры и архитектуры Meta (это одна из самых интересных частей)
#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps
Telegram
Книжный куб
[1/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Общее содержание статьи (Рубрика #Infrastructure)
В январе 2025 года вышла интересная статья об инфраструктуре компании Meta, чья деятельность запрещенна в России. Статья представляет собой…
В январе 2025 года вышла интересная статья об инфраструктуре компании Meta, чья деятельность запрещенна в России. Статья представляет собой…
❤7🔥4⚡1
[7/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Будущие направления развития (Рубрика #Infrastructure)
Этот пост финальный в рассмотрении крутой обзорной статьи от запрещенной в России компании Meta (предыдущие выпуски: 1, 2, 3, 4, 5 и 6). Здесь мы обсудим как автор видит дальнейшее развитие инфраструктуры, архитектуры и проникновение AI в системы компании. Отмечу, что эта часть была мне очень интересна - сложить пазл о том, как развивалась история это одно, а сделать качественное предсказание - это уже задачка со звездочкой.
AI и новая архитектура дата-центров
AI-нагрузки уже стали главным потребителем ресурсов Meta: к концу десятилетия они займут более половины мощностей ЦОД. В отличие от классических веб-сервисов, обучение моделей требует сотен терабайт данных, мощных GPU и сверхбыстрых сетей. Это ведёт к смене парадигмы — от scale-out (много дешёвых узлов) к scale-up, когда создаются крупные AI-кластеры, напоминающие суперкомпьютеры. Meta выстраивает полный стек под AI: от PyTorch и моделей до собственных чипов (MTIA), сетевых решений, хранилищ и систем охлаждения. Всё проектируется комплексно, чтобы работать синхронно. В будущем датацентры наполовину станут «машинами для обучения ИИ» - это изменит всю их архитектуру.
Эра специализированного железа
После эпохи унификации серверов начинается обратный процесс: расцвет кастомных ASIC и ускорителей. Гиперскейлеры могут позволить себе проектировать собственные чипы для AI-тренинга, компрессии, шифрования, видео-кодирования, In-Network-/In-Storage-Processing и т.д. Meta ожидает, что ЦОДы превратятся в гетерогенные кластеры из множества типов оборудования. Главный вызов - научить софт эффективно использовать столь разнородные ресурсы. Для этого потребуются новые уровни абстракций и оркестрации. Но выигрыш в энергоэффективности и стоимости на миллионах серверов окупит усилия.
Краевые датацентры и метавселенная
Meta прогнозирует бурный рост инфраструктуры на «краю» сети — мини-ЦОД, близких к пользователям. Это нужно для AR/VR, облачного гейминга и IoT, где критична задержка <25 мс. Компания строит модель Global Data-center-as-a-Computer: приложения будут автоматически выполняться там, где ближе пользователь, без участия разработчика. Архитектура станет многоуровневой - крупные регионы + сеть микро-ЦОД, объединённых общей системой оркестрации.
Прорыв в средствах разработки
Meta ожидает качественного скачка продуктивности инженеров за счет двух факторов
1. Массовое внедрение AI-ассистентов (Copilot, GPT-4 и др.), которые автоматизируют генерацию кода, поиск багов и рефакторинг и так далее
2. Появление вертикально интегрированных платформ, где разработчик описывает только бизнес-логику, а инфраструктура скрыта под капотом.
Пример - внутренний проект FrontFaaS, ускоряющий создание веб-интерфейсов. Похожие фреймворки появятся и в других доменах, радикально повышая индивидуальную продуктивность.
Совместное развитие
Автор подчёркивает: за 20 лет гиперскейлеры задали темп всей индустрии, и ИИ лишь ускорит этот процесс. Чтобы инновации распространялись быстрее, нужно делиться опытом. Meta призывает публиковать открытые проекты и исследования — как она делает сама. Статья служит именно этой цели: показать, из каких «кирпичиков» строится инфраструктура Meta и какие принципы могут вдохновить инженеров по всему миру.
В общем, это действительно качественная статья от Meta, которую было интересно прочитать. В будущем я планирую найти и разобрать похожие статьи и от других компаний.
#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps
Этот пост финальный в рассмотрении крутой обзорной статьи от запрещенной в России компании Meta (предыдущие выпуски: 1, 2, 3, 4, 5 и 6). Здесь мы обсудим как автор видит дальнейшее развитие инфраструктуры, архитектуры и проникновение AI в системы компании. Отмечу, что эта часть была мне очень интересна - сложить пазл о том, как развивалась история это одно, а сделать качественное предсказание - это уже задачка со звездочкой.
AI и новая архитектура дата-центров
AI-нагрузки уже стали главным потребителем ресурсов Meta: к концу десятилетия они займут более половины мощностей ЦОД. В отличие от классических веб-сервисов, обучение моделей требует сотен терабайт данных, мощных GPU и сверхбыстрых сетей. Это ведёт к смене парадигмы — от scale-out (много дешёвых узлов) к scale-up, когда создаются крупные AI-кластеры, напоминающие суперкомпьютеры. Meta выстраивает полный стек под AI: от PyTorch и моделей до собственных чипов (MTIA), сетевых решений, хранилищ и систем охлаждения. Всё проектируется комплексно, чтобы работать синхронно. В будущем датацентры наполовину станут «машинами для обучения ИИ» - это изменит всю их архитектуру.
Эра специализированного железа
После эпохи унификации серверов начинается обратный процесс: расцвет кастомных ASIC и ускорителей. Гиперскейлеры могут позволить себе проектировать собственные чипы для AI-тренинга, компрессии, шифрования, видео-кодирования, In-Network-/In-Storage-Processing и т.д. Meta ожидает, что ЦОДы превратятся в гетерогенные кластеры из множества типов оборудования. Главный вызов - научить софт эффективно использовать столь разнородные ресурсы. Для этого потребуются новые уровни абстракций и оркестрации. Но выигрыш в энергоэффективности и стоимости на миллионах серверов окупит усилия.
Краевые датацентры и метавселенная
Meta прогнозирует бурный рост инфраструктуры на «краю» сети — мини-ЦОД, близких к пользователям. Это нужно для AR/VR, облачного гейминга и IoT, где критична задержка <25 мс. Компания строит модель Global Data-center-as-a-Computer: приложения будут автоматически выполняться там, где ближе пользователь, без участия разработчика. Архитектура станет многоуровневой - крупные регионы + сеть микро-ЦОД, объединённых общей системой оркестрации.
Прорыв в средствах разработки
Meta ожидает качественного скачка продуктивности инженеров за счет двух факторов
1. Массовое внедрение AI-ассистентов (Copilot, GPT-4 и др.), которые автоматизируют генерацию кода, поиск багов и рефакторинг и так далее
2. Появление вертикально интегрированных платформ, где разработчик описывает только бизнес-логику, а инфраструктура скрыта под капотом.
Пример - внутренний проект FrontFaaS, ускоряющий создание веб-интерфейсов. Похожие фреймворки появятся и в других доменах, радикально повышая индивидуальную продуктивность.
Совместное развитие
Автор подчёркивает: за 20 лет гиперскейлеры задали темп всей индустрии, и ИИ лишь ускорит этот процесс. Чтобы инновации распространялись быстрее, нужно делиться опытом. Meta призывает публиковать открытые проекты и исследования — как она делает сама. Статья служит именно этой цели: показать, из каких «кирпичиков» строится инфраструктура Meta и какие принципы могут вдохновить инженеров по всему миру.
В общем, это действительно качественная статья от Meta, которую было интересно прочитать. В будущем я планирую найти и разобрать похожие статьи и от других компаний.
#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps
Telegram
Книжный куб
[1/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Общее содержание статьи (Рубрика #Infrastructure)
В январе 2025 года вышла интересная статья об инфраструктуре компании Meta, чья деятельность запрещенна в России. Статья представляет собой…
В январе 2025 года вышла интересная статья об инфраструктуре компании Meta, чья деятельность запрещенна в России. Статья представляет собой…
❤10🔥7⚡3👍1
No Vibes Allowed: Solving Hard Problems in Complex Codebases (Рубрика #AI)
Интересное выступление от Dex Horthy, основателя компании HumanLayer, разрабатывающей инструменты для AI-assisted разработки. Его предыдущий доклад "12 Factor Agents: Patterns of reliable LLM applications" (см. мой разбор) в июне 2025 стал одним из самых популярных на конференции. Именно ему приписывают популяризацию термина "context engineering".
Исследование Stanford показало неприятную правду об AI-инструментах для кодинга (это было в выступлении "Does AI Actually Boost Developer Productivity?" от Yegor Denisov-Blanch, про которое я уже рассказывал)
- Большая часть "дополнительного кода", написанного с помощью AI - это переработка slop'а, который был написан до этого
- Агенты отлично работают на новых проектах, но в больших legacy-кодовых базах часто делают разработчиков менее продуктивными
Для решения этих проблем автор рассказывает про context engineering
- LLM - это stateless системы. Единственный способ получить лучший результат - подать лучший контекст на вход. При каждом вызове модель выбирает следующий шаг исключительно на основе того, что находится в текущем контексте.
- "Dumb Zone". У контекстного окна есть практический предел. После ~40% заполнения начинается деградация качества ответов. Если у вас подключено много MCP-инструментов, которые забивают контекст JSON'ами и UUID'ами - вы постоянно работаете в dumb zone.
- Методология: Research → Plan → Implement. Вместо наивного подхода "попросил → получил slop → поругался → попросил снова" команда Dex'а использует частую намеренную компактизацию контекста:
-- Research - понимание системы, поиск нужных файлов. Результат сжимается в markdown с конкретными файлами и номерами строк.
-- Plan - детальный план с code snippets того, что именно будет изменено. Чем конкретнее план, тем надёжнее выполнение.
-- Implement - выполнение плана. Если план хороший, даже "тупая" модель справится.
- Напоследок автор рассказывает про практические результаты вида: за 7 часов субботней сессии отправили 35,000 строк кода в проект BAML (300k LOC Rust) - обычно это была работа на 1-2 недели
Практические советы от автора
- Sub-agents - не для ролей, а для контроля контекста. Не создавайте "frontend agent" и "backend agent". Используйте sub-agents для изоляции тяжёлых операций чтения кодовой базы, возвращая только сжатый результат.
- Прогрессивное раскрытие контекста. Вместо одного огромного файла документации в корне репозитория - размещайте контекстные файлы на каждом уровне, подгружая только релевантное.
- On-demand сжатый контекст лучше статичной документации. Документация устаревает и врёт. Код - источник истины. Генерируйте research-документы на лету из реального кода.
- Trajectory matters. Если вы 5 раз поругали модель в одном контексте - она "научилась", что следующий шаг = ошибка + ругань. Лучше начать новый контекст.
- Культурные изменения должны идти сверху. Если вы технический лидер - выберите один инструмент и набивайте практику. Не прыгайте между Claude Code, Cursor и Codex
Главный вывод из выступления примерно такой
#Engineering #AI #Metrics #Software #DevEx #Productivity
Интересное выступление от Dex Horthy, основателя компании HumanLayer, разрабатывающей инструменты для AI-assisted разработки. Его предыдущий доклад "12 Factor Agents: Patterns of reliable LLM applications" (см. мой разбор) в июне 2025 стал одним из самых популярных на конференции. Именно ему приписывают популяризацию термина "context engineering".
Исследование Stanford показало неприятную правду об AI-инструментах для кодинга (это было в выступлении "Does AI Actually Boost Developer Productivity?" от Yegor Denisov-Blanch, про которое я уже рассказывал)
- Большая часть "дополнительного кода", написанного с помощью AI - это переработка slop'а, который был написан до этого
- Агенты отлично работают на новых проектах, но в больших legacy-кодовых базах часто делают разработчиков менее продуктивными
Для решения этих проблем автор рассказывает про context engineering
- LLM - это stateless системы. Единственный способ получить лучший результат - подать лучший контекст на вход. При каждом вызове модель выбирает следующий шаг исключительно на основе того, что находится в текущем контексте.
- "Dumb Zone". У контекстного окна есть практический предел. После ~40% заполнения начинается деградация качества ответов. Если у вас подключено много MCP-инструментов, которые забивают контекст JSON'ами и UUID'ами - вы постоянно работаете в dumb zone.
- Методология: Research → Plan → Implement. Вместо наивного подхода "попросил → получил slop → поругался → попросил снова" команда Dex'а использует частую намеренную компактизацию контекста:
-- Research - понимание системы, поиск нужных файлов. Результат сжимается в markdown с конкретными файлами и номерами строк.
-- Plan - детальный план с code snippets того, что именно будет изменено. Чем конкретнее план, тем надёжнее выполнение.
-- Implement - выполнение плана. Если план хороший, даже "тупая" модель справится.
- Напоследок автор рассказывает про практические результаты вида: за 7 часов субботней сессии отправили 35,000 строк кода в проект BAML (300k LOC Rust) - обычно это была работа на 1-2 недели
Практические советы от автора
- Sub-agents - не для ролей, а для контроля контекста. Не создавайте "frontend agent" и "backend agent". Используйте sub-agents для изоляции тяжёлых операций чтения кодовой базы, возвращая только сжатый результат.
- Прогрессивное раскрытие контекста. Вместо одного огромного файла документации в корне репозитория - размещайте контекстные файлы на каждом уровне, подгружая только релевантное.
- On-demand сжатый контекст лучше статичной документации. Документация устаревает и врёт. Код - источник истины. Генерируйте research-документы на лету из реального кода.
- Trajectory matters. Если вы 5 раз поругали модель в одном контексте - она "научилась", что следующий шаг = ошибка + ругань. Лучше начать новый контекст.
- Культурные изменения должны идти сверху. Если вы технический лидер - выберите один инструмент и набивайте практику. Не прыгайте между Claude Code, Cursor и Codex
Главный вывод из выступления примерно такой
AI cannot replace thinking. It can only amplify the thinking you have done - or the lack of thinking you have done.
#Engineering #AI #Metrics #Software #DevEx #Productivity
YouTube
No Vibes Allowed: Solving Hard Problems in Complex Codebases – Dex Horthy, HumanLayer
It seems pretty well-accepted that AI coding tools struggle with real production codebases. At AI Engineer 2025 in June, The Stanford study on AI's impact on developer productivity found:
A lot of the ""extra code"" shipped by AI tools ends up just reworking…
A lot of the ""extra code"" shipped by AI tools ends up just reworking…
👍15🔥9❤5
[1/2] Defying Gravity (Рубрика #AI)
Это интересное выступление про новую IDE "Antigravity" от Кевина Хоу, руководителя продуктовой инженерии Google Antigravity в Google DeepMind. До лета 2025 года Кевин возглавлял продуктовую инженерию в Windsurf (бывший Codeium), а потом Google приобрёл команду Windsurf за $2,4 млрд именно для создания Antigravity. В этом выступлении Хоу описывает эволюцию AI-инструментов для разработчиков как последовательность скачков, каждый из которых был связан с улучшением моделей:
1️⃣ Автокомплит (GitHub Copilot)
2️⃣ Чат (ChatGPT с RLHF)
3️⃣ Агенты (Antigravity)
Antigravity запущен 18 ноября 2025 года вместе с Gemini 3 Pro и позиционируется не просто как редактор с AI-функциями, а "агент-ориентированная платформа", где автономные агенты становятся полноценными партнёрами по разработке. В этой IDE есть три составляющие
1️⃣ Agent Manager - центральный хаб управления агентами. Это inbox для задач, требующих внимания (например, подтверждение команд терминала), с OS-уведомлениями и возможностью управлять несколькими агентами параллельно.
2️⃣ AI Editor - форк VS Code с быстрым автокомплитом и агентской боковой панелью. Переключение между Editor и Agent Manager занимает <100 мс (Cmd/Ctrl+E).
3️⃣ Agent-Controlled Browser - автоматизированный Chrome, который агент использует для:
- Получения контекста (доступ к Google Docs, GitHub dashboards с вашей аутентификацией)
- Верификации результатов (клики, скроллинг, выполнение JavaScript для тестирования приложений)
- Записи видео действий вместо показа diff'ов кода
IDE предлагает новый паттерн для взаимодействия посредством концепции Artifacts - это динамические визуальные представления работы агента:
- Типы артефактов: планы реализации (как PRD, product requirement definitions), task-листы, архитектурные диаграммы Mermaid, скриншоты, видеозаписи браузера, walkthrough'ы (финальные отчёты как PR description)
- Динамичность: модель сама решает, нужен ли артефакт, какого типа, кто должен его видеть (другие агенты, conversations, база знаний)
- Feedback-система: можно оставлять комментарии в стиле Google Docs / Figma - выделять текст или области на изображениях, батчить правки и отправлять агенту, не прерывая выполнение задачи
Раньше для отслеживания за роботой агентов надо было читать простыню chain-of-thoughts, что было тяжеловато. А вот артефакты дают визуальное представление прогресса - это похоже на PowerPoint для презентаций.
Продукт построен на возможнотях Gemini 3 Pro и предлагает четыре категории улучшений
1️⃣ Интеллект и reasoning: лучше следует инструкциям, понимает нюансы использования инструментов, справляется с долгими задачами
2️⃣ Multimodal: обработка текста, изображений, аудио, видео, кода одновременно. Image Generation (Nano Banana Pro) интегрирована для итераций по дизайну прямо в редакторе
3️⃣ Computer Use: вариант Gemini для управления браузером - клики, DOM-инспекция, JavaScript. Результат - не diff, а видеозапись действий для верификации
4️⃣ Долгоживущие задачи: агенты работают в фоне, уведомляя о необходимости вмешательства
По мнению Хоу ключевым преимуществом новой IDE является симбиоз с DeepMind
- Команда Antigravity сидит "в паре десятков метров" от команды Computer Use
- Ранний доступ к Gemini 3 за несколько месяцев до релиза позволил найти слабые места модели и исправить их в продукте
- Antigravity используется внутри Google инженерами и исследователями DeepMind - это пример dog fooding
- Такой симбиоз создаёт цикл обратной связи: продукт показывает пробелы модели → исследователи улучшают модель → продукт интегрирует улучшения
Например, Computer Use изначально работал плохо, пока команды не синхронизировали data distribution и agent harness, а концепция artifacts потребовала доработки модели, чтобы понимать концепцию ревью.
В продолжении мы обудим какие выводы можно сделать из появления такой IDE.
#Engineering #AI #Metrics #Software #DevEx #Productivity #IDE
Это интересное выступление про новую IDE "Antigravity" от Кевина Хоу, руководителя продуктовой инженерии Google Antigravity в Google DeepMind. До лета 2025 года Кевин возглавлял продуктовую инженерию в Windsurf (бывший Codeium), а потом Google приобрёл команду Windsurf за $2,4 млрд именно для создания Antigravity. В этом выступлении Хоу описывает эволюцию AI-инструментов для разработчиков как последовательность скачков, каждый из которых был связан с улучшением моделей:
1️⃣ Автокомплит (GitHub Copilot)
2️⃣ Чат (ChatGPT с RLHF)
3️⃣ Агенты (Antigravity)
Antigravity запущен 18 ноября 2025 года вместе с Gemini 3 Pro и позиционируется не просто как редактор с AI-функциями, а "агент-ориентированная платформа", где автономные агенты становятся полноценными партнёрами по разработке. В этой IDE есть три составляющие
1️⃣ Agent Manager - центральный хаб управления агентами. Это inbox для задач, требующих внимания (например, подтверждение команд терминала), с OS-уведомлениями и возможностью управлять несколькими агентами параллельно.
2️⃣ AI Editor - форк VS Code с быстрым автокомплитом и агентской боковой панелью. Переключение между Editor и Agent Manager занимает <100 мс (Cmd/Ctrl+E).
3️⃣ Agent-Controlled Browser - автоматизированный Chrome, который агент использует для:
- Получения контекста (доступ к Google Docs, GitHub dashboards с вашей аутентификацией)
- Верификации результатов (клики, скроллинг, выполнение JavaScript для тестирования приложений)
- Записи видео действий вместо показа diff'ов кода
IDE предлагает новый паттерн для взаимодействия посредством концепции Artifacts - это динамические визуальные представления работы агента:
- Типы артефактов: планы реализации (как PRD, product requirement definitions), task-листы, архитектурные диаграммы Mermaid, скриншоты, видеозаписи браузера, walkthrough'ы (финальные отчёты как PR description)
- Динамичность: модель сама решает, нужен ли артефакт, какого типа, кто должен его видеть (другие агенты, conversations, база знаний)
- Feedback-система: можно оставлять комментарии в стиле Google Docs / Figma - выделять текст или области на изображениях, батчить правки и отправлять агенту, не прерывая выполнение задачи
Раньше для отслеживания за роботой агентов надо было читать простыню chain-of-thoughts, что было тяжеловато. А вот артефакты дают визуальное представление прогресса - это похоже на PowerPoint для презентаций.
Продукт построен на возможнотях Gemini 3 Pro и предлагает четыре категории улучшений
1️⃣ Интеллект и reasoning: лучше следует инструкциям, понимает нюансы использования инструментов, справляется с долгими задачами
2️⃣ Multimodal: обработка текста, изображений, аудио, видео, кода одновременно. Image Generation (Nano Banana Pro) интегрирована для итераций по дизайну прямо в редакторе
3️⃣ Computer Use: вариант Gemini для управления браузером - клики, DOM-инспекция, JavaScript. Результат - не diff, а видеозапись действий для верификации
4️⃣ Долгоживущие задачи: агенты работают в фоне, уведомляя о необходимости вмешательства
По мнению Хоу ключевым преимуществом новой IDE является симбиоз с DeepMind
- Команда Antigravity сидит "в паре десятков метров" от команды Computer Use
- Ранний доступ к Gemini 3 за несколько месяцев до релиза позволил найти слабые места модели и исправить их в продукте
- Antigravity используется внутри Google инженерами и исследователями DeepMind - это пример dog fooding
- Такой симбиоз создаёт цикл обратной связи: продукт показывает пробелы модели → исследователи улучшают модель → продукт интегрирует улучшения
Например, Computer Use изначально работал плохо, пока команды не синхронизировали data distribution и agent harness, а концепция artifacts потребовала доработки модели, чтобы понимать концепцию ревью.
В продолжении мы обудим какие выводы можно сделать из появления такой IDE.
#Engineering #AI #Metrics #Software #DevEx #Productivity #IDE
YouTube
Defying Gravity - Kevin Hou, Google DeepMind
Why we built Google Antigravity, and discussing the future of agentic IDEs with Gemini 3.
Speaker: https://x.com/kevinhou22
AIE is coming to London and SF! see dates and sign up to be notified of sponsorships, CFPs, and tickets: https://ai.engineer
**Timestamps:**…
Speaker: https://x.com/kevinhou22
AIE is coming to London and SF! see dates and sign up to be notified of sponsorships, CFPs, and tickets: https://ai.engineer
**Timestamps:**…
❤8👍2🔥1
[2/2] Defying Gravity (Рубрика #AI)
Рассказ об интересной IDE хотелось бы закончить анализом того, а что этот выпуск значит для инженеров
1️⃣ Повышение планки амбиций
Antigravity - это ставка на «raising the ceiling»: агенты должны брать на себя не только написание кода (это уже умеют LLM), но и части «что строить» и «как строить». Инженерам нужно учиться делегировать сложные задачи агентам, работая на уровне задач, а не строк кода.
2️⃣ Работа на разных поверхностях
Разработка уже не ограничена редактором. Browser automation открывает возможности:
- Тестирование UI/UX агентом в реальном браузере
- Автоматическая верификация по дизайну
- Доступ к institutional knowledge (bug trackers, внутренние документы с аутентификацией)
3️⃣ Визуальная коммуникация вместо текстовой
Артефакты меняют парадигму review: вместо чтения длинных chain-of-thought смотрите планы, диаграммы, видеозаписи. Для инженеров это означает необходимость учиться давать обратную связь в мультимодальном формате (комментарии на изображениях, выделение текста в планах).
4️⃣ Параллельная оркестрация
Antigravity поддерживает параллельную работу нескольких агентов на одном проекте (например, дизайн мокапа + исследование API + реализация фичи одновременно). Инженерам нужно научиться декомпозировать задачи для параллельного выполнения агентами.
5️⃣Аварийный люк (escape hatch) всегда доступен
Хоу честен: агентам пока нельзя доверять на 100%. Поэтому всегда можно вернуться в редактор (Cmd+E) для ручной доработки последних 20% задачи. Но тренд - будущее за agent manager'ом.
6️⃣ Модель = продукт
Главный урок от DeepMind: "продукт настолько хорош, насколько хороша модель". Antigravity опередит конкурентов, потому что имеет ранний доступ к Gemini и прямую связь с исследователями. Для инженеров это сигнал: выбирайте инструменты, у которых есть плотная интеграция с моделью (не просто API-обёртки).
7️⃣ Бесплатный доступ к frontier-моделям
Antigravity в public preview бесплатен с unlimited AI completions и доступом к Gemini 3 Pro, Claude Sonnet 4.5, GPT-OSS. Это шанс экспериментировать с агентскими workflow без финансовых барьеров.
В общем, Antigravity - это ставка Google на то, что будущее разработки за агентами, которые работают не внутри редактора, а над ним, оркестрируя задачи через редактор, терминал и браузер. Для инженеров это означает переход от написания кода к управлению агентами через визуальные артефакты и мультимодальный feedback.
#Engineering #AI #Metrics #Software #DevEx #Productivity #IDE
Рассказ об интересной IDE хотелось бы закончить анализом того, а что этот выпуск значит для инженеров
1️⃣ Повышение планки амбиций
Antigravity - это ставка на «raising the ceiling»: агенты должны брать на себя не только написание кода (это уже умеют LLM), но и части «что строить» и «как строить». Инженерам нужно учиться делегировать сложные задачи агентам, работая на уровне задач, а не строк кода.
2️⃣ Работа на разных поверхностях
Разработка уже не ограничена редактором. Browser automation открывает возможности:
- Тестирование UI/UX агентом в реальном браузере
- Автоматическая верификация по дизайну
- Доступ к institutional knowledge (bug trackers, внутренние документы с аутентификацией)
3️⃣ Визуальная коммуникация вместо текстовой
Артефакты меняют парадигму review: вместо чтения длинных chain-of-thought смотрите планы, диаграммы, видеозаписи. Для инженеров это означает необходимость учиться давать обратную связь в мультимодальном формате (комментарии на изображениях, выделение текста в планах).
4️⃣ Параллельная оркестрация
Antigravity поддерживает параллельную работу нескольких агентов на одном проекте (например, дизайн мокапа + исследование API + реализация фичи одновременно). Инженерам нужно научиться декомпозировать задачи для параллельного выполнения агентами.
5️⃣Аварийный люк (escape hatch) всегда доступен
Хоу честен: агентам пока нельзя доверять на 100%. Поэтому всегда можно вернуться в редактор (Cmd+E) для ручной доработки последних 20% задачи. Но тренд - будущее за agent manager'ом.
6️⃣ Модель = продукт
Главный урок от DeepMind: "продукт настолько хорош, насколько хороша модель". Antigravity опередит конкурентов, потому что имеет ранний доступ к Gemini и прямую связь с исследователями. Для инженеров это сигнал: выбирайте инструменты, у которых есть плотная интеграция с моделью (не просто API-обёртки).
7️⃣ Бесплатный доступ к frontier-моделям
Antigravity в public preview бесплатен с unlimited AI completions и доступом к Gemini 3 Pro, Claude Sonnet 4.5, GPT-OSS. Это шанс экспериментировать с агентскими workflow без финансовых барьеров.
В общем, Antigravity - это ставка Google на то, что будущее разработки за агентами, которые работают не внутри редактора, а над ним, оркестрируя задачи через редактор, терминал и браузер. Для инженеров это означает переход от написания кода к управлению агентами через визуальные артефакты и мультимодальный feedback.
#Engineering #AI #Metrics #Software #DevEx #Productivity #IDE
Telegram
Книжный куб
[1/2] Defying Gravity (Рубрика #AI)
Это интересное выступление про новую IDE "Antigravity" от Кевина Хоу, руководителя продуктовой инженерии Google Antigravity в Google DeepMind. До лета 2025 года Кевин возглавлял продуктовую инженерию в Windsurf (бывший…
Это интересное выступление про новую IDE "Antigravity" от Кевина Хоу, руководителя продуктовой инженерии Google Antigravity в Google DeepMind. До лета 2025 года Кевин возглавлял продуктовую инженерию в Windsurf (бывший…
❤6🔥5👍1
2026: The Year The IDE Died (Рубрика #AI)
Посмотрел интересный доклад от Gene Kim и про будущее разработки. Это заслуженные авторы, которые совмещают опыт и влияние на индустрию
- Steve Yegge работал в Google, Amazon, а сейчачс работает в Sourcegraph. Стив знаменит своими едкими, объемными и часто провокационными постами на темы языков программирования, продуктивности, культуры разработки и работы в крупных технологических компаниях
- Gene Kim - соавтор книг "DevOps Handbook", "The Phoenix Project", "Accelerate", "The Unicorn Project"
Совсем недавно два эти джентельмена выпустили книгу "Vibe Coding", а теперь решили рассказать про то, что современные IDE уже устарели:) Ниже представлены основные тезисы в чуть более расширенном варианте
1️⃣ Индустрия отстает на 9-12 месяцев от реальности
Большинство разработчиков используют AI как "улучшенный автокомплит" (GitHub Copilot в режиме tab-tab). Это мышление уровня печатной машинки в эпоху текстовых процессоров. Реальная мощь - в агентских системах, но ими пользуются единицы. Мы оптимизируем написание текста, а надо оптимизировать принятие решений.
2️⃣ IDE в привычном виде мертва
Традиционная IDE (IntelliJ, VS Code) - это инструмент, заточенный под чтение и написание текста человеком. Человеку нужны вкладки, подсветка синтаксиса и дерево файлов. AI-агенту нужен контекст (логи, тикеты, архитектура, связи), а не визуальный редактор. В 2026 году IDE станет "бэкендом" для агентов, а интерфейс разработчика превратится в диалог об архитектуре и намерениях (Intent), а не о синтаксисе. Кстати, раньше я разбирал выступление про IDE "Antigravity" от Google, где многие из этих идей уже материлизовались в продукт
3️⃣ Сдвиг от "Как сделать" к "Что сделать"
Йегге представил концепцию Amp (новый редактор от Sourcegraph). В нем вы не пишете код построчно. Вы описываете намерение (Intent), а стая агентов (планировщик, кодер, тестировщик) реализует его.
- Если сейчас цикл это: Думай -> Печатай -> Дебажь.
- То будет: Опиши цель -> Валидируй план агента -> Прими результат.
4️⃣ Контекст - это новая нефть
Главная проблема текущих чат-ботов - они галлюцинируют, потому что не видят всей картины. Будущее тулинга - это Model Context Protocol (MCP). Инструменты должны уметь сами «ходить» в Jira, Notion, Sentry и прод-базу, чтобы понимать задачу так же глубоко, как сеньор, работающий в компании 3 года.
В общем, это как обычно сейчас предсказание про то, что мы переходим от роли "писателей кода" к роли "архитекторов систем", где чернорабочими выступают LLM. Во всем выступлении сквозит тезис о том, что кто быстрее перестроит процессы под эту реальность - тот и выиграет рынок.
#Engineering #AI #Metrics #Software #DevEx #Productivity #IDE
Посмотрел интересный доклад от Gene Kim и про будущее разработки. Это заслуженные авторы, которые совмещают опыт и влияние на индустрию
- Steve Yegge работал в Google, Amazon, а сейчачс работает в Sourcegraph. Стив знаменит своими едкими, объемными и часто провокационными постами на темы языков программирования, продуктивности, культуры разработки и работы в крупных технологических компаниях
- Gene Kim - соавтор книг "DevOps Handbook", "The Phoenix Project", "Accelerate", "The Unicorn Project"
Совсем недавно два эти джентельмена выпустили книгу "Vibe Coding", а теперь решили рассказать про то, что современные IDE уже устарели:) Ниже представлены основные тезисы в чуть более расширенном варианте
1️⃣ Индустрия отстает на 9-12 месяцев от реальности
Большинство разработчиков используют AI как "улучшенный автокомплит" (GitHub Copilot в режиме tab-tab). Это мышление уровня печатной машинки в эпоху текстовых процессоров. Реальная мощь - в агентских системах, но ими пользуются единицы. Мы оптимизируем написание текста, а надо оптимизировать принятие решений.
2️⃣ IDE в привычном виде мертва
Традиционная IDE (IntelliJ, VS Code) - это инструмент, заточенный под чтение и написание текста человеком. Человеку нужны вкладки, подсветка синтаксиса и дерево файлов. AI-агенту нужен контекст (логи, тикеты, архитектура, связи), а не визуальный редактор. В 2026 году IDE станет "бэкендом" для агентов, а интерфейс разработчика превратится в диалог об архитектуре и намерениях (Intent), а не о синтаксисе. Кстати, раньше я разбирал выступление про IDE "Antigravity" от Google, где многие из этих идей уже материлизовались в продукт
3️⃣ Сдвиг от "Как сделать" к "Что сделать"
Йегге представил концепцию Amp (новый редактор от Sourcegraph). В нем вы не пишете код построчно. Вы описываете намерение (Intent), а стая агентов (планировщик, кодер, тестировщик) реализует его.
- Если сейчас цикл это: Думай -> Печатай -> Дебажь.
- То будет: Опиши цель -> Валидируй план агента -> Прими результат.
4️⃣ Контекст - это новая нефть
Главная проблема текущих чат-ботов - они галлюцинируют, потому что не видят всей картины. Будущее тулинга - это Model Context Protocol (MCP). Инструменты должны уметь сами «ходить» в Jira, Notion, Sentry и прод-базу, чтобы понимать задачу так же глубоко, как сеньор, работающий в компании 3 года.
В общем, это как обычно сейчас предсказание про то, что мы переходим от роли "писателей кода" к роли "архитекторов систем", где чернорабочими выступают LLM. Во всем выступлении сквозит тезис о том, что кто быстрее перестроит процессы под эту реальность - тот и выиграет рынок.
#Engineering #AI #Metrics #Software #DevEx #Productivity #IDE
YouTube
2026: The Year The IDE Died — Steve Yegge & Gene Kim, Authors, Vibe Coding
As AI has grown more capable, software developers around the world have lagged behind the technology advances, and have consistently eschewed the most powerful tools. In this talk I explore why devs are staying 9-12 months behind the AI curve. I'll share…
❤8🥴8👍3🔥2
Moving away from Agile. What's next? (Рубрика #Processes)
Посмотрел претенциозный доклад ребят из McKinsey с недавноей конфы AI Engineer, в котором они раскрывали несколько ключевых мыслей
- Текущие операционные модели (Agile based) плохо раскрывают потенциал AI‑инструментов
- "AI‑native" команды отличаются другими workflow, ролями и метриками
- Переход от Agile - это в первую очередь организационные и культурные изменения, а не использование инструментов
Тезисы, что поддерживают их мысли основаны на следующем
- У нас есть разрыв между индивидуальным бустом инженеров и эффектом на компанию: отдельные разработчики получают ускорение "дни → минуты", а в среднем по компании видят лишь 5–15% прироста продуктивности, потому что остальной процесс остался старым.
- AI создаёт новые бутылочные горлышки: распределение задач между людьми и агентами, ручной код‑ревью при лавине сгенерированного кода, ускоренное накопление техдолга и сложности.
- Старый agile‑сетап (8–10 человек, двухнедельные спринты, story‑driven dev, раздельные роли frontend, backend, qa, ...) оптимизирован под "чисто человеческую" разработку и плохо сочетается с использованием агентов
Интересно, что название самого доклада выглядит как байтинг - авторы на самом деле не предлагают "выкинуть agile", скорее они предлагат уйти от конкретной реализации со спринтами по две недели, командами формата "two-pizza teams" и остальными ритуалами. На замену этому они предлагают "AI native подход": короткие циклы, более мелкие команды, spec‑driven development, ну и изменение роли product manager и инженеров.
Вообще забавно смотреть на выступления консультантов про разработку - не уверен, что они сами когда-то писали код, поэтому они базируют свой helicopter view анализ на куче различных исследований и кейс study. Ну и мыслят они не с уровня команды, а с уровня портфеля из сотен команд: много говорят про change management, измерения, роль обучения, перестройку орг‑структуры. Это консалтинговый взгляд, но он полезен, если говорить про крупные корпорации:)
Если говорить подробнее про изменения, то они предлагают
- Перейти от квартального планирования к continuous planning
- Перейти от story‑driven к spec‑driven разработке - PM/lead сначала "выбивают" нормальную спецификацию вместе с агентом, а уже потом команда/агенты пилят код, чтобы сократить рефакторы и перегенерации.
- Перейти к командам по 3-5 человек, где участники больше напоминают fullstack инженеров, а также оркестрируют агентов и отвечают за части архитектуры, а не только за свой слой
- Перейти к продактам, что сами начинают прототипировать с coding agent, а не только писать длинные PRD (product requirement definitions)
Авторы говорят и про метрики для измерения эффекта, предлагая многоуровневую систему
- Инвестиции в инструменты, обучение, коучинг
- Adoption, velocity, capacity, MTTR по критичным багам, безопасность и качество кода
- Бизнес‑результаты: time‑to‑revenue, cost-benefit analysis, возможность реинвестировать в greenfield/brownfield.
В общем, консультанты предлагают поменять весь процесс, а не просто навесить агентов и copilot на старые agile‑процессы
#Engineering #AI #Metrics #Software #DevEx #Productivity #Management #Leadership
Посмотрел претенциозный доклад ребят из McKinsey с недавноей конфы AI Engineer, в котором они раскрывали несколько ключевых мыслей
- Текущие операционные модели (Agile based) плохо раскрывают потенциал AI‑инструментов
- "AI‑native" команды отличаются другими workflow, ролями и метриками
- Переход от Agile - это в первую очередь организационные и культурные изменения, а не использование инструментов
Тезисы, что поддерживают их мысли основаны на следующем
- У нас есть разрыв между индивидуальным бустом инженеров и эффектом на компанию: отдельные разработчики получают ускорение "дни → минуты", а в среднем по компании видят лишь 5–15% прироста продуктивности, потому что остальной процесс остался старым.
- AI создаёт новые бутылочные горлышки: распределение задач между людьми и агентами, ручной код‑ревью при лавине сгенерированного кода, ускоренное накопление техдолга и сложности.
- Старый agile‑сетап (8–10 человек, двухнедельные спринты, story‑driven dev, раздельные роли frontend, backend, qa, ...) оптимизирован под "чисто человеческую" разработку и плохо сочетается с использованием агентов
Интересно, что название самого доклада выглядит как байтинг - авторы на самом деле не предлагают "выкинуть agile", скорее они предлагат уйти от конкретной реализации со спринтами по две недели, командами формата "two-pizza teams" и остальными ритуалами. На замену этому они предлагают "AI native подход": короткие циклы, более мелкие команды, spec‑driven development, ну и изменение роли product manager и инженеров.
Вообще забавно смотреть на выступления консультантов про разработку - не уверен, что они сами когда-то писали код, поэтому они базируют свой helicopter view анализ на куче различных исследований и кейс study. Ну и мыслят они не с уровня команды, а с уровня портфеля из сотен команд: много говорят про change management, измерения, роль обучения, перестройку орг‑структуры. Это консалтинговый взгляд, но он полезен, если говорить про крупные корпорации:)
Если говорить подробнее про изменения, то они предлагают
- Перейти от квартального планирования к continuous planning
- Перейти от story‑driven к spec‑driven разработке - PM/lead сначала "выбивают" нормальную спецификацию вместе с агентом, а уже потом команда/агенты пилят код, чтобы сократить рефакторы и перегенерации.
- Перейти к командам по 3-5 человек, где участники больше напоминают fullstack инженеров, а также оркестрируют агентов и отвечают за части архитектуры, а не только за свой слой
- Перейти к продактам, что сами начинают прототипировать с coding agent, а не только писать длинные PRD (product requirement definitions)
Авторы говорят и про метрики для измерения эффекта, предлагая многоуровневую систему
- Инвестиции в инструменты, обучение, коучинг
- Adoption, velocity, capacity, MTTR по критичным багам, безопасность и качество кода
- Бизнес‑результаты: time‑to‑revenue, cost-benefit analysis, возможность реинвестировать в greenfield/brownfield.
В общем, консультанты предлагают поменять весь процесс, а не просто навесить агентов и copilot на старые agile‑процессы
#Engineering #AI #Metrics #Software #DevEx #Productivity #Management #Leadership
YouTube
Moving away from Agile: What's Next – Martin Harrysson & Natasha Maniar, McKinsey & Company
Most enterprises are not capturing much value from AI in software dev to date (at least relative to the potential). The reason is that most are adding AI tools to their dev teams without changing the people and operating model aspects (i.e., limited changes…
❤13🔥8👍5
Can you prove AI ROI in Software Engineering? (Рубрика #AI)
Буквально недавно Егор Денисов-Бланш (Yegor Denisov-Blanch) выступил на конференции AI Engineer Code Summit 2025 в Нью-Йорке с таким провокационным докладом:) По-факту, это тизер результатов двухлетнего исследования влияния AI-инструментов на продуктивность разработчиков, охватывающего 120 000+ разработчиков в 600+ компаниях (такой охват как минимум внушает доверие ). Кстати, предыдущее выступление Егора "Does AI Actually Boost Developer Productivity?" я уже разбирал и часть тезисов полностью повторяются, а точнее вопросы вида
1. Почему существующие оценки продуктивности ненадёжны?
2. Как выглядела методология ребят из Stanford?
3. Главные численные выводы исследования
Но в этом докладе есть и новенькие результаты
1. Медианный прирост продуктивности составляет ~10%, но разброс между лидерами и отстающими постоянно увеличивается.
2. Качество использования AI важнее объёма. Корреляция между количеством потраченных токенов и ростом продуктивности слабая (R² = 0.20). Более того, наблюдается эффект "долины смерти" на уровне 10 млн токенов на инженера в месяц - команды, использующие такой объём, показывают результаты хуже, чем те, кто использует меньше.
3. Чистота кодовой базы критична для AI. Индекс "чистоты окружения" (Environment Cleanliness Index), учитывающий тесты, типы, документацию, модульность и качество кода, показывает корреляцию R² = 0.40 с приростом продуктивности от AI. Чистый код усиливает эффект от AI, а технический долг его нивелирует.
4. AI ускоряет энтропию кодовой базы. Бесконтрольное использование AI ускоряет накопление технического долга, что сдвигает кодовую базу в зону, где AI менее эффективен. Требуется активное управление качеством кода для сохранения преимуществ.
5. Доступ к AI ≠ эффективное использование. В кейсе с двумя бизнес-юнитами одной компании при равном доступе к инструментам использование было сильно разное. Важно измерять не только факт использования, но и как инженеры применяют AI.
Ну и собственно автор предлагает свою методологию для измерения ROI из двух частей
1. Измерение использования
Access-based (кто получил доступ) vs usage-based (телеметрия API). Usage-based - золотой стандарт, позволяющий ретроспективный анализ через git-историю.
2. Измерение инженерных результатов
- Primary metric: Engineering Output - ML-модель, реплицирующая оценку панели из 10-15 независимых экспертов по сложности, времени реализации и поддерживаемости
- Guardrail metrics: Rework & Refactoring, Code Quality & Risk, People & DevOps - метрики, которые нужно держать на здоровом уровне, но не максимизировать
Забавно, что автор категорически против использования PR counts, lines of code и даже DORA как основных метрик продуктивности.
Ну и если анализировать подход автора, то он содержит сильные и слабые стороны
(+) Исследовательская методология выглядит солидно. ML-модель, реплицирующая экспертные оценки, проверенная на корреляцию с реальными панельными данными - это правильный подход к измерению сложных качественных аспектов кода.
(+) Понимание системных эффектов. Концепция управления энтропией кодовой базы, связь между чистотой кода и эффективностью AI, понимание, что инженеры должны знать, когда не использовать AI
(+) Критика DORA как primary metric обоснована. DORA - это индикаторы процесса, а не результата. Их максимизация может вредить (вспомним Goodhart's Law)
(+)AI Practices Benchmark с уровнями зрелости (от личного использования до агентной оркестрации) показывает понимание эволюции практик.
(-) Background автора не в чистой разработке - у него отсутствует опыт и образование как инженера
(-) ML-модель как чёрный ящик. Хотя утверждается, что модель коррелирует с экспертными оценками, детали методологии, датасет для обучения, метрики качества модели не раскрыты в докладе
(-) Environment Cleanliness Index экспериментальный. Как именно взвешиваются компоненты индекса? Как он валидирован кроме корреляции с продуктивностью?
#Engineering #AI #Metrics #Software #DevEx #Productivity
Буквально недавно Егор Денисов-Бланш (Yegor Denisov-Blanch) выступил на конференции AI Engineer Code Summit 2025 в Нью-Йорке с таким провокационным докладом:) По-факту, это тизер результатов двухлетнего исследования влияния AI-инструментов на продуктивность разработчиков, охватывающего 120 000+ разработчиков в 600+ компаниях (
1. Почему существующие оценки продуктивности ненадёжны?
2. Как выглядела методология ребят из Stanford?
3. Главные численные выводы исследования
Но в этом докладе есть и новенькие результаты
1. Медианный прирост продуктивности составляет ~10%, но разброс между лидерами и отстающими постоянно увеличивается.
2. Качество использования AI важнее объёма. Корреляция между количеством потраченных токенов и ростом продуктивности слабая (R² = 0.20). Более того, наблюдается эффект "долины смерти" на уровне 10 млн токенов на инженера в месяц - команды, использующие такой объём, показывают результаты хуже, чем те, кто использует меньше.
3. Чистота кодовой базы критична для AI. Индекс "чистоты окружения" (Environment Cleanliness Index), учитывающий тесты, типы, документацию, модульность и качество кода, показывает корреляцию R² = 0.40 с приростом продуктивности от AI. Чистый код усиливает эффект от AI, а технический долг его нивелирует.
4. AI ускоряет энтропию кодовой базы. Бесконтрольное использование AI ускоряет накопление технического долга, что сдвигает кодовую базу в зону, где AI менее эффективен. Требуется активное управление качеством кода для сохранения преимуществ.
5. Доступ к AI ≠ эффективное использование. В кейсе с двумя бизнес-юнитами одной компании при равном доступе к инструментам использование было сильно разное. Важно измерять не только факт использования, но и как инженеры применяют AI.
Ну и собственно автор предлагает свою методологию для измерения ROI из двух частей
1. Измерение использования
Access-based (кто получил доступ) vs usage-based (телеметрия API). Usage-based - золотой стандарт, позволяющий ретроспективный анализ через git-историю.
2. Измерение инженерных результатов
- Primary metric: Engineering Output - ML-модель, реплицирующая оценку панели из 10-15 независимых экспертов по сложности, времени реализации и поддерживаемости
- Guardrail metrics: Rework & Refactoring, Code Quality & Risk, People & DevOps - метрики, которые нужно держать на здоровом уровне, но не максимизировать
Забавно, что автор категорически против использования PR counts, lines of code и даже DORA как основных метрик продуктивности.
Ну и если анализировать подход автора, то он содержит сильные и слабые стороны
(+) Исследовательская методология выглядит солидно. ML-модель, реплицирующая экспертные оценки, проверенная на корреляцию с реальными панельными данными - это правильный подход к измерению сложных качественных аспектов кода.
(+) Понимание системных эффектов. Концепция управления энтропией кодовой базы, связь между чистотой кода и эффективностью AI, понимание, что инженеры должны знать, когда не использовать AI
(+) Критика DORA как primary metric обоснована. DORA - это индикаторы процесса, а не результата. Их максимизация может вредить (вспомним Goodhart's Law)
(+)AI Practices Benchmark с уровнями зрелости (от личного использования до агентной оркестрации) показывает понимание эволюции практик.
(-) Background автора не в чистой разработке - у него отсутствует опыт и образование как инженера
(-) ML-модель как чёрный ящик. Хотя утверждается, что модель коррелирует с экспертными оценками, детали методологии, датасет для обучения, метрики качества модели не раскрыты в докладе
(-) Environment Cleanliness Index экспериментальный. Как именно взвешиваются компоненты индекса? Как он валидирован кроме корреляции с продуктивностью?
#Engineering #AI #Metrics #Software #DevEx #Productivity
YouTube
Can you prove AI ROI in Software Eng? (Stanford 120k Devs Study) – Yegor Denisov-Blanch, Stanford
You’re investing millions in AI for software engineering. Can you prove it’s paying off?
Benchmarks show models can write code, but in enterprise deployments ROI is hard to measure, easy to bias, and often distorted by activity metrics (PR counts, DORA)…
Benchmarks show models can write code, but in enterprise deployments ROI is hard to measure, easy to bias, and often distorted by activity metrics (PR counts, DORA)…
🔥10❤5👍4
From Vibe Coding To Vibe Engineering (Рубрика #AI)
Посмотрел юморное выступление Kitze (Кристияна Ристовски), состоявшееся в конце 2025 года на саммите AI Engineer. Спикер - заметный в сообществе фронтенд-разработчик и предприниматель, что известен своим саркастичным подходом к современной веб-разработке, которую он критикует излишнюю сложность инструментов (Webpack, конфигурации) и пропагандирует подход "Just Ship It". В этом докладе Kitze утверждает, что "vibe coding" веселый способ создания пет-проектов, но для реальной работы нужно превратить это в "vibe engineering. Если говорить про тезисы, то вот они
1️⃣ Спираль смерти (The Doom Loop)
Проблема с vibe coding в том, что как только вы начинаете вручную править код, написанный ИИ, вы ломаете «вайб». Вы тратите время на чтение чужого (машинного) кода, пытаетесь его понять, вносите правку, а потом при следующей генерации ИИ может затереть ваши изменения или перестать понимать контекст. Решение от Kitze в том, что если ИИ написал баг, не чините его руками. Заставьте ИИ починить его. Это требует дисциплины, но это единственный способ сохранить скорость. Вы должны стать менеджером, который не делает работу за стажера, а заставляет стажера переделать задачу правильно.
2️⃣ Контекст - это всё
Обычный vibe doding ломается на больших проектах, потому что ИИ «забывает» или не знает структуру всего проекта. А "vibe engineering" - это уже построение инфраструктуры вокруг LLM, которая автоматически скармливает модели весь актуальный контекст проекта (структуру файлов, типы, документацию) перед каждым запросом. Kitze показывает, что вместо написания кода он теперь пишет скрипты и промпты, которые собирают контекст для ИИ. Это и есть новая инженерия.
3️⃣ От синтаксиса к семантике
Разработчик перестает быть "писателем кода" и становится "архитектором намерений". Ваша задача - четко описать что должно произойти, а как это будет написано (на React, Vue или чистом JS) - становится вторичным.
Интересно, что автор предлагает эволюцию названия и подходов:
- "Vibe coding": "Я попросил Claude сделать змейку, и оно работает. Прикольно". Это хаотичный процесс, случайный результат.
- "Vibe engineering: "Я построил конвейер, где ИИ имеет доступ ко всей моей базе кода, знает мои линтеры и тесты, и я могу надежно генерировать сложные фичи, управляя процессом через промпты и тесты". Это уже похоже на инженерию
Kitze аргументирует, что мы должны перейти от стадии "игры" с ИИ к стадии профессионального встраивания ИИ в инженерные процессы.
Если подумать о том, а как предложенные изменения влияют на индустрию, то получим следующее
- Vibe coding опасен для новичков. Если ты не можешь верифицировать результат (не понимаешь архитектуру), ты создашь монстра. Новички теперь должны учиться не синтаксису
- Опытный инженер - становится супер-продуктивен. Если он знает что хочет получить, то с помощью vibe engineering может заменить целую команду из 3-5 человек. Kitze приводит пример, как он переписал огромные куски Sizzy за дни, а не месяцы (sizzy - это браузер для разработчиков и qa-инженеров)
- DevEx меняется - раньше мы оптимизировали подсветку синтаксиса и автодополнение. Теперь DX - это то, насколько легко ваш проект "читается" нейросетью. Если ваш код непонятен для LLM, вы проиграли.
Ну и однострочные выводы из доклада звучат так
- Не пишите код, управляйте им. Лучший код - тот, который вы не писали руками.
- Инвестируйте в контекст. Научитесь создавать инструменты, которые позволяют ИИ "видеть" ваш проект целиком.
- Сопротивляйтесь желанию "быстро поправить руками". Это ловушка, которая возвращает вас в старую парадигму и замедляет в долгосрочной перспективе.
- Код становится эфемерным. Мы привыкли беречь код. В эпоху vibe engineering код можно легко удалить и сгенерировать заново, если он перестал соответствовать требованиям. Ценность - в описании задачи, а не в файле с кодом.
#Engineering #AI #Software #ML #DevEx #Productivity #IDE
Посмотрел юморное выступление Kitze (Кристияна Ристовски), состоявшееся в конце 2025 года на саммите AI Engineer. Спикер - заметный в сообществе фронтенд-разработчик и предприниматель, что известен своим саркастичным подходом к современной веб-разработке, которую он критикует излишнюю сложность инструментов (Webpack, конфигурации) и пропагандирует подход "Just Ship It". В этом докладе Kitze утверждает, что "vibe coding" веселый способ создания пет-проектов, но для реальной работы нужно превратить это в "vibe engineering. Если говорить про тезисы, то вот они
1️⃣ Спираль смерти (The Doom Loop)
Проблема с vibe coding в том, что как только вы начинаете вручную править код, написанный ИИ, вы ломаете «вайб». Вы тратите время на чтение чужого (машинного) кода, пытаетесь его понять, вносите правку, а потом при следующей генерации ИИ может затереть ваши изменения или перестать понимать контекст. Решение от Kitze в том, что если ИИ написал баг, не чините его руками. Заставьте ИИ починить его. Это требует дисциплины, но это единственный способ сохранить скорость. Вы должны стать менеджером, который не делает работу за стажера, а заставляет стажера переделать задачу правильно.
2️⃣ Контекст - это всё
Обычный vibe doding ломается на больших проектах, потому что ИИ «забывает» или не знает структуру всего проекта. А "vibe engineering" - это уже построение инфраструктуры вокруг LLM, которая автоматически скармливает модели весь актуальный контекст проекта (структуру файлов, типы, документацию) перед каждым запросом. Kitze показывает, что вместо написания кода он теперь пишет скрипты и промпты, которые собирают контекст для ИИ. Это и есть новая инженерия.
3️⃣ От синтаксиса к семантике
Разработчик перестает быть "писателем кода" и становится "архитектором намерений". Ваша задача - четко описать что должно произойти, а как это будет написано (на React, Vue или чистом JS) - становится вторичным.
Интересно, что автор предлагает эволюцию названия и подходов:
- "Vibe coding": "Я попросил Claude сделать змейку, и оно работает. Прикольно". Это хаотичный процесс, случайный результат.
- "Vibe engineering: "Я построил конвейер, где ИИ имеет доступ ко всей моей базе кода, знает мои линтеры и тесты, и я могу надежно генерировать сложные фичи, управляя процессом через промпты и тесты". Это уже похоже на инженерию
Kitze аргументирует, что мы должны перейти от стадии "игры" с ИИ к стадии профессионального встраивания ИИ в инженерные процессы.
Если подумать о том, а как предложенные изменения влияют на индустрию, то получим следующее
- Vibe coding опасен для новичков. Если ты не можешь верифицировать результат (не понимаешь архитектуру), ты создашь монстра. Новички теперь должны учиться не синтаксису
for loop, а системному дизайну и проверке качества.- Опытный инженер - становится супер-продуктивен. Если он знает что хочет получить, то с помощью vibe engineering может заменить целую команду из 3-5 человек. Kitze приводит пример, как он переписал огромные куски Sizzy за дни, а не месяцы (sizzy - это браузер для разработчиков и qa-инженеров)
- DevEx меняется - раньше мы оптимизировали подсветку синтаксиса и автодополнение. Теперь DX - это то, насколько легко ваш проект "читается" нейросетью. Если ваш код непонятен для LLM, вы проиграли.
Ну и однострочные выводы из доклада звучат так
- Не пишите код, управляйте им. Лучший код - тот, который вы не писали руками.
- Инвестируйте в контекст. Научитесь создавать инструменты, которые позволяют ИИ "видеть" ваш проект целиком.
- Сопротивляйтесь желанию "быстро поправить руками". Это ловушка, которая возвращает вас в старую парадигму и замедляет в долгосрочной перспективе.
- Код становится эфемерным. Мы привыкли беречь код. В эпоху vibe engineering код можно легко удалить и сгенерировать заново, если он перестал соответствовать требованиям. Ценность - в описании задачи, а не в файле с кодом.
#Engineering #AI #Software #ML #DevEx #Productivity #IDE
YouTube
From Vibe Coding To Vibe Engineering – Kitze, Sizzy
Web development has always moved in cycles of hype, from frameworks to tooling. With the rise of large language models, we're entering a new era of "vibe coding," where developers shape software through collaboration with Al rather than syntax. This talk…
🔥15❤8🥴4🤝3👍1
Atlassian покупает платформу DX (developer experience) за $1 млрд - причины и последствия (Рубрика #DevEx)
18 сентября 2025 года компания Atlassian официально объявила о приобретении платформы DX (Developer Experience) приблизительно за $1 млрд с оплатой наличными средствами и акциями Atlassian (крупнейшее поглощение в истории Atlassian). DX представляет собой платформу инженерной аналитики, которая позволяет организациям оценивать продуктивность команд разработки и выявлять "узкие места" в их процессах. Мне это поглощение интересно тем, что среди создателей DX есть авторы подходов DORA, SPACE, DevEx, про которые я много рассказывал.
Руководство Atlassian объясняет покупку DX стратегическим стремлением помочь своим клиентам эффективнее использовать инвестиции в ИИ и улучшить работу инженерных команд. Компания отмечает, что всё больше предприятий вкладываются в инструменты искусственного интеллекта, но сталкиваются с вопросом, приносят ли эти вложения реальную отдачу в ускорении разработки (DX недавно опубликовали методологию "Measuring AI code assistants and agents")
Дополнительным обоснованием сделки стал синергетический эффект: около 90% клиентов DX уже используют продукты Atlassian (Jira, Confluence, Bitbucket и др.), что сделало DX очевидным кандидатом для присоединения. Кэннон-Брукс, соучредитель и CEO Atlassian, отмечал, что Atlassian несколько лет пыталась создать собственный инструмент для анализа продуктивности инженеров, однако в итоге решила приобрести готовое решение (сам стартап DX был основан 5 лет назад)
Atlassian планирует глубоко интегрировать DX в свою экосистему. В октябре 2025 года CTO Atlassian представил новый комплект Atlassian Software Collection, куда DX вошла в качестве новейшего компонента: платформа DX дополняет существующие решения, объединяя качественные опросы разработчиков с количественными метриками такими, как время прохождения pull request, частота сбоев сборки и уровень использования AI-инструментов. Данные DX будут напрямую доступны в продуктах Atlassian, а также DX продолжит поддерживать интеграции и с сторонними инструментами, чтобы клиенты могли извлекать пользу из DX независимо от стека Atlassian.
В будущем пользователям Atlassian станут доступны следующие возможности благодаря интеграции DX
- Измерение продуктивности и узких мест: система автоматически собирает ключевые показатели развития софта (скорость цикла код-ревью, частоту неудачных билдов, время внедрения фич) и выявляет узкие места в процессе
- Аналитика использования ИИ: DX позволяет отслеживать, как активно и с каким эффектом разработчики применяют AI-инструменты (код-ассистентов, агентов и пр.), отсекая шум и показывая реальную отдачу от AI-внедрений.
- Оценка опыта разработчиков: Помимо технических метрик, DX регулярно собирает качественные данные об опыте инженеров (опросы удовлетворённости, индексы Developer Experience). Совмещая цифры с мнением самих разработчиков, платформа определяет, что мешает людям работать продуктивно, и где возникают точки напряжения в взаимодействии команд
В целом, покупка DX сигнализирует о появлении в линейке Atlassian нового класса функций - “инженерной аналитики” - благодаря которому разработчики и менеджеры смогут совместно измерять и улучшать продуктивность, основываясь на данных, а не интуиции. Atlassian позиционирует этот шаг как часть более широкой стратегии по созданию интегрированной платформы для управления разработкой в эпоху ИИ, где связаны воедино планирование (Jira/Confluence), выполнение (код и CI/CD) и анализ эффективности (DX) для непрерывного совершенствования процесса создания софта
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
18 сентября 2025 года компания Atlassian официально объявила о приобретении платформы DX (Developer Experience) приблизительно за $1 млрд с оплатой наличными средствами и акциями Atlassian (крупнейшее поглощение в истории Atlassian). DX представляет собой платформу инженерной аналитики, которая позволяет организациям оценивать продуктивность команд разработки и выявлять "узкие места" в их процессах. Мне это поглощение интересно тем, что среди создателей DX есть авторы подходов DORA, SPACE, DevEx, про которые я много рассказывал.
Руководство Atlassian объясняет покупку DX стратегическим стремлением помочь своим клиентам эффективнее использовать инвестиции в ИИ и улучшить работу инженерных команд. Компания отмечает, что всё больше предприятий вкладываются в инструменты искусственного интеллекта, но сталкиваются с вопросом, приносят ли эти вложения реальную отдачу в ускорении разработки (DX недавно опубликовали методологию "Measuring AI code assistants and agents")
Дополнительным обоснованием сделки стал синергетический эффект: около 90% клиентов DX уже используют продукты Atlassian (Jira, Confluence, Bitbucket и др.), что сделало DX очевидным кандидатом для присоединения. Кэннон-Брукс, соучредитель и CEO Atlassian, отмечал, что Atlassian несколько лет пыталась создать собственный инструмент для анализа продуктивности инженеров, однако в итоге решила приобрести готовое решение (сам стартап DX был основан 5 лет назад)
Atlassian планирует глубоко интегрировать DX в свою экосистему. В октябре 2025 года CTO Atlassian представил новый комплект Atlassian Software Collection, куда DX вошла в качестве новейшего компонента: платформа DX дополняет существующие решения, объединяя качественные опросы разработчиков с количественными метриками такими, как время прохождения pull request, частота сбоев сборки и уровень использования AI-инструментов. Данные DX будут напрямую доступны в продуктах Atlassian, а также DX продолжит поддерживать интеграции и с сторонними инструментами, чтобы клиенты могли извлекать пользу из DX независимо от стека Atlassian.
В будущем пользователям Atlassian станут доступны следующие возможности благодаря интеграции DX
- Измерение продуктивности и узких мест: система автоматически собирает ключевые показатели развития софта (скорость цикла код-ревью, частоту неудачных билдов, время внедрения фич) и выявляет узкие места в процессе
- Аналитика использования ИИ: DX позволяет отслеживать, как активно и с каким эффектом разработчики применяют AI-инструменты (код-ассистентов, агентов и пр.), отсекая шум и показывая реальную отдачу от AI-внедрений.
- Оценка опыта разработчиков: Помимо технических метрик, DX регулярно собирает качественные данные об опыте инженеров (опросы удовлетворённости, индексы Developer Experience). Совмещая цифры с мнением самих разработчиков, платформа определяет, что мешает людям работать продуктивно, и где возникают точки напряжения в взаимодействии команд
В целом, покупка DX сигнализирует о появлении в линейке Atlassian нового класса функций - “инженерной аналитики” - благодаря которому разработчики и менеджеры смогут совместно измерять и улучшать продуктивность, основываясь на данных, а не интуиции. Atlassian позиционирует этот шаг как часть более широкой стратегии по созданию интегрированной платформы для управления разработкой в эпоху ИИ, где связаны воедино планирование (Jira/Confluence), выполнение (код и CI/CD) и анализ эффективности (DX) для непрерывного совершенствования процесса создания софта
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
TechCrunch
Atlassian acquires DX, a developer productivity platform, for $1B | TechCrunch
Atlassian is making its largest acquisition yet by buying DX so it can offer a developer productivity tool.
❤5🔥5🤯2⚡1
Leadership in AI Assisted Engineering (Рубрика #AI)
Интересный доклад Justin Reock, Deputy CTO компании DX (ее недавно купила Atlassian за $1 млрд). Reock известен своей работой по измерению и оптимизации developer productivity, что делает его одним из ведущих голосов в индустрии по вопросам внедрения AI в разработку. В этом докладе он рассказывал про продуктивность инженеров и приводил много отсылок к исследованиям, о которых я уже раньше рассказывал. Ниже я привел основные тезисы доклада
1️⃣ Парадокс AI-продуктивности: огромная вариативность результатов
Вопреки хайпу, реальное влияние AI на продуктивность крайне неоднородно.
Например, Сундар Пичай, CEO Google, в июне 2025 рассказывал про 10% увеличения engineering capacity. И тем же летом исследование METR показало 19% замедление работы с AI - хотя разработчики чувствовали себя на 20% быстрее. Я разбирал это исследование в постах 1 и 2 и даже в подкасте RIMS, где показано, что само исследование задизайнено под конкретный результат + представляет очень узкий кейс.
Если ориентироваться на данные платформы DX, где представлены 300+ компаний, то средние показатели выглядят скромно: +7.5% качество документации, +3.4% качество кода, +2.6% confidence в изменениях, -1% change failure rate. Но если смотреть на вариативность результатов, то некоторые видят +20% улучшение метрик, другие 20% ухудшение метрик. Кажется, что это обусловлено подходом к внедрению AI и измерению эффектов
2️⃣ Психологическая безопасность - фундамент AI-трансформации
Автор презентации вспомнил про Project Aristotle от Google, которому почти 15 лет. Тогда ребята из Google решили провести исследование команд и ответить на вопрос "What makes a team effective at Google?". Ответом стал такой фактор как psychological safety. Подробнее про исследование я уже рассказывал. Фактор психологической безопасности важен при внедрении AI
- Страх замены AI приводит к саботажу внедрения
- Без доверия люди не экспериментируют с инструментами
- Необходима прозрачная коммуникация: AI дополняет, а не заменяет
3️⃣ W. Edwards Deming: 95% - система, 5% - люди
Эдвард Деминг говорил о том, что 90-95% производительности определяется системой (процессы, инструменты, культура). А вот остальное зависит от индивидуальных качеств работника.
Если это переносить на процессы разработки, то
- Performance reviews, individual coaching - работа на 5%, трата человеческого таланта
- Фокус должен быть на оптимизации системы: инфраструктура, workflows, developer experience
- Если что-то идёт не так - ищите проблемы в системе, а не в людях
4️⃣ DX AI Measurement Framework: три измерения успеха
Спикер рассказал подход про измерение эффектов AI по трем осям
- Utilization (Использование)
- Impact (Влияние)
- Cost (Стоимость)
Подробнее я рассказывал про подход ребят раньше в разборе + в моем подкасте вместе с Женей Сергеевым. Но если говорить про мысли спикера, то он говорит, что baseline в виде стандартных метрки developer productivity (DORA, SPACE) важнее AI-специфичных метрик - они показывают реальное влияние на outcomes.
5️⃣ Интеграция AI по всему SDLC, а не только в coding
Для большинства организаций написание когда никогда не было узким местом - часто они были в других местах: поиске информации и контекста, задержек code reviews, сложностей координации, работы с инцидентами и легаси кодом. Дальше автор привел ряд примеров внедрения AI в разных компаниях: Morgan Stanley, Zapier, Spotify, Booking.
6️⃣ Топ-5 приоритетов для лидеров
1. Снизить страх AI через прозрачность
2. Вложиться в образовании сотрудников + выделить время на эксперименты
3. Вндерить измерения и начать открытую дискуссию о метриках
4. Unblock usage - внедрить креативный подход к compliance
5. Создать циклы обратной связи для непрерывного улучшения
#Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership #Economy #Metrics
Интересный доклад Justin Reock, Deputy CTO компании DX (ее недавно купила Atlassian за $1 млрд). Reock известен своей работой по измерению и оптимизации developer productivity, что делает его одним из ведущих голосов в индустрии по вопросам внедрения AI в разработку. В этом докладе он рассказывал про продуктивность инженеров и приводил много отсылок к исследованиям, о которых я уже раньше рассказывал. Ниже я привел основные тезисы доклада
1️⃣ Парадокс AI-продуктивности: огромная вариативность результатов
Вопреки хайпу, реальное влияние AI на продуктивность крайне неоднородно.
Например, Сундар Пичай, CEO Google, в июне 2025 рассказывал про 10% увеличения engineering capacity. И тем же летом исследование METR показало 19% замедление работы с AI - хотя разработчики чувствовали себя на 20% быстрее. Я разбирал это исследование в постах 1 и 2 и даже в подкасте RIMS, где показано, что само исследование задизайнено под конкретный результат + представляет очень узкий кейс.
Если ориентироваться на данные платформы DX, где представлены 300+ компаний, то средние показатели выглядят скромно: +7.5% качество документации, +3.4% качество кода, +2.6% confidence в изменениях, -1% change failure rate. Но если смотреть на вариативность результатов, то некоторые видят +20% улучшение метрик, другие 20% ухудшение метрик. Кажется, что это обусловлено подходом к внедрению AI и измерению эффектов
2️⃣ Психологическая безопасность - фундамент AI-трансформации
Автор презентации вспомнил про Project Aristotle от Google, которому почти 15 лет. Тогда ребята из Google решили провести исследование команд и ответить на вопрос "What makes a team effective at Google?". Ответом стал такой фактор как psychological safety. Подробнее про исследование я уже рассказывал. Фактор психологической безопасности важен при внедрении AI
- Страх замены AI приводит к саботажу внедрения
- Без доверия люди не экспериментируют с инструментами
- Необходима прозрачная коммуникация: AI дополняет, а не заменяет
3️⃣ W. Edwards Deming: 95% - система, 5% - люди
Эдвард Деминг говорил о том, что 90-95% производительности определяется системой (процессы, инструменты, культура). А вот остальное зависит от индивидуальных качеств работника.
Если это переносить на процессы разработки, то
- Performance reviews, individual coaching - работа на 5%, трата человеческого таланта
- Фокус должен быть на оптимизации системы: инфраструктура, workflows, developer experience
- Если что-то идёт не так - ищите проблемы в системе, а не в людях
4️⃣ DX AI Measurement Framework: три измерения успеха
Спикер рассказал подход про измерение эффектов AI по трем осям
- Utilization (Использование)
- Impact (Влияние)
- Cost (Стоимость)
Подробнее я рассказывал про подход ребят раньше в разборе + в моем подкасте вместе с Женей Сергеевым. Но если говорить про мысли спикера, то он говорит, что baseline в виде стандартных метрки developer productivity (DORA, SPACE) важнее AI-специфичных метрик - они показывают реальное влияние на outcomes.
5️⃣ Интеграция AI по всему SDLC, а не только в coding
Для большинства организаций написание когда никогда не было узким местом - часто они были в других местах: поиске информации и контекста, задержек code reviews, сложностей координации, работы с инцидентами и легаси кодом. Дальше автор привел ряд примеров внедрения AI в разных компаниях: Morgan Stanley, Zapier, Spotify, Booking.
6️⃣ Топ-5 приоритетов для лидеров
1. Снизить страх AI через прозрачность
2. Вложиться в образовании сотрудников + выделить время на эксперименты
3. Вндерить измерения и начать открытую дискуссию о метриках
4. Unblock usage - внедрить креативный подход к compliance
5. Создать циклы обратной связи для непрерывного улучшения
#Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership #Economy #Metrics
YouTube
Leadership in AI Assisted Engineering – Justin Reock, DX (acq. Atlassian)
To realize meaningful returns on AI investments, leadership must take accountability and ownership of establishing best practices, enabling engineers, measuring impact, and ensuring proper guardrails are in place. When prompting practice and reflexive AI…
🔥10❤4💯2
[1/3] The Pragmatic Engineer 2025 Survey (Рубрика #DevEx)
Добрался до результатов летнего исследования Гергели Ороша (Gergely Orosz), известного инженера и автора популярной рассылки "The Pragmatic Engineer", одного из самых влиятельных источников аналитики в сфере технологий. Этот опрос проводился среди читателей рассылки "The Pragmatic Engineer" в апреле–мае 2025, причем в нем приняли участие 3k инженеров. Респондентами преимущественно являются инженеры-разработчики софта причем из компаний всех масштабов (от стартапа до бигтехов), причем так получилось, что половина работала в мелких и половина в крупных компаниях. Следует отметить, что выборка не случайна, а основана на подписчиках технического блога, поэтому она может смещаться в сторону продуктовых IT-компаний. Например, среди читателей заметно выше доля пользователей AWS и ниже - Azure по сравнению с традиционными корпоративными сегментами. В целом же охват опроса по ролям и компаниям очень широк, что даёт основание доверять тенденциям, выявленным в данных.
Результаты Гергели оформил в трех частях, каждая из которых посвящена определённым категориям инструментов разработки. Вот эти три части
1️⃣ Часть
Демография респондентов; использование AI-инструментов; наиболее используемые и любимые языки программирования; рейтинг самых нелюбимых и самых любимых инструментов; среды разработки (IDE) и терминалы; системы контроля версий и CI/CD; облачные платформы (IaaS/PaaS)
2️⃣ Часть
Наиболее часто упоминаемые инструменты (лидируют JIRA, VS Code и AWS); средства управления проектами; инструменты коммуникации и совместной работы (Slack, MS Teams, Confluence, Miro, Figma); базы данных и хранилища (PostgreSQL и мн. др.); бекенд-инфраструктура (Docker, Kubernetes, Terraform, облачные сервисы); балансировщики нагрузки; а также
3️⃣ Часть
Средства наблюдаемости, мониторинга и логирования; инструменты для дежурств и управления инцидентами; системы feature flags, аналитики и экспериментов; инструменты фронтенд- и мобильной разработки; различные утилиты для разработчиков; собственные (custom) внутренние инструменты команд; и нишевые любимые инструменты энтузиастов
Среди ключевых результатов можно выделить следующие
🤖 Широкое внедрение ИИ-инструментов
85% опрошенных инженеров используют в работе хотя бы один инструмент с элементами AI, например кодового помощника. Каждый второй респондент применяет GitHub Copilot – этот AI-помощник для программирования стал самым популярным средством из своего класса. Лишь около 4% принципиально не пользуются AI (по причинам корпоративного запрета, неэффективности или этических убеждений), что подчёркивает массовое проникновение данных технологий в разработку.
🐍 Популярные языки программирования
TypeScript вышел на первое место по частоте использования среди языков разработки (ожидаемо, учитывая его применение и в фронтенде, и в бекенде). Широко распространены также Python, JavaScript, Java, C# и другие языки, при этом все основные языковые экосистемы оцениваются разработчиками положительно - ни один язык не получил значимого перевеса негатива в отзывах. Это говорит о зрелости современных языков: откровенно "плохие" решения попросту не становятся массовыми. В топ-10 самых любимых языков неожиданно вошёл даже нишевый Elixir, а фреймворк Ruby on Rails оказался одновременно 5-м по использованию и 3-м по любви, что подчёркивает лояльность его сообщества (чтобы понять любовь к нему можно глянуть документалку про RoR)
Продолжение в следующем посте.
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
Добрался до результатов летнего исследования Гергели Ороша (Gergely Orosz), известного инженера и автора популярной рассылки "The Pragmatic Engineer", одного из самых влиятельных источников аналитики в сфере технологий. Этот опрос проводился среди читателей рассылки "The Pragmatic Engineer" в апреле–мае 2025, причем в нем приняли участие 3k инженеров. Респондентами преимущественно являются инженеры-разработчики софта причем из компаний всех масштабов (от стартапа до бигтехов), причем так получилось, что половина работала в мелких и половина в крупных компаниях. Следует отметить, что выборка не случайна, а основана на подписчиках технического блога, поэтому она может смещаться в сторону продуктовых IT-компаний. Например, среди читателей заметно выше доля пользователей AWS и ниже - Azure по сравнению с традиционными корпоративными сегментами. В целом же охват опроса по ролям и компаниям очень широк, что даёт основание доверять тенденциям, выявленным в данных.
Результаты Гергели оформил в трех частях, каждая из которых посвящена определённым категориям инструментов разработки. Вот эти три части
1️⃣ Часть
Демография респондентов; использование AI-инструментов; наиболее используемые и любимые языки программирования; рейтинг самых нелюбимых и самых любимых инструментов; среды разработки (IDE) и терминалы; системы контроля версий и CI/CD; облачные платформы (IaaS/PaaS)
2️⃣ Часть
Наиболее часто упоминаемые инструменты (лидируют JIRA, VS Code и AWS); средства управления проектами; инструменты коммуникации и совместной работы (Slack, MS Teams, Confluence, Miro, Figma); базы данных и хранилища (PostgreSQL и мн. др.); бекенд-инфраструктура (Docker, Kubernetes, Terraform, облачные сервисы); балансировщики нагрузки; а также
3️⃣ Часть
Средства наблюдаемости, мониторинга и логирования; инструменты для дежурств и управления инцидентами; системы feature flags, аналитики и экспериментов; инструменты фронтенд- и мобильной разработки; различные утилиты для разработчиков; собственные (custom) внутренние инструменты команд; и нишевые любимые инструменты энтузиастов
Среди ключевых результатов можно выделить следующие
85% опрошенных инженеров используют в работе хотя бы один инструмент с элементами AI, например кодового помощника. Каждый второй респондент применяет GitHub Copilot – этот AI-помощник для программирования стал самым популярным средством из своего класса. Лишь около 4% принципиально не пользуются AI (по причинам корпоративного запрета, неэффективности или этических убеждений), что подчёркивает массовое проникновение данных технологий в разработку.
TypeScript вышел на первое место по частоте использования среди языков разработки (ожидаемо, учитывая его применение и в фронтенде, и в бекенде). Широко распространены также Python, JavaScript, Java, C# и другие языки, при этом все основные языковые экосистемы оцениваются разработчиками положительно - ни один язык не получил значимого перевеса негатива в отзывах. Это говорит о зрелости современных языков: откровенно "плохие" решения попросту не становятся массовыми. В топ-10 самых любимых языков неожиданно вошёл даже нишевый Elixir, а фреймворк Ruby on Rails оказался одновременно 5-м по использованию и 3-м по любви, что подчёркивает лояльность его сообщества (чтобы понять любовь к нему можно глянуть документалку про RoR)
Продолжение в следующем посте.
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
Please open Telegram to view this post
VIEW IN TELEGRAM
Pragmaticengineer
The Pragmatic Engineer 2025 Survey: What’s in your tech stack? Part 1
Which tools do software engineers use for backend development, frontend, infrastructure, AI tooling, and more, today? Reader survey, with feedback and analysis, based on 3,000+ responses
❤5🔥2⚡1
[2/3] The Pragmatic Engineer 2025 Survey (Рубрика #DevEx)
Продолжая рассказ про опрос Гергели, рассмотрим оставшиеся темы
❤🔥 Инструменты разработки: любовь и ненависть
Список самых часто используемых инструментов возглавил неожиданно JIRA (чаще даже VS Code или AWS). Парадоксально, но JIRA же стал и самым ненавидимым инструментом (разработчики не любят JIRA за медлительность и громоздкость), а вот более лёгкий конкурент, Linear, напротив, попал в число самых любимых инструментов (№4) и рассматривается инженерами как желанная замена JIRA. В целом, два этих инструмента сейчас доминируют в управлении проектами (вместе 75% упоминаний project management инструментов). JIRA в крупных компаниях, а Linear в малых.
✈ Командная коммуникация и сотрудничество
Среди средств коммуникации лидируют проверенные решения: Slack - самый используемый чат для разработки, а Microsoft Teams - наиболее распространён для видеозвонков. Для хранения документации чаще всего применяют Confluence, для совместного brainstorming - онлайн-доску Miro, а для дизайна интерфейсов - Figma. Примечательно, что Figma упоминалась разработчиками даже чаще, чем такой профильный инструмент, как K8s. Это свидетельствует о глубоком вовлечении команд разработки в процесс проектирования UX/UI и тесной междисциплинарной работе с дизайнерами.
😶🌫️ Облачные платформы
В облачной инфраструктуре опрос подтвердил безусловное лидерство Amazon Web Services (AWS) - эту платформу используют ~44% респондентов, тогда как у ближайшего преследователя, Microsoft Azure, ~30%. Доля Google Cloud Platform составляет оставшиеся ~26%.
🐘 Инфраструктура и базы данных
Практически повсеместно используются контейнеры Docker и оркестратор K8s - де-факто стандарт развёртывания приложений. Для управления инфраструктурой как кодом лидирует Terraform. Кроме того, широко востребованы управляемые облачные сервисы (например, от AWS) для типовых задач backend. Что касается хранения данных, опрос показал безоговорочную популярность PostgreSQL (1/3 респондентов упоминало ее). Тем не менее, выбор технологий хранения невероятно разнообразен: профессионалы упомянули десятки разных баз данных (SQL, NoSQL, NewSQL, специализированные хранилища и т. д.). Это говорит о том, что современный стек данных очень неоднороден, и команды подбирают БД строго под свои задачи.
♾️ Мониторинг и надежность (DevOps)
В сфере observability данных наиболее популярны платформы Datadog, Grafana и Sentry - каждая из них используется примерно у 15-25% участников опроса. Эти инструменты (соответственно, облачный сервис мониторинга, open-source система дашбордов и сервис отслеживания ошибок) стали привычной частью инфраструктуры многих команд. Для оповещений и реагирования на инциденты подавляющее число инженеров применяют классические решения PagerDuty и OpsGenie.
📱 Фронтенд и мобильные технологии
Здесь наблюдается большая консолидация вокруг нескольких фреймворков. React практически без конкурентов доминирует как основной фронтенд-фреймворк (упоминается большинством веб-разработчиков), а Next.js стал самым популярным "мета"-фреймворком для React-приложений. Для мобильной разработки кроссплатформенно лидирует React Native - опрошенные отмечают его гораздо чаще любых альтернатив. Иными словами, стек фронтенда в 2025 году у большинства команд выглядит схоже. На бекенде разброс решений больше, но и там многие используют единый стек на TypeScript/Node.js либо популярные фреймворки вроде .NET и Spring.
🎌 Feature flags и внутренние инструменты
Практика feature flags и a/b тестирования прочно вошла в жизнь: для этого многие используют готовые сервисы, главным из которых является LaunchDarkly. Тем не менее, опрос показал, что весьма часто компании создают собственные системы фичефлагов, платформы экспериментов и кастомные конвейеры деплоя. Это может указывать на то, что существующие продукты не полностью покрывают нужды команд, либо на желание сэкономить на лицензиях, либо на требования безопасности.
Выводы из исследования в финальном посте.
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
Продолжая рассказ про опрос Гергели, рассмотрим оставшиеся темы
Список самых часто используемых инструментов возглавил неожиданно JIRA (чаще даже VS Code или AWS). Парадоксально, но JIRA же стал и самым ненавидимым инструментом (разработчики не любят JIRA за медлительность и громоздкость), а вот более лёгкий конкурент, Linear, напротив, попал в число самых любимых инструментов (№4) и рассматривается инженерами как желанная замена JIRA. В целом, два этих инструмента сейчас доминируют в управлении проектами (вместе 75% упоминаний project management инструментов). JIRA в крупных компаниях, а Linear в малых.
Среди средств коммуникации лидируют проверенные решения: Slack - самый используемый чат для разработки, а Microsoft Teams - наиболее распространён для видеозвонков. Для хранения документации чаще всего применяют Confluence, для совместного brainstorming - онлайн-доску Miro, а для дизайна интерфейсов - Figma. Примечательно, что Figma упоминалась разработчиками даже чаще, чем такой профильный инструмент, как K8s. Это свидетельствует о глубоком вовлечении команд разработки в процесс проектирования UX/UI и тесной междисциплинарной работе с дизайнерами.
😶🌫️ Облачные платформы
В облачной инфраструктуре опрос подтвердил безусловное лидерство Amazon Web Services (AWS) - эту платформу используют ~44% респондентов, тогда как у ближайшего преследователя, Microsoft Azure, ~30%. Доля Google Cloud Platform составляет оставшиеся ~26%.
Практически повсеместно используются контейнеры Docker и оркестратор K8s - де-факто стандарт развёртывания приложений. Для управления инфраструктурой как кодом лидирует Terraform. Кроме того, широко востребованы управляемые облачные сервисы (например, от AWS) для типовых задач backend. Что касается хранения данных, опрос показал безоговорочную популярность PostgreSQL (1/3 респондентов упоминало ее). Тем не менее, выбор технологий хранения невероятно разнообразен: профессионалы упомянули десятки разных баз данных (SQL, NoSQL, NewSQL, специализированные хранилища и т. д.). Это говорит о том, что современный стек данных очень неоднороден, и команды подбирают БД строго под свои задачи.
♾️ Мониторинг и надежность (DevOps)
В сфере observability данных наиболее популярны платформы Datadog, Grafana и Sentry - каждая из них используется примерно у 15-25% участников опроса. Эти инструменты (соответственно, облачный сервис мониторинга, open-source система дашбордов и сервис отслеживания ошибок) стали привычной частью инфраструктуры многих команд. Для оповещений и реагирования на инциденты подавляющее число инженеров применяют классические решения PagerDuty и OpsGenie.
📱 Фронтенд и мобильные технологии
Здесь наблюдается большая консолидация вокруг нескольких фреймворков. React практически без конкурентов доминирует как основной фронтенд-фреймворк (упоминается большинством веб-разработчиков), а Next.js стал самым популярным "мета"-фреймворком для React-приложений. Для мобильной разработки кроссплатформенно лидирует React Native - опрошенные отмечают его гораздо чаще любых альтернатив. Иными словами, стек фронтенда в 2025 году у большинства команд выглядит схоже. На бекенде разброс решений больше, но и там многие используют единый стек на TypeScript/Node.js либо популярные фреймворки вроде .NET и Spring.
🎌 Feature flags и внутренние инструменты
Практика feature flags и a/b тестирования прочно вошла в жизнь: для этого многие используют готовые сервисы, главным из которых является LaunchDarkly. Тем не менее, опрос показал, что весьма часто компании создают собственные системы фичефлагов, платформы экспериментов и кастомные конвейеры деплоя. Это может указывать на то, что существующие продукты не полностью покрывают нужды команд, либо на желание сэкономить на лицензиях, либо на требования безопасности.
Выводы из исследования в финальном посте.
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Книжный куб
[1/3] The Pragmatic Engineer 2025 Survey (Рубрика #DevEx)
Добрался до результатов летнего исследования Гергели Ороша (Gergely Orosz), известного инженера и автора популярной рассылки "The Pragmatic Engineer", одного из самых влиятельных источников аналитики…
Добрался до результатов летнего исследования Гергели Ороша (Gergely Orosz), известного инженера и автора популярной рассылки "The Pragmatic Engineer", одного из самых влиятельных источников аналитики…
❤6🔥4👍3
[3/3] The Pragmatic Engineer 2025 Survey (Рубрика #DevEx)
Если финализировать разбор этого отчета Гергели (начало в 1 и 2), то видны следующие ключевые тренды
1️⃣ Инструменты с искусственным интеллектом из разряда эксперимента перешли в категорию повседневных - подавляющее большинство разработчиков теперь пользуется AI-помощниками. Это означает, что продуктивность инженеров всё больше будет зависеть от интеграции AI в их рабочие процессы, а компании должны учитывать данную тенденцию при выборе инструментов.
2️⃣ Технологический стек продолжает унифицироваться вокруг лучших решений: TypeScript и React стали фактическим стандартом веб-разработки, Kubernetes – стандартом развёртывания, GitHub - стандартом хостинга кода и т. д. Популярные языки и фреймворки достигли такой зрелости, что разработчики в целом ими довольны и не испытывают острой необходимости срочно искать им замену
3️⃣ Позиции крупных экосистемных игроков остаются сильны. Так, Microsoft контролирует заметную часть инструментов разработчика (4 из 15 самых распространённых, включая VS Code, GitHub и Azure DevOps), Amazon - облачную инфраструктуру, Atlassian - управление проектами и т.д. Для индустрии это означает стабильность базового инструментария и продолжение инвестиций со стороны гигантов рынка.
Одновременно опрос показал и точки напряжения, которые можно рассматривать как ниши для инноваций.
Разработчики явно фрустрированы от "тяжеловесных" корпоративных решений – яркий пример тому JIRA, которую вынужденно используют повсеместно, но называют худшим инструментом. Запрос на более продуктивные, быстрые и удобные инструменты налицо, что подтверждается успехом конкурента Linear и других облегённых аналогов. Когда две системы (JIRA и Linear) охватывают порядка 75% всех командных процессов планирования, рынок фактически монополизирован парой игроков - и в то же время открывается возможность для новых продуктов, способных потеснить устоявшиеся, но нелюбимые решения.
Похожая ситуация складывается и в других категориях: например, появление специализированных стартапов в области oncall, фичефлагов, observability говорит о том, что существующие крупные продукты удовлетворяют не всех. Многие компании продолжают строить критически важные инструменты "in-house", и это сигнал вендорам о незакрытых потребностях. С другой стороны, столь богатый и разнообразный ландшафт инструментов - благо для инженеров, но и вызов для технологических лидеров.
В 2025 году перед командами стоит задача грамотной интеграции множества инструментов: от AI-помощников до облачных сервисов, от мониторинга до экспериментальных платформ. Те компании, которые сумеют подобрать оптимальный набор технологий и процессов, получают конкурентное преимущество в эффективности разработки и скорости вывода продукта на рынок.
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
Если финализировать разбор этого отчета Гергели (начало в 1 и 2), то видны следующие ключевые тренды
1️⃣ Инструменты с искусственным интеллектом из разряда эксперимента перешли в категорию повседневных - подавляющее большинство разработчиков теперь пользуется AI-помощниками. Это означает, что продуктивность инженеров всё больше будет зависеть от интеграции AI в их рабочие процессы, а компании должны учитывать данную тенденцию при выборе инструментов.
2️⃣ Технологический стек продолжает унифицироваться вокруг лучших решений: TypeScript и React стали фактическим стандартом веб-разработки, Kubernetes – стандартом развёртывания, GitHub - стандартом хостинга кода и т. д. Популярные языки и фреймворки достигли такой зрелости, что разработчики в целом ими довольны и не испытывают острой необходимости срочно искать им замену
3️⃣ Позиции крупных экосистемных игроков остаются сильны. Так, Microsoft контролирует заметную часть инструментов разработчика (4 из 15 самых распространённых, включая VS Code, GitHub и Azure DevOps), Amazon - облачную инфраструктуру, Atlassian - управление проектами и т.д. Для индустрии это означает стабильность базового инструментария и продолжение инвестиций со стороны гигантов рынка.
Одновременно опрос показал и точки напряжения, которые можно рассматривать как ниши для инноваций.
Разработчики явно фрустрированы от "тяжеловесных" корпоративных решений – яркий пример тому JIRA, которую вынужденно используют повсеместно, но называют худшим инструментом. Запрос на более продуктивные, быстрые и удобные инструменты налицо, что подтверждается успехом конкурента Linear и других облегённых аналогов. Когда две системы (JIRA и Linear) охватывают порядка 75% всех командных процессов планирования, рынок фактически монополизирован парой игроков - и в то же время открывается возможность для новых продуктов, способных потеснить устоявшиеся, но нелюбимые решения.
Похожая ситуация складывается и в других категориях: например, появление специализированных стартапов в области oncall, фичефлагов, observability говорит о том, что существующие крупные продукты удовлетворяют не всех. Многие компании продолжают строить критически важные инструменты "in-house", и это сигнал вендорам о незакрытых потребностях. С другой стороны, столь богатый и разнообразный ландшафт инструментов - благо для инженеров, но и вызов для технологических лидеров.
В 2025 году перед командами стоит задача грамотной интеграции множества инструментов: от AI-помощников до облачных сервисов, от мониторинга до экспериментальных платформ. Те компании, которые сумеют подобрать оптимальный набор технологий и процессов, получают конкурентное преимущество в эффективности разработки и скорости вывода продукта на рынок.
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
Telegram
Книжный куб
[1/3] The Pragmatic Engineer 2025 Survey (Рубрика #DevEx)
Добрался до результатов летнего исследования Гергели Ороша (Gergely Orosz), известного инженера и автора популярной рассылки "The Pragmatic Engineer", одного из самых влиятельных источников аналитики…
Добрался до результатов летнего исследования Гергели Ороша (Gergely Orosz), известного инженера и автора популярной рассылки "The Pragmatic Engineer", одного из самых влиятельных источников аналитики…
👍5❤3🔥2
Developer Experience in the Age of AI Coding Agents (Рубрика #Agents)
Посмотрел интересное выступление Max Kanat-Alexander, Executive Distinguished Engineer в Capital One, где он рассказывал про DevEx в эпоху AI-агентов или как не утонуть в уже существующем legacy и новосозданном legacy, генерящегося агентами в ускоренном режиме:) Макс ранее работал Tech Lead в Google (над Code Health) и Principal Staff Engineer в LinkedIn (над Developer Productivity). Также он написал книги "Code Simplicity" и "Understanding Software", которые я пока не прочел:)
Основные тезисы доклада такие
1️⃣ Не сражайтесь с Training Set
Используйте стандартные инструменты. Если вы написали свой пакетный менеджер или используете редкий язык — агент будет тупить. Он обучен на open source стандартах. Чем "скучнее" и стандартнее ваш стек, тем умнее на нём работает AI.
2️⃣ CLI > GUI
Агентам нужны API и CLI, а не браузер. Заставлять агента "кликать" через GUI — дорого и ненадежно. Если у инструмента есть текстовый интерфейс, агент справится с ним быстрее и точнее.
3️⃣ Тесты должны быть детерминированными
Агенту ничего не говорит ошибка `500 Internal Error`. Ему нужны четкие сообщения валидаторов. Инвестиция в качественные сообщения об ошибках в тестах и линтерах — это инвестиция в автономность агента. Критично что тесты должны бежать быстро (30 секунд, а не 20 минут). Агент запускает их в цикле. Медленный CI убьёт продуктивность агента.
4️⃣ Документируйте "Зачем", а не "Что"
Агент видит код и понимает, что он делает. Но он не был на ваших митингах и не умеет читать мысли.
В документации теперь нужно писать контекст: бизнес-цели, внешние ограничения, форму данных на входе. То, чего нет в коде.
5️⃣ Проблема Code Review (Порочный цикл)
Написание кода превращается в чтение. Количество PR-ов растет экспоненциально.
Но, если у вас слабый процесс ревью, вы начнете "штамповать" (LGTM) плохой код от агентов. Кодовая база деградирует, агенту становится сложнее в ней работать, он пишет еще больше чуши → получается порочный круг. Решение в том, чтобы распределять нагрузку по ревью (не слать всё в общий канал "кто-нибудь гляньте") и жестко держать планку качества.
🚀 Что это значит для разработки?
- Рефакторинг легаси обязателен. Если человек не может понять структуру проекта без "тайных знаний", агент там просто галлюцинирует. Хорошая структура кода теперь — экономическая необходимость.
- Сдвиг парадигмы. Мы переходим от написания кода к верификации. Навык быстро читать и валидировать чужой код становится важнее навыка быстро печатать.
- Золотое правило. Всё, что хорошо для AI-агента (быстрые тесты, внятные ошибки, стандартные инструменты), хорошо и для человека. Даже если AI завтра исчезнет, эти инвестиции окупятся для людей. Забавно, что это очень похоже на "золотое правило морали", универсальный этический принцип, который гласит: «Поступай с другими так, как хочешь, чтобы поступали с тобой»,
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign
Посмотрел интересное выступление Max Kanat-Alexander, Executive Distinguished Engineer в Capital One, где он рассказывал про DevEx в эпоху AI-агентов или как не утонуть в уже существующем legacy и новосозданном legacy, генерящегося агентами в ускоренном режиме:) Макс ранее работал Tech Lead в Google (над Code Health) и Principal Staff Engineer в LinkedIn (над Developer Productivity). Также он написал книги "Code Simplicity" и "Understanding Software", которые я пока не прочел:)
Основные тезисы доклада такие
1️⃣ Не сражайтесь с Training Set
Используйте стандартные инструменты. Если вы написали свой пакетный менеджер или используете редкий язык — агент будет тупить. Он обучен на open source стандартах. Чем "скучнее" и стандартнее ваш стек, тем умнее на нём работает AI.
2️⃣ CLI > GUI
Агентам нужны API и CLI, а не браузер. Заставлять агента "кликать" через GUI — дорого и ненадежно. Если у инструмента есть текстовый интерфейс, агент справится с ним быстрее и точнее.
3️⃣ Тесты должны быть детерминированными
Агенту ничего не говорит ошибка `500 Internal Error`. Ему нужны четкие сообщения валидаторов. Инвестиция в качественные сообщения об ошибках в тестах и линтерах — это инвестиция в автономность агента. Критично что тесты должны бежать быстро (30 секунд, а не 20 минут). Агент запускает их в цикле. Медленный CI убьёт продуктивность агента.
4️⃣ Документируйте "Зачем", а не "Что"
Агент видит код и понимает, что он делает. Но он не был на ваших митингах и не умеет читать мысли.
В документации теперь нужно писать контекст: бизнес-цели, внешние ограничения, форму данных на входе. То, чего нет в коде.
5️⃣ Проблема Code Review (Порочный цикл)
Написание кода превращается в чтение. Количество PR-ов растет экспоненциально.
Но, если у вас слабый процесс ревью, вы начнете "штамповать" (LGTM) плохой код от агентов. Кодовая база деградирует, агенту становится сложнее в ней работать, он пишет еще больше чуши → получается порочный круг. Решение в том, чтобы распределять нагрузку по ревью (не слать всё в общий канал "кто-нибудь гляньте") и жестко держать планку качества.
🚀 Что это значит для разработки?
- Рефакторинг легаси обязателен. Если человек не может понять структуру проекта без "тайных знаний", агент там просто галлюцинирует. Хорошая структура кода теперь — экономическая необходимость.
- Сдвиг парадигмы. Мы переходим от написания кода к верификации. Навык быстро читать и валидировать чужой код становится важнее навыка быстро печатать.
- Золотое правило. Всё, что хорошо для AI-агента (быстрые тесты, внятные ошибки, стандартные инструменты), хорошо и для человека. Даже если AI завтра исчезнет, эти инвестиции окупятся для людей. Забавно, что это очень похоже на "золотое правило морали", универсальный этический принцип, который гласит: «Поступай с другими так, как хочешь, чтобы поступали с тобой»,
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign
YouTube
Developer Experience in the Age of AI Coding Agents – Max Kanat-Alexander, Capital One
It feels like every two weeks, the world of software engineering is being turned on its head. Are there any principles we can rely on that will continue to hold true, and that can help us prepare for the future, no matter what happens? Max uses research,…
👍10❤6🔥2