[2/2] From Predictive to Generative - How Michelangelo Accelerates Uber’s AI Journey (Рубрика #PlatformEngineering)
Продолжая рассказ про ML-платформу Michelangelo хочется поделиться уроками, что можно извлечь из рассказа про 8 лет ее эволюции и развития внутри Uber. Вдруг вы тоже планируете делать свою платформу:)
1. Централизованная ML-платформа
Для средних и больших компаний централизация значительно повышает эффективность разработки ML-моделей, избавляя от дублирования и позволяя внедрять стандарты повсеместно. В Uber оргструктура выглядела так: сильная центральная ML Platform team + встраивание ML-инженеров и data scientist’ов в продуктовые команды. Это позволило совместить экспертизу платформы с глубоким знанием домена продукта
2. Единый и гибкий UX
Кто-то любит интерфейсы “point-and-click”, а другие предпочитают всё делать кодом. Но для платформы важно предоставить обе возможности в рамках единого платформенного опыта: UI-инструменты для визуализации и быстрого прототипирования, а также возможность полноценно работать через код (API, конфигурации, Git). В Uber эта дуальность была критичной для принятия платформы разными командами. Причем разные режимы существуют совместно и платформа синхронизирует изменения, будь то через UI или код, обеспечивая согласованность и version control
3. Высокоуровневые шаблоны + доступ к низкоуровневым компонентам
Платформа обеспечивает эффективность за счет предоставления high-level абстракций (шаблоны типовых ML-пайплайнов, авто-настройки, готовые интеграции) для большинства пользователей. Но для продвинутых команд нужно обеспечить доступ к низкоуровневым компонентам для кастомизации. Именно так сделано в Michelangelo 2.0: большинство используют готовые workflow templates и стандартные конфигурации, а power users при необходимости "спускаются" на уровень кастомных pipelines, встроенных в общую систему.
4. Модульная архитектура и открытость
Модульность позволяет компонентам платформы развиваться и масштабироваться независимо друг от друга. Plug-and-play дизайн позволяет быстро внедрять state-of-the-art технологии из open-source или сторонних сервисов по мере их появления. Uber держит фокус на основном пользовательском опыте, но технически может подключать лучшие решения для оркестрации, хранения данных, вычислений и т.д., не ломая общий продукт. Uber предпочитает открытые решения там, где это возможно, но использует и облачные модели, внимательно оценивая косты
5. Осознанное применение Deep Learning
Продвинутые методы вроде DL способны решать очень сложные задачи, но требуют огромных ресурсов и инфраструктуры, что должно быть оправдано бизнес-ценностью. Поэтому архитектура поддерживает разные типы моделей, а выбор делается прагматично. Для команд, планирующих внедрять DL, важно заранее обеспечить поддержку масштабируемого обучения (GPU/TPU, distributed training) и продумать мониторинг продуктивности моделей, так как обслуживание DL в продакшене сложнее и дороже обычных моделей.
6. Приоритизация ML-проектов
Не все модели равны - какие-то напрямую влияют на ключевые метрики бизнеса, другие играют вспомогательную роль. Вводите систему приоритетов (tiers) для ML-проектов, чтобы рационально распределять ресурсы и требования к надежности. Опыт Uber показывает эффективность четкого разделения
- Критичные (tier-1) модели получают максимальный уровень поддержки, мониторинга, строгие процессы деплоя
- Низкоприоритетные экспы (tier-4) могут обслуживаться по упрощенной схеме, предоставляя командам свободу творить, но без расходования чрезмерных ресурсов.
Итого, кажется, что Michelangelo показал путь эволюции платформы для успешного масштабирования AI в крупной компании. Секрет успеха - в постоянном улучшении опыта разработчиков, стандартизации процессов и гибкой архитектуре, готовой к новым технологическим веяниям.
#Architecture #Engineering #Management #ML #AI #Software #Leadership #DistributedSystem #SystemDesign
Продолжая рассказ про ML-платформу Michelangelo хочется поделиться уроками, что можно извлечь из рассказа про 8 лет ее эволюции и развития внутри Uber. Вдруг вы тоже планируете делать свою платформу:)
1. Централизованная ML-платформа
Для средних и больших компаний централизация значительно повышает эффективность разработки ML-моделей, избавляя от дублирования и позволяя внедрять стандарты повсеместно. В Uber оргструктура выглядела так: сильная центральная ML Platform team + встраивание ML-инженеров и data scientist’ов в продуктовые команды. Это позволило совместить экспертизу платформы с глубоким знанием домена продукта
2. Единый и гибкий UX
Кто-то любит интерфейсы “point-and-click”, а другие предпочитают всё делать кодом. Но для платформы важно предоставить обе возможности в рамках единого платформенного опыта: UI-инструменты для визуализации и быстрого прототипирования, а также возможность полноценно работать через код (API, конфигурации, Git). В Uber эта дуальность была критичной для принятия платформы разными командами. Причем разные режимы существуют совместно и платформа синхронизирует изменения, будь то через UI или код, обеспечивая согласованность и version control
3. Высокоуровневые шаблоны + доступ к низкоуровневым компонентам
Платформа обеспечивает эффективность за счет предоставления high-level абстракций (шаблоны типовых ML-пайплайнов, авто-настройки, готовые интеграции) для большинства пользователей. Но для продвинутых команд нужно обеспечить доступ к низкоуровневым компонентам для кастомизации. Именно так сделано в Michelangelo 2.0: большинство используют готовые workflow templates и стандартные конфигурации, а power users при необходимости "спускаются" на уровень кастомных pipelines, встроенных в общую систему.
4. Модульная архитектура и открытость
Модульность позволяет компонентам платформы развиваться и масштабироваться независимо друг от друга. Plug-and-play дизайн позволяет быстро внедрять state-of-the-art технологии из open-source или сторонних сервисов по мере их появления. Uber держит фокус на основном пользовательском опыте, но технически может подключать лучшие решения для оркестрации, хранения данных, вычислений и т.д., не ломая общий продукт. Uber предпочитает открытые решения там, где это возможно, но использует и облачные модели, внимательно оценивая косты
5. Осознанное применение Deep Learning
Продвинутые методы вроде DL способны решать очень сложные задачи, но требуют огромных ресурсов и инфраструктуры, что должно быть оправдано бизнес-ценностью. Поэтому архитектура поддерживает разные типы моделей, а выбор делается прагматично. Для команд, планирующих внедрять DL, важно заранее обеспечить поддержку масштабируемого обучения (GPU/TPU, distributed training) и продумать мониторинг продуктивности моделей, так как обслуживание DL в продакшене сложнее и дороже обычных моделей.
6. Приоритизация ML-проектов
Не все модели равны - какие-то напрямую влияют на ключевые метрики бизнеса, другие играют вспомогательную роль. Вводите систему приоритетов (tiers) для ML-проектов, чтобы рационально распределять ресурсы и требования к надежности. Опыт Uber показывает эффективность четкого разделения
- Критичные (tier-1) модели получают максимальный уровень поддержки, мониторинга, строгие процессы деплоя
- Низкоприоритетные экспы (tier-4) могут обслуживаться по упрощенной схеме, предоставляя командам свободу творить, но без расходования чрезмерных ресурсов.
Итого, кажется, что Michelangelo показал путь эволюции платформы для успешного масштабирования AI в крупной компании. Секрет успеха - в постоянном улучшении опыта разработчиков, стандартизации процессов и гибкой архитектуре, готовой к новым технологическим веяниям.
#Architecture #Engineering #Management #ML #AI #Software #Leadership #DistributedSystem #SystemDesign
Telegram
Книжный куб
[1/2] From Predictive to Generative - How Michelangelo Accelerates Uber’s AI Journey (Рубрика #PlatformEngineering)
Когда я изучал как устроена инженерия в Uber, я наткнулся на отличную статью с разбором эволюции ML/AI платформы Michelangelo. Мне показалось…
Когда я изучал как устроена инженерия в Uber, я наткнулся на отличную статью с разбором эволюции ML/AI платформы Michelangelo. Мне показалось…
❤3🔥2👍1
How AI will change software engineering (Рубрика #Engineering)
Посмотрел интересное интервью Martin Fowler о том, что реально меняется для инженеров и тимлидов из‑за LLM и coding‑агентов. Мартин давал интервью Гергели Орошу в рамках подкаста Pragmatic Engineer. Сам разговор получился плотным (в самый раз для просмотра на 2x скорости) и ключевыми тезисами были следующие
🤖 AI - крупнейший сдвиг в разработке со времён высокоуровневых языков
Фаулер ставит нынешнюю волну ИИ в один ряд с переходом от ассемблера к Fortran/C: это новая парадигма работы с кодом, а не “ещё один инструмент в IDE”.
🎲 Код становится недетерминированным - нужно мыслить “допусками”
LLM не гарантирует одинаковый результат на один и тот же запрос. Фаулер предлагает заимствовать из классической инженерии мышление про допуски и запас прочности: заранее решать, где вариативность допустима, а где нужна жёсткая детерминированность и дополнительные проверки (особенно в безопасности).
👩💻 Тесты важнее, чем когда‑либо
Тесты теперь страхуют и людей, и модель. Любой сгенерированный LLM код должен проходить такой же, а лучше - более жёсткий, набор автотестов, статического анализа и quality‑checks. Без этого “ускорение” от ИИ превращается в отложенный технический долг. На эту тему рекомендую почитать книгу "AI Engineering" и конкретно главы "Evaluation Methodology" и "Evaluate AI Systems", что я уже разбирал в подкасте с обзором книги
🤖 AI + детерминированные инструменты > AI в одиночку
Один из ключевых паттернов: LLM генерирует черновой код, а предсказуемые инструменты делают массовые и безопасные трансформации - миграции, рефакторинги, форматирование.
👾 LLM особенно полезны для легаси и рефакторинга
AI показывает отличные результаты в рефакторинге старых монолитов, демонстрируя понимание странных зависимостей, генерируя первые варианты рефакторинга и миграций (например, на новый фреймворк или архитектурный паттерн). Но именно люди решают, куда систему развивать и какой “целевой дизайн” считать приемлемым.
💯 Vibe coding - режим прототипов, а не продакшена
Vibe coding - это создание решения, когда вы в основном говорите с агентом/IDE, почти не читая получившийся код. Это даёт огромную скорость для прототипов и одноразовых проектов, но переносить такой код в прод без ревью и тестов - гарантированные баги, уязвимости и проблемы с поддержкой.
📚 Список ключевых навыков инженера не поменялся
Несмотря на хайп вокруг ИИ, по мнению Фаулера, всё ещё решают: понимание домена, умение строить абстракции и архитектуру, делать осознанные trade-offs коммуницировать с бизнесом и командой. LLM усиливают сильных инженеров, но не подменяют сами навыки.
🔁 Agile по‑прежнему про обратную связь и обучение - просто цикл стал быстрее
Основные принципы Agile (короткие итерации, работа с заказчиком, постоянное обучение) остаются валидными. LLM‑инструменты лишь ускоряют цикл “придумал → набросал → проверил → переписал”, но не заменяют живую обратную связь, парное программирование и ретро.
🧠 ИИ не отменяет необходимость самому учиться программировать
Фаулер подчёркивает: разработка - это всегда процесс обучения. Если постоянно “аутсорсить” мышление ИИ, не формируется внутренняя модель системы, и команда быстро прилетает в maintenance‑cliff: код есть, понимания нет. Инструменты могут ускорять, но не могут “выучить за вас”.
🚀 Совет тимлидам: начинайте с низкорисковых сценариев
Внедрять ИИ лучше начать с документации, тестов, сниппетов, миграций и работы с легаси, а не с критических бизнес‑флоу. Параллельно вкладываться в автотесты, observability и инженерную культуру - тогда выгода от ИИ не будет одноразовым “демо‑эффектом”.
🌱 Совет джунам: не становитесь просто “операторами промптов”
Для начинающих разработчиков ИИ - отличный репетитор: можно просить объяснить незнакомый код, показать альтернативные решения, придумать упражнения. Но если ограничиться промптами и никогда не разбираться в том, что под капотом, - роста до middle/senior не будет. Нужны свои попытки, ошибки и рефакторинги.
#Architecture #Software #AI #Engineering #ML #Data #SystemDesign
Посмотрел интересное интервью Martin Fowler о том, что реально меняется для инженеров и тимлидов из‑за LLM и coding‑агентов. Мартин давал интервью Гергели Орошу в рамках подкаста Pragmatic Engineer. Сам разговор получился плотным (в самый раз для просмотра на 2x скорости) и ключевыми тезисами были следующие
Фаулер ставит нынешнюю волну ИИ в один ряд с переходом от ассемблера к Fortran/C: это новая парадигма работы с кодом, а не “ещё один инструмент в IDE”.
LLM не гарантирует одинаковый результат на один и тот же запрос. Фаулер предлагает заимствовать из классической инженерии мышление про допуски и запас прочности: заранее решать, где вариативность допустима, а где нужна жёсткая детерминированность и дополнительные проверки (особенно в безопасности).
Тесты теперь страхуют и людей, и модель. Любой сгенерированный LLM код должен проходить такой же, а лучше - более жёсткий, набор автотестов, статического анализа и quality‑checks. Без этого “ускорение” от ИИ превращается в отложенный технический долг. На эту тему рекомендую почитать книгу "AI Engineering" и конкретно главы "Evaluation Methodology" и "Evaluate AI Systems", что я уже разбирал в подкасте с обзором книги
Один из ключевых паттернов: LLM генерирует черновой код, а предсказуемые инструменты делают массовые и безопасные трансформации - миграции, рефакторинги, форматирование.
AI показывает отличные результаты в рефакторинге старых монолитов, демонстрируя понимание странных зависимостей, генерируя первые варианты рефакторинга и миграций (например, на новый фреймворк или архитектурный паттерн). Но именно люди решают, куда систему развивать и какой “целевой дизайн” считать приемлемым.
Vibe coding - это создание решения, когда вы в основном говорите с агентом/IDE, почти не читая получившийся код. Это даёт огромную скорость для прототипов и одноразовых проектов, но переносить такой код в прод без ревью и тестов - гарантированные баги, уязвимости и проблемы с поддержкой.
📚 Список ключевых навыков инженера не поменялся
Несмотря на хайп вокруг ИИ, по мнению Фаулера, всё ещё решают: понимание домена, умение строить абстракции и архитектуру, делать осознанные trade-offs коммуницировать с бизнесом и командой. LLM усиливают сильных инженеров, но не подменяют сами навыки.
🔁 Agile по‑прежнему про обратную связь и обучение - просто цикл стал быстрее
Основные принципы Agile (короткие итерации, работа с заказчиком, постоянное обучение) остаются валидными. LLM‑инструменты лишь ускоряют цикл “придумал → набросал → проверил → переписал”, но не заменяют живую обратную связь, парное программирование и ретро.
🧠 ИИ не отменяет необходимость самому учиться программировать
Фаулер подчёркивает: разработка - это всегда процесс обучения. Если постоянно “аутсорсить” мышление ИИ, не формируется внутренняя модель системы, и команда быстро прилетает в maintenance‑cliff: код есть, понимания нет. Инструменты могут ускорять, но не могут “выучить за вас”.
Внедрять ИИ лучше начать с документации, тестов, сниппетов, миграций и работы с легаси, а не с критических бизнес‑флоу. Параллельно вкладываться в автотесты, observability и инженерную культуру - тогда выгода от ИИ не будет одноразовым “демо‑эффектом”.
🌱 Совет джунам: не становитесь просто “операторами промптов”
Для начинающих разработчиков ИИ - отличный репетитор: можно просить объяснить незнакомый код, показать альтернативные решения, придумать упражнения. Но если ограничиться промптами и никогда не разбираться в том, что под капотом, - роста до middle/senior не будет. Нужны свои попытки, ошибки и рефакторинги.
#Architecture #Software #AI #Engineering #ML #Data #SystemDesign
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
How AI will change software engineering – with Martin Fowler
Martin Fowler is one of the most influential people within software architecture, and the broader tech industry. He is the Chief Scientist at Thoughtworks and the author of Refactoring and Patterns of Enterprise Application Architecture, and several other…
👍34❤11🔥7
Modern Architecture 101 for New Engineers & Forgetful Experts - NDC Copenhagen 2025 (Рубрика #Architecture)
Отличное выступление Jerry Nixon, product manager из команд SQL Server и Data API Builder, в котором он говорит, что архитектура - это не про "best practices", а про контекстные решения и смелость говорить "нет". Фактически, Никсон разрушает мифы и дальше показывает как строить архитектуру под любой масштаб с учетом вашего контекста. А начинает он с провокации, говоря, что термин "best practice" используют как оправдание отсутствия аргументов. Единственная настоящая best practice - не использовать SQL injection. Все остальное зависит от:
- Политики и бюджета компании
- Уровня команды (джуниоры vs эксперты)
- Наследия систем и ограничений от объединения разных систем
- Возможности "платить за ошибки" (Twitter может себе позволить глупости, а вы - нет)
Дальше он показывает "годовые кольца" технологий: spaghetti code 90-х, трехуровневые приложения 2000-х и микросервисы 2010-х, а дальше заключает, что все это работает до сих пор. В итоге, architecture shaming - это просто неуважение к контексту, в котором были приняты прошлые архитектурные решения.
По Никсону роль архитектора быть хранителем простоты. Ведь архитектор отвечает за самые дорогие решения, которые нельзя отложить. Это не тот, кто рисует схемы в начале проекта, а тот, кто постоянно решает, что оставить за бортом. Главная задача - не добавлять компоненты, а защищать систему от лишнего - это очень похоже на тезис Антуана де Сент-Экзюпери
После этого спикер начинает показывать как можно начинать проектировать решение с базы и постепенно наращивать сложность по мере появления доп требований
- Client → Database
- Client → API → Database (добавили интерфейс)
- Write API → Primary DB (синхронизация через логи) и Read API → Read replica. Логика в том, что вы масштабируете запись и чтение независимо за счет простого изменения connection string, а также за счет eventual consistency (и вам сразу становитсья важно понимать модели консистентности)
- Дальше появляется API Manager (APIM) / Gateway для управления API, версионирования, балансировки нагрузки, постепенной раскатки и a/b тестов
- Дальше появляется история про мониторинг (Никсон советует OpenTelemetry), кеши и service bus
- Ну и вообще асинхронность - это способ работы на масштабе: CQRS (Command Query Responsibility Segregation), Queue для работы со спайками нагрузки
- И так далее
В общем, выступление очень интересное. Основные мысли примерно такие
- Все компромиссы исходят из реальности, а не идеологии
- Архитектор - это тот, кого винят. Ваши решения будут судить через 5 лет, когда вы уже покинете компанию
- Сложность должна оправдываться. Каждый добавленный компонент (service bus, cache, gateway) - это еще одна система, за которую вы отвечаете.
Ну и напоследок тезис от автора, что меня сначала повеселил, а потом заставил задуматься
#Architecture #DistributedSystems #Management #Software #Leadership #Patterns #SystemDesign
Отличное выступление Jerry Nixon, product manager из команд SQL Server и Data API Builder, в котором он говорит, что архитектура - это не про "best practices", а про контекстные решения и смелость говорить "нет". Фактически, Никсон разрушает мифы и дальше показывает как строить архитектуру под любой масштаб с учетом вашего контекста. А начинает он с провокации, говоря, что термин "best practice" используют как оправдание отсутствия аргументов. Единственная настоящая best practice - не использовать SQL injection. Все остальное зависит от:
- Политики и бюджета компании
- Уровня команды (джуниоры vs эксперты)
- Наследия систем и ограничений от объединения разных систем
- Возможности "платить за ошибки" (Twitter может себе позволить глупости, а вы - нет)
Дальше он показывает "годовые кольца" технологий: spaghetti code 90-х, трехуровневые приложения 2000-х и микросервисы 2010-х, а дальше заключает, что все это работает до сих пор. В итоге, architecture shaming - это просто неуважение к контексту, в котором были приняты прошлые архитектурные решения.
По Никсону роль архитектора быть хранителем простоты. Ведь архитектор отвечает за самые дорогие решения, которые нельзя отложить. Это не тот, кто рисует схемы в начале проекта, а тот, кто постоянно решает, что оставить за бортом. Главная задача - не добавлять компоненты, а защищать систему от лишнего - это очень похоже на тезис Антуана де Сент-Экзюпери
Совершенство достигается не тогда, когда нечего добавить, а когда нечего убрать
После этого спикер начинает показывать как можно начинать проектировать решение с базы и постепенно наращивать сложность по мере появления доп требований
- Client → Database
- Client → API → Database (добавили интерфейс)
- Write API → Primary DB (синхронизация через логи) и Read API → Read replica. Логика в том, что вы масштабируете запись и чтение независимо за счет простого изменения connection string, а также за счет eventual consistency (и вам сразу становитсья важно понимать модели консистентности)
- Дальше появляется API Manager (APIM) / Gateway для управления API, версионирования, балансировки нагрузки, постепенной раскатки и a/b тестов
- Дальше появляется история про мониторинг (Никсон советует OpenTelemetry), кеши и service bus
- Ну и вообще асинхронность - это способ работы на масштабе: CQRS (Command Query Responsibility Segregation), Queue для работы со спайками нагрузки
- И так далее
В общем, выступление очень интересное. Основные мысли примерно такие
- Все компромиссы исходят из реальности, а не идеологии
- Архитектор - это тот, кого винят. Ваши решения будут судить через 5 лет, когда вы уже покинете компанию
- Сложность должна оправдываться. Каждый добавленный компонент (service bus, cache, gateway) - это еще одна система, за которую вы отвечаете.
Ну и напоследок тезис от автора, что меня сначала повеселил, а потом заставил задуматься
Мы не пишем код для компьютера, а для следующего разработчика, который, возможно, маньяк с топором. Не злите его
#Architecture #DistributedSystems #Management #Software #Leadership #Patterns #SystemDesign
YouTube
Modern Architecture 101 for New Engineers & Forgetful Experts - Jerry Nixon - NDC Copenhagen 2025
This talk was recorded at NDC Copenhagen in Copenhagen, Denmark. #ndccopenhagen #ndcconferences #developer #softwaredeveloper
Attend the next NDC conference near you:
https://ndcconferences.com
https://ndccopenhagen.com/
Subscribe to our YouTube channel…
Attend the next NDC conference near you:
https://ndcconferences.com
https://ndccopenhagen.com/
Subscribe to our YouTube channel…
🔥19❤10👍9😍1
Meta looks to power trading supports its AI energy needs (Рубрика #AI)
В ноябре 2025 года стало известно о нетривиальном шаге запрещенной в России компании Meta, которая получила разрешение американских регуляторов на торговлю электроэнергией на оптовом рынке. Такой шаг призван удовлетворить стремительно растущий спрос ее центров обработки данных (ЦОД) на электричество для решений искусственного интеллекта (AI). По сути, Meta создает собственное направление энерготрейдинга, чтобы напрямую закупать электроэнергию, заключать долгосрочные контракты с электростанциями и при необходимости перепродавать излишки мощности на рынке. Интересно, что в документе "Meta’s Hyperscale Infrastructure: Overview and Insights", что я разбирал раньше, было рассказано как раз о энергии, как о главном лимитирующем факторе для датацентров и инфры (условно, железо можно и обновить, а вот новые мощности по питанию обеспечить сложнее)
Тезисы тут примерно такие
- Сейчас мы наблюдаем взрывной рост потребности в энергии для AI, которые требуют огромных вычислительных ресурсов
- Существующая энергосистема с трудом справляется с такими темпами роста нагрузки, что уже вызвало в отдельных регионах США рекордный рост цен на мощность на оптовых аукционах
- Традиционных подходов к закупке энергии недостаточно - разработчики новых электростанций нуждаются в “якорных” покупателях, готовых брать на себя долгосрочные обязательства по закупке энергии. Например, Meta для своего нового ДЦ в Луизиане потребовалось вкладываться в строительство трех газовых станций, чтобы запитать ДЦ (они закоммитились только на это потратить 1.6 млрд $)
- А закупая электричество оптом можно не только снижать издержки за счет оптовых закупок, но и получать прибыль в периоды избытка продавая её обратно в сеть по пиковым ценам
В итоге, Meta создала дочернюю компанию Atem Energy LLC и получила разрешение на торговлю электроэнергией оптом от федеральной комиссии по регулированию энергетики США (FERC). Компания планирует изначально сотрудничать с опытными партнёрами-трейдерами и сконцентрироваться на работе на рынке США
Интересно, что Meta пошла по стопам других корпораций, получавших аналогичные лицензии. На оптовом рынке уже есть Google Energy, Apple Energy, Energy LLC, Amazon Energy. В общем, Meta не прокладывает абсолютно новый путь, но масштаб её усилий в энергетике - один из крупнейших на сегодня в Big Tech.
Если подумать, то для инфраструктуры ЦОДов это может значить следующее
- Снятие энергетических ограничений на рост ИИ - раньше именно энергия была лимитирующим фактором
- Увеличение капитальных затрат на дата-центры - теперь при планировании новых центров обработки данных компаний уровня Meta или Google необходимо учитывать и строительство параллельной энергоструктуры (это приведет к росту стоимости ЦОД проектов)
- Дизайн будущих дата-центров - появляется стимул размещать их ближе к источникам энергии: например, строить кампусы рядом с зонами богатых ВИЭ-ресурсов (ветер, солнце) или возле действующих крупных электростанций, чтобы минимизировать нагрузку на сети.
- Новые стандарты надежности и устойчивости - включение дата-центров в активное управление энергопотреблением (через торги, регулирование нагрузки) повышает устойчивость энергосистем, но и задаёт новые стандарты самим ЦОД. Например, Google уже заключает demand response-контракты с энергокомпаниями, согласившись переносить часть вычислений на непиковое время во избежание перегрузок сети
В сумме, инициатива Meta сигнализирует всему ИИ-сектору: эры дешёвого и гарантированного электричества больше нет, и дальнейший прогресс ML/AI тесно увязан с энергетической инфраструктурой. Те, кто сумеют интегрироваться с энергосистемой (через инвестиции или партнерства), получат фору в гонке ИИ, а те, кто проигнорируют - рискуют столкнуться с энергетическим дефицитом, замедляющим их инновации.
#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #AI #Economics
В ноябре 2025 года стало известно о нетривиальном шаге запрещенной в России компании Meta, которая получила разрешение американских регуляторов на торговлю электроэнергией на оптовом рынке. Такой шаг призван удовлетворить стремительно растущий спрос ее центров обработки данных (ЦОД) на электричество для решений искусственного интеллекта (AI). По сути, Meta создает собственное направление энерготрейдинга, чтобы напрямую закупать электроэнергию, заключать долгосрочные контракты с электростанциями и при необходимости перепродавать излишки мощности на рынке. Интересно, что в документе "Meta’s Hyperscale Infrastructure: Overview and Insights", что я разбирал раньше, было рассказано как раз о энергии, как о главном лимитирующем факторе для датацентров и инфры (условно, железо можно и обновить, а вот новые мощности по питанию обеспечить сложнее)
Тезисы тут примерно такие
- Сейчас мы наблюдаем взрывной рост потребности в энергии для AI, которые требуют огромных вычислительных ресурсов
- Существующая энергосистема с трудом справляется с такими темпами роста нагрузки, что уже вызвало в отдельных регионах США рекордный рост цен на мощность на оптовых аукционах
- Традиционных подходов к закупке энергии недостаточно - разработчики новых электростанций нуждаются в “якорных” покупателях, готовых брать на себя долгосрочные обязательства по закупке энергии. Например, Meta для своего нового ДЦ в Луизиане потребовалось вкладываться в строительство трех газовых станций, чтобы запитать ДЦ (они закоммитились только на это потратить 1.6 млрд $)
- А закупая электричество оптом можно не только снижать издержки за счет оптовых закупок, но и получать прибыль в периоды избытка продавая её обратно в сеть по пиковым ценам
В итоге, Meta создала дочернюю компанию Atem Energy LLC и получила разрешение на торговлю электроэнергией оптом от федеральной комиссии по регулированию энергетики США (FERC). Компания планирует изначально сотрудничать с опытными партнёрами-трейдерами и сконцентрироваться на работе на рынке США
Интересно, что Meta пошла по стопам других корпораций, получавших аналогичные лицензии. На оптовом рынке уже есть Google Energy, Apple Energy, Energy LLC, Amazon Energy. В общем, Meta не прокладывает абсолютно новый путь, но масштаб её усилий в энергетике - один из крупнейших на сегодня в Big Tech.
Если подумать, то для инфраструктуры ЦОДов это может значить следующее
- Снятие энергетических ограничений на рост ИИ - раньше именно энергия была лимитирующим фактором
- Увеличение капитальных затрат на дата-центры - теперь при планировании новых центров обработки данных компаний уровня Meta или Google необходимо учитывать и строительство параллельной энергоструктуры (это приведет к росту стоимости ЦОД проектов)
- Дизайн будущих дата-центров - появляется стимул размещать их ближе к источникам энергии: например, строить кампусы рядом с зонами богатых ВИЭ-ресурсов (ветер, солнце) или возле действующих крупных электростанций, чтобы минимизировать нагрузку на сети.
- Новые стандарты надежности и устойчивости - включение дата-центров в активное управление энергопотреблением (через торги, регулирование нагрузки) повышает устойчивость энергосистем, но и задаёт новые стандарты самим ЦОД. Например, Google уже заключает demand response-контракты с энергокомпаниями, согласившись переносить часть вычислений на непиковое время во избежание перегрузок сети
В сумме, инициатива Meta сигнализирует всему ИИ-сектору: эры дешёвого и гарантированного электричества больше нет, и дальнейший прогресс ML/AI тесно увязан с энергетической инфраструктурой. Те, кто сумеют интегрироваться с энергосистемой (через инвестиции или партнерства), получат фору в гонке ИИ, а те, кто проигнорируют - рискуют столкнуться с энергетическим дефицитом, замедляющим их инновации.
#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #AI #Economics
Energy Connects
Meta Pushes Into Power Trading as AI Sends Demand Soaring
Meta Platforms Inc. is moving to break into the wholesale power-trading business to better manage the massive electricity needs of its data centers.
❤6⚡3🔥2
[1/2] Communication Patterns: A Guide for Developers and Architects (Паттерны коммуникации: руководство для ИТ-разработчиков и архитекторов) (Рубрика #Management)
Забавная вышла история у этой книги - я начинал ее читать еще на английском в формате early preview на платформе O'Reilly, а закончил уже в формате книги на русском, которую перевело и выпустило издательство "БХВ". Вообще, книжка мне понравилась - она про успешные коммуникации для инженеров и технических руководителей, которые уже привыкли к использованию шаблонов в проектировании, разработке и оргдизайне. Автор книги - Джеки Рид (Jacqui Read) - архитектор решений (Solution & Enterprise Architect) из Великобритании. Она начинала как full-stack разработчик, а позже перешла в архитектуру и продвигает идею, что коммуникация - это такой же навык, как написание кода, и его можно систематизировать. Вместо советов "будьте понятнее", она предлагает конкретные паттерны (проверенные решения) и антипаттерны (типичные ошибки).
Если говорить про струткру книги, то она разделена на 4 части и 13 глав, которые последовательно закрывают все каналы передачи информации: от визуальных схем до асинхронной работы.
1️⃣ Визуальная коммуникация (Visuals) - здесь разбирается, как создавать диаграммы, которые действительно читают и понимают.
- Глава 1. Основы коммуникации (Communication Essentials). Здесь закладывается фундамент книги: принцип "знай свою аудиторию" и управление уровнями абстракции. Объясняется, почему нельзя смешивать бизнес-контекст и детали реализации на одной схеме.
- Глава 2. Устранение шума (Clarify the Clutter). Здесь автор рассказывает как очистить диаграммы от лишних элементов, которые отвлекают внимание. Рассказывается про борьбу с визуальным мусором для повышения читаемости.
- Глава 3. Доступность (Accessibility). Это важная тема, которую часто упускают: как делать схемы понятными для людей с дальтонизмом или особенностями восприятия (например, не полагаться только на цвет). Интересно, что про это иногда забывают и в потребительских продуктах
- Глава 4. Повествование (Narrative). Диаграмма должна рассказывать историю. Паттерн "Сначала общая картина" (The Big Picture Comes First) учит погружать зрителя в контекст перед тем, как топить его в деталях. Кстати, у меня есть подборка книг про сторителлинг и истории
- Глава 5. Нотация (Notation). Глава о том, как выбирать уровень формальности нотации в зависимости от задачи, и почему легенда к схеме обязательна.
- Глава 6. Композиция (Composition). Принципы визуальной иерархии: как располагать элементы так, чтобы взгляд зрителя скользил по схеме в правильном порядке, считывая логику системы.
2️⃣ Письменная и устная коммуникация (Written, Verbal, and Non-verbal) - переход от картинок к словам и выступлениям.
- Глава 7. Письменная коммуникация (Written Communication). Паттерны для документации и переписки. Как писать лаконично, структурировать технические тексты и избегать "стены текста". Здесь говорится и про пирамиду Минто, о которой я рассказывал раньше.
- Глава 8. Вербальная и невербальная коммуникация (Verbal and Nonverbal Communication). Глава о том, как наши жесты, тон и поза влияют на восприятие технических решений. Как считывать реакцию аудитории во время презентации.
- Глава 9. Риторический треугольник (The Rhetoric Triangle). Адаптация античного принципа Аристотеля (Этос, Патос, Логос) для инженеров. Как балансировать между логикой (фактами), авторитетом и эмоциями для убеждения стейкхолдеров. Подробнее в отдельном посте
Об оставшейся книге я расскажу в продолжении этого поста.
#Thinking #Writing #Leadership #Management #DistributedSystems #Architecture #SoftwareArchitecture #SystemDesign #Software #Writing #Speaking
Забавная вышла история у этой книги - я начинал ее читать еще на английском в формате early preview на платформе O'Reilly, а закончил уже в формате книги на русском, которую перевело и выпустило издательство "БХВ". Вообще, книжка мне понравилась - она про успешные коммуникации для инженеров и технических руководителей, которые уже привыкли к использованию шаблонов в проектировании, разработке и оргдизайне. Автор книги - Джеки Рид (Jacqui Read) - архитектор решений (Solution & Enterprise Architect) из Великобритании. Она начинала как full-stack разработчик, а позже перешла в архитектуру и продвигает идею, что коммуникация - это такой же навык, как написание кода, и его можно систематизировать. Вместо советов "будьте понятнее", она предлагает конкретные паттерны (проверенные решения) и антипаттерны (типичные ошибки).
Если говорить про струткру книги, то она разделена на 4 части и 13 глав, которые последовательно закрывают все каналы передачи информации: от визуальных схем до асинхронной работы.
1️⃣ Визуальная коммуникация (Visuals) - здесь разбирается, как создавать диаграммы, которые действительно читают и понимают.
- Глава 1. Основы коммуникации (Communication Essentials). Здесь закладывается фундамент книги: принцип "знай свою аудиторию" и управление уровнями абстракции. Объясняется, почему нельзя смешивать бизнес-контекст и детали реализации на одной схеме.
- Глава 2. Устранение шума (Clarify the Clutter). Здесь автор рассказывает как очистить диаграммы от лишних элементов, которые отвлекают внимание. Рассказывается про борьбу с визуальным мусором для повышения читаемости.
- Глава 3. Доступность (Accessibility). Это важная тема, которую часто упускают: как делать схемы понятными для людей с дальтонизмом или особенностями восприятия (например, не полагаться только на цвет). Интересно, что про это иногда забывают и в потребительских продуктах
- Глава 4. Повествование (Narrative). Диаграмма должна рассказывать историю. Паттерн "Сначала общая картина" (The Big Picture Comes First) учит погружать зрителя в контекст перед тем, как топить его в деталях. Кстати, у меня есть подборка книг про сторителлинг и истории
- Глава 5. Нотация (Notation). Глава о том, как выбирать уровень формальности нотации в зависимости от задачи, и почему легенда к схеме обязательна.
- Глава 6. Композиция (Composition). Принципы визуальной иерархии: как располагать элементы так, чтобы взгляд зрителя скользил по схеме в правильном порядке, считывая логику системы.
2️⃣ Письменная и устная коммуникация (Written, Verbal, and Non-verbal) - переход от картинок к словам и выступлениям.
- Глава 7. Письменная коммуникация (Written Communication). Паттерны для документации и переписки. Как писать лаконично, структурировать технические тексты и избегать "стены текста". Здесь говорится и про пирамиду Минто, о которой я рассказывал раньше.
- Глава 8. Вербальная и невербальная коммуникация (Verbal and Nonverbal Communication). Глава о том, как наши жесты, тон и поза влияют на восприятие технических решений. Как считывать реакцию аудитории во время презентации.
- Глава 9. Риторический треугольник (The Rhetoric Triangle). Адаптация античного принципа Аристотеля (Этос, Патос, Логос) для инженеров. Как балансировать между логикой (фактами), авторитетом и эмоциями для убеждения стейкхолдеров. Подробнее в отдельном посте
Об оставшейся книге я расскажу в продолжении этого поста.
#Thinking #Writing #Leadership #Management #DistributedSystems #Architecture #SoftwareArchitecture #SystemDesign #Software #Writing #Speaking
❤11👍8🔥6
[2/2] Communication Patterns: A Guide for Developers and Architects (Паттерны коммуникации: руководство для ИТ-разработчиков и архитекторов) (Рубрика #Management)
Продолжая рассказ о паттернах коммуникации, расскажу про вторую половину книги, в которой речь идет про передачу знаний и эффективную удаленную работу.
3️⃣ Передача знаний (Communicating Knowledge) - как управлять знаниями в команде и организации.
- Глава 10. Принципы управления знаниями (Knowledge Management Principles). Разница между данными, информацией и знаниями. Почему wiki-системы превращаются в свалку и как этого избежать.
- Глава 11. Знания и люди (Knowledge and People). Как люди усваивают информацию и почему "шаринг знаний" часто не работает. Психология обучения взрослых применительно к инженерным командам.
- Глава 12. Эффективные практики (Effective Practices). Конкретные инструменты: от ведения ADR (Architectural Decision Records) до проведения воркшопов и сессий совместного моделирования.
4️⃣ Удаленная работа (Remote Communication) - специфика общения в распределенных командах.
- Глава 13. Фактор времени при удаленной работе (Remote Time). Паттерны для асинхронной коммуникации и работы в разных часовых поясах. Как сохранить контекст и темп работы, когда команда разбросана по миру.
- Глава 14. Принципы дистанционного общения (Remote Principles). Здесь речь про создание четких коммуникационных каналов, протоколов, а также про адаптацию стиля общения в зависимости от нужд команды. На эту тему есть хорошая книга "Remote Team Interactions Workbook" (о которой я уже рассказывал) от авторов книги "Team Topologoies".
- Глава 15. Методы дистанционного общения (Remote Channels). Здесь автор рассказывает про установление культуры открытой и честной обратной связи, а также использование технологий для улучшения коммуникации и поддержания связи между членами команды. Кстати, про открытую и честную обратную связь можно почитать в книге "Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity", о которой я уже рассказывал.
#Thinking #Writing #Leadership #Management #DistributedSystems #Architecture #SoftwareArchitecture #SystemDesign #Software #Writing #Speaking
Продолжая рассказ о паттернах коммуникации, расскажу про вторую половину книги, в которой речь идет про передачу знаний и эффективную удаленную работу.
3️⃣ Передача знаний (Communicating Knowledge) - как управлять знаниями в команде и организации.
- Глава 10. Принципы управления знаниями (Knowledge Management Principles). Разница между данными, информацией и знаниями. Почему wiki-системы превращаются в свалку и как этого избежать.
- Глава 11. Знания и люди (Knowledge and People). Как люди усваивают информацию и почему "шаринг знаний" часто не работает. Психология обучения взрослых применительно к инженерным командам.
- Глава 12. Эффективные практики (Effective Practices). Конкретные инструменты: от ведения ADR (Architectural Decision Records) до проведения воркшопов и сессий совместного моделирования.
4️⃣ Удаленная работа (Remote Communication) - специфика общения в распределенных командах.
- Глава 13. Фактор времени при удаленной работе (Remote Time). Паттерны для асинхронной коммуникации и работы в разных часовых поясах. Как сохранить контекст и темп работы, когда команда разбросана по миру.
- Глава 14. Принципы дистанционного общения (Remote Principles). Здесь речь про создание четких коммуникационных каналов, протоколов, а также про адаптацию стиля общения в зависимости от нужд команды. На эту тему есть хорошая книга "Remote Team Interactions Workbook" (о которой я уже рассказывал) от авторов книги "Team Topologoies".
- Глава 15. Методы дистанционного общения (Remote Channels). Здесь автор рассказывает про установление культуры открытой и честной обратной связи, а также использование технологий для улучшения коммуникации и поддержания связи между членами команды. Кстати, про открытую и честную обратную связь можно почитать в книге "Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity", о которой я уже рассказывал.
#Thinking #Writing #Leadership #Management #DistributedSystems #Architecture #SoftwareArchitecture #SystemDesign #Software #Writing #Speaking
Telegram
Книжный куб
[1/2] Communication Patterns: A Guide for Developers and Architects (Паттерны коммуникации: руководство для ИТ-разработчиков и архитекторов) (Рубрика #Management)
Забавная вышла история у этой книги - я начинал ее читать еще на английском в формате early…
Забавная вышла история у этой книги - я начинал ее читать еще на английском в формате early…
👍8❤5🔥2
AI-инженерия. Построение приложений с использованием базовых моделей (AI Engineering) (Рубрика #AI)
Книгу "AI Engineering" уже перевели и скоро выпустят в издательстве Питер. А я эту книгу прочитал на английском еще в начале года и она мне супер зашла (мы ее вместе с Женей Сергеевым из Flo почти целиком разобрали за три серии подкаста: 1, 2 и 3). Собственно, книга отлична подходит инженерам, что строят GenAI‑продукт прямо сейчас, например, чат‑бот, copilot, RAG, ...
Книгу написала Chip Huyen, которая
- Преподавала Machine Learning Systems Design в Stanford (CS329S), а значит умеет объяснять системно и доступно
- Написала книгу "Designing Machine Learning Systems" (O’Reilly), которую многие считают must‑read для инженеров из ML/Platform команд
- Работала на стыке AI + инфраструктуры (NVIDIA, Snorkel AI), сейчас - Voltron Data (GPU‑ускорение аналитики)
Есть несколько факторов почему "AI Engineering" стала бестселлером
1. Попала в боль 2024–2025: команды массово интегрируют базовые модели, и нужен инженерный фреймворк, а не очередной набор промптов
2. Большой фокус был на evaluation: не “vibe check”, а измеримые метрики, регрессионные наборы, LLM‑as‑a‑judge, тестирование на деградации
3. Закрывает прод‑реальность: стоимость и латентность инференса, мониторинг, качество данных/фидбек‑лупы, безопасность и риск‑менеджмент
4. Даёт карту паттернов (prompting, RAG, fine‑tuning, tools/function calling, agents) и отвечает на главный вопрос: когда что выбирать
5. У книги есть публичные материалы/ресурсы (репо на 12.5к звездочек), поэтому вокруг неё быстро выросла “экосистема” практик
Вот чем может быть полезна эта книга инженерам, которые уже пилят GenAI
- Превращает "демку на фреймворке" в проект: требования → архитектура → eval harness → релиз → наблюдаемость
- Помогает говорить на одном языке с Product/Platform: какие SLO/SLI у LLM‑фичи, что логируем, где делаем гейтинг качества, как считаем cost‑per‑request
- Хороша для техлидов: много про компромиссы (качество vs цена, контекст vs retrieval, детерминизм vs креативность) и про то, где чаще всего “ломается” система
Мини‑чеклист из книги, который можно использовать хоть завтра:
- Golden кейсы + негативные кейсы (и регулярные регрессионные eval’ы)
- Версионирование промптов/моделей/ретривера + логирование контекста
- Метрика "стоимость ответа" + бюджет на фичу
- Eval гейты в CI перед деплоем (как unit/integration, только для LLM)
В общем, книга определенно заслуживает прочтения. Кстати: пока книга еще в предзаказе на нее действует скидка в 35% при использовании промокода "Предзаказ"
#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems
Книгу "AI Engineering" уже перевели и скоро выпустят в издательстве Питер. А я эту книгу прочитал на английском еще в начале года и она мне супер зашла (мы ее вместе с Женей Сергеевым из Flo почти целиком разобрали за три серии подкаста: 1, 2 и 3). Собственно, книга отлична подходит инженерам, что строят GenAI‑продукт прямо сейчас, например, чат‑бот, copilot, RAG, ...
Книгу написала Chip Huyen, которая
- Преподавала Machine Learning Systems Design в Stanford (CS329S), а значит умеет объяснять системно и доступно
- Написала книгу "Designing Machine Learning Systems" (O’Reilly), которую многие считают must‑read для инженеров из ML/Platform команд
- Работала на стыке AI + инфраструктуры (NVIDIA, Snorkel AI), сейчас - Voltron Data (GPU‑ускорение аналитики)
Есть несколько факторов почему "AI Engineering" стала бестселлером
1. Попала в боль 2024–2025: команды массово интегрируют базовые модели, и нужен инженерный фреймворк, а не очередной набор промптов
2. Большой фокус был на evaluation: не “vibe check”, а измеримые метрики, регрессионные наборы, LLM‑as‑a‑judge, тестирование на деградации
3. Закрывает прод‑реальность: стоимость и латентность инференса, мониторинг, качество данных/фидбек‑лупы, безопасность и риск‑менеджмент
4. Даёт карту паттернов (prompting, RAG, fine‑tuning, tools/function calling, agents) и отвечает на главный вопрос: когда что выбирать
5. У книги есть публичные материалы/ресурсы (репо на 12.5к звездочек), поэтому вокруг неё быстро выросла “экосистема” практик
Вот чем может быть полезна эта книга инженерам, которые уже пилят GenAI
- Превращает "демку на фреймворке" в проект: требования → архитектура → eval harness → релиз → наблюдаемость
- Помогает говорить на одном языке с Product/Platform: какие SLO/SLI у LLM‑фичи, что логируем, где делаем гейтинг качества, как считаем cost‑per‑request
- Хороша для техлидов: много про компромиссы (качество vs цена, контекст vs retrieval, детерминизм vs креативность) и про то, где чаще всего “ломается” система
Мини‑чеклист из книги, который можно использовать хоть завтра:
- Golden кейсы + негативные кейсы (и регулярные регрессионные eval’ы)
- Версионирование промптов/моделей/ретривера + логирование контекста
- Метрика "стоимость ответа" + бюджет на фичу
- Eval гейты в CI перед деплоем (как unit/integration, только для LLM)
В общем, книга определенно заслуживает прочтения. Кстати: пока книга еще в предзаказе на нее действует скидка в 35% при использовании промокода "Предзаказ"
#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems
www.piter.com
AI-инженерия. Построение приложений с использованием базовых моделей
Новая книга бестового автора Чип Хьюен по AI-инженерии.
🔥18❤8⚡5
Amp Code: Next generation AI Coding (Рубрика #AI)
Посмотрел интересный доклад Beyang Liu, CTO Sourcegraph, о новом редакторе Amp Code, в котором автор говорит о том, что это не просто "еще один Copilot", а попытка фундаментально изменить то, как мы взаимодействуем с AI в разработке. Если коротко: по мнению автора мы переходим от фазы "AI пишет текст" к фазе "AI замыкает цикл разработки". Сам Beyang Liu закончил Стэнфорд, а также успел поработать в Palantir и Google. Известен как создатель Sourcegraph (движок поиска по коду) и Cody (один из первых AI-ассистентов с контекстом кодовой базы). Он верит, что главное в AI-кодинге - это не генерация токенов, а доступ к графу знаний кода и runtime-окружению.
Основные тезисы доклада следующие
1️⃣ Смерть "Copilot-парадигмы"
Традиционные AI-ассистенты (GitHub Copilot, ранний Cody) работают как "умный автокомплит". Они предсказывают следующий токен, но не знают, работает ли этот код. Beyang называет это "Fire and Forget": AI выдал код, а разгребать ошибки компиляции - тебе.
2️⃣ Agentic Loop
Amp Code строит работу вокруг цикла OODA (Observe-Orient-Decide-Act)
- AI пишет код
- Сам запускает линтер/компилятор/тесты
- Видит ошибку (например,
- Исправляет её без участия человека.
- Повторяет, пока не заработает.
3️⃣ Контекст - это не только текст
Просто засунуть 100 файлов в контекстное окно (даже на 1M токенов) - недостаточно. Amp использует LSP (Language Server Protocol) и реальные данные из runtime, чтобы понимать структуру проекта так же, как её понимает IDE, а не просто как набор символов.
4️⃣ Режим "Review Agent"
В Amp встроен отдельный агент-ревьюер. Перед тем как применить изменения, он проводит Code Review: ищет баги, проверяет стиль и безопасность, имитируя процесс PR-ревью в команде.
🚀 Что это значит для разработки?
- Сдвиг скиллсета: От "быстрого набора кода" мы переходим к управлению агентами. Ваша задача - четко сформулировать намерение (Intent) и архитектуру, а реализацию (Implementation) и отладку берет на себя тул.
- Меньше Context Switching: Вам не нужно переключаться между редактором и терминалом, чтобы проверить, работает ли код, который выдал AI. Агент делает это фоном.
- Unix-way: Beyang подчеркивает, что Amp доступен и как VS Code extension, и как CLI-инструмент. Это возвращение к корням: мощные инструменты, которые можно скриптовать и встраивать в пайплайны.
В докладе и документации Amp, Beyang опирается на следующие концепции и материалы:
1. Agentic Workflows & Scaling Laws
Автор ссылается на то, что качество кода растет не линейно от размера модели, а скачкообразно при использовании agentic loops. Это подтверждается результатами бенчмарка SWE-bench, где агенты, умеющие запускать код, радикально обходят простые LLM. Подробнее про концепцию можно почитать у Andrew Ng
2. Sourcegraph’s "Big Code" Intelligence
База Amp - это технологии анализа графа кода (SCIP), которые Sourcegraph разрабатывает годами.
3. LSP как источник истины
Тезис о том, что LLM нужны структурированные данные от компилятора, а не просто текст. Это отсылка к Language Server Protocol, был разработан компанией Microsoft для своего редактора кода VS Code, но стал открытым стандартом и теперь активно развивается совместно с Red Hat и Codenvy, а сам проект размещен на GitHub, что позволяет использовать его в разных редакторах и для множества языков программировани
#AI #Software #Engineering #Architecture #Agents #ML #SystemDesign
Посмотрел интересный доклад Beyang Liu, CTO Sourcegraph, о новом редакторе Amp Code, в котором автор говорит о том, что это не просто "еще один Copilot", а попытка фундаментально изменить то, как мы взаимодействуем с AI в разработке. Если коротко: по мнению автора мы переходим от фазы "AI пишет текст" к фазе "AI замыкает цикл разработки". Сам Beyang Liu закончил Стэнфорд, а также успел поработать в Palantir и Google. Известен как создатель Sourcegraph (движок поиска по коду) и Cody (один из первых AI-ассистентов с контекстом кодовой базы). Он верит, что главное в AI-кодинге - это не генерация токенов, а доступ к графу знаний кода и runtime-окружению.
Основные тезисы доклада следующие
1️⃣ Смерть "Copilot-парадигмы"
Традиционные AI-ассистенты (GitHub Copilot, ранний Cody) работают как "умный автокомплит". Они предсказывают следующий токен, но не знают, работает ли этот код. Beyang называет это "Fire and Forget": AI выдал код, а разгребать ошибки компиляции - тебе.
2️⃣ Agentic Loop
Amp Code строит работу вокруг цикла OODA (Observe-Orient-Decide-Act)
- AI пишет код
- Сам запускает линтер/компилятор/тесты
- Видит ошибку (например,
TypeError)- Исправляет её без участия человека.
- Повторяет, пока не заработает.
3️⃣ Контекст - это не только текст
Просто засунуть 100 файлов в контекстное окно (даже на 1M токенов) - недостаточно. Amp использует LSP (Language Server Protocol) и реальные данные из runtime, чтобы понимать структуру проекта так же, как её понимает IDE, а не просто как набор символов.
4️⃣ Режим "Review Agent"
В Amp встроен отдельный агент-ревьюер. Перед тем как применить изменения, он проводит Code Review: ищет баги, проверяет стиль и безопасность, имитируя процесс PR-ревью в команде.
- Сдвиг скиллсета: От "быстрого набора кода" мы переходим к управлению агентами. Ваша задача - четко сформулировать намерение (Intent) и архитектуру, а реализацию (Implementation) и отладку берет на себя тул.
- Меньше Context Switching: Вам не нужно переключаться между редактором и терминалом, чтобы проверить, работает ли код, который выдал AI. Агент делает это фоном.
- Unix-way: Beyang подчеркивает, что Amp доступен и как VS Code extension, и как CLI-инструмент. Это возвращение к корням: мощные инструменты, которые можно скриптовать и встраивать в пайплайны.
В докладе и документации Amp, Beyang опирается на следующие концепции и материалы:
1. Agentic Workflows & Scaling Laws
Автор ссылается на то, что качество кода растет не линейно от размера модели, а скачкообразно при использовании agentic loops. Это подтверждается результатами бенчмарка SWE-bench, где агенты, умеющие запускать код, радикально обходят простые LLM. Подробнее про концепцию можно почитать у Andrew Ng
2. Sourcegraph’s "Big Code" Intelligence
База Amp - это технологии анализа графа кода (SCIP), которые Sourcegraph разрабатывает годами.
3. LSP как источник истины
Тезис о том, что LLM нужны структурированные данные от компилятора, а не просто текст. Это отсылка к Language Server Protocol, был разработан компанией Microsoft для своего редактора кода VS Code, но стал открытым стандартом и теперь активно развивается совместно с Red Hat и Codenvy, а сам проект размещен на GitHub, что позволяет использовать его в разных редакторах и для множества языков программировани
#AI #Software #Engineering #Architecture #Agents #ML #SystemDesign
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Amp Code: Next Generation AI Coding – Beyang Liu, Amp Code
Introduction to Amp Code and its approach to AI-powered software development.
Speaker: Beyang Liu | Co-founder & CTO, Amp Code
https://x.com/beyang
https://www.linkedin.com/in/beyang-liu/
https://github.com/beyang
Timestamps:
00:00 Introduction & The…
Speaker: Beyang Liu | Co-founder & CTO, Amp Code
https://x.com/beyang
https://www.linkedin.com/in/beyang-liu/
https://github.com/beyang
Timestamps:
00:00 Introduction & The…
1❤9🔥5⚡3😁1
RepoSwarm - Giving AI Agents Architecture Context Across All Your Repos (Рубрика #Architecture)
Интересный доклад про восстановление архитектурного контекста при помощи AI агентов от Roy Osherove, Chief AI Architect в Verbit AI (компания с ~90 разработчиками, 12 командами и 400+ репозиториями). Интересно, что Roy написал три книги: The Art of Unit Testing, Elastic Leadership, Pipeline Driven (пока в разработке, но про его доклад с таким названием я уже рассказывал). У Роя есть и интересный блог robotpaper.ai, где он документирует AI-паттерны для разработчиков. Из интересного - его книги попали в обучающие датасеты LLM, поэтому промпт "review my tests in Roy Osherove style" работает из коробки в Cursor:)
Если же говорить про основные тезисы доклада изложены ниже
Документация в enterprise - проигрышная битва
В компаниях с 400+ репозиториями реальность такова
- 90% README-файлов устаревшие или неполные
- Архитектурные диаграммы существуют как кот Шредингера (пока не посмотришь не знаешь они еще живы или уже нет)
- Критические вопросы требуют недель ручного анализа: "что за инструменты мониторинга используются", "где хранятся определенные данные", "кто пользуется устаревшими API "
Не только люди страдают от такого качества документации - AI-агенты страдают тоже, так как им нужен контекст для правильных решений (какой UI-компонент использовать, как вызывать внутренний сервис).
Автор доклада в качестве решения создал RepoSwarm, живой архитектурный репозиторий, который доступен в виде open source. Он работает примерно следующим образом
1. Ежедневно сканирует GitHub-репозитории (приватные/публичные) с коммитами за последние 12 месяцев (это настраивается)
2. Генерирует markdown-документацию (один repo.md на репозиторий) через Claude Code SDK
3. Сохраняет в централизованный Architecture Hub — Git-репозиторий с полной историей изменений
4. Никогда не устаревает: при новом прогоне файлы полностью перезатираются (нет никакой backward compatibility)
Ключевое отличие от статической документации в том, что документы сделаны AI-readable (markdown) и у нас есть git-история
Если говорить про то, что автор решил добавить в repo.md, то это такой список инфомрации
- Базовая информация - High-level overview, Dependencies (package.json/requirements.txt), Security checks (top 10 OWASP), Monitoring tools
- Данные и API - Database schemas, API versioning, Events/messaging (pub/sub), Data mapping (GDPR/HIPAA flows)
- Инфраструктура - CI/CD deployment, Authentication/Authorization, Feature flags, ML/LLM usage (Gemini/Claude endpoints)
- Специализированные - Prompt security (injection checks), Mobile UI patterns (для repo_type: mobile), IaC analysis (для Terraform/K8s)
В каких реальных кейсах этот инструмент использовался автором
1. Cross-repo анализ - ответы на вопрос вида "какие monitoring tools используются?"
2. Large-scale migrations - обновление Python, консолидация API gateways (переход на Kong), deprecation внутреннего сервиса (поиск всех зависимостей)
3. Архитектурная история - генерация ретроспективно ADR с ответом на вопросы вида "why we moved to serverless in Q2 2024"
4. AI-агентам как контекст - использование Architecture Hub в Cursor → автоконтекст для features/bugs
Что использование значит для разработки
1. Смещение роли архитектора - от ручной работы к построению и использованию таких инструментов
2. Новый workflow для compliance - проще выстроить соответствие внешним требованиям
3. Эволюция AI-агентов - улучшениие AI-assisted разработки за счет интеграции архитектурной информации в контекст агентов
4. Следование философии "живой документации" - генерация ее из кода и гарантированный freshness
#DevOps #AI #Architecture #Culture #Engineering #ML #Future #Software #SystemDesign
Интересный доклад про восстановление архитектурного контекста при помощи AI агентов от Roy Osherove, Chief AI Architect в Verbit AI (компания с ~90 разработчиками, 12 командами и 400+ репозиториями). Интересно, что Roy написал три книги: The Art of Unit Testing, Elastic Leadership, Pipeline Driven (пока в разработке, но про его доклад с таким названием я уже рассказывал). У Роя есть и интересный блог robotpaper.ai, где он документирует AI-паттерны для разработчиков. Из интересного - его книги попали в обучающие датасеты LLM, поэтому промпт "review my tests in Roy Osherove style" работает из коробки в Cursor:)
Если же говорить про основные тезисы доклада изложены ниже
Документация в enterprise - проигрышная битва
В компаниях с 400+ репозиториями реальность такова
- 90% README-файлов устаревшие или неполные
- Архитектурные диаграммы существуют как кот Шредингера (пока не посмотришь не знаешь они еще живы или уже нет)
- Критические вопросы требуют недель ручного анализа: "что за инструменты мониторинга используются", "где хранятся определенные данные", "кто пользуется устаревшими API "
Не только люди страдают от такого качества документации - AI-агенты страдают тоже, так как им нужен контекст для правильных решений (какой UI-компонент использовать, как вызывать внутренний сервис).
Автор доклада в качестве решения создал RepoSwarm, живой архитектурный репозиторий, который доступен в виде open source. Он работает примерно следующим образом
1. Ежедневно сканирует GitHub-репозитории (приватные/публичные) с коммитами за последние 12 месяцев (это настраивается)
2. Генерирует markdown-документацию (один repo.md на репозиторий) через Claude Code SDK
3. Сохраняет в централизованный Architecture Hub — Git-репозиторий с полной историей изменений
4. Никогда не устаревает: при новом прогоне файлы полностью перезатираются (нет никакой backward compatibility)
Ключевое отличие от статической документации в том, что документы сделаны AI-readable (markdown) и у нас есть git-история
Если говорить про то, что автор решил добавить в repo.md, то это такой список инфомрации
- Базовая информация - High-level overview, Dependencies (package.json/requirements.txt), Security checks (top 10 OWASP), Monitoring tools
- Данные и API - Database schemas, API versioning, Events/messaging (pub/sub), Data mapping (GDPR/HIPAA flows)
- Инфраструктура - CI/CD deployment, Authentication/Authorization, Feature flags, ML/LLM usage (Gemini/Claude endpoints)
- Специализированные - Prompt security (injection checks), Mobile UI patterns (для repo_type: mobile), IaC analysis (для Terraform/K8s)
В каких реальных кейсах этот инструмент использовался автором
1. Cross-repo анализ - ответы на вопрос вида "какие monitoring tools используются?"
2. Large-scale migrations - обновление Python, консолидация API gateways (переход на Kong), deprecation внутреннего сервиса (поиск всех зависимостей)
3. Архитектурная история - генерация ретроспективно ADR с ответом на вопросы вида "why we moved to serverless in Q2 2024"
4. AI-агентам как контекст - использование Architecture Hub в Cursor → автоконтекст для features/bugs
Что использование значит для разработки
1. Смещение роли архитектора - от ручной работы к построению и использованию таких инструментов
2. Новый workflow для compliance - проще выстроить соответствие внешним требованиям
3. Эволюция AI-агентов - улучшениие AI-assisted разработки за счет интеграции архитектурной информации в контекст агентов
4. Следование философии "живой документации" - генерация ее из кода и гарантированный freshness
#DevOps #AI #Architecture #Culture #Engineering #ML #Future #Software #SystemDesign
YouTube
RepoSwarm - Giving AI Agents Architecture Context Across All Your Repos - Roy Osherove
more info at https://robotpaper.ai by Roy Osherove.
This talk explores RepoSwarm, an AI-first developer tool for giving LLM-powered coding agents deep, accurate context across large multi-repository codebases. Instead of relying on stale READMEs or static…
This talk explores RepoSwarm, an AI-first developer tool for giving LLM-powered coding agents deep, accurate context across large multi-repository codebases. Instead of relying on stale READMEs or static…
🔥8❤6👍4☃1🎄1
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,…
👍15❤6🔥3