Книжный куб

[2/2] 2026 Agentic Coding Trends Report - How coding agents are reshaping software development (Рубрика #AI) В этом посте мы закончим разбирать короткий trend-report Anthropic, который задает фокус того, что стоит делать в 2026 году нам как инженерам и руководителям, чтобы не отстать от стремительно меняющейся индустрии разработки софта. 3️⃣ Impact trends: What agents may change in 2026 Trend 6: Productivity gains reshape software development economics Эффект - не только "быстрее", но "больше": растёт объём shipped-результата, появляется работа, которую раньше бы не делали (в отчёте ~27% AI-задач - “не сделали бы иначе”). TELUS, например, сделали 13k внутренних AI-решений и ускорили shipping кода на 30%, сэкономив 500k+ часов. - Инженерам надо пересмотреть приоритеты - закрывать техдолг и “papercuts” становится выгодно. • CTO стоит ожидать “взрыва output” и заранее ставить рамки качества, иначе скорость съест поддерживаемость. Trend 7: Non-technical use cases expand across organizations Неинженерные команды начинают автоматизировать процессы сами: меньше тикетов в разработку, больше локальных “мини-продуктов”. Zapier в отчёте - 89% adoption и 800+ внутренних агентов; у Anthropic юристы сократили маркетинг-ревью до 24 часов, причём self-service инструменты собрал юрист без опыта кодинга. - Инженерам надо помогать через внутренние библиотеки/коннекторы/примеры, а не “делать за всех”. - CTO пора строить governance для citizen devevelopers (что можно автоматизировать, где хранятся секреты, кто отвечает за поддержку). Trend 8: Dual-use risk requires security-first architecture Агентный кодинг усиливает и защиту, и атаки. Любой инженер может делать security-review с агентом - и любой атакующий тоже масштабирует свои попытки. - Инженерам надо двигать практики безопасности: “least privilege” для инструментов агента, изоляция, журналирование, защита от инъекций/подмены контекста. - CTO надо идти в security by design агентных систем (права, контуры, аудит, red teaming) до того, как агенты получат доступ к продовым данным/деплою. Если свести отчёт к одному тезису: выиграют команды, которые научатся - Ууправлять несколькими агентами - Масштабировать контроль качества - Безопасно расширить агентные инструменты за пределы инженерии #AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture

[1/2] 2026 Agentic Coding Trends Report - How coding agents are reshaping software development (Рубрика #AI) Anthropic опубликовала любопытный отчёт о ключевых трендах "агентного кодинга" на 2026 год. Этот документ рисует картину того, что разработка всё больше опирается на AI-агентов, которые пишут код, пока люди задают им цели и контролируют результат. Они приводят статистику, что разработчики Anthropic используют AI в 60% задач, хотя полностью доверяют ему лишь 0–20% работы (это из их декабрьской статьи "How AI is transforming work at Anthropic", о которой я уже рассказывал). В новом документе они приводят кейсы и других компаний, который смогли добиться значимых результатов, но все-таки фокус на 8 тенденциях, что сгруппированы в три категории: foundation trends, capability trends, impact trends. Ну и ниже я расскажу про каждый из трендов, а также поделюсь мыслями, а что делать с ними инженерам и руководителям 1️⃣ Foundation trends: The tectonic shift Trend 1: The software development lifecycle changes dramatically SDLC остаётся, но цикл сжимается: агент пишет/дебажит/документирует, тесты и мониторинг быстрее замыкают фидбек (недели → часы). - Инженерам стоит начать прокачивать «оркестрацию» (декомпозиция, постановка задач агенту, критерии приёмки, быстрый ревью). • CTO стоит пересобрать процесс и метрики (меньше “время на задачу”, больше “качество+output”), и реально использовать “онбординг за часы” для динамического перераспределения людей по продуктам/проектам 2️⃣ Capability trends: What agents can do Trend 2: Single agents evolve into coordinated teams Один агент → команда агентов с ролями + оркестратор. Это про параллельную работу и синхронизацию в VCS. Пример из отчёта: multi-agent оркестрация дала Fountain 50% быстрее screening и сократила срок укомплектования нового центра до <72 часов. - Инженерам надо научиться резать задачи так, чтобы их можно было делать параллельно (и собирать через PR/чеки). - CTO стоит внедрять паттерны multi-agent (роли, протоколы, правила мержа/ревью для “агентских” изменений). Trend 3: Long-running agents build complete systems Агенты работают «долго»: часы → дни/недели. Могут тащить фичу/подсистему целиком, закрывать техдолг, делать “невыгодные руками” улучшения. Пример: Rakuten прогнали Claude Code по задаче в vLLM (12,5 млн строк) - 7 часов автономной работы и 99,9% точности. - Инженерам пора начать мыслить чекпоинтами (контракты, тесты, инварианты) и строить ограждения, чтобы агент не «уехал». - CTO стоит подготовить среду для длинных прогонов (sandbox, CI, лимиты, наблюдаемость) и выделить задачи “под агента” (миграции, рефакторинги, чистка бэклога). Trend 4: Human oversight scales through intelligent collaboration Ключ в том, чтобы масштабировать контроль. Агенты учатся звать человека, а не молча “дожимать”; AI проверяет AI (security/архитектура/качество), человек смотрит только «что важно». - Инженерам надо собирать пайплайн “генерация → автопроверки → человек”. - CTO стоит формализовать уровни риска и эскалации (что агент может сам, что только через человека), инвестировать в автоматизированный ревью/тестирование. Trend 5: Agentic coding expands to new surfaces and users Агентный кодинг выходит за IDE: больше языков (включая legacy типа COBOL/Fortran), больше ролей (ops, security, design, DS), больше интерфейсов для не-разработчиков. - Инженерам пора готовиться к "коду от доменных экспертов" - нужны шаблоны, guardrails, API/платформа, чтобы это было безопасно. Тут можно вспомнить про условный Lovable и приложения, что продакты сгенерировали через него - CTO надо сознательно открывать агентные инструменты другим отделам, но через песочницы, права доступа и наблюдаемость. В продолжении я расскажу про последние три тренда из этого интересного отчета. #AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture

The history of C# and TypeScript with Anders Hejlsberg | GitHub (Рубрика #Software) Интересное интервью Андерса Хейлсберга, создателя C#, Delphi, Turbo Pascal и ведущего архитектора TypeScript, которое он дал GitHub. Андреас разбирает, как создавались C# и TypeScript и какие компромиссы стояли за решениями и какие принципы помогают языкам и командам "жить долго". Из получасовго интервью можно почерпнуть много интересного 1️⃣ Быстрый фидбек важнее почти всего Короткий цикл «написал → сразу понял/проверил» определяет скорость и качество. Поэтому ценность TypeScript - не только в типах, но и в инструментах: подсказки, проверка, рефакторинг, быстрый компилятор. 2️⃣Масштаб требует жертвовать личным идеалом Когда пользователей и сценариев много, побеждает прагматика: язык успешен, если вписывается в реальную работу команд, а не только в учебник. 3️⃣ Эволюция сильнее революции TypeScript вырос как надстройка над JavaScript: улучшает поддерживаемость больших проектов, не заставляя «сжигать мосты» и менять экосистему. 4️⃣ Прозрачность ускоряет open source Публичные PR/issue и обсуждения переводят приоритеты от "внутренних" к реальным потребностям, а решения становятся объяснимыми и проверяемыми. 5️⃣ Иногда нужен рывок в основании без ломки внешнего контракта Переписывание критического компонента ради производительности имеет смысл, если пользователь не платит ценой совместимости. 6️⃣ Эпоха AI смещает роль инженера Всё больше кода генерируется, а ценность инструментов - в точности: типы, проверки, тесты и рефакторинг как ограждения от правдоподобных ошибок. 7️⃣ "Память проекта" - это актив История обсуждений и решений (почему сделали так, а не иначе) снижает повторение ошибок и облегчает онбординг. Если эти lessons learned превратить в какие-то выводы, то они могу быть такими Для инженеров - Инвестируйте в быстрый цикл: локальные проверки, быстрые тесты, линтеры/типы, удобные IDE-инструменты. - Пишите для "коллективного владения": читаемость, предсказуемость, простые правила важнее личной элегантности. - Учитесь по контексту решений: обсуждения в issue/PR часто дают больше, чем абстрактные «best practices». - При работе с AI-кодом усиливайте страховку: типизация + статанализ + тесты, иначе вы просто быстрее генерируете долг. Для технических руководителей - Ставьте скорость обратной связи в KPI инженерной системы: CI, тесты, статанализ, быстрые сборки. Медленный фидбек рождает процессы-«костыли». - Держите баланс интересов: стандарты и совместимость важнее вкуса отдельных сильных инженеров. - Внедряйте изменения через миграции и совместимость: постепенное улучшение обычно дешевле и надёжнее тотальной замены. - Стройте институциональную память: ADR/решения, ссылки на обсуждения, понятные причины компромиссов - это снижает риски при росте и текучести. В общем, долгоживущие технологии и команды выигрывают, когда обеспечивают быстрый фидбек, принимают прагматичные компромиссы, эволюционируют без ломки и ведут прозрачную историю решений. #AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture #RnD

Масштабная конференция получилась:) С моего второго этажа отлично видны все остальные стенды - я решил отдохнуть немного, так как чуток осип полтора часа рассказыаать про исследование. А мне еще через полтора часа вести инженерную дискуссию про влияние AI на разработку:)

T-Sync Conf (Рубрика #Engineering) Сегодня я проведу весь день на конференции T-Sync, где нет докладов, а больше дискуссий и зон для общения. Собственно, у меня будет такая зона на втором этаже, где мы сможем поговрить про исследование AI4SDLC, которое мы стартанули в прошлом году опросом сообщества. Само исследование доступно на сайте ai4sdlc.tbank.ru при клике на вкладку "Исследование". Оно состоит из двух частей: 1️⃣ Раздел с мета-исследованием 2023–2025, где мы взяли порядка 50 отдельных исследований за последние годы и посмотрели на их результаты. Особенно интересно было смотреть на тренды серийных исследований, что проводятся ежегодно - по ним видно, как менялось отношение к AI в среде разработки, проникновение AI в разные сценарии, оценки его эффектов и так далее. Среди таких серийных исследований были исследования от: DORA, GitHub, Stack Overflow, JetBrains, Atlassian, McKinsey, Яков и Партнёры / Yandex, Express42, МФТИ. На сайте есть список серий, где можно посмотреть основные тренды каждой серии. Также есть таймлайн со всеми учтенными исследованиями + можно изучить краткое саммари по каждому из них 2️⃣ Раздел с результатами опроса, который мы проводили в конце прошлого года. Опрос получился объемным и я хотел бы поблагодарить всех поучавствовавших в нем. По результатам получилось примерно следующее: начали заполнять опрос порядка 1к человек и хорошо, что мы вопросы про использование и влияние AI вынесли в самое начало, так как до конца опроса дошли не все:) Если говорить, про профиль респондентов, то он получился такой: - 50% разработчики, 17% технические руководители, 7% топ-менеджеры, 6% qa-инженеры, 4% AI/ML инженеры и так далее - 24% работают в крупных компаниях (1к - 10к), 23% в очень крупных (10к+ сотрудников), 18% в средних (100 - 500 сотрудников), 16% в маленьких (10-100) - основные представленные отрасли: финансы - 25%, технологии - 20%, розничная торговля и e-com - 15%, телеком - 7%, образование - 5% - основные приложения/сервисы, над которыми работают респонденты распределились довольно равномерно: внутреннее/внешнее для пользователей - 45% vs 37% и b2c vs b2b - 34% vs 41% Если говорить про executive summary результатов опроса, то они такие - AI для генерации / автодополнения кода используют "часто/всегда" 58%; для code review 24%; для модернизации legacy 18% (при 42% "никогда"). - Производительность выросла у 64% (18% "значительно"); способность писать код улучшилась у 37%. - Качество кода: улучшение 32%, ухудшение 14%, без изменений 42%. - Доверие к AI-коду низкое: 49% не доверяют, 11% доверяют (остальные — нейтрально). - Роль AI внутри компании выросла у 54%; прозрачность планов внедрения ощущают 50%, не ощущают 21%. - "Системная готовность": commit→prod у заметной части измеряется неделями/месяцами; документация как источник правды работает плохо (около 39–42% не опираются на нее в критичных ситуациях). И эти результаты хорошо откликаются в результатах мета-исследования - Охват AI приближается к "почти у всех" (например, в сводках DORA к 2025 — около 90%); при этом личный эффект обычно сильнее командного. - Узкие места переезжают в интеграцию, тестирование, ревью, релизы, коммуникации; в исследованиях регулярно всплывает тезис, что кодинг - лишь часть времени инженера (и что организационные барьеры съедают ощутимую долю недели). - Качество и доверие - центральная проблема зрелости: "almost right" ответы создают новый долг проверки и дебага. - Экспериментальные данные показывают: на сложных задачах эффект может быть нулевым или отрицательным; AI - усилитель системы, а не замена инженерии. - Без guardrails (тесты, quality gates, small batch, ревью, наблюдаемость) "ускорение" легко превращается в "ускорение хаоса". В общем, если вас интересует эта тема, то приходите на стенд и я подробнее расскажу про всю эту машинерию и отвечу на дополнительные вопросы. #AI #RnD #Software #Engineering #Management #Leadership #Metrics #Processes #Productivity

Почти интеллектуальные системы» (Smart (enough) systems) (Рубрика #Processes) Нашел у себя на полке книгу про интеллектуальные системы, что вышла почти 20 лет назад. Когда-то давно я ее читал и в ней было много умных слов. А сейчас я ее открыл и понял, что если половину терминов оттуда заменять на модные сейчас слова типа "GenAI", "мультиагентные систем", "RAG" или "context engineering", то текст будет выглядеть как свежий архитектурный гайд по построению интеллектуальных систем. Дальше я решил понять, а что за авторы написали этот труд и оказалось, что там два автора - Джеймс Тейлор - один из главных евангелистов decision management: работал в Fair Isaac (FICO), где развивал подход Enterprise Decision Management, а позже стал CEO Decision Management Solutions. Он много лет продвигает идею «делайте решения явными и управляемыми». - Нил Рэйден - легенда BI/analytics: основатель Hired Brains, практик и аналитик, который умел объяснять, почему «данные есть, инсайты есть, а бизнес всё равно принимает решения “на глазок”». Книга была хороша в свое время, так как в середине 2000‑х компании уже купили ERP/BPM/BI, построили витрины и дашборды… и внезапно обнаружили, что: - Процессы автоматизировали, а решения внутри процессов - нет - Аналитика живёт в презентациях и Excel, а не в runtime - Правила размазаны по коду/табличкам/головам людей и меняются больно Тейлор и Рэйден попали в нерв: они предложили смотреть на «решение» как на отдельный объект инженерии - как на сервис/компонент, который можно проектировать, тестировать, версионировать, мониторить и улучшать. Не «магический AI», а честная промышленная автоматизация скрытых решений. Почему и сейчас книга актуальна - потому что многие используют buzzwords для описания желаемого результата вместо того, чтобы описать что именно они хотят. Условно "а тут у нас GenAI сделает все по красоте" или "наша multi-agent система выполнит эту работу сама" или просто "а тут справится AI". Для тех, кто немного понимает в технике такой подход кажется карго-культом. И тут полезно вспомнить про то, о чем рассказывала эта старая книга, а именно про то, что обычно болит в любой интеллектуальной системе: - Где в продукте спрятаны решения и кто за них отвечает; - Как отделять decision logic от process orchestration; - Как сочетать “правила” и “модели” без религиозных войн; - Как измерять качество решений (а не количество токенов); - Как обеспечивать согласованность между каналами и командами; - Как менять логику быстро, но безопасно (управление изменениями, контроль, обратная связь). Когда читал эту книгу, то составил для себя минисловарик терминов из 2007 года и как они маппятся на термины из 2026 года - Business rules engine → guardrails / policy engine / “промпт‑конституция” - Predictive analytics model → ML‑модель / LLM‑модель / routing‑модель - Decision service → AI‑оркестратор / агент с тулзами / микросервис решения - Data & analytics → feature store + telemetry + (да‑да) RAG/векторная база - Adaptive control → online‑эксперименты, bandits, self‑improving пайплайн - “Make decisions explicit” → «вынесите это из кода/голов в явный артефакт + evals» Забавно, что в 2007 году авторы специально добавили “(enough)” в название, чтобы отстроиться от тогдашнего "настоящего AI" - мол, нам не нужна эзотерика, нам нужна практическая автоматизация решений. В 2026 мы делаем наоборот: берём те же идеи, добавляем GPU, векторную БД и называем это GenAI. Итого: технологии крутятся по кругу, а хорошая инженерия - нет. Если вы строите AI‑системы, то вам всё равно придётся: - Делать решения явными - Измерять их эффект - Управлять изменениями - Обеспечивать контроль и обратную связь Просто вместо правил/скорингов иногда будет промпт/LLM. 🙂 #AI #Engineering #Software #Management #Leadership #Processes #LLM #ML #Architecture

Local-First Software: Taking Back Control of Our Data | a mini-doc (Рубрика #DistributedSystems) Посмотрел интересный мини-документальный фильм, в котором засветились разные люди, но меня заинтересовал Мартин Клеппман, автор книги DDIA и один из апологетов подхода local-first. Собственно, этот подход предлагает альтернативу централизации хранения информации в облаке (и фиксации там источника истины). В local-first приложениях "истина" хранится на устройстве пользователя, работает без интернета и синхронизируется с облаком как с дополнительной копией. Основные идеи концепции такие 1️⃣ Главная копия - у пользователя. Приложение читает/пишет локально → быстрый UX, офлайн по умолчанию. Облако нужно для синка между устройствами и бэкапа. 2️⃣ Cloud‑first ломается в быту. Например, пропал сигнал - пропал плейлист, хотя музыку «купили». И ещё хуже: сервис закрылся/выключил серверы - люди теряют доступ к своим данным. 3️⃣ Коллаборация возможна, но это сложно. Цель - как в лучших облачных продуктах (реал‑тайм, единые данные), но без постоянной связи с центральным сервером. Техники: CRDT, p2p/распределённая синхронизация, «слияние» изменений. Пока есть трудные кейсы и много инженерной работы. 4️⃣ Это уже движение. Сообщество растёт, появляются митапы/инструменты. Большинство «local‑first» продуктов пока гибридные (компромисс идеала и практики), но направление ясно: больше автономности и контроля пользователя. Если прекладывать это на идеи для проектирования своих приложений и хочется попробовать двигаться в эту сторону, то можно сделать следующее - Сделайте offline‑first базовым нефункциональным требованиям. Не «спиннер без сети», а работа с локальными данными + очередь/ретраи/идемпотентность (кстати, сейчас такой подход был бы актуален на случай блокирования мобильного интернета) - Локальная БД + фоновый sync. SQLite/IndexedDB и слой репликации: журналы изменений, версии, мердж, лимиты/квоты, наблюдаемость синка. - Конфликты - не баг, а сценарий. Опишите модель консистентности: last‑write‑wins, CRDT, явные конфликты в UI, правила домена. - Контроль и долговечность данных. Экспорт, локальные бэкапы, миграции схем, E2E‑шифрование для синка/облака. - Сдвиг сложности на клиент. Сервер может стать проще (координация/хранилище), но растут требования к тестированию офлайн/синка и к компетенциям в распределённых системах. В общем. если подводить итог, то local-first пытается решить боли уехавших в облака приложений и ставших cloud-only, а список проблем большой: зависимость от сети, доверие и сохранность данных. Но надо отметить, что полный переход не обязателен, но уже сейчас можно внедрять элементы: локальное хранение, офлайн‑UX, безопасный sync и понятную модель конфликтов. Это даст продукту устойчивость и пользователю - ощущение контроля. P.S. Минидокументалка всего на 10 минут, поэтому ее вообще изян посмотреть почти как shorts:) P.P.S. Эта документалка тоже попала на сайт system-design.space, так как в ней очень интересно обсуждаются компромиссы при проектировании распределенных систем. #DistributedSystems #Architecture #SystemDesign #Software #Databases

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

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

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

[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

[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

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

[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

[1/2] Нейросети захватили соцсети: как казахстанский стартап взорвал все AI-тренды и стал единорогом (Рубрика #AI) Посмотрел интересное интервью Ерзата Дулата, CTO и co-founder Higgsfield AI (первый единорог Казахстана, оценка $1.3B), что он дал Елизавете Осетинской, иностранному агенту. Среди занимательных фактов, после которых интервью смотреть еще интереснее то, что у Ерзата нет высшего образования, когда-то его звали в OpenAI и он не пошел (когда он публиковал алгоритмы и papers на GitHub во второй половине 2010х), а также он созадл один из самых быстрорастущих AI-стартапов в истории (может даже быстрее Lovable, про который я уже рассказывал). Ниже немного данных и цифр про сам стартап 🚀 Таймлайн Higgsfield AI - 2023: основание компании, 1.5 года research - 31 марта 2025: релиз продукта - Январь 2026: $1.3B valuation, $200M ARR Метрики роста: - $0 → $100M ARR за <9 месяцев - обогнали Cursor (достиг $100M ARR за 12 месяцев) и Lovable по скорости) - $100M → $200M ARR за ~2 месяца - Рост 50-150% в месяц - 15M+ пользователей, 4.5M видео/день А дальше ключевые инсайты, что показались мне интересными в подходе ребят 1️⃣ Скорость - единственный настоящий "moat" в AI и вот почему - Модели обновляются каждые несколько месяцев → дисрапт рынка - OpenAI "убивает сотни стартапов" каждым релизом (пример: когда они анонсировали canvas/документы, это вынесло кучу стартапов) - Классические defensibility (network effects, data moats) слишком медленные для AI - можно глянуть интересный эпизод от Y Combinator про это Стратегия Higgsfield: собирать "низковисящие фрукты" Пример: Google выпустила Veo3 - мощную video-генерацию, но модель не даёт точного контроля камерой. Higgsfield взяли Veo3 по API и добавили: - Точный контроль движения камеры - Click-to-video интерфейс (шаблоны, как в PowerPoint) - Camera techniques для профессиональных операторов Цитата о том, а почему сами провайдеры фронтир моделей это не делают

Гегемон слепой. Google/Meta настолько большие, что не думают о деталях для профессионалов. Мы собираем вот эти low-hanging fruits

В итоге, собирается примерно такой алгоритм действий для создателей GenAI приложений - Не строй foundation models - оркестрируй их - Используй API (OpenAI, Anthropic, Google) + добавь "упаковку" для конкретной ниши - Релизь MVP за недели, не месяцы → собери feedback → iterate 2️⃣ Синтез креативщиков + ML-инженеров = магия Из интервью видно, что прорыв произошел когда профессиональные операторы начали объяснять ML-инженерам, какой продукт нужен. Как это работает: 1. Большой отдел креаторов придумывает AI-хуки для TikTok/Instagram (камера налетает на землю, морфинг одежды, превращение в стаю ворон) 2. ML-команда тренирует нейронки под эти хуки 3. Выкатывают → viral в соцсетях → миллионы пользователей Результат: - Все AI-тренды в соцсетях за последние 9 месяцев созданы в Higgsfield - Мадонна, Will Smith, Snoop Dogg, Timbaland, Златан Ибрагимович используют - TikTok и Meta пытались повторить, но "ни один тренд не создали" В итоге, собирается примерно такой алгоритм действий для создателей GenAI приложений - Не просто tech problem, а product/culture problem - Нанимайте domain experts (операторы, режиссёры, дизайнеры), не только ML-инженеров - Креативность + Engineering = дифференциация В продолжении закончу разбор интервью рассказом о том, как ребята обеспечивают такой стремительный рост аудитории своего приложения, а также как они работают с моделями для генерации видео. #AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture

[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

[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

Dronescapes (Рубрика #Travel) У меня в библиотеке есть большое количество красивых книг, которые я люблю иногда лтстать по вечерам, особенно когда устаю от рабочих вопросов днем. Одна из таких книг это "Dronescapes", которая вышла в те времена, когда дроны использовали в основном фотографы и выкладывали их на сайт https://www.dronestagr.am/ (инстаграм для дронов). Я помню, что 10 лет назад, когда я увлекался фото, то очень хотел попробовать квадрокоптеры для фото, но тогда не сложилось, но зато теперь можно, сидя вечером и попивая чай, наслаждаться чужими красивейшими фото:) #Culture

Командировка в Питер (Рубрика #Travel) Сегодня тревел-пост про комадировку в Питер, куда мне нравилось приезжать и раньше. Но в прошлом году у нас открылся новый офис, который подальше от метро, но супер уютный и удобный. Кроме того, в этот приезд нам как часть стратсессии коллеги устроили посещение Эрмитажа, но в закрытом режиме с отдельным гидом и почти пустыми залами и это было бомбически. Я люблю искусство, но я очень не люблю толпы людей, поэтому я редко хожу на большие мероприятия (концерты, популярные музеи и так далее). А тут получилось очень здорово - крутой музей и почти весь наш ... Теперь я и в другие музеи хочу ходить в таком режиме:)) #Travel

ASML Statement on Strengthening Focus on Engineering and Innovation (Рубрика #Engineering) Вышла интересная новость от ASML, чьи литографы хотят все производители чипов. Так вот ASML внезапно обнаружила, что стала… less agile, процессы усложнились, скорость упала, матричная оргструктура начала мешать инженерии и пора принимать меры. Если переводить с корпоративного, то можно прочитать это письмо так - Matrix-структура больше не вывозит - слишком много пересечений, согласований и «непонятно кто владелец результата» - Хотим product-ориентированную модель - чёткие продуктовые направления, end-to-end ownership, меньше размазанной ответственности - Processes became “less agile” - для компании, которая живёт на скорости R&D, это почти диагноз. В итоге, ребята решили сократить лишние уровни менеджмента и уволить 1.7к сотрудников, что я прочитал примерно так "кажется, у нас слишком много людей, которые управляют людьми, которые управляют процессами". Интересно будет дальше посмотреть как пройдет эта трансформация. #Engineering #Management #Leadership #Software #Processes