Книжный куб

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

Everything I Learned Training Frontier Small Models - Maxime Labonne, Liquid AI (Рубрика #AI) Посмотрел этот короткий доклад Maxime Labonne, Head of Post-Training " Liquid AI, где Максим рассказывает, как Liquid AI проектирует и обучает edge-модели от архитектуры до reinforcement learning. Главная мысль доклада в том, что маленькие модели нельзя воспринимать как уменьшенные версии больших моделей. У них другая физика продукта: они живут на телефонах, ноутбуках, машинах, IoT и embedded-устройствах; они упираются в память, latency и качество конкретных задач, а не в универсальную способность работать в режиме чата. Основные идеи этого выступления следующие 1️⃣ Маленькая модель должна быть специализированной Большая frontier-модель может быть "средне хорошей во всем": код, текст, рассуждения, поиск, креатив, длинный контекст. Маленькая модель так не работает. У нее мало параметров, мало "памяти" для фактов и меньше пространства для самокоррекции. Поэтому хороший use case для small model - это закрыть узкий повторяемый workflow: extraction, structured outputs, function calling, tool use, приватная обработка пользовательских данных на устройстве. Liquid AI в посте про LFM2.5-350M прямо пишет про границы ее применимости. 2️⃣ Параметры могут быть потрачены не туда В слайдах Максим показывает, что у некоторых маленьких моделей embedding layer может занимать огромную долю параметров: например, 63% у Gemma 3 270M и 29% у Qwen3.5-0.8B. Для маленькой модели это очень дорого: формально параметров много, но "полезная емкость" модели оказывается сильно меньше. В LFM2.5-350M у Liquid AI embedding layer занимает 19% параметров, а effective size указан как 287M и это напрямую влияяет на latency, память и качество. 3️⃣ Считать FLOPs недостаточно - надо профилировать на целевом железе В докладе важный акцент сделан на on-device profiling. Liquid AI проектирует архитектуру не в вакууме, а смотрит, какие операции реально быстрые на целевых устройствах вроде Galaxy S24 Ultra и Ryzen HX 370. В общем, если вы строите AI-фичу под мобильное устройство, браузер, ноутбук или embedded, нельзя выбирать модель только по leaderboard. Надо мерить prefill, decode, memory footprint, quantization impact, cold start, battery и стабильность tool-calling именно на вашем runtime. 4️⃣ Больше pre-training может работать даже на маленьком масштабе Интуитивно кажется, что 350M-модель быстро "насытится" данными (про это даже есть Chinchilla scale of law). Но Liquid AI показывает обратную сторону: LFM2.5-350M получила дополнительный pre-training с 10T до 28T токенов и large-scale reinforcement learning. В официальном посте Liquid AI говорится, что модель превосходит более чем вдвое большие модели на ряде бенчей по знаниям, следованию инструкциям и использованию инструментов. 5️⃣ Doom looping - отдельный failure mode маленьких reasoning-моделей Очень интересная часть - про doom looping: когда модель застревает в повторении текста вместо того, чтобы дойти до ответа. Это особенно неприятно для маленьких reasoning-моделей и agentic-сценариев: пользователь ждет ответ, tool call или действие, а модель начинает повторять куски рассуждения. Liquid AI описывает свой способ борьбы с этим, что снизил doom loop с 15.74% до 0.36%. В итоге, оценивать надо не только accuracy, но и "поведенческие" ошибки типа зацикливания, пустых ответов и так далее. 6️⃣ Маленькие модели особенно интересны в agentic-системах Будущее не обязательно выглядит как “одна огромная модель отвечает на все”. Более реалистичная архитектура - router + набор специализированных моделей + инструменты + evals + fallback на большую модель. Большая модель может планировать, рассуждать, разбирать сложные случаи. Маленькая локальная модель может быстро и дешево исполнять планы. #AI #LLM #SmallModels #EdgeAI #Architecture #Engineering #ML #Agents #DevEx #Management

[2/2] Clojure: The Documentary (Рубрика #Architecture) Продолжая разбор документалки, расскажу про оставшиеся интересные моменты, что мне запомнились. 4️⃣ Concurrency не надо "побеждать локами" Clojure предлагает сделать так, чтобы большую часть данных можно было свободно шарить между потоками, потому что они immutable. А там, где состояние всё-таки меняется, пусть это происходит через явные и согласованные механизмы: refs, atoms, agents, STM. В документации Clojure прямо описано, что immutable core data structures легко разделяются между потоками, а изменение состояния координируется без ручного управления конфликтами через lock-и. 5️⃣ Практичность важнее идеологической чистоты Clojure не стал "очередным красивым языком в вакууме". Он сел на JVM, потому что там уже были инфраструктура, библиотеки, performance, доверие enterprise-клиентов и доступ к существующему Java-коду. И это было запланировано изначально: Clojure хотел быть Lisp для functional programming, symbiotic with an established platform и designed for concurrency. Для меня это один из главных уроков фильма. Новая технология получает шанс не тогда, когда она “правильная”, а когда она соединяет сильную идею с существующей реальностью бизнеса. 6️⃣ Стабильность - это не отсутствие развития, а продуктовая фича В фильме много говорится про консервативный подход к развитию Clojure: не принимать всё подряд, уметь говорить “нет”, сохранять совместимость, не ломать старый код ради ощущения движения. Релиз Clojure 1.0 состоялся в 2009 году и стал моментом стабилизации ядра языка, а дальше был фокус на backward compatibility. 7️⃣ Datomic - та же философия, только на уровне данных Datomic в этой истории выглядит как продолжение той же идеи: данные - это факты, история важна, прошлое не надо перезаписывать. Официальный сайт Datomic описывает его как распределенную транзакционную базу, где можно использовать всю историю критичных данных, а не только текущее состояние; факты не update-in-place, данные сохраняются по умолчанию, есть audit и query history. Для банков и fintech это звучит почти очевидно. Но забавно, что в обычной backend-разработке мы часто всё еще проектируем системы так, будто прошлое можно просто потереть update-запросом. В общем, документалка хорошо напоминает: Clojure - это не только язык со скобками. Это попытка ответить на вопрос: можем ли мы строить программы из более простых вещей? #Architecture #SoftwareDesign #EngineeringManagement #SystemDesign

[1/2] Clojure: The Documentary (Рубрика #Architecture) Посмотрел новую документалку CultRepo про Clojure и это история о том, как взгляд Rich Hickey на сложность превратился в язык, комьюнити,базу данных Datomic и вообще production-стек для компаний уровня Nubank (о котором я как-то уже рассказывал). В самом фильме появляется не только Рич, но и остальные ключевые люди, которые строили язык, писали про него книги, внедряли его в компаниях и использовали в больших системах. Ниже интересные моменты, подсвеченные в документалке и которые я вынес для себя (отдельно отмечу, что я не являюсь фанатом Clojure и мне этот язык всегда казался далеким от прода) 1️⃣ Язык программирования - это не синтаксис, а способ думать Clojure важен не потому, что это наследник Lisp и работает поверх JVM, этот язык навязывает определенную модель мышления, где программа строится из простых частей: immutable data, pure functions, explicit state transitions и минимального количества лишних приседаний. И это хороший вопрос для любой команды: ваш основной язык и фреймворки помогают думать проще или просто делают привычные вещи удобнее? 2️⃣ Simple и easy - разные вещи Фильм постоянно возвращается к идеям Rich Hickey из доклада "Simple Made Easy" 15 летней давности. И Рич разделяет их между собой так - Easy - это то, что рядом, знакомо и быстро дается текущей команде. - Simple - это то, где меньше переплетений, меньше скрытых зависимостей и меньше случайной сложности. Понимать это различие важно для технических руководителей - часто команда выбирает easy: знакомый фреймворк, привычную ORM, еще один слой абстракции, еще один микросервис, еще одну интеграцию. А потом через год оказывается, что система стала не simple, а просто знакомо-сложной. 3️⃣ Mutable state - главный источник боли Clojure пытается убрать из программы не всю изменяемость, а неуправляемую изменяемость. В официальном rationale прямо говорится, что Clojure строится вокруг Lisp, functional programming, JVM и concurrency, а также вокруг immutable persistent data structures и STM. Самая сильная идея здесь - разделить identity и state. Identity может жить во времени, но конкретное значение состояния должно быть immutable. Значение не меняется; система просто связывает identity с новым value. Это радикально меняет то, как мы думаем про баги, concurrency, аудит, отладку и историю данных. В посте-продолжении расскажу про оставшиеся интересные моменты. #Architecture #SoftwareDesign #EngineeringManagement #SystemDesign

Слепой патриотизм - новая работа Бэнкси (Рубрика #Culture) В конце апреля 2026 года в центре Лондона на площади Ватерлоо-плейс (Waterloo Place) появилась новая скульптура Бэнкси: человек в костюме с флагом на лице, шагающий с постамента. Прикольно иметь возможность лично посетить новую достопримечательность:)) #Travel #Culture

Harry Poter: Film Wizardry (Рубрика #Travel) Сегодня с женой и детьми были в студии Warner Brosers и детям очень понравилось. А мы с Настей уже посещали эту достопримечательность пару месяцев назад и тогда я так и не выбрал себе сувенир. В этот раз я исправился и купил интересную книгу с бекстейджом создания фильма. Отдельно отмечу, что в ней не только текст, но и еще куча приколюх типа письма о зачислении или билетов на кубок мира по квидичу. Доеду до отеля и смогу ее внимательно полистать. #Travel #Movie

Кадры / The Internship: Google как старая техноутопия и новая реальность AI-агентов (Рубрика #Culture) Недавно пересмотрели с женой фильм "Кадры" / "The Internship" 2013 года. На поверхности это довольно простая комедия с Винсом Воном и Оуэном Уилсоном: два олдскульных продавца, Билли и Ник, теряют работу, потому что их привычный мир уходит в цифру, а дальше пытаются попасть на стажировку в Google, хотя почти ничего не понимают в современной технологической культуре. У фильма довольно скромные 34% Tomatometer, так что это не киношедевр, но интересный артефакт индустрии. Главная мысль, которая сейчас смотрится совсем иначе: в 2013 году герои фильма боялись, что их знания устарели и их вытеснила цифровая экономика. Но спасением тогда выглядел BigTech. Google в фильме - это почти карьерный рай: кампус, бесплатная еда, умные люди, красивые офисы, веселые хакатоны, меритократия и шанс начать жизнь заново. А в 2026 году картина стала сложнее. Теперь уже сам BigTech не выглядит спокойной гаванью - сегодня внутри таких компаний тоже идет собственная перестройка: меньше слоев менеджмента, больше AI-инфраструктуры, больше автоматизации и больше ожиданий от каждого инженера. 1️⃣ Устаревают не люди, а способ создания ценности Билли и Ник в фильме не глупые. Они умеют продавать, договариваться, читать людей, поддерживать команду, вытаскивать слабых участников и превращать группу случайных людей в работающую систему. Их проблема не в отсутствии интеллекта, а в том, что рынок резко поменял интерфейс к ценности. Сейчас похожая история происходит с обычной разработкой. Если ценность инженера сводится к "быстро написать CRUD", "сверстать экран", "поправить тест", то эта часть работы все быстрее уходит к AI-инструментам и агентам. Но это не значит, что инженер становится ненужным. Это значит, что дешевеет конкретный способ создавать результат. 2️⃣ BigTech перестал быть финальной точкой маршрута В фильме Google выглядит как место, где можно "переизобрести себя" и получить билет в новую экономику. Это очень дух 2010-х: попади в правильную технологическую компанию - и ты снова на стороне будущего. Сейчас эта логика ломается: безопасной является не компания, а способность человека менять собственный уровень абстракции и создавать ценность с использованием AI. 3️⃣ AI-агенты бьют не только по junior-задачам Есть удобная версия реальности: AI заберет только самые простые задачи, а все сложное останется людям. Частично это правда, но не полностью. Под ударом оказывается любой инженер, senior или middle, если его работа распадается на хорошо делегируемые микрозадачи без сильного ownership вокруг результата. 4️⃣ Суперзвезды - это не обязательно “ML PhD”, а люди с agentic leverage Кажется, что индустрия теперь ищет только ML/AI-суперзвезд. И это правда: спрос на людей, которые понимают модели, данные, evaluation, inference, GPU-инфраструктуру и production AI, действительно вырос. Но важна и другая категория - инженеры, которые умеют строить и эксплуатировать контуры, где AI-агенты становятся частью production-системы. 5️⃣ Фильм хорошо показывает ценность “не кодовых” навыков, но сегодня этого мало В "Кадрах" герои выигрывают не потому, что внезапно становятся лучшими программистами. Они выигрывают потому, что умеют делать то, чего не умеют молодые технари вокруг них: собрать группу, вытянуть слабых, договориться, придумать нестандартный ход. Это все до сих пор важно. Более того, в мире AI это становится еще важнее, потому что когда код дешевеет, дороже становятся: - Постановка задачи; - Вкус к хорошему решению; - Коммуникация с бизнесом; - Понимание пользователя; - Способность довести дело до результата; - Ответственность за последствия. В общем, если подытожить, то теперь набор необходимых знаний и навыков выглядит шире: нужны знания домена, умение проектировать решения, навыки использования AI инструментов, ну и крутой уровень базовых инженерных практик. #SystemDesign #AI #GenAI #Engineering #Software

[3/3] System Design. Подготовка к сложному интервью по GenAI (Рубрика #SystemDesign) Заканчивая разбор книги (1 и 2), стоит посмотреть 10 задач, что подготовили авторы для тренировок 1️⃣ Gmail Smart Compose - система, которая прямо во время набора письма предлагает продолжение фразы. Здесь важно уложиться в очень маленькую задержку, показывать подсказку только когда модель достаточно уверена, и дополнительно фильтровать неудачные, токсичные или неуместные варианты. 2️⃣ Google Translate - система машинного перевода, которая принимает текст на одном языке и превращает в текст на другом языке. Главные вопросы: как работать с разными языками, как обучаться на многоязычных данных и как измерять качество перевода, если дословный перевод не всегда является лучшим. 3️⃣ ChatGPT-like Personal Assistant - персональный AI-ассистент, который ведет диалог, помнит контекст, может обращаться к внешним инструментам и подстраиваться под пользователя. Здесь особенно важны безопасность, управление памятью, приватность и контроль за тем, что ассистент может делать от имени человека. 4️⃣ Image Captioning - система, которая смотрит на изображение и генерирует его текстовое описание. Это пример мультимодальной задачи: на входе картинка, на выходе текст. Важно не просто "угадать объекты", а описать сцену так, чтобы это было полезно пользователю. 5️⃣ Retrieval-Augmented Generation - система, которая отвечает на вопросы не только из "памяти" модели, а сначала ищет релевантные фрагменты в документах, базе знаний или корпоративном поиске. Главные темы: как разбивать документы на части, как искать близкие по смыслу фрагменты, как заставить модель опираться на найденные источники и как показывать ссылки на них. 6️⃣ Realistic Face Generation - система генерации реалистичных лиц. Здесь важно не только качество картинки, но и риски: смещения в данных, генерация нежелательного контента, возможность злоупотреблений и необходимость защитных ограничений. 7️⃣ High-Resolution Image Synthesis - система генерации или улучшения изображений в высоком разрешении. Главная инженерная сложность в том, что такие операции дорого стоят по вычислениям, поэтому часто приходится строить многошаговый пайплайн: сначала грубая генерация, потом улучшение, детализация и увеличение разрешения. 8️⃣ Text-to-Image Generation - система, которая создает изображение по текстовому описанию. Здесь важно понять, как текстовый запрос превращается в визуальный результат, как управлять стилем и деталями изображения, а также как фильтровать запрещенные или небезопасные запросы и результаты. 9️⃣ Personalized Headshot Generation - система, которая генерирует персонализированный портрет пользователя, например деловую аватарку или фотографию для профиля. Основные сложности: сохранить узнаваемость человека, не нарушить приватность, правильно хранить и удалять пользовательские изображения, а также не допустить злоупотреблений с чужой личностью. 🔟 Text-to-Video Generation - система, которая создает видео по текстовому описанию. Это один из самых сложных классов задач: нужно не только генерировать красивые кадры, но и сохранять связность сцены во времени, движение объектов, стиль, персонажей и при этом управлять очень дорогими и долгими вычислениями. Эти задачи стоит не просто прочитать, а прорешать как тренировочные интервью - поставить таймер и самому набросать дизайн: требования, ML-формулировку, данные, модель, метрики, архитектуру, deployment и monitoring. А потом уже сравнить с авторским разбором. #SystemDesign #AI #GenAI #Architecture #Engineering #ML #Interview #Software

#SystemDesign #AI #GenAI #Architecture #Engineering #ML #Interview #Software

[2/3] System Design. Подготовка к сложному интервью по GenAI (Рубрика #SystemDesign) Продолжая тему книги, стоит обсуждть фреймворк из 7 шагов, который важен, так как такое интервью легко провалить разными способами, например - Отвечать как на обычном backend system design интервью и почти не говорить про данные, модели, качество генерации, hallucinations и safety - Говорить только про LLM, RAG, embeddings и fine-tuning, но забыть, что это все должно работать как production-система: с задержками, стоимостью, мониторингом, контролем доступа, fallback’ами и нормальной эксплуатацией А хороший фреймворк может помочь не свалиться в эти крайности. И ниже представлены шаги такого фреймворка 1️⃣ Clarifying requirements Сначала надо понять, что именно мы строим. "Чатбот", "генератор картинок" или "AI-ассистент" - слишком широкие формулировки. Хороший кандидат уточняет: кто пользователь, какой input и output, нужна ли персонализация, нужна ли память, какие языки и модальности поддерживаем, какой latency budget, сколько пользователей, можно ли ошибаться, какие требования к privacy и security, насколько критичны hallucinations. Это похоже на обычный System Design, но с AI-специфичными вопросами: можно ли использовать пользовательские данные, нужен ли RAG, нужен ли fine-tuning, какие safety-ограничения есть на входе и выходе. 2️⃣ Framing the problem as an ML task Дальше продуктовую задачу надо перевести в ML-формулировку. Например, Gmail Smart Compose - это не просто "помогать писать письма". Это text generation: на входе уже набранная часть письма, на выходе - короткое вероятное продолжение. RAG-система - это не просто «чатбот по документам». Это retrieval-augmented question answering: пользовательский запрос → поиск релевантных chunks → сбор контекста → генерация ответа → проверка и ссылки на источники. На этом шаге важно показать, что вы различаете generation, transformation, retrieval, ranking, summarization, captioning, translation и multimodal tasks. 3️⃣ Data preparation В GenAI данные - это часть качества системы. Надо обсудить: откуда берутся данные, как их чистить, как удалять персональную информацию, как фильтровать NSFW и токсичный контент, как бороться с bias, как делать чанки документов, как строить embeddings, как версионировать данные и индексы, как соблюдать права доступа. Для RAG это особенно критично. Если retrieval достал неправильный контекст, то даже хорошая LLM сгенерирует уверенный, но бесполезный ответ. 4️⃣ Model development Теперь можно обсуждать модель. Но не в формате "возьмем самую большую модель". Для Smart Compose может быть важнее маленькая и быстрая decoder-only Transformer-модель, потому что подсказка должна появляться почти мгновенно. Для Google Translate логичнее encoder-decoder Transformer, потому что это задача преобразования из одного языка в другой. В общем, хороший ответ включает объяснения компромиссов. 5️⃣ Evaluation Это один из самых важных шагов в этих задачах. В обычных ML-задачах часто можно говорить про accuracy, precision, recall. Но в GenAI все сложнее: у хорошего ответа может не быть единственного ground truth. Поэтому надо разделять: offline оценка, online оценка, оценка людей, продуктовые метрики, системные метрики, safety метрики. 6️⃣ Overall ML system design Это центральный момент: собрать систему целиком. В этот момент становится видно, что GenAI System Design — это не только ML, но и нормальная инженерия: сервисы, очереди, хранилища, кэширование, права доступа, observability, rollback, A/B-тесты и capacity planning. 7️⃣ Deployment and monitoring После запуска система не становится "готовой". GenAI-продукт надо постоянно мониторить: latency, token usage, cost per request, GPU utilization, timeout rate, safety filter trigger rate, hallucination signals, user feedback, retrieval quality, drift в данных, деградацию после смены модели или версии промпта, попытки prompt injection и abuse. Именно этот слой отличает production AI-систему от красивого демо. В последнем посте мы закончим посмотрим на задачи из книги.

[1/3] System Design. Подготовка к сложному интервью по GenAI (Рубрика #SystemDesign) Изучил интересную книгу для подготовки к интервью по System Design, но уже в новой реальности, когда проектировать надо не только базы, очереди, кэши и микросервисы, но и системы вокруг LLM, diffusion models, RAG, мультимодальных моделей и AI-powered продуктов. Это русское издание книги "Generative AI System Design Interview" из экосистемы ByteByteGo. Авторы - Али Аминиан и Хао Шенг. Али Аминиан уже известен по книге про ML System Design Interview, а здесь фокус смещается с классических ML-систем вроде поиска и рекомендаций на генеративный AI: чатботы, генерацию текста, изображений, видео, RAG и персонализированные AI-сценарии. В обычном System Design Interview кандидат часто рисует распределенную систему: API, балансировщики, базы данных, очереди, кэши, фоновые джобы, мониторинг. В GenAI-интервью все это остается, но появляется еще один слой сложности: - Какие данные нужны; - Какую модель выбрать; - Нужен ли RAG или fine-tuning; - Как измерять качество генерации; - Как бороться с hallucinations; - Как учитывать latency и стоимость инференса; - Как встроить safety-фильтры; - Как собирать feedback loop; - Как мониторить деградацию системы после запуска. Именно поэтому книга полезна не только ML-инженерам. Она хорошо ложится и на backend engineers, и на архитекторов, и на технических руководителей, которым сейчас приходится проектировать AI-фичи не как демо на API, а как часть production-системы. Внутри книги заявлены три главные вещи: 1️⃣ Фреймворк из 7 шагов для GenAI System Design Авторы предлагают не начинать сразу с "берем LLM и векторную базу данных", а последовательно пройти путь от требований до деплоя и мониторинга в проде. Это сильно дисциплинирует мышление, потому что в GenAI-задачах легко перепрыгнуть к модной технологии и забыть про реальные ограничения продукта. 2️⃣ 10 практических задач с подробными решениями Среди кейсов есть следующие: Gmail Smart Compose, Google Translate, ChatGPT-like personal assistant, Image Captioning, Retrieval-Augmented Generation, Realistic Face Generation, High-Resolution Image Synthesis, Text-to-Image Generation, Personalized Headshot Generation и Text-to-Video Generation. Этот набор покрывает разные сценарии и сильно шире, чем просто прикрутить трансформер к чат-боту:) 3️⃣ Много диаграмм и end-to-end разборов Для System Design это особенно важно. Хороший ответ на интервью - это не только "какую модель выбрать", но и то, как выглядит система вокруг модели: preprocessing, retrieval, prompt builder, inference service, post-processing, safety layer, logging, monitoring, feedback loop. Мне кажется, главная ценность книги в том, что она показывает: "GenAI-система - это не модель в вакууме". В общем, модель - это конечно ядро, но вокруг него есть данные, права доступа, индексы, промпты, ранжирование, guardrails, UX, стоимость, GPU-инфраструктура, A/B-тесты, метрики качества и эксплуатационные ограничения. И если все это не проектировать осознанно, то на выходе получается не production-система, а красивый прототип с непредсказуемым поведением. Книга полезна как способ обновить представление о System Design в эпоху AI, ведь раньше мы проектировали в основном детерминированный софт: запрос пришел, сервис обработал, база ответила, результат вернулся. Теперь все чаще приходится проектировать системы с вероятностным поведением: модель может ответить хорошо, средне, неверно, опасно, дорого или слишком медленно. Поэтому архитектура должна включать не только масштабирование и отказоустойчивость, но и evaluation, safety, feedback и постоянный контур улучшения. #SystemDesign #AI #GenAI #Architecture #Engineering #ML #Interview #Software