[1/2] Google открыл A2UI - протокол, который позволяет агентам “говорить UI”, а не только текстом (Рубрика #AI)

15 декабря 2025 команда A2UI в Google публично выложила проект A2UI (Agent-to-User Interface) - открытый формат + библиотеки рендеринга, чтобы “удалённые” AI‑агенты могли возвращать сложные интерфейсы (формы, карточки, списки, кнопки) как данные, а не как исполняемый код. Этот протокол призван решить проблему текстовых чатов, когда простые пользовательские действия (забронировать столик, заполнить поля, выбрать время) превращаются в долгую переписку “вопрос‑ответ‑уточнение”. A2UI предлагает вместо этого дать агенту возможность сгенерировать контекстную форму/карточку из каталога компонентов и отрисовать её в вашем приложении. Сам протокол доступен на GitHub.

По сути это работает примерно следующим образом - агент генерирует декларативное описание UI в JSON, клиент рендерит это нативными компонентами своего приложения.
Ключевые принципы (сформулированы в README проекта):
- Security‑first: агент не присылает JS/HTML/код. Он присылает данные, которые проходят валидацию, а UI строится из каталога заранее разрешённых компонентов (Button/Card/TextField/и т.д.). Это снижает риск UI‑инъекций и “случайного RCE через UI”
- LLM‑friendly + инкрементальные апдейты: UI описывается “плоской” структурой (adjacency list) с ID‑ссылками, поэтому агент может стримить интерфейс и патчить отдельные компоненты по ID, не пересылая всё дерево
- Framework‑agnostic: один и тот же A2UI‑пейлоад может быть отрендерен в разных клиентах (web/mobile/desktop) — потому что “как рисовать” решает клиент
- Transport‑agnostic: A2UI - это формат/контракт сообщений, его можно гонять поверх разных “транспортов” (включая A2A и AG‑UI)

На практике (в версии v0.8, stable/public preview) сообщения обычно идут как JSON Lines (JSONL): одна строка = одно сообщение. Есть 4 ключевых типа:
- beginRendering
- surfaceUpdate
- dataModelUpdate
- deleteSurface
Сам стрим может выглядеть примерно так

{"surfaceUpdate": {"surfaceId":"main","components":[ ... ]}}
{"dataModelUpdate": {"surfaceId":"main","contents":[ ... ]}}
{"beginRendering": {"surfaceId":"main","root":"root-component"}}

Но надо отметить, что спека все еще дорабатывается и между v0.8 (stable) и v0.9 (draft) уже есть изменения в деталях и даже названиях envelope‑сообщений

Теперь давайте обсудим, а почему этот протокол нам интересен и чем он лучше альтернатив.
1. Одной из альтернатив является генерация HTML/JS/React‑кода агентом.
Здесь у нас есть проблема с безопасностью и контролем - вам либо нужно исполнять непроверенный код, либо городить тяжёлую песочницу. В A2UI у нас вместо кода данные, а рендеринг идет только из доверенного каталога компонентов.
2. Другой алтернативой являются iframe‑подходы / “UI как ресурс” (например, MCP Apps)
В статье Google прямо сравнивает A2UI с MCP Apps: там UI часто приходит как “opaque payload” (например HTML) и рендерится в sandboxed iframe. Но A2UI выгодно отличается “native‑first” подходом: агент отправляет blueprint нативных компонентов, и UI наследует стиль/дизайн‑систему/доступность хост‑приложения, вместо отдельного “мини‑веба в iframe”.
3. Платформенные end2end экосистемы (например, OpenAI ChatKit)
Плюс таких решений - интеграция в рамках одной платформы. Минус - переносимость и работа в мульти‑агентных сценариях с разными вендорами. A2UI целится в переносимый UI‑контракт для ваших собственных клиентов и enterprise‑mesh сценариев.
4. Просто возьмём AG‑UI и хватит
AG‑UI решает вопросы интеграция агента и UI), а A2UI - описывает сам формат UI‑ответа. Google явно позиционирует A2UI как комплементарный слой: подключили хост через AG‑UI → можете использовать A2UI как формат для UI‑ответов, в том числе от внешних агентов

Продолжение о том, а почему этот проект так интересен в посте-продолжении.

#Engineering #AI #Agents #Software #Architecture #RnD #ML #DistributedSystems

[2/2] Google открыл A2UI - протокол, который позволяет агентам “говорить UI”, а не только текстом (Рубрика #AI)

В продолжении обсуждения протокола A2UI от Google мы рассмотрим, а почему он может быть интересен создателям genAI приложений для пользователей.

Если смотреть на публичные сигналы, проект реально подхватили:
1. GitHub traction. За полтора месяца проект набрал 10.9k звезд, 810 forks, 66 issues, 80 PR, 332 commits, 31 contributor в основном репозитории
2. Официальные туториалы Google. В документации для Google Workspace появился quickstart “Build a Google Chat app with an Agent2UI agent” (обновлён 2026‑01‑27), с развёртыванием агента через ADK и хостингом в Vertex AI Agent Engine. Это хороший индикатор, что A2UI продвигают как практический способ строить UI‑ответы агентов внутри Workspace/Chat‑сценариев.
3. Экосистема вокруг. Появляются сторонние реализации/порты:
- a2ui-rails - порт в Ruby/Rails
- A2UI-for-Google-Apps-Script - демо/адаптация под Apps Script/Workspace
- Отдельные упоминания и интеграционные запросы в других agent‑framework репозиториях тоже всплывают (feature requests/discussions)

И отдельно: сам проект помечен как Early stage public preview (v0.8), при этом параллельно ведётся v0.9 (draft) - то есть активная фаза “формат шлифуется”.

Отдельно надо подсветить почему это должно быть инженерам
- Нормальный контракт между “мозгом” и UI: агент не “рисует DOM”, а отправляет декларативные апдейты, которые ваш клиент валидирует и рендерит. Это лучше ложится на архитектуру “удалённый агент / недоверенная граница”
- Инкрементальность и патчи: можно стримить UI и менять только нужные куски по ID, вместо “перерисовать всё”
- Переиспользование дизайн‑системы: UI остаётся нативным (ваши компоненты/темизация/а11y), а агент лишь “просит” собрать композицию
- Прагматичная интеграция: есть референсные рендереры (Lit/Angular/Flutter), есть понятный quickstart с демо‑агентом

Для техлидов и engineering менеджеров это может быть интересно по другим причинам
- Скорость поставки фич: вместо того чтобы каждый раз вручную проектировать “формочку под новый workflow”, часть UX можно делегировать агенту, но в рамках жёсткого каталога компонентов и правил
- Управляемый риск: “данные вместо кода” = проще проходить security review, проще ограничивать поверхность атаки, проще объяснять границы доверия между командами/вендорами
- Стандартизация для мульти‑агентных сценариев: когда разные агенты/под‑агенты (внутренние и внешние) должны отдавать UI в единый клиент, формат уровня A2UI снижает интеграционный ад
- Сигналы зрелости: быстрорастущий репозиторий + официальный quickstart в Google Workspace доках + параллельная работа над спецификацией (v0.8 stable / v0.9 draft) — это похоже на проект, который реально хотят “довести до v1”

Если вы сейчас строите agentic‑продукт и упираетесь в “чат вместо продукта”, A2UI выглядит как очень практичный способ превратить ответы агента в управляемые, нативные, безопасные UI‑сессии - и при этом не завязаться на один конкретный фронтенд‑стек.

#Engineering #AI #Agents #Software #Architecture #RnD #ML #DistributedSystems

[2/2] Нейросети захватили соцсети: как казахстанский стартап взорвал все AI-тренды и стал единорогом (Рубрика #AI)

В продолжении разбора интервью расскажу о том, как ребята обеспечивают такой стремительный рост аудитории своего приложения, а также как они работают с моделями для генерации видео.

3️⃣ Просюмерская модель (B2B SaaS 2.0)
Просюмер = professional + consumer. И именно это аудитория компании
- 60% аудитории Higgsfield — профессионалы (графдизайнеры, SMM-менеджеры, операторы)
- Они используют продукт в работе, но покупают сами (не через enterprise-договоры)
Почему это важно:
- Individual adoption быстрее, чем enterprise (бизнесы более инерционные)
- Просюмеры становятся evangelists → word-of-mouth → viral
- Примеры: Cursor (developers), Gamma (презентации), Lovable (vibe-coding)
Бизнес-модель:
- $9/мес (для фана) + $100/мес (профессионалы)
- Подписки + токены (как в LLM)

4️⃣ Органический рост без перформанс-маркетинга
"60% трафика - органика. Люди просто где-то узнали и вбили 'Higgsfield' в поиск". Если говорить точнее, то есть следующие каналы
Каналы:
- Viral-тренды в TikTok/Instagram/YouTube
- Сеть инфлюенсеров/креаторов (постят туториалы)
- Топовые футбольные клубы Европы, звёзды
Почему VC любят:
- Не сжигаешь деньги на рекламу → defensibility сильнее
- Organic = сарафанное радио → доказательство product-market fit

5️⃣ Прокси моделей: как конкурировать с Google/Meta
Стратегия Higgsfield:
- Используют модели Google (Veo3), Kling (китайская), другие по API
- Делают собственные модели (Soul - "самая эстетичная image gen")
- Упаковывают модели для просюмеров (click-to-video, templates, camera control)
Результат:
- Google, Kling, другие борются, кто первым зарелизит модель на Higgsfield
- Higgsfield контролирует distribution → leverage в переговорах с гигантами
Lesson learned:
- В AI дистрибуция > технологий
- Если у тебя сильные каналы, foundation model providers будут с тобой работать

Если подбить итоги, то однострочные выводы для создателей продуктов такие
1. Speed wins в AI. Если твой цикл итераций дольше 2-4 недель, ты проиграешь
2. Не изобретай велосипед - используй foundation models по API, добавляй value через UX/workflow
3. Просюмеры > enterprise на ранних стадиях. Individual users быстрее adopt и становятся evangelists
4. GitHub = твой second resume, особенно если ты junior или без CS-degree
5. Креативность + Engineering = дифференциация. Не просто нанимай ML-инженеров, найди domain experts

#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture

Update по System Design Space (Рубрика #Engineering)

Я запустил этот сайт чуть больше недели назад и продолжил его активно дорабатывать и решил поделиться lessons learned.
- Дорабатывать сайт ипользуя только Lovable дорого - кредиты улетают как не в себя - я прошел такой путь за месячную подписку всего за полтора месяца 0$ -> 25$ -> 50$ -> 100$ -> 200$
- Как второй и основной помощник я сейчас использую OpenAI Codex, где подписки в 200$ хватает как на веб, deep research, так и на написание кода (сразу для целой пачки ресурсов)
- Я добавил очень много новых глав + отдельный раздел, что посвящен документальным фильмам про технологии
- Для сложных тем я сделал визуализации архитектуры и процесса работы - смотрите примеры из части с кейсами
- Я добавил светлую тему, оглавление, поменял верстку под мобилу и еще кучу всего
- Сайт успел за неделю полежать пару раз. Один раз мы с Codex оптимизировали сборку и lazy загрузку React, что локально все работало, а на внешнем хостинге нет - пришлось откатить эту оптимизацию. Второй раз была проблема с DNS - я забыл подтвердить email регистратору доменных имен и дальше делегирование сайта было преостановлено (дальше прожал кнопочку подтверждения из email и буквально всего через 2 часа все вернулось, а могло и через 2 дня)
- Как-то я попросил отрефакторить проект и агент ушел локально колбасить что-то на всю ночь - утром пришел проверил, сделал несколько фиксов и все полетело
- Тесты у меня есть, но из-за того, что я часто меняю внешний вид сайта, то я часто их просто заново гененрирую, а не прогоняю для проверки (главы - это отдельные ts файлы, поэтому изменения обычно хорошо локализованы и дают мало внешних эффектов)
- Я занимаюсь этим по выходным, а также по вечерам после работы и это затягивает - иногда в 2 часа ночи ловлю себя на мысли, что надо выдать задачку помасштабнее и наконец-то пойти спать:)

А если в целом, то мне давно не было так интересно заниматься разработкой софта в качестве хобби после работы - раньше мешало отсутствие времени, а теперь с новыми инструментами мешает только отсутствие идей ... А если идеи у вас есть, то возьмите и попробуйте новые инструменты и может быть вам это понравится.

#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software

[1/2] Achieving Productivity Gains with AI-based IDE features: A Journey at Google∗ (Рубрика #Whitepaper)

Прочитал ночью свежую статью (27 января 2026 года) от Google про их опыт к внедрению двух AI-функций в своей внутренней IDE: стандартного code completion и более интересной трансформации кода (где выделяешь код и дальше пишешь промпт о том, как поменять). Эти фичи были призваны ускорить работу разработчиков, но по пути инженерам пришлось решить проблемы с задержкой, UX и качеством подсказок, опираясь на эксперименты и данные. По-факту, ребята посмотрели на процесс продуктово - построили воронку и оценили потери на каждом шаге из-за разных факторов: неуверенности модели, задержек, нерелевантных рекомендаций или низкого вовлечения пользователей. Это позволило системно бороться с этими факторами, понимая на какие из них стоит сделать больший упор.

Дальше рассмотрим оба сценария

1️⃣ AI-автодополнение кода
В основе автодополнения - трансформер, обученный предсказывать код сразу за курсором (fill-in-the-middle), причем модель дообучена на реальных историях правок Google-разработчиков (приближая ее к живым сценариям). Для ускорения отклика и повышения качества применяются адаптивное кэширование (повторно использует недавние подсказки, устраняя лаг при быстром наборе), спекулятивное декодирование (параллельный запуск небольшой модели-прогнозера для снижения латентности) и другие оптимизации latency. Кроме того, модель получает расширенный контекст - фрагменты кода из открытых файлов вместе с их окружением (релевантные части, ближайшие к месту редактирования).

Совсетно все эти приседания дали следующие эффекты:
- Адаптивный кэш дал ~35% кеш-хитов и снизил медианную задержку на 9% (p90 –2%), а acceptance rate подсказок вырос на ~17%, увеличив долю кода, генерируемого ML, на 41%
- Добавление контекста дало еще +5% к принятию и +11% к FCML (хоть задержка выросла, медиана +46%)

Совокупно acceptance rate достиг ~45%, а ~28,7% всего кода теперь генерируется моделью (до 70,6%, если исключить copy-paste). В среднем принятый фрагмент подсказки составляет ~62 символа.

2️⃣ Transform Code (авто-правки по описанию)
Этот инструмент позволяет по запросу разработчика отредактировать выделенный код согласно текстовой инструкции (например, “замени X на Y”). Под капотом – модель Gemini, дообученная на внутреннем коде; она получает контекст файла с выделенным фрагментом и текст запроса, а выдает изменения в формате диффа. Основные сложности внедрения - как подсказать пользователю воспользоваться функцией (discoverability), как удобно отобразить крупные правки и как обеспечить высокое качество предложений даже на незавершённом коде.

Google решил эти проблемы несколькими улучшениями:
- Кнопка при выделении (+40% запросов, +64% новых пользователей).
- Упрощенный дифф (ревью быстрее на 7%, acceptance +2.2%, до +4.5% на крупных изменениях).
- Дообучение на правках (acceptance вырос ~55% → 63%).

Transform Code уже приносит пользу: ~68% предложенных правок принимаются разработчиками, а средний отклик < 1 с.

В продолжении я расскажу про то, как ребята оценивали изменения продуктивности от этих инструментов (это интересно).

#Engineering #AI #ML #Software #Bigtech #Productivity #Management #Leadership #Processes #Architecture

[2/2] Achieving Productivity Gains with AI-based IDE features: A Journey at Google∗ (Рубрика #Whitepaper)

В продолжении разбора обсудим на подход с оценкой изменения продуктивности в реальном использовании. Для этого они проанализировали показатели работы инженеров (подробнее про подход Google можно прочитать в whitepaper "Enabling the Study of Software Development Behavior With Cross-Tool Logs", который я уже разбирал). Измеряли, сколько Change Lists (CL, завершённых кодовых изменений) сдаёт разработчик в месяц, сколько времени он активно пишет код на один CL, и сколько времени тратит на поиск информации вне IDE. Эффект от Transform Code оценили через онлайн-эксперимент и Difference-in-Differences анализ, сравнив метрики пользователей инструмента с контрольной группой (2023–2024).

Результаты: У разработчиков, начавших пользоваться Transform Code
- CL throughput (CL в месяц) вырос на +17.5%.
- Среднее время поисковых сессий вне IDE сократилось на –3.6%.
- Active coding time per CL не изменился значимо.
Эти эффекты статистически значимы и свидетельствуют о росте продуктивности благодаря инструменту.

Из этой работы видно, что повысить продуктивность позволяют только комплексные улучшения во всех слоях инструмента. Важны UX (чтобы фичей легко пользовались), оптимизация интеграции (латентность, контекст), тюнинг модели на данных реального использования, мониторинг метрик вроде acceptance/FCML и проверка общей отдачи на уровне throughput. Все эти аспекты взаимозависимы и требуют координации между ML-, платформенными и UX-командами.

Кроме того видно, что такая работа по своей природе итеративна. Начните с MVP и улучшайте его на основе обратной связи. Подход “сделал → замерил → улучшил” (A/B-тесты, дообучение на пользовательских правках, доработка UI) оказался решающим для превращения прототипа в инструмент, давший +17.5% к выпуску кода.

В конце статьи приводится прогноз относительно AI в разработке
1) Сегодня это умные помощники для программиста
2) Завтра - полуавтономные агенты для рутинных задач
3) В перспективе - полностью автоматизированная разработка под контролем человека

Мне кажется, что часть людей вне корпораций уже живет в "завтра" по этой классификации. Но в любом случае конечная цель в том, чтобы ИИ ускорял весь цикл от идеи до продукта.

#Engineering #AI #ML #Software #Bigtech #Productivity #Management #Leadership #Processes #Architecture

The Future of General AI Agents: The Story of Manus AI - SuperAI Singapore 2025 (Рубрика #AI)

Глянул старенькое видео Tao Cheung, co‑founder Manus AI, где он делился тем, какой путь прошла компания. Конечно там нет последнего этапа - acquistion компании запрещенной в России Meta (так как видео уже больше полугода). По-факту, Тао рассказывает как продукт прошел от браузерного расширения, эксперимент с AI-браузером, а дальше к облачному агенту, которые делает вещи, а не только отвечает на вопросы. В этом выступлении мало слов про технику и много про то, как сделать AI полезным в реальных сценариях.

Основные моменты из этого 24-минутного видео такие

1️⃣ General AI agent = мозг + руки
Ключевая метафора: одной генерации текста недостаточно. Агенту нужны “руки” - способность выполнять действия (инструменты/интеграции/исполнение задач), иначе это остаётся умным помощником в чате. Кстати, название стартапа с латинского переводится как рука (кисть).

2️⃣ Путь: расширение → AI‑браузер → облачные задачи
Команда начинала с расширения браузера как способа "встроить AI туда, где пользователь уже работает". Дальше был заход в "AI‑браузер", над которым команда работала 7-месяцев, но он оказался неудобен и ломал привычный флоу (надо было сидеть и ждать пока агент в браузере работает и не мешать ему). Этот опыт подтолкнул к идее облачного выполнения задач, когда агент делает работу в фоне и отдаёт готовый результат.

3️⃣ AI должен жить в рабочем контексте, а не в отдельной вкладке
Расширение как wedge‑продукт - это ставка на "AI в потоке работы" (браузер/страницы/контент), а не отдельный чат, куда нужно каждый раз перетаскивать контекст. Ребята вдохновлялись тем, как работает Cursor (IDE для разработчиков)

4️⃣ Самые частые юзкейсы (и почему это важно)
В Q&A Тао рассказал про три основных сценария: сбор/исследование информации, создание слайдов, сборка сайтов. Это хороший маркер того, где агенты дают ценность уже сейчас:
- много рутины,
- много “склеивания” источников/артефактов,
- понятный результат (“готовый deck / страница / отчёт”).([SuperAI Singapore][4])

Для инженеров можно почерпнуть следующие мысли

1) Парадигма меняется: вы строите не “чат”, а систему выполнения задач
Агент — это мини‑distributed system: планирование → шаги → инструменты → промежуточные состояния → финальный артефакт → логирование. Даже если “мозг” - LLM, инженерная часть - это оркестрация и контроль.
2) Архитектурный паттерн: sandbox + коннекторы
У Manus явно просматривается модель:
- облачный sandbox/браузер для изоляции и повторяемости
- плюс локальный коннектор/расширение там, где важны авторизованные сессии и “доверенный” контекст (логины, IP, вкладки)
Для ваших внутренних агентов это переводится в: где исполнять (локально/в облаке), с какими правами (least privilege), как аудитить (лог действий)
3) “Контекст‑инжиниринг” важнее “промпт‑инжиниринга”
Если агент собирает слайды/страницы/отчёты, решает не красота промпта, а:
- какие источники подключены,
- какие форматы входов/выходов стандартизованы,
- как агент получает обратную связь и исправляет.

А вот что это значит для технических руководителей

1) Выбирать нужно сценарии для автоматизации, а не “намазывать AI” ровным слоем
Самые “быстрые победы” - процессы с чётким Definition of Done и низким blast radius:
- подготовка отчёта/ресёрча,
- генерация презентации из RFC/PRD,
- сборка лендинга/демо‑страницы,
- автоматизация повторяемых web‑операций
2) KPI для агента = скорость × качество × цена
Вводите метрики, например
- % задач “сдано без переделок”,
- среднее время до результата,
- стоимость (деньги/кредиты/токены),
- количество вмешательств человека
3) Управление рисками: доступы, аудит, остановка
Если агент “кликает и логинится”, вам нужны политики:
- кто может подключать какие интеграции,
- где хранятся секреты,
- как выглядит audit trail,
- как быстро “остановить выполнение”

В общем, у ребят из Manus все получалось настолько хорошо, что их выкупила Meta.

#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture

Troubleshooting Interview (Рубрика #Engineering)

Вчера впервые за полгода или даже больше провел интервью по траблшутингу для SRE-инженера. Когда-то я был лидером этой секции найма, много рассказывал про нее (на Devops Conf) и даже провел публичное интервью на Devoops Conf. Но потом я передал секцию другому лидеру, а сам остался в пуле интервьюеров и мне почти никогда не прилетал этот вид собеседований. Но на этой неделе он прилетел и я хотел отказаться - слишком я был перегружен другими делами и не хотелось тратить время на то, чтобы освежить воспоминания. Но я решил, что это отличный способ размять мозг и вспомнить былое - я вспомнил регламент, взял одну из задач, которую я добавлял в пул задач по траблшутингу на основе постмортема одной из моих команд и отправился проводить интервью. На самом интервью я вспомнил как это круто играть в DnD в роли гейм-мастера - мы "побеждали дракона" и "спасали принцессу" (нашу систему), а мне было очень интересно:) В итоге, я решил, что надо бы на сайт system-design.space добавить главы про troubleshooting - вопрос надежности спроектированного решения часто очень важен в рамках интервью по system design. В общем, я добавил главу про интервью в общем, а в главе про публичное интервью еще сделал визуализации архитектуры приложения и старта сбоя). Думаю, что на досуге возьму еще постмортемов и сделаю практических задач - а потом может с ними сделаю публичные моки интервью:)

#Architecture #SRE #Engineering #Software #Management #Career #Devops #Interview #SystemDesign

Official PyTorch Documentary: Powering the AI Revolution (Рубрика #AI)

Что-то я подсел в последнее время на документальные фильмы про технологии - очень интересно смотреть истории о том, как создавались техно-продукты, что сейчас являются де-факто стандартами индустрии. И это именно такой фильм про PyTorch с названием "Powering the AI Revolution", который вышел в 2024 году. Это фильм - ретроспектива от людей, которые строили PyTorch "изнутри": Soumith Chintala (со‑создатель PyTorch в Meta/FAIR), коллеги из Meta AI/FAIR (в т.ч. Yann LeCun) и партнёры по экосистеме. Основная мысль крутится вокруг того, как инструмент для быстрых экспериментов стал платформой, на которой учат и доставляют модели в прод.

Если говорить про основные вехи развития PyTorch (что хорошо освещается в фильме), то они такие
- Зарождение (2016). Выходцы из Torch7 (Lua) переносят идеи в Python и делают ключевую ставку на динамический граф (define‑by‑run / eager) + autograd «из коробки». Публичный релиз - осень 2016.
- Взлёт в ресёрче (2017). Минимальная «церемония», дебаг как в обычном Python, высокий темп релизов и рост комьюнити. Осенью 2017 с Microsoft запускают ONNX - стандарт переносимости моделей между фреймворками.
- Дорога в прод (2018). Объединение PyTorch и Caffe2. PyTorch 1.0 + TorchScript/JIT дают экспорт/оптимизацию для инференса и начинают закрывать разрыв между ноутбуком и сервисом.
- Массовое принятие (2019–2020): PyTorch догоняет/перегоняет TF по «весу» в академии и индустрии; усиливаются distributed‑возможности (torch.distributed и друзья). В 2020 OpenAI переводит стек на PyTorch ради скорости итераций; вокруг растёт «мидлварь» (Transformers, Lightning и т.п.), делая DL более инженерным.
- Нейтральность и устойчивость (2022). PyTorch Foundation под Linux Foundation, мультивендорное управление (облака, железо, платформы) - меньше рисков вендор‑локина, больше доверия рынка.
- Скорость без потери DX (2023). PyTorch 2.0 приносит torch.compile (Dynamo/Inductor) — компиляция, фьюзы, более агрессивные оптимизации, при этом код остаётся «питоничным».

Ключевые инсайты от создателей
- Конкуренция (TensorFlow) полезна: она заставила выбрать дифференциатор. PyTorch выиграл UX‑ом, а не лозунгами.
- Eager‑подход - продуктовая фича: меньше «магии графов», проще дебаг, быстрее цикл «гипотеза → код → метрика».
- Open source - это процесс: быстрые ревью/релизы, уважение к обратной связи, совместимость и прозрачность превращают библиотеку в стандарт.
- Побеждают экосистемы: training → export → serving → observability + интеграции с облаками и ускорителями. Один фреймворк не закрывает весь контур.
- Governance важно не меньше кода: нейтральная площадка и мультивендорность - условие долгой жизни платформы.

Уроки для разработчиков и техлидов
- DX - измеримая метрика: time‑to‑first‑result, скорость дебага, онбординг и число «переобучений» команды важнее синтетических бенчмарков. Кстати, про DX я много рассказываю и скоро опубликую целый динамический сайт, что посвящен именно этой теме
- Делайте путь из research в prod прямым: компиляция/экспорт/оптимизации должны быть частью дизайна, а не «потом допилим».
- Инвестируйте в компонуемость: стандарты (в духе ONNX), extension‑points, обратная совместимость, понятные контракты.
- Стройте платформу, а не зоопарк скриптов: пайплайны, репрод, трекинг экспериментов, тесты на деградации, понятные SLA.
- Организационный паттерн: дайте ресёрчу максимум свободы (eager, быстрые итерации), а платформенной команде - ответственность за «мост» в прод (compile/export/serving).
- Комьюнити (внутреннее или внешнее) - стратегический актив: доки, примеры, triage, RFC‑процессы и прозрачные решения масштабируют команду.
- Опирайтесь на облака/вендоров, но закладывайте переносимость: железо и провайдеры меняются быстрее ваших моделей.

Кстати, добавил этот фильм в список документалок на платформе system-design.space, так как тут очень интересно показаны вопросы дизайна платформы и миграции на нее с legacy систем

#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture #RnD