Книжный куб

Upper Management Meeting: когда AI выглядит как магия для менеджмента (Рубрика #Management) Посмотрел "Upper Management Meeting". Это очень смешно и немного грустно, потому что карикатура попадает в знакомое место: про AI действительно очень легко рассказывать красиво. Особенно если ты не очень хорошо понимаешь, как он устроен. В этом и есть управленческая опасность. Проблема не в том, что менеджеры интересуются AI. Это как раз нормально: технология уже влияет на продукты, процессы, разработку, поддержку, аналитику и стоимость работы. Проблема начинается там, где AI воспринимают как магию, а не как инженерный инструмент. Артур Кларк, известный английский изобретатель, писатель и футуролог сформулировал знаменитый третий закон:

Любая достаточно развитая технология неотличима от магии

Для пользователя это иногда даже хорошо. Нажал кнопку - получил результат. Зачем ему знать, что там внутри? Но для человека, который принимает управленческие решения, такой подход опасен. Если технология выглядит как магия, ей легко приписать любые свойства: “пусть AI решит”, “добавим AI в продукт”, “сократим людей”, “автоматизируем все”, “сейчас модели сами все поймут”. И в этот момент обсуждение перестает быть инженерным, а становится почти ритуальным. Хорошее AI-решение начинается не с восторга и не с красивой презентации. Оно начинается с более скучных вопросов: - Какую конкретную задачу мы решаем - Какие данные для этого нужны - Какие ограничения есть у модели - Как проверим качество - Кто отвечает за ошибку - Как это встроится в процесс - Сколько будет стоить эксплуатация - Что произойдет, если система уверенно сделает не то Именно поэтому техническим руководителям сейчас важно уметь переводить AI из магического языка в инженерный: сценарии, ограничения, метрики, риски, контуры проверки, безопасность, эксплуатация и ответственность. AI можно воспринимать как магию, когда смотришь демо. Но нельзя принимать управленческие решения, полагаясь на магическое мышление. Чем сильнее технология, тем важнее понимать не только ее возможности, но и границы. В общем, ролик короткий, смешной и полезный. Особенно для тех, кто участвует в AI-стратегиях, комитетах, roadmap-сессиях и разговорах с бизнесом. #Management #AI #Engineering #Architecture #Leadership

Organizational evolution: From products to user needs | Eugene Sergueev (Рубрика #Management) Посмотрел доклад Евгения Сергеева про эволюцию инженерной организации во Flo Health, и у меня было очень сильное чувство дежавю. Лет 6 назад я проходил довольно похожий путь: превращение приложения в супер-апп, закон Конвея, обратный маневр Конвея, Team Topologies, попытки понять, где границы команд помогают продукту, а где начинают ломать архитектуру и пользовательский опыт (есть вот такой мой доклад с Techlead Conf). С Женей мы записывали ряд подкастов (например, про книгу Will Larson), поэтому смотреть выступление было особенно интересно. Но даже без этого личного контекста доклад, мне кажется, очень полезен для технических менеджеров. Он не столько про Flo Health как компанию, сколько про более общий вопрос: как эволюционировать инженерную организацию, когда продукт растет, а структура прошлого постепенно становится ограничением будущего. Главная мысль доклада простая и правильная: организацию нужно проектировать так же осознанно, как продукт и архитектуру. Организация - это живой продукт. У нее есть пользователи, ограничения, обратная связь, накопленный долг и моменты, когда старое решение перестает работать. В кейсе Flo это хорошо видно. Компания выросла от трекера цикла к большой health-платформе с 70+ млн месячных пользователей. На раннем этапе нормальной могла быть функциональная структура: отдельно мобильная разработка, отдельно web, отдельно backend и другие функции. Потом потребовался переход к более продуктовой модели с автономными командами вокруг каналов и возможностей. Это ускорило рост, но со временем создало новую проблему: разные каналы начали конкурировать за внимание пользователя, а опыт стал фрагментированным. И следующий сдвиг оказался уже не про “давайте добавим еще одну продуктовую команду”, а про переход к пользовательским сценариям и Jobs-to-be-Done. То есть вопрос меняется с “как развивать конкретную фичу или канал?” на “что нужно пользователю в конкретном жизненном сценарии?”. Для health-продукта это особенно важно: планирование беременности, раннее материнство, разные состояния здоровья - это не набор независимых фич, а связанные пользовательские пути. Здесь как раз появляется обратный маневр Конвея. Обычно закон Конвея напоминает, что архитектура системы повторяет коммуникационную структуру организации. Обратный маневр предлагает использовать это осознанно: если мы хотим определенную архитектуру и определенный пользовательский опыт, нужно проектировать команды, границы ответственности и платформы под этот результат. Мне понравилось, что в докладе это подается как управленческая рамка: выровнять бизнес-цели, честно оценить текущее состояние, выбрать подходящие паттерны, провести изменения и дальше итерировать. Без этого компании часто оптимизируют локальные неудобства, а не системное ограничение. Еще одна хорошая практика - Organizational Decision Records. По сути, это аналог ADR, только для организационных решений. Почему мы поменяли структуру? Какую проблему решали? Какие альтернативы рассматривали? Какие компромиссы приняли? Это кажется бюрократией ровно до того момента, пока через год никто уже не помнит, почему команды были нарезаны именно так. Самый практичный пример в докладе - история с экспериментами в онбординге. Если для каждого изменения пользовательского сценария нужно участие инженеров, то узкое место находится не в разработке конкретной фичи, а в способе доставки ценности. Во Flo доля onboarding-экспериментов, которые можно было запускать без инженеров, выросла примерно с 20% до 87%. И это уже меняет культуру: вместо “можем ли мы это построить?” организация чаще спрашивает “давайте быстро проверим”. Для меня главный вывод такой: технический менеджер проектирует не только людей в оргчарте. Он проектирует поток ценности. Границы команд, платформы самообслуживания, правила взаимодействия, архитектурные зависимости и память об оргрешениях влияют на скорость разработки не меньше, чем фреймворки и процессы. #Management #Architecture #Engineering #TeamTopologies #Product #Leadership

The Developer's Playbook for LLM Security (Рубрика #Books) Прочитал эту книгу за авторством Steve Wilson, который был руководителем проекта "OWASP Top 10 for LLM Applications". Брался за нее с вопросом, насколько книга 2024 года про безопасность больших языковых моделей еще актуальна в 2026-м. Ответ такой: как базовая инженерная рамка - да, очень. Как полный обзор текущей повестки - уже нет, потому что область за два года заметно уехала вперед. Книга ценна тем, что она не пытается объяснять безопасность LLM как набор страшилок про промпт инъекции”, а показывает более широкую картину: где проходят границы доверия, почему приложение с языковой моделью нельзя воспринимать как обычное приложение, как появляются утечки данных, что делать с галлюцинациями, обработкой ответа, цепочкой поставки, паспортами моделей, SBOM/ML-BOM, защитными ограничениями, проверками атакующими сценариями и эксплуатацией LLM-систем. Основные моменты из книги следующие 1️⃣ LLM - это не просто модель, а компонент программной системы. У него есть пользователи, контекст, данные, внешние источники, инструменты, среда выполнения, журналы, лимиты, права доступа и последствия действий. Поэтому безопасность нельзя повесить на один фильтр запросов перед моделью. 2️⃣ Промпт инъекции важны, но это не все. Ведь модель имеет доступ к внутренним сервисам, документам, базе знаний или инструментам, риск не в самом тексте, а в том, что он может сдвинуть поведение системы за границу допустимого. 3️⃣ Цепочка поставки в AI становится сложнее обычной цепочки поставки ПО. Кроме библиотек и контейнеров появляются модели, обучающие данные, векторные представления, подключаемые инструменты, шаблоны запросов, наборы для оценки качества и внешние провайдеры. Все это нужно описывать, версионировать, проверять и наблюдать в работе. 4️⃣ Важно выстроить безопасные процессы, а не просто реагировать на инциденты. Книга хорошо подводит к мысли, что безопасность LLM должна жить внутри разработки и эксплуатации: моделирование угроз, тесты, проверки атакующими сценариями, защитные ограничения, централизованные журналы, наблюдение, реакция на инциденты и регулярная переоценка рисков. Но в 2026 году книгу уже нельзя читать как исчерпывающий справочник. В 2024-м центр тяжести был вокруг чат-ботов, RAG-приложений и LLM как нового класса прикладной безопасности. Сейчас повестка заметно сместилась к агентам: вызов инструментов, автономные рабочие процессы, MCP, память, идентичность, злоупотребление правами, межагентные взаимодействия, наблюдаемость в работе и возможность остановить или откатить действия. OWASP это тоже отражает: помимо LLM Top 10 уже появились материалы по агентным приложениям и MCP Top 10. Чем больше агент может делать во внешнем мире, тем меньше безопасность похожа на “проверим ответ модели” и тем больше похожа на архитектуру доверия: кто дал цель, какие инструменты доступны, какие права выданы, что агент помнит, что пишется в журналы, кто подтверждает опасные действия и где находится аварийная остановка. Поэтому моя оценка такая: книгу стоит читать как хороший фундамент для инженеров, архитекторов, специалистов по безопасности приложений, техлидов и руководителей, которые запускают LLM-фичи в промышленную эксплуатацию. Она помогает поставить голову на место и перестать думать, что безопасность AI - это отдельный магический слой вокруг модели. #Books #AI #Security #LLM #Architecture #Engineering #DevSecOps

How a Group of Developers Took Back Control from Enterprise Java | Spring: The Documentary (Рубрика #Software) Посмотрел на выходных документалку про Spring. Я люблю такие фильмы про технологии: они показывают не только что появилось, но и какую боль технология изначально пыталась снять. История Spring особенно хорошая: это не просто рассказ про популярный Java framework, а история про то, как разработчики устали от тяжелой enterprise-модели и начали возвращать себе контроль над кодом. В начале 2000-х Enterprise Java выглядела очень солидно: спецификации, application servers, EJB, XML-дескрипторы, контейнеры, большие vendor'ы. Все как будто было устроено “по-взрослому”. Но для обычной разработки это часто означало медленный цикл обратной связи, сложное тестирование и ощущение, что простая бизнес-логика внезапно требует слишком много инфраструктурной магии. Spring появился как ответ на это трение. Rod Johnson сначала сформулировал критику тогдашнего J2EE-подхода в книге "Expert One-on-One J2EE Design and Development", а код из приложения к книге постепенно превратился в Spring. Мне нравится, что альтернатива пришла не как очередная большая спецификация сверху, а как практичный набор инженерных принципов снизу: POJO вместо тяжелых компонентов, Dependency injection и Inversion of Control вместо жесткой связки с контейнером. Тестируемость как нормальное требование к дизайну. Композиция объектов вместо ощущения, что настоящая архитектура обязательно должна быть спрятана в application server. По сути, Spring сказал разработчикам: бизнес-логика снова может быть обычным Java-кодом. Ее можно читать, подменять зависимости, тестировать отдельно и постепенно встраивать в большую систему. Сегодня это звучит почти банально, но тогда в этом был сильный архитектурный сдвиг. Отдельно интересно, что Spring не остановился на первой победе. Со временем он сам стал большим ecosystem, со своей конфигурацией, conventions и complexity. Следующим шагом стал Spring Boot: меньше ручной настройки, sensible defaults, embedded server, быстрый старт приложения. Boot хорошо попал в эпоху microservices, containers и cloud-native разработки, где старый подход “сначала собери всю enterprise-инфраструктуру вокруг приложения” снова стал слишком тяжелым. Но у этой истории есть и вторая сторона. Когда технология выигрывает, она становится инфраструктурой. А инфраструктура обрастает legacy, версиями, upgrade cost, security-патчами, совместимостью и long-term maintenance. Spring начинался как способ вернуть контроль разработчикам, а теперь сам является частью огромного enterprise landscape, которым нужно управлять аккуратно. Забавно, что главный спонсор этого фильма - компания HeroDevs, которая саппортит код legacy приложений, которые живут на фреймворках и библиотеках, что давно уже вышли из цикла поддержки, но никто не готов переписывать сами бизнес-приложения. В итоге, ребята из HeroDevs занимаются таким maintenance и фиксят в основном уязвимости в старой кодовой базе. Для меня главный вывод такой: сильные технологии часто появляются не из желания “сделать еще один framework”, а из желания убрать трение между идеей, кодом, тестом и production. Они побеждают не только фичами, а тем, что меняют повседневный опыт разработчика. #Software #Java #Spring #Architecture #Engineering #OpenSource #History

State of AI4SDLC (Рубрика #AI4SDLC) Появилась запись моего апрельского выступления на DevOps Conf с докладом про "State of AI4SDLC" или что сейчас реально происходит с AI в разработке и почему история уже давно не только про генерацию кода. Про само исследование я уже рассказывал много раз, поэтому коротко. AI уже стал повседневным инструментом для кодогенерации. По нашим данным, 58% часто или всегда используют AI для генерации кода, 64% видят рост продуктивности. Но дальше картинка сложнее: доверие к AI-коду остается низким, а качество не улучшается автоматически. Главный вывод для меня такой: AI ускоряет не весь SDLC, а отдельные его участки. Если ничего не менять в инженерной системе, bottleneck просто переезжает из написания кода в review, тесты, CI/CD, интеграцию, безопасность, релизы и управление контекстом. И вот здесь начинается самое интересное: мы движемся от Software Engineering 1.0 к Software Engineering 2.0. В классическом Software Engineering 1.0 разработка часто выглядит как цепочка стадий и handoff’ов: требования, дизайн, реализация, review, тестирование, релиз. Даже в agile-командах эта логика никуда полностью не исчезла: есть тикет, есть исполнитель, есть diff, есть ревью, есть pipeline. В AI-native варианте часть работы начинают делать ассистенты и агенты. Они могут писать код, предлагать тесты, читать документацию, анализировать баги, готовить PR, помогать с миграциями. Но человек при этом не исчезает. Скорее меняется его позиция. Разработчик становится не только автором кода, но и навигатором: задает intent, собирает context, формулирует ограничения, декомпозирует work graph, делегирует задачи агентам, проверяет результат и принимает инженерное решение. Мне все больше нравится описывать это как цепочку: intent -> context -> plan -> tasks -> implementation -> verification. И это сильно меняет привычный inner loop. Раньше основное усилие часто было в том, чтобы самому написать реализацию. Теперь все больше усилия уходит в то, чтобы правильно поставить задачу, дать системе достаточно контекста, ограничить пространство решений и построить проверку, которой можно доверять. Отсюда следующий важный сдвиг: классический ticket tracker начинает трещать. Тикет как “описание задачи + статус + комментарии” был нормальной единицей координации для людей. Но агенту этого мало. Агенту нужен связанный контекст: цель, ограничения, зависимости, решения из прошлого, права доступа, кодовая база, тесты, логи, критерии приемки, доступные инструменты и границы того, что можно менять. Новая единица работы - не тикет, а context-rich work graph, в котором человек и агент могут безопасно довести задачу до результата. Это влияет и на оргдизайн. AI-native организация - это не просто “меньше людей”. Скорее это меньше лишних handoff’ов, сильнее роль senior и staff engineers, больше self-service, сильнее platform engineering, больше automation и guardrails. То есть организация должна не только генерировать больше output’а, но и уметь безопасно его переваривать. Именно поэтому метрики usage почти ничего не говорят. Количество запросов к AI, включенных лицензий или сгенерированных строк кода - это vanity metrics. Смотреть надо на всю цепочку: adoption -> throughput -> quality/risk -> economics. То есть: используют ли инструмент; ускорились ли PR, review, time to merge и cycle time; не выросли ли дефекты, инциденты, security-риск и технический долг; какая экономика у этой новой скорости. Для разработчиков вывод в том, что надо уметь работать с AI как с инженерным контуром: декомпозировать задачи, писать хорошие acceptance критерии, проверять диффы, сгенерированные AI, понимать архитектурные последствия и держать в голове эксплуатацию. Для тимлидов, EM и CTO вывод еще жестче: AI-внедрение нельзя вести как закупку инструмента. Это изменение production-системы разработки. Нужны правила, доступ к контексту, безопасные контуры, CI/CD, тесты, ownership, platform engineering, evals, observability и метрики результата. #AI #AI4SDLC #Engineering #DevOps #Management #Architecture

Root Cause: Stories and Lessons from Two Decades of Backend Engineering Bugs (Рубрика #Books) Прочитал несколько глав книги Хусейна Нассера, популярного блоггера (500к подписчиков на канале), что рассказывает про software engineering. Брался я за нее из простого интереса почитать не просто про архитектуру, базы данных и распределенные системы, а скорее про то, как все это ломается на проде. Собственно, эти истории автор и обещает в описании своей книги. Автор считает, что опыт инженера измеряется не только годами, количеством фичей или строк кода, а количеством багов, которые он смог воспроизвести, отследить до root cause и исправить. Это звучит почти банально, пока не вспоминаешь, сколько настоящего инженерного знания приходит именно из таких расследований: где-то узнал, как браузер ограничивает HTTP/1.1 connections, где-то разобрался с HPACK в HTTP/2, где-то впервые увидел, как file descriptor limit превращается в 504 Gateway Timeout. Мне эта книга напомнила опыт, когда я сам работал с инцидентами, писал или разбирал постмортемы, а также как-то руководил секций траблшутинга для SRE-инженеров, что хотели попасть к нам в компанию и в итоге сделал пару публичных выступлений и статей (они сейчас есть на моем сайте system-design.space: описание самого подхода к интервью и пример такого интервью). Если же возвращаться к самой книге, то я прочел несколько глав и вот о чем они 1️⃣ История про системное замедление системы. Пользователи видят, что весь продукт стал медленным. Не один endpoint, не одна кнопка, не один сценарий, а как будто “все плохо”. В итоге расследование приводит к маленькому UI-элементу: поисковая строка показывает текст вроде “Search 550M items”, а JavaScript дергает API, который выполняет SELECT COUNT(*) по огромной таблице. Причем делает это снова и снова. В трейсе обнаруживается больше 100 тысяч таких запросов за 30 минут. Хорошая деталь здесь в том, что простой ответ “добавим CPU базе” был бы неправильным. Да, база была перегружена по CPU. Но причина была не в том, что база “слабая”, а в том, что продуктовый UI породил бессмысленную backend-нагрузку. Настоящее исправление — не вертикально масштабировать симптом, а убрать саму необходимость считать точное число там, где пользователю достаточно приблизительного. 2️⃣ Истории про live translation system, HTTP/1.1, HTTP/2 и load balancer И это, кажется интересная часть для архитекторов и технических руководителей. Сначала long-lived SSE-сессии упираются в браузерный лимит соединений на один host: седьмой запрос просто висит в client-side queue. Потом включение HTTP/2 решает эту проблему, но приносит другую: много маленьких запросов, TLS, frame parsing, stream state и HPACK начинают съедать CPU на backend. Потом появляется load balancer, backend переводят обратно на HTTP/1.1, статические ресурсы кэшируются, все становится лучше — пока unlimited backend connection pool не упирается в file descriptors и TCP receive window. То есть книга хорошо показывает неприятную, но реальную картину: архитектурное улучшение редко бывает “просто улучшением”. Оно меняет профиль отказов. HTTP/2 убирает один bottleneck, но добавляет CPU overhead. Load balancer разгружает backend, но приносит новые настройки и новые default values. Увеличение лимита file descriptors помогает, но не объясняет, почему столько соединений вообще было создано. В общем, книга действительно неплохо описывает реальность траблшутинга проблемы по всему стеку и поиск root cause проблемы. Она будет полезна инженерам, кто хочет не просто рассказывать про крутую архитектуру, но и понимать как разные компоненты могут работать друг с другом, если что-то пойдет не так. В итоге, книга напоминает скорее инженерный блог по разбору инцидентов, чем обычный академический учебник и может быть полезна еще и SRE инженерам для подготовки к тем же собеседованиям. #Books #Engineering #Software #Architecture #Management #SRE

Atomic Heart. Предыстория «Предприятия 3826»: как строилась советская техноутопия до сбоя (Рубрика #SciFi) Продолжая свое погружение в мир Atomic Heart, прочитал специальное издание "Atomic Heart. Предыстория «Предприятия 3826»" Харальда Хорфа, которая отличается цветными вставками и более плотной и белой бумагой от обычного издания. Про саму игру я уже рассказывал отдельно: для меня Atomic Heart оказался не просто шутером про роботов, а погружением в советскую техноутопию, где автономные системы, централизованное управление и вера в автоматизацию в какой-то момент начинают вести себя как большая распределенная система со сбойнувшим контуром управления (control plane). Также чуть раньше этого я разбирал сборник "Atomic Heart: Далёкое светлое будущее", который показывает мир до старта игры: витрины утопии, бытовых роботов, ощущение прогресса и тот самый момент, когда ты читаешь почти лог системы прямо перед тем, как все пошло по наклонной. Но новая книга показалась мне еще интереснее - она расскрывает всю историю от открытия полимера Сеченовым до научного рывка, роботизации, инфраструктуры Предприятия 3826 и движения к "Коллективу 2.0". Это крепкая научная фантастика, а не просто справочник с описанием основых персонажей - здесь раскрывается история о том, как большая технологическая мечта постепенно становится системой. Книга добавляет к игре не столько факты, сколько логичную историю с набором причин и следствий, в конце которых мы понимаем как мы оказались на месте майора Нечаева и понимаем кто и как сгенерировал этот сбой. Но это же означает, что книга содержит спойлеры, а значит ее стоит читать уже после прохождения игры. В игре мы уже видим последствия сбоя: агрессивных роботов, закрытые комплексы, поломанный контур управления и странное ощущение, что красивые лозунги будущего обернулись инфраструктурной катастрофой. А здесь видишь, почему люди вообще могли поверить в такую систему. Почему она выглядела не опасной, а логичной, прогрессивной и почти неизбежной. Это, кстати, хорошо дополняет мои предыдущие мысли про Atomic Heart. Большая автономная система опасна не потому, что роботы внезапно “злые”. Она опасна, когда масштаб, централизация, доступы, цели, governance и границы ответственности становятся частью архитектуры, но к ним относятся как к второстепенным деталям. В мире Atomic Heart это выглядит красиво: наука, заводы, полимер, роботы, коллективное будущее. Но инженерно ты все время видишь вопрос: а где план Б, observability, kill switch и независимый контур контроля? Мне кажется, что как отдельная фантастическая книга эта предыстория зайдет не всем, но она понравится тем, кому уже интересен Atomic Heart или кто хотя бы примерно понимает мир игры. Она делает мир плотнее и понятнее. После нее Предприятие 3826 воспринимается не просто как декорация для шутера, а как большой технологический проект со своей логикой, идеологией и архитектурной ценой. В общем, если вам нравится Atomic Heart, советская техноутопия, автономные роботы и истории о том, как “идеальное будущее” постепенно превращается в систему с огромным радиусом сбоя, книгу можно смело брать. #SciFi #Games #AtomicHeart #AI #Robotics #Architecture #SystemDesign

Почему AI делает инфраструктуру управленческой темой (Рубрика #AI) Пару дней назад вышла статья РБК про то, почему бизнес выбирает гибридную инфраструктуру. В этом интервью РБК от 19 мая генеральный директор Yandex Cloud Григорий Атрепьев говорит, что рынок корпоративного ПО в России по итогам 2025 года вырос до 808 млрд руб., а два главных фактора изменения рынка сейчас - информационная безопасность и искусственный интеллект. А сегодня я весь день преподаю в рамках программы ВШЭ “ИИ-лидеры: бизнес-лаборатория для руководителей” и рассказываю менеджерам про облака, DataOps, MLOps и AIOps. И эта статья отлично попадает в главный тезис моего рассказа: AI в компании начинается не с красивой демки модели. Он начинается с инфраструктуры, данных, безопасности, эксплуатации и управленческой готовности довести пилот до промышленного внедрения. Если возвращаться к тезисам Григория из статьи то они примерно такие 1️⃣ Искусственный интеллект и информационная безопасность - это комбо-связка. С одной стороны, компании живут в более агрессивной среде: по словам Yandex Cloud, в прошлом году они обрабатывали 103 млрд событий ежедневно в собственной SIEM-системе, в три раза больше год к году. С другой стороны, AI уже перестал быть только экспериментом: на платформе, по данным компании, создано более 18 тыс. агентов. 2️⃣ Дальше начинается самое интересное для менеджеров. AI быстро превращается в инфраструктурную задачу. Растет спрос на GPU, по исследованию Yandex Cloud и Apple Hills Digital среднегодовой темп роста этого сегмента до 2030 года оценивается в 23%. Меняются требования к ЦОД: если раньше стойка могла потреблять 5-6 кВт, то сейчас для AI-нагрузок речь идет уже о 100 кВт и выше. 3️⃣ На этом фоне гибридная инфраструктура выглядит не как компромисс “между облаком и своим железом”, а как рабочая модель зрелой компании. Публичное облако дает скорость экспериментов, быстрые пилоты и гибкое потребление ресурсов. Частный контур нужен там, где есть чувствительные данные, регуляторные ограничения, требования ИБ и уже сложившиеся корпоративные системы. 4️⃣ Но гибридность не достается бесплатно. В статье хорошо перечислены барьеры: разные инструменты и навыки, Kubernetes, API, мониторинг, синхронизация, резервное копирование, безопасность. А с AI добавляется новый слой: нужно контролировать агентов в корпоративных системах, разграничивать доступ к данным, защищать протоколы и наблюдать цепочки действий. Observability становится не только темой SRE, но и темой управления AI-рисками. В общем, управленческий вывод такой: AI-проекты чаще ломаются не на выборе или доступе к вашей любимой модели. Они начинаю буксовать на качестве данных, доступности инфраструктуры, отсутствии сильного бизнес-спонсора, непонятной модели ответственности и неспособности превратить пилот в повторяемый процесс. Поэтому менеджерам важно понимать не только "какую нейросеть купить". Важно понимать, какой контур данных, облаков, MLOps/AIOps, ИБ, мониторинга и эксплуатации нужен, чтобы AI не остался презентацией на несколько сотрудников, а стал частью корпоративной системы. #AI #Cloud #DataOps #MLOps #AIOps #Management #Engineering

No Drama - Color Lama (Рубрика #Brain) Я давно замечал, что у меня лучше работает голова, если я размышления совмещаю с физическим действием. Именно поэтому я часто провожу one-on-ones, гуляя вокруг нашего офиса. Потом у нас в офисе в каждой переговорке добавили карандаши и листочки раскраски - мне эта идея понравилась и я купил себе набор раскрасок. Я использую их теперь на некоторых онлайн встречах или просто когда надо подумать о чем-то глубоко, а руки требуется занять чем-то. В итоге, получается этакая арт-терапия, которая мне помогает фокусироваться. К посту прикрепил несколько раскрашенных картинок, что накопились за пару лет, что я практикую эту активность. #Thinking #Brain #Books

AI Dev Podcast #2: Александр Поломодов, Сергей Баранов / Архитектура в эпоху ИИ (Рубрика #Architecture) Около месяца назад мы записывали подкаст вместе с Сергеем Барановым (основателем ArchDays) и Андреем Дмтриевым (со-основателем JUG.RU) в рамках подготовки к сегодняшней конфе AI Dev Conf. Так получилось, что дальше я уехал в отпуск и забыл поделиться с вами этим эпизодом, а он был интересным:) Речь в нем шла про то, как LLM и мультиагентные системы меняют software architecture и инженерные процессы. Обсудили двойственную природу ИИ: с одной стороны - демократизация разработки (через lovable.dev и аналоги), с другой - жесткая необходимость в инженерном фундаменте для масштабирования. Основными темами выпуска стали - От SOE 1.0 к SOE 2.0: как люди и агенты будут работать в связке. - Роль архитектора: больше не "чертежник", а стратег, валидирующий варианты от ИИ и выстраивающий внутренние модели. - Экономика: почему типовые решения уходят в автоматизацию, а ценность повторного использования компонентов взлетает до небес. - Болевые точки: бардак с данными и онтологиями, блокирующие зависимости между сервисами и проблема контекста. - Прогноз: как готовить платформу к "мажорной разработке" с агентами и почему локальные эксперименты с моделями станут базовым навыком архитектора. В итоге: агенты научатся писать код, делать ревью и документацию. Но ставить цели, изобретать и управлять контекстом останется за человеком. Тех, кто не адаптируется, ждет разорение. Компании уже поняли, что просто заменить людей ИИ недостаточно — им срочно понадобились специалисты, умеющие с ним диалогизировать. #AI4SDLC #AI #Engineering #Software #Processes #Management #Productivity

Spec-driven development (SDD): почему AI вернул спецификации в разработку (Рубрика #Engineering) Горячая тема spec-driven development мне кажется реинкарнацией старых подходов типа бородатых V-Model или RUP, что в районе двухтысячных использовались для описания инженерных процессов. Мне стало интересно поразмышлять, а почему так происходит и так появилась этот пост:) Старый spec-driven подход был про то, что сначала нужно описать требования, потом дизайн, потом реализацию, потом проверку. V-Model хорошо показывала эту симметрию: каждому уровню проектирования соответствует свой уровень validation/verification. Плюсы были в трассировке от требований к коду и проверяемости ожиданий, а минусы были в бюрократии и разрыве между документами и кодом. С AI ситуация поменялась. Спецификация стала рабочим интерфейсом между человеком и агентом. Если код пишет или сильно помогает писать агент, то главный вопрос уже не “как быстро я напишу реализацию руками”. Главный вопрос: насколько точно я могу сформулировать intent, ограничения, критерии приемки и способ проверки результата. Агенту мало сказать “сделай фичу”. Ему нужен контекст: что должно измениться, что не должно сломаться, какие сценарии считаются успехом, какие тесты запустить, где границы задачи. Поэтому современный spec-driven development выглядит примерно так: intent -> acceptance criteria -> plan -> tasks -> implementation -> verification. Теперь документы становятся исполняемым контекстом для агента. Спека используется для составления плана, план раскладывается на задачи, задачи делегируются, тесты и логи становятся доказательством работоспособности, а review проверяет не только diff, но и соответствие исходному намерению. Есть разные подходы к этому снаряду 1️⃣ GitHub Spec Kit прямо формулирует SDD как процесс “сначала определить, что строить, потом дать AI coding agent реализовать”. Там есть цепочка spec -> plan -> tasks -> implement, checklists, clarify/analyze шаги и интеграции с разными агентами. Тут соль в agent-agnostic идее: спецификация становится переносимым контрактом, а не промптом для одного IDE. 2️⃣ Kiro от AWS идет похожим путем, но более продуктово. У них spec обычно раскладывается на requirements.md, design.md, tasks.md; отдельно есть steering-файлы для постоянного знания о проекте: архитектура, стек, conventions, структура. Это уже очень похоже на попытку сделать из AI coding управляемый процесс разработки feature или bugfix. 3️⃣ Codex и подход harness engineering показывают третий вариант. Там важны AGENTS.md, знание репозитория, configured dev environment, тесты, логи, PR review и возможность запускать несколько задач параллельно. В таком мире prompt начинает напоминать хорошо написанный GitHub issue: цель, контекст, ограничения, expected behavior, команды проверки. 4️⃣ Есть и lightweight-вариант, который, кажется, сейчас самый практичный для многих команд: PRD/RFC/issue + acceptance tests + CI + agent instructions. Без отдельного фреймворка. Главное, чтобы у задачи был четкий “definition of done”, а агент мог доказать, что он его достиг. На практике это дает несколько преимуществ - Меньше неопределенность - агент хуже всего работает там, где человек сам не решил, чего хочет - Большие задачи проще делегировать - их можно резать на независимые pieces и проверять по частям - Появляется трассировка между намерением, дизайном решения, задачами и тестами - Review перестает быть только чтением diff'а - он становится проверкой: “достигли ли мы цели, которую сами же сформулировали?” Правда, не все так безоблачно - spec-driven development (SDD) сам по себе не гарантирует качество. Пeлохая спецификация просто быстрее производит неправильный код. #Engineering #AI #Software #Architecture #Management #DevTools #Agents #ML #SystemDesign

Билеты на AI Dev Conf (Рубрика #Conference) Я вхожу в программный комитет конференции AI Dev Conf, а заодно и выступаю на этой конференции с keynote докладом про "State of AI4SDLC". Сама конференция пройдет уже завтра, а у меня есть пара билетиков, что я готов раздать подписчикам канала. Для того, чтобы претендовать на билетик вам надо порекомендовать мне в комментариях интересные whitepapers про внедрение AI в разработку, метрики и результаты. Но важно не просто накидать whitepapers, но и объяснить почему они вам понравились и какие интересные инсайты вы из них почерпнули. В конце этого дня я определю двух победителей и отправлю им билетик в личку. #AI #Engineering #Architecture #ML #Software #Economics #Software

Gemini 3.5: Google делает ставку на агентные workflow (Рубрика #AI) Посмотрел вчерашний анонс Gemini 3.5 с Google I/O. Формально Google опубликовала его 19 мая 2026 года, и мне кажется, важная часть здесь не в очередной гонке benchmark'ов, а в том, как компания формулирует следующий слой применения моделей. Если коротко, то Google представила семейство Gemini 3.5 и начала с 3.5 Flash. А модель 3.5 Pro, по словам Google, уже используется внутри компании и должен пойти в rollout в следующем месяце. Интересно, что Flash больше не выглядит как “быстрый младший брат” большой модели. Его прямо позиционируют как модель для frontier-level agents and coding. Это сильный сигнал того, куда сдвигается рынок. Еще недавно основной разговор был вокруг “насколько хорошо модель отвечает на сложные вопросы”. Теперь все больше разговоров про другое: может ли модель выполнить длинную задачу автономно, разложить ее на шаги, пользоваться инструментами, запускать субагентов, поддерживать контекст и доводить работу до конца. По утверждению Google, 3.5 Flash обходит Gemini 3.1 Pro на ряде кодинговых и агентных бенчей: Terminal-Bench 2.1, GDPval-AA, MCP Atlas, CharXiv Reasoning. Google также говорит про скорость вывода до 4x относительно других frontier-моделей. Интересно проверить эти заявления на в собственных сценариях, но по бенчам ожидания от модели большие. Если смотреть на саму модель, то видно, что сделана ставка на long-horizon tasks. В посте Google много примеров не про “ответь на вопрос”, а про “сделай работу”: поддержка codebase, подготовка финансовых документов, анализ неструктурированных ассетов, миграция legacy codebase, генерация интерактивных UI, параллельные подходы к UX-задачам. Это уже не чат как интерфейс к модели, а модель как исполнитель внутри workflow. Отдельно интересно, как они описывают Antigravity (это их IDE, что круто умеет в фронтовые задачи). В связке с обновленным harness 3.5 Flash должен запускать коллаборативных субагентов и выполнять многошаговые кодинговые задачи под наблюдением. По сути, Google двигает идею supervised execution: модель не просто предлагает фрагмент решения, а становится оркестратором набора действий, которые человек или система контролируют. Enterprise-примеры тоже показательные. Shopify использует субагентов для долгого анализа данных, Macquarie Bank пилотирует онбординг по документам на 100+ страниц, Salesforce интегрирует Flash в Agentforce, Ramp применяет мультимодальное понимание к распознаванию инвойсов , Xero автоматизирует многошаговые налоговые workflows, Databricks смотрит в сторону диагностики проблем в сложных data environments. Это, конечно, кейсы из материала Google, но они хорошо показывают направление: модели тащат в рутину компаний, где много документов, данных, проверок и tool calling. Еще одна важная деталь: Google несет agentic слой не только в инструменты для разработчиков. 3.5 Flash становится дефолтной моделью в Gemini app и AI Mode in Search, а новый Gemini Spark описан как персональный AI агент, который работает 24/7 и действует по указанию пользователя. То есть одна и та же логика идет сразу в три стороны: разработчики, enterprise и массовые пользовательские продукты. Про safety тоже стоит сказать осторожно. Google пишет про Frontier Safety Framework, усиленные кибер и CBRN (Chemical, Biological, Radiological, and Nuclear) safeguards, более продвинутое safety training и interpretability tools. Это правильные слова, но реальную безопасность мы увидем, когда модель попадет в руки миллионов пользователей, разработчиков и остальных желающих. В общем, Gemini 3.5 показывает, что фронтирная гонка смещается к агентной модели, где фронтир модели используются для выполнения автономных задач, через декомпозицию их на части, использование инструментов, запуск субагентов, поддержку контекст и все остальное ... для того, чтобы доводить работу до конца:) #AI #Google #ML #Engineering #Software #Management #Agents

Empire of AI (Рубрика #Books) Дочитал вчера книгу "Empire of AI" от Karen Hao, которую купил в Foyles во время поездки в Лондон. Вообще мне было сложно оторваться от чтения этой книги и пока летел в Москву я прочел ее на треть - вроде бы ты уже знаешь основные события вокруг OpenAI, но в связном рассказе они начинают выглядеть совсем иначе. В этой книге речь не про ChatGPT как продукт и про то, как устроены трансформеры. Скорее она про ранние годы GenAI-революции и про компанию, которая оказалась в странном положении: одновременно исследовательская лаборатория, стартап, идеологический проект, инфраструктурный клиент Microsoft и организация, заявляющая, что строит технологию с рисками для всего человечества. Мне особенно понравились следующие моменты 1️⃣ Динамика основания OpenAI В ретроспективе легко думать, что все шло по прямой: собрались умные люди, взяли много compute, сделали GPT, потом ChatGPT, дальше все понятно. Но из книги хорошо видно, что прямой дорожки там не было. Были амбиции, страх перед концентрацией AI у больших компаний, конфликтующие представления о миссии, деньги, эго, исследовательская неопределенность и очень быстро меняющаяся реальность. 2️⃣ Трение между Илоном Маском и Сэмом Альтманом Это не просто драматическая деталь для биографии. Через этот конфликт лучше видно, насколько разные модели власти и контроля могут стоять за одной и той же публичной риторикой про “безопасный AI для человечества”. Кто принимает решения? Кто владеет рычагами? Кто определяет, что значит безопасность? В AI-компаниях эти вопросы не второстепенные, а архитектурные. Интересно, что буквально на днях закончился суд между Максом и OpenAI на тему конвертации из non-profit организации в коммерческую 3️⃣ Политические истории про внутренние “кланы” OpenAI: Applied, Research и Safety Для меня это один из главных инженерно-управленческих слоев книги. Applied тянет к продукту, пользователям и развертыванию продуктов. Research двигает frontier и живет логикой научного прорыва. Safety пытается удержать под контрлем вопрос последствий и рисков. По отдельности все три культуры понятны и нужны. Но в одной компании они создают постоянное напряжение: скорость против осторожности, продукт против исследования, миссия против рынка. 4️⃣ Партнерство с Microsoft Книга помогает почувствовать, что прорывы GPT были не только результатом моделей и данных. Это еще история про инфраструктуру, поиск капиталов, доступ к compute, способность превращать research в работающую систему и выдерживать темп, на котором обычные организационные процессы начинают разваливаться. Без этого слоя легко романтизировать AI как чистую науку, хотя на практике frontier двигает связка research, infra, product, funding и distribution. 5️⃣Кризис с советом директоров Я хорошо помнил его как новостной хаос: увольнение Альтмана, возвращение, давление сотрудников, Microsoft на фоне, странные заявления и почти полная непрозрачность. Но в книге этот эпизод читается не как внезапная авария, а как результат противоречий, которые копились с самого начала: nonprofit-миссия, коммерческая реальность, safety-опасения, персональная власть и цена лидерства на frontier. Отдельно стоит отметить, что эта книга подает историю с авторской точки зрения Karen Hao, которая закончила MIT и работала долго журналистом, освещая события в сфере технологий и AI. В итоге, она провела целое расследование в 300+ интервью и собрала кучу материалов, чтобы суметь оценить то, что происходило за закрытыми дверями компании OpenAI:) Рекомендую книгу всем, кто хочет понимать GenAI не только как набор моделей, бенчмарков и API, но как систему людей, власти, инфраструктуры и организационных компромиссов. Особенно полезно инженерам, руководителям и архитекторам: после этой книги лучше видно, что frontier двигается не только в лаборатории, но и в структуре компании. #Books #AI #OpenAI #Engineering #Management #Research

Empire of AI (Рубрика #Books) Дочитал вчера книгу "Empire of AI" от Karen Hao, которую купил в Foyles во время поездки в Лондон. Вообще мне было сложно оторваться от чтения этой книги и пока летел в Москву я прочел ее на треть - вроде бы ты уже знаешь основные события вокруг OpenAI, но в связном рассказе они начинают выглядеть совсем иначе. В этой книге речь не про ChatGPT как продукт и про то, как устроены трансформеры. Скорее она про ранние годы GenAI-революции и про компанию, которая оказалась в странном положении: одновременно исследовательская лаборатория, стартап, идеологический проект, инфраструктурный клиент Microsoft и организация, заявляющая, что строит технологию с рисками для всего человечества. Мне особенно понравились следующие моменты 1️⃣ Динамика основания OpenAI В ретроспективе легко думать, что все шло по прямой: собрались умные люди, взяли много compute, сделали GPT, потом ChatGPT, дальше все понятно. Но из книги хорошо видно, что прямой дорожки там не было. Были амбиции, страх перед концентрацией AI у больших компаний, конфликтующие представления о миссии, деньги, эго, исследовательская неопределенность и очень быстро меняющаяся реальность. 2️⃣ Трение между Илоном Маском и Сэмом Альтманом Это не просто драматическая деталь для биографии. Через этот конфликт лучше видно, насколько разные модели власти и контроля могут стоять за одной и той же публичной риторикой про “безопасный AI для человечества”. Кто принимает решения? Кто владеет рычагами? Кто определяет, что значит безопасность? В AI-компаниях эти вопросы не второстепенные, а архитектурные. Интересно, что буквально на днях закончился суд между Максом и OpenAI на тему конвертации из non-profit организации в коммерческую 3️⃣ Политические истории про внутренние “кланы” OpenAI: Applied, Research и Safety Для меня это один из главных инженерно-управленческих слоев книги. Applied тянет к продукту, пользователям и развертыванию продуктов. Research двигает frontier и живет логикой научного прорыва. Safety пытается удержать под контрлем вопрос последствий и рисков. По отдельности все три культуры понятны и нужны. Но в одной компании они создают постоянное напряжение: скорость против осторожности, продукт против исследования, миссия против рынка. 4️⃣ Партнерство с Microsoft Книга помогает почувствовать, что прорывы GPT были не только результатом моделей и данных. Это еще история про инфраструктуру, поиск капиталов, доступ к compute, способность превращать research в работающую систему и выдерживать темп, на котором обычные организационные процессы начинают разваливаться. Без этого слоя легко романтизировать AI как чистую науку, хотя на практике frontier двигает связка research, infra, product, funding и distribution. 5️⃣Кризис с советом директоров Я хорошо помнил его как новостной хаос: увольнение Альтмана, возвращение, давление сотрудников, Microsoft на фоне, странные заявления и почти полная непрозрачность. Но в книге этот эпизод читается не как внезапная авария, а как результат противоречий, которые копились с самого начала: nonprofit-миссия, коммерческая реальность, safety-опасения, персональная власть и цена лидерства на frontier. Отдельно стоит отметить, что эта книга подает историю с авторской точки зрения Karen Hao, которая закончила MIT и работала долго журналистом, освещая события в сфере технологий и AI. В итоге, она провела целое расследование в 300+ интервью и собрала кучу материалов, чтобы суметь оценить то, что происходило за закрытыми дверями компании OpenAI:) Рекомендую книгу всем, кто хочет понимать GenAI не только как набор моделей, бенчмарков и API, но как систему людей, власти, инфраструктуры и организационных компромиссов. Особенно полезно инженерам, руководителям и архитекторам: после этой книги лучше видно, что frontier двигается не только в лаборатории, но и в структуре компании. #Books #AI #OpenAI #Engineering #Management #Research

State of AI4SDLC: как AI сдвигает узкие места процессов разработки Уже в 21 мая в четверг я выступлю на конференции AI Dev Conf с этим докладом, где продолжу разговор о State of AI4SDLC . Сейчас уже всем ясно, что AI в разработке перестал быть просто экспериментом, так как он массово используется для всех основных сценариев: coding, review, planning, debugging и работы с документацией. И теперь вопрос в том, а как встроить ускорение отдельных сценариев вокруг в наш продакшен цикл разработки: с понятной целью, достаточным контекстом, корректной интеграцией, доверием к результату и измеримым эффектом. Вообще, программа конференции получилась очень плотной и в этом большая заслуга программного комитета и организаторов (JUG.RU), к которой я тоже приложил руку, так как вхожу в ПК этой конфы. P.S. В конце конференции я еще буду модерировать круглый стол "Потребности ИТ vs. Возможности ИИ", где уважаемые доны - Рафаел Тонаканян (Сбер) - Андрей Кулешов (Yandex, SourceCraft) - Алексей Тотмаков (VK Tech) обсудят вопросы внедрения AI инструментов и оценки результатов такого внедрения (условно на какие метрики стоит смотреть или не стоит). #AI #Engineering #Architecture #ML #Software #Economics #Software

История робототехники: не одна линия, а несколько инженерных сдвигов (Рубрика #Robotics) Продолжая рассказ про то, почему робототехникой сейчас интересно заниматься, хочется сделать шаг назад. Текущая волна с AI, гуманоидными роботами, симуляторами и фундаментальными моделями выглядит новой, но она стоит на плечах гигантов, что творили историю раньше. Причем эта история не выглядела как одна прямая линия - на нее полезнее смотреть как на несколько шагов, которые постепенно складывались друг с другом: механическое действие, программируемость, восприятие мира и автономное поведение. 1️⃣ Автоматы Еще задолго до слова “робот” инженеры строили механизмы, которые после запуска выполняли последовательность действий. Герон Александрийский описывал устройства, работавшие от воды, пара и грузов. Аль-Джазари в XIII веке фиксировал сложные механические устройства в чертежах и описаниях. В XVIII веке Жак де Вокансон показывал автоматов как публичную демонстрацию инженерной точности. Это еще не робототехника в современном смысле, но здесь появляется важная идея: поведение можно “записать” в конструкции машины. 2️⃣ Культура В 1920 году Карел Чапек публикует R.U.R., и слово “robot” входит в массовую культуру. Это важный поворот: робот становится не просто механизмом, а фигурой, через которую общество обсуждает труд, контроль, ответственность и искусственную жизнь. Позже Айзек Азимов закрепляет слово robotics и формулирует свои законы робототехники. Инженерной дисциплины в строгом смысле там еще нет, но появляется язык, на котором люди начинают говорить об автономных машинах. 3️⃣ Промышленность В 1961 году Unimate устанавливают на линии General Motors. Здесь робот перестает быть образом из пьесы или выставочным автоматом и становится производственным активом. Важны не человекоподобность и не эффектность, а повторяемость, программируемость и способность работать там, где человеку тяжело или опасно. George Devol и Joseph Engelberger перевели идею из “можно представить” в “можно внедрять”. 4️⃣ Мобильность и AI Если промышленный робот чаще всего стоит в контролируемой среде, то мобильному роботу нужно понимать пространство и принимать решения. Здесь появляются У. Грей Уолтер с кибернетическими “черепахами”, а затем Shakey the Robot в SRI. Shakey был важен не скоростью и не практической готовностью, а архитектурной идеей: восприятие, планирование и действие можно собрать в одну систему. Это уже очень похоже на тот вопрос, который мы снова задаем сегодня: как соединить модель мира с физическим действием? 5️⃣ Выход из лаборатории и завода Sojourner показывает ценность роботов для исследования Марса. da Vinci делает робот-ассистированную хирургию заметной медицинской категорией. ASIMO превращает гуманоидную робототехнику в публичный символ. Roomba показывает, что бытовой робот может стать массовым продуктом, если задача достаточно узкая. FIRST и RoboCup добавляют еще один трек: робототехника как образовательная и исследовательская культура. 6️⃣ Open-source stack и новая AI-волна ROS, симуляторы, дешевые сенсоры, GPU и современные модели меняют темп разработки. Робот становится не отдельным железным устройством, а системой из механики, электроники, perception, planning, control, данных, симуляции и софта. Именно поэтому текущая волна интересна: она не возникла с нуля, а пытается соединить то, что десятилетиями развивалось отдельными линиями. Итого, история робототехники - это история о том, как машина постепенно училась действовать в мире: сначала механически, потом программируемо, потом с восприятием, а теперь с попыткой понимать задачу и контекст. #Robotics #History #Engineering #AI #Software

Почему заниматься робототехникой сейчас самое время (Рубрика #Robotics) Решил стартануть новую рубрику про робототехнику, к которой сейчас большой интерес с разных сторон. Но интересно, а почему он такой плотный? Ответ в том, что робототехника внезапно оказалась в точке, где несколько длинных инженерных линий сошлись вместе. 1️⃣ Промышленная база Роботы давно перестали быть фантастикой: по данным IFR (International Federation of Robotics), в 2024 году в мире установили 542 тыс. промышленных роботов, а годовые установки держатся выше 500 тыс. уже четвертый год подряд. То есть это уже большая производственная инфраструктура. 2️⃣ Достижения в AI Последние годы модели хорошо научились работать с текстом, изображениями, видео и кодом. Теперь следующий естественный вопрос: можно ли связать восприятие, язык и действие в физическом мире? Отсюда интерес к VLA (vision-language-action) моделям, embodied reasoning, роботам, которые не просто распознают сцену, а пытаются понять задачу и выполнить ее руками, колесами или ногами. 3️⃣ Данные и обучение У робототехники всегда была проблема: в интернете много текстов и картинок, но мало качественных данных о действиях роботов в реальном мире. Поэтому так важны проекты вроде Open X-Embodiment, где разные лаборатории собирают данные с разных типов роботов и пытаются учить модели переносить навыки между платформами. Это пока не “универсальный робот”, но это заметный сдвиг в сторону повторно используемого robotics intelligence. 4️⃣ Инфраструктура Симуляторы, синтетические данные, GPU, onboard compute, ROS (robot operating system), Isaac, MuJoCo и похожие инструменты постепенно делают робототехнику ближе к нормальной инженерной дисциплине, а не к магии из лаборатории. Все еще сложно, дорого и больно, но уже появляется стек, на котором можно строить системно. 5️⃣ Спрос Производство, склады, медицина, доставка, инспекция, сельское хозяйство, уход за людьми, опасные и повторяемые операции. Везде, где есть дефицит людей, высокая цена ошибки или тяжелая физическая рутина, робототехника перестает быть красивой демкой и становится экономическим вопросом. Мне кажется, поэтому сейчас хороший момент заниматься этой темой. Не потому что “все решено”, а наоборот: потому что базовые компоненты уже достаточно зрелые, а большая часть интересных вопросов еще открыта. Дальше я буду периодически писать про робототехнику и попробую делать это интересно:) Попробую сам для себя и для вас разобраться, а где у нас есть реальный инженерный прогресс, а где просто маркетинг, почему роботы так тяжело выходят из лаборатории и почему, несмотря на это, сейчас в теме происходит что-то действительно важное. #Robotics #AI #Engineering #Software #History

The Multi-Agent Architecture That Actually Ships — Luke Alvoeiro, Factory (Рубрика #Agents) Посмотрел интересное видео Luke Alvoeiro из Factory (их агент Droid когда-то выбивал первое место в terminal bench v1) про систему, где несколько AI-агентов ведут длинные engineering-задачи: планируют, пишут код, проверяют, чинят и не теряют контекст часами или днями. Мысль в том, что если раньше вопрос был “может ли модель написать код?”, то теперь вопрос в том, а может ли система автономно довести задачу до рабочего состояния и доказать, что результат корректный? Ребята из Factory называют это миссией (mission): пользователь описывает цель и scope, а дальше система разбивает работу на части, запускает агентов, валидирует результат и возвращает проблемы в цикл исправлений. 1️⃣ Multi-agent - это не запустить 10 агентов Сам по себе параллелизм не делает систему умнее. Важно разделение ролей: - Orchestrator уточняет требования, строит план и validation contract. - Workers реализуют конкретные части с ограниченным контекстом. - Validators независимо проверяют результат. Ценность не в количестве агентов, а в надежном цикле: plan → execute → validate → fix → repeat. 2️⃣ Контракт валидации пишется до кода Проверка должна появляться до реализации, так как если агент сначала написал код, а потом сам же написал тесты, то эти тесты легко становятся подтверждением уже принятого решения. В итоге, сначала формулируется, что должно быть истинным для пользователя и системы, и только потом пишется код. Это похоже на TDD, но на уровне всей задачи. 3️⃣ Validator должен быть независимым Проверяющий агент не должен тащить контекст автора реализации. Иначе он унаследует те же предположения и слепые зоны. То есть лучше проверять кодингова агента другой моделью, другой сессией или отдельным контекстом - по acceptance критериям, а не по объяснению автора (в этом случае автор - это исходный кодинговый агент) 4️⃣ Писать код лучше последовательно Если просто запускать агентов в параллель, то возникают проблемы - они одновременно меняют одни и те же файлы, появляются конфликты, дубли и несовместимые интерфейсы. В итоге, есть базовый подход, который может неплохо работать: write operations выстраивать последовательно, а research, чтение документации, поиск по кодовой базе и валидацию можно параллелить. 5️⃣ Состояние должно жить вне контекстного окна Длинная задача не может держаться только на памяти одного агента. Нужны внешние артефакты: validation contract, feature list, research notes, guidelines, knowledge base. Отсюда новый критерий качества репозитория: насколько он AI-ready. README, AGENTS.md, conventions, тесты, scripts, CI и понятные boundaries становятся инфраструктурой для автономной разработки. В итоге, получаем, что хороший AI workflow от автора доклада выглядит примерно так 1. Сначала validation contract. 2. Потом ограниченный scope. 3. Structured handoff: что сделано, что не сделано, какие команды запускались. 4. Независимая проверка. 5. И только потом merge. И ценность разработчика смещается от ручного написания кода к проектированию границ, проверок и контура исполнения. #AI #Agents #Architecture #SystemDesign #Engineering #Software #Management