Measuring the effectiveness of software development tools and practices (Рубрика #Productivity)

Я часто рассказываю про тему продуктивности инженеров, а также подходов к этому крупных компаний (смотри статьи от Google, или статьи запрещенной в России Meta), а также про то, как мы внутри Т-Банка подходим к этому. Но сегодня я хотел рассказать про подход Amazon к этому непростому снаряду - авторы предлагают метод измерения экономического эффекта от инструментов и практик разработки. Они предлагают смотреть на единую метрику CTS-SW (cost-to-serve software) - по сути, сколько ресурсов уходит на доставку единицы ПО до клиента. Эта метрика должна связать привычные engineering-метрики в духе DORA/SPACE с понятным бизнес-результатом: сэкономленной инженерной емкостью или деньгами.

Интересно, что у нас внутри Т-Банка тоже есть похожие подходы к расчетам, которые основаны на унификации процессов разработки и выделении уровня задач в командах, что приносят понятный бизнес-результат. Но давайте вернемся к оригинальной статье и посмотрим как работает подход авторов

1️⃣ Они берут "стоимость доставки ПО" как итоговую метрику, а не пытаются детально оценить каждый шаг разработки
Авторы говорят, что классический activity-based costing для софта слишком хрупок и поэтому они упрощают задачу до "входные затраты → единица результата", а затем уже ищут драйверы этой стоимости по всему жизненному циклу: coding, CI/CD, planning, incident management, maintenance, search for information и т.д. Единица результата тоже подбирается под архитектуру
- Микросервисы - деплои
- Монолит - зашипленный в мастер код
- Библиотеки - коммиты

2️⃣Дальше они строят панельные данные (микс факторов + время) и используют линейные смешанные модели
У них есть телеметрия по тысячам "two-pizza teams" за пять лет, и они моделируют CTS-SW через время разработчиков на деплой. Линейные смешанные модели нужны им потому, что они одновременно ловят общий эффект факторов и различия между командами. Так они нашли основные кандидаты-драйверы CTS-SW:
- Team velocity (сколько отревьювернного кода команда мерджит в неделю на инженера) - самый сильный предиктор
- Здоровье деливери (например, рейт ролбеков)
- Пейджи на on-call инженера

3️⃣ Переходят от корреляции к причинности через causal inference
После нахождения эффектов авторы ищут возможность для эксперимента. Таким естественным экспериментом для них стало внедрение genAI-инструментов, в частности Amazon Q Developer. Для оценки они строят панельную регрессию с dynamic two-way fixed effects: учитывают постоянные различия между командами, общие временные эффекты, лаг прошлой скорости и time-varying covariates вроде доли команды, использующей Q Developer, rollback rate и manual interventions. Цель - не просто увидеть корреляцию, а изолировать именно причинный вклад инструмента в CR velocity и deployment velocity.

4️⃣ Добавляют "страховку" от переоценки эффекта AI
Авторы отдельно признают, что если просто складывать эффекты разных экспериментов, можно завысить реальное влияние. Поэтому они разрабатывают baseline model, чтобы нормализовать оценки влияния AI-инструментов.

В общем, это явно интересный подход, который позволяет
- Решать, какие dev tools и AI tools масштабировать, исходя из измеримого эффекта
- Приоритизировать CI/CD автоматизации и практики надежности, потому что они свзяаны с лучшим CTS-SW.
- Создавать через онбординг условия для высокой team velocity, но использовать это именно как командную, а не индивидуальную метрику.
- Осторожно интерпретировать "полезные" сигналы

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

#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Software #Agents #Economics

Atomic Heart: советская техноутопия, автономные роботы и мультиагентные системы (Рубрика #Games)

Недавно прошел игру Atomic Heart, и это оказался один из тех редких для меня случаев, когда я был готов играть в одиночном режиме, а не в кооперативе с женой или детьми:) Конкретно мне понравилось оказаться внутри огромной советской техноутопии, где роботы должны были освободить человека от рутины, а в итоге все сломалось примерно так, как ломается большая распределенная система, если у нее есть автономия, но плохо настроены ограничения, наблюдаемость и контур управления:) Особенно забавно проходить такую игру вечером, когда днем на работе занимаешься построением мультиагентных систем:)

Интересные моменты, что мне зашли

1️⃣ Это не просто игра про роботов, а игра про доверие к автономии
В Atomic Heart роботы изначально выглядят как продолжение мечты про автоматизацию: они работают на заводах, помогают людям, обслуживают инфраструктуру и вообще должны быть частью удобного мира будущего. Но когда система управления начинает вести себя не так, вся эта красота превращается в проблему с огромным радиусом поражения. И это очень знакомая инженерная мысль. В software engineering мы тоже все время пытаемся отдавать больше автономии системам: сервисам, платформам, AI-агентам, автоматическим пайплайнам, self-healing инфраструктуре. Но чем больше автономии, тем важнее вопросы governance: кто ставит цель, кто ограничивает действия, кто видит аномалии, как устроен kill switch и что будет, если локально разумное поведение глобально начнет разрушать систему.

2️⃣ Советская эстетика как часть идеи
Мне понравилось, что сеттинг СССР здесь не ощущается просто декоративной оберткой. Это не "давайте нарисуем плакаты и поставим роботов на фоне серпа и молота". В игре сама идея будущего выглядит очень по-советски: единая большая система, централизованная научная программа, вера в инженерный прогресс, заводы как храмы модерна, человек как часть большого проекта. Если киберпанк часто рассказывает про корпорации, рынок и приватизированное будущее, то Atomic Heart скорее рассказывает про другую версию техноутопии: будущее как централизованная платформа. Почти госплан для роботов, нейросетей и автоматизированного быта.

3️⃣ Геймплей хорошо поддерживает ощущение системного сбоя
В игре ты постоянно чувствуешь, что находишься не просто на наборе уровней, а внутри большой инфраструктуры, у которой случился каскадный сбой. Камеры, локальные контуры безопасности, ремонтные дроны, роботы, которые возвращаются в строй, лаборатории, полигоны, подземные комплексы - все это создает ощущение живой, но враждебной системы. И это как раз одна из причин, почему одиночный режим здесь хорошо работает. В кооперативе было бы веселее, но потерялась бы важная часть атмосферы: ты один, вокруг автономные системы, не все объяснения надежны, а твой помощник в перчатке слишком много знает про происходящее, чтобы ему просто верить.

4️⃣ В игре хорошо показана цена красивой техноутопии
Atomic Heart постоянно играет на контрасте: солнечные парки, музыка, красивые здания, счастливые лозунги, и рядом - мертвые сотрудники, лабораторный хаос, биомеханические эксперименты и роботы, которые вместо помощи начинают устранять людей как источник проблемы. Это довольно сильная метафора для любой большой технологической программы. Пока система работает, все говорят про эффективность, автоматизацию и новый уровень жизни. Но когда она ломается, внезапно выясняется, что важны не только возможности, но и отказоустойчивость, безопасность, права доступа, аудит, границы ответственности и способность остановить систему до того, как она начнет масштабировать ошибку.

В общем, Atomic Heart мне понравился не только как шутер, а скорее как интересное погружение в мир автономных роботов, построенных явно не на трех законах робототехники Айзека Азимова:)

#Games #AI #Robotics #Agents #Architecture #Software #SystemDesign

Object Oriented Design Interview: An Insider’s Guide (Рубрика #SystemDesign)

Эта книга вышла в 2025 году как продолжение линейки “Insider’s Guide” от ByteByteGo, но уже не про высокоуровневый system design, а про более низкоуровневый объектно-ориентированный дизайн (OOD, object-oriented design), где идеи превращаются в классы, интерфейсы, состояния, потоки выполнения и так далее. Интересно, что уже почти готов и перевод от издательства Питер причем с моим отзывом на обложке книги:)

Авторами книги являются трио: Fawaz Bokhari, Alex Xu и Desmond Zhou, в котором Alex Xu известен лучше всего по начальной серии "System Design Interview: An Insider’s Guide", про которую я уже рассказывал (и которая теперь есть в разборе на system-design.space). В этой книге авторы решили рассказать про новый тип интервью, где проверяются умение строить логичные, расширяемые и поддерживаемые системы, применять принципы ООП и паттерны, а не просто писать синтаксически корректный код. Среди примеров, где используются такие интервью упоминаются Amazon, Bloomberg и Uber.

Книга выглядит как тренажер для кандидата, который получает три важные вещи

1️⃣ Рамка решения OOD-задач
В книге заявлен 4-шаговый фреймворк для любой object-oriented design задачи:
- Понять требования
- Выделить сущности и связи
- Продумать взаимодействия
- Уточнить дизайн и edge cases

2️⃣ Набор типовых задач
В книге 11 реальных OOD interview questions с подробными решениями: Parking Lot, Movie Ticket Booking, Unix File Search, Vending Machine, Elevator, Grocery Store, Tic-Tac-Toe, Blackjack, Shipping Locker, ATM и Restaurant Management System

3️⃣ Визуальная модель проектирования
В книге приведены 133 диаграммы, которые объясняют архитектуру, workflows и связи между частями системы. В общем, именно визуальная составляющая на интервью ясно кандидат показывает ответственности, границы, состояния и взаимодействия.

Первые три главы книги дают базовое понимание про объектно-ориентированное интервью, как к нему подходить и какие базовые принципы надо держать в голове. А следующие главы уже содержат конкретные задачи, которые можно использовать при подготовке. На каждой задаче стоит делать паузу до чтения решения: самому набросать классы, интерфейсы, последовательность вызовов и основные edge cases. Только после этого сравнивать с авторским решением.

Если смотреть на другие типы интервью, то объектно-ориентированный дизайн - это что-то посередине между кодинговым интервью и системным дизайном. Это уже выше по абстракции написания алгоритмов, но все еще про написание кода внутри сервисов. В этой схеме system design - это про то, какие сервисы есть, как они общаются, где хранятся данные и так далее. А вот low-level или объектно ориентированный дизайн отвечает: какие объекты живут внутри сервиса, кто за что отвечает, какие состояния возможны, где инварианты, как добавлять новые сценарии без переписывания всего кода. Поэтому книга хорошо дополняет классический System Design. Она не заменяет знания про distributed systems, но помогает довести архитектурную идею до уровня, на котором её реально можно реализовать.

#SystemDesign #OOD #Architecture #Interview #Software #Engineering

[1/2] Ranking Engineer Agent: как Meta превращает ML-эксперименты в автономный контур разработки моделей (Рубрика #AI)

С интересом прочел мартовскуюстатью запрещенной в России компании Meta про Ranking Engineer Agent, или REA. Это внутренний агент, который помогает развивать ads ranking модели: сам генерирует гипотезы, запускает тренировочные джобы, дебажит ошибки, анализирует результаты и идет на следующий цикл экспериментов. То есть это уже не copilot, который помогает инженеру на одном шаге, а агент, который пытается закрыть длинный инженерный workflow от идеи до кандидата на улучшение модели.

Суть в том, что бутылочное горлышко в ML-разработке у зрелых компаний давно находится не только в качестве моделей, а в скорости и дисциплине экспериментов. В обычном процессе инженер придумывает гипотезу, собирает конфиг, запускает обучение, ждет часы или дни, разбирает ошибки, смотрит метрики, делает выводы и повторяет цикл. Каждый такой оборот может занимать дни или недели, а на зрелых ranking-моделях значимые улучшения становится находить всё сложнее. Meta прямо пишет, что ручной и последовательный характер ML-экспериментов стал ограничением для инноваций.

REA интересен тем, что он атакует не отдельный шаг, а весь цикл. У него есть долгоживущее состояние, память по прошлым экспериментам, доступ к инфраструктурным инструментам, механизм ожидания долгих задач и guardrails по бюджету, правам и эскалациям. По сути, Meta делает из ML-экспериментирования управляемый производственный контур, который дает следующие возможности

1️⃣ Он снимает с инженера механику экспериментов
Запуск обучения, мониторинг, первичный дебаг инфраструктурных ошибок, сбор результатов, логирование выводов и подготовка следующей итерации - всё это типичная работа, которая важна, но плохо масштабируется вниманием человека.

2️⃣ Он позволяет вести много длинных экспериментов параллельно
Training job может идти часами или днями. Обычный чат-ассистент на этом месте просто “заканчивается”, потому что он ограничен длинной сессии. REA умеет уснуть после запуска задачи и проснуться, когда результаты готовы.

3️⃣ Он накапливает институциональную память
Каждый эксперимент попадает в базу инсайтов: какие гипотезы пробовали, какие конфиги работали, какие ошибки возникали, какие метрики получались. Это важно, потому что зрелая ML-разработка очень быстро превращается в задачу про память организации, а не только про талант отдельных инженеров.

4️⃣ Он повышает пропускную способность инженеров и повышает качество артефактов
В первой раскатке в прод Meta получила, по своим данным, 2x рост средней model accuracy относительно baseline по шести моделям и 5x рост пропускной способности: три инженера подготовили предложения по улучшению восьми моделей, тогда как раньше похожая работа требовала примерно двух инженеров на модель.

Я бы, конечно, аккуратно относился к таким цифрам, потому что это внутренние метрики Meta и конкретный домен ads ranking, но это уже не про токены, а про пропускную способность команд и качество их работы (метрики точности моделей).

В следующем посте я расскажу немного про то, как устроен этот агент.

#AI #Agents #Engineering #ML #Architecture #DevEx #Productivity #Management #Software #SystemDesign

[2/2] Ranking Engineer Agent: как Meta превращает ML-эксперименты в автономный контур разработки моделей (Рубрика #AI)

Продолжая рассказ про ML-агента от запрещенной в России компании Meta, надо рассказать про его архитектуру и устройство. Но начать надо с основных концепций

1️⃣ Hibernate-and-wake mechanism
Когда агент запускает долгую training job, он не держит активную сессию, а передает ожидание фоновой системе, сохраняет состояние и потом автоматически продолжает работу после завершения job. Это выглядит как важный паттерн для всех production-агентов, которые работают не с быстрым “ответь на вопрос”, а с процессами на часы, дни и недели.

2️⃣ Dual-source hypothesis engine
Гипотезы генерируются не только из головы LLM. REA опирается на два источника:
- Historical insights database - базу прошлых экспериментов, успехов и неудач;
- ML Research Agent - компонент, который исследует baseline-конфигурации и предлагает новые стратегии оптимизации.

3️⃣ Трехфазный planning framework
Перед запуском REA предлагает exploration strategy, оценивает GPU cost и согласует подход с инженером. Дальше план обычно идет в три этапа:
- Validation - проверка отдельных гипотез;
- Combination - комбинирование перспективных гипотез;
- Exploitation - более агрессивная оптимизация лучших кандидатов в рамках согласованного бюджета.

4️⃣ Planner + Executor
Внутри агент разделен на планировщика и исполнителя: REA Planner и REA Executor. Planner помогает сформировать план экспериментов, а Executor занимается асинхронным выполнением: запускает jobs, ждет, собирает результаты, обрабатывает ошибки и возвращает planner’у уже actionable output.

5️⃣ Skills, Knowledge and Tool System
REA подключен к внутренним инструментам Meta: job schedulers, experiment tracking, codebase navigation и другим системам. Плюс он работает на внутреннем agent framework Confucius (есть отдельный whitepaper), который как раз рассчитан на долгие многошаговые задачи в больших кодовых базах.

6️⃣ Guardrails и runbooks
Когда агент сталкивается с OOM (out of memory), loss explosion, инфраструктурной ошибкой или плохими результатами, он не зовет инженера по каждому поводу. Он сверяется с runbook’ом типовых проблем и действует в рамках заранее заданных ограничений. Но при этом доступы, preflight checklist, compute budget и остановка при превышении лимитов остаются под контролем людей.

В общем, REA - это связка из агента, памяти, инструментов, очередей, бюджетов, метрик, runbooks и точек контроля. Именно это отличает его от демки и делает production-системой.

У ребят из Meta есть дальнейшие план по развитию этого агента:
- Fine-tuning специализированных моделей для генерации гипотез
- Расширение аналитических инструментов
- Усиление privacy/security/governance
- Перенос подхода на новые домены

И это уже начало происходить. В следующем посте серии Meta рассказала про KernelEvolve - агентную систему для оптимизации низкоуровневых kernels под разные accelerator’ы: NVIDIA GPU, AMD GPU, MTIA и CPU. Там логика похожая: не one-shot генерация кода, а поиск по множеству вариантов, автоматическая проверка correctness/performance, профилирование и итерации. Meta пишет, что KernelEvolve дал более 60% improvement inference throughput для Andromeda Ads model на NVIDIA GPU и более 25% training throughput improvement для ads model на MTIA.

То есть траектория понятна: сначала агент помогает находить лучшие модели, потом помогает делать их production-ready через оптимизацию инфраструктуры, а дальше похожие agentic-подходы можно переносить на compiler optimization, memory management, system configuration и другие инженерные контуры.

#AI #Agents #Engineering #ML #Architecture #DevEx #Productivity #Management #Software #SystemDesign

[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 и постоянный контур улучшения.

В продолжении более подробный разбор фреймворка в 7 шагов от авторов книги.

#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-систему от красивого демо.

А в последнем посте мы посмотрим на задачи из книги.

#SystemDesign #AI #GenAI #Architecture #Engineering #ML #Interview #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

Кадры / 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

[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

[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

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

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”, а агент мог доказать, что он его достиг.

На практике это дает несколько преимуществ
- Меньше неопределенность - агент хуже всего работает там, где человек сам не решил, чего хочет
- Большие задачи проще делегировать - их можно резать на независимые кусочки и проверять по частям
- Появляется трассировка между намерением, дизайном решения, задачами и тестами
- Review перестает быть только чтением diff'а - он становится проверкой: “достигли ли мы цели, которую сами же сформулировали?”

Правда, не все так безоблачно - spec-driven development (SDD) сам по себе не гарантирует качество. Пeлохая спецификация просто быстрее производит неправильный код.

#Engineering #AI #Software #Architecture #Management #DevTools #Agents #ML #SystemDesign

System Design Space (Рубрика #Architecture)

Последние месяцы мало рассказывал про свой пет-проект system-design.space, но я не переставал над ним работать:)
По-факту, было 3 основных трека

1️⃣ Улучшение языка изложения - я хотел избавиться от runglish по всему сайту. Многие из вас говорили о том, что это мешает изучению материалов. В итоге, я сделал специальный подход с терминологическим словарем и рефакторингом проекта. Сейчас термин в первый раз внутри главы сопровождается английским термином в скобках + при наведении можно посмотреть расшифровку. Дальше по главе он идет уже на русском. Это касается почти всех терминов, но акронимы все равно остаются на английском

2️⃣ Добавление покрытия материалов по разным темам в основном вокруг проектирования ML/AI систем

3️⃣ Сборка книжки и подача ее в издательство - теперь у меня есть черновик, который возможно превратится в книгу.
В книге пока три основные части
- Принципы найма и проведения собесов в bigtech - мои статьи про найм у нас
- Принципы проектирования - тут тоже я пилил статьи и даже обучающие курсы по архитектуре
- Задачи на проектирование из домена ML/AI, описание и решение которых оформлено в том стиле, что мы используем внутри себя (по 7-шаговому фрймворку). Я выбрал задачки из этого домена для того, чтобы читатели разобрались на практике с тем, как работают эти технологии и что там нет магии, понимали их ограничения и рабочие режимы, а также лучше понимали как встраивать эти возможности в свои сервисы.
В книге есть еще 3 приложения
- Разборы других материалов на тему system design (книг и курсов)
- Немного про документалки о технологиях и зачем их смотреть
- Терминологический словарь
А в конце еще есть список ссылок на литературу

#SystemDesign #Architecture #Software #DistributedSystems #UX #Interview

Dylan Patel про AI-inference и про ко-дизайн софта и железа как залог кратного роста (Рубрика #AI)

Посмотрел выпуск Sequoia Training Data с Dylan Patel, основателем SemiAnalysis: "Why Hardware-Software Co-Design Is AI's Real 100x". Вообще, я слежу за работами этой компании (например, я разбирал их крутую статью "The Great GPU Shortage"). Это интервью с основателем компании было взято буквально на днях и классно подсвечивает, что улучшения в возможностях genAI систем основаны на совместном дизайне моделей и железа: модель, kernels, runtime, сеть, память, чип и дата-центр нельзя оптимизировать как независимые детали. Отдельный рост в "2x" в моделях, "2x" в ядрах (kernels) и "2x" в железе могут дать не 8-кратный рост, а скачок на порядок больше (100x), если модели и железj проектируются вместе. Или, наоборот, хороший чип может выглядеть слабым, если модель и софт под него не подходят (аля новые модели на старых чипах).

Самый конкретный пример в выпуске - InferenceX, живой benchmark SemiAnalysis для inference. По словам Patel, point-in-time бенчи быстро устаревают: модели меняются почти каждую неделю, PyTorch, vLLM, SGLang, драйверы и inference-оптимизации обновляются постоянно, а одно измерение через месяц уже плохо описывает рынок. Поэтому InferenceX каждый день прогоняет модели на разных типах железа и строит не одну цифру "кто быстрее", а кривую throughput / interactivity.

Это интересный взгляд на баланс пропускной способности и скорости токенов на пользователя - у пакетных задач и интерактивных кодинговых агентов разные экономики
- Если пользователь ждет ответ в цикле обратной связи, то задержка дорогая: можно платить больше за fast mode, спекулятивный декодинг или меньший размер батча
- Если нужно ночью прогнать пачку документов, важнее tokens per second на единицу железа, а не мгновенная реакция.
Итого, оценивать "лучшую модель" и "лучшую железку" стоит относительно рабочих нагрузок, бюджета задержек и цены ошибки.

Дальше Patel интересно рассакзывает про топовые лабы и по его мнению OpenAI, Anthropic, Google и DeepSeek расходятся не только по качеству моделей, но и по архитектурной форме. Различаются значимые компоненты
- Размеры матриц для перемножения
- Структура внимания (attention)
- Структура экспертов в MoE (mixture of experts)
- Топология сети и пропускная способность памяти
- и так далее
В итоге, все это определяет где модель будет работать хорошо
По мнению Patel DeepSeek лучше ложится на Nvidia/Hopper/Blackwell-подобный мир (а теперь и Ascend от Huawei), TPUs сильны в других классах моделей, а Google оптимизирует Gemini под свои поколения TPU. В итоге, мы видим как модели становятся неотделимы от железа, на котором они будут жить.

Отсюда следует интересный взгляд на преимущества (moat) Nvidia, которое сегодня не сводится к тому, что все используют CUDA. Модели уже неплохо помогают писать кастомные ядра, а большие лаборатории давно могут форкнуть PyTorch или собрать свою инфраструктуру. Но важно, что все открытые модели, inference-провайдеры, RL-компании и downstream-экосистема часто оказываются оптимизированы под Nvidia просто потому, что там уже лежит масса рабочих моделей и обвязки. Если у Google появится сопоставимая открытая модельная экосистема под TPU, то ситуация может сместиться.

Мне кажется, это хороший антидот к простым разговорам про AI-железо. Каждый крупный игрок ищет оптимум для себя в связке model architecture + infrastructure software + silicon + power. Специализированный чип может быть прекрасным на одном участке пайплайна и неудачным через год, если архитектура моделей уехала в другую сторону. Поэтому стандартное железо для вычислений остается в мейнстриме не из-за лени рынка, а потому что даже большие лаборатории не всегда знают, какие модели будут запускать через год.

Патель дает интересные оценки и прогнозы, которые выглядят полезными для понимания этого рынка
- Стоимость inference на единицу качества падает примерно на 60x в год. Смысл в том, чтобы сравнивать надо не просто цену токена, а стоимость достижения сопоставимого уровня качества.
- Интеллект на Ватт растет не на 60x, но примерно на 40x в год
- Inference станет одним из крупнейших рынков в мире, возможно больше нефти. Это завязано на то, что ценность работы, которую AI сможет выполнять, станет огромной долей экономики
- К 2030 году OpenAI + Anthropic, по его прогнозу, могут иметь более 100 GW компьюта совместно, а потом к этому празднику жизни добавятся Meta, Google и остальные.
- К 2040 году inference deployments могут измеряться уже тераваттами, что следует из предыдущих прогнозов
- В 2030 году датацентры в космосе будут почти не важны: меньше 1% железа под инференс, а вот к 2040 году они займут потенциально больше половины инкремента компьюта

Итого, главный вывод из интервью такой, что AI-инфраструктура окончательно становится системной инженерией. Нельзя отдельно выбрать модель, отдельно купить железо, отдельно настроить serving и потом удивляться экономике. Нужно описывать классы задач, latency/cost curve, качество ответа, размер контекста, сетевые ограничения, доступную мощность, capital constraints и только потом решать, где нужен fast mode, где batch, где GPU, где TPU, где своя обвязка.

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

#AI #Engineering #Architecture #Infrastructure #Bigtech #Software #SystemDesign

AI для software architecture: почему в 2026-м copilot архитектора всё ещё не получился (Рубрика #Architecture)

Бегло пролистал систематический обзор литературы "Artificial Intelligence Support for Software Architecture Practice", в котором поставлен практичный вопрос - а какие архитектурные задачи AI уже умеет поддерживать и почему отдельные успехи пока не складываются в целостную практику. Первая версия появилась в 2025 году, но в 2026 году ее обновили и 2 июля 2026 года статья вышла в ACM Transactions on Software Engineering and Methodology. При обновлении обзор литературы доведен до августа 2025-го, добавлен срез массовых инструментов на март 2026-го.

Авторы начали свой анализ с 874 публикаций из четырех научных баз, отдельно проверили ICSA и ECSA и оставили 51 рецензируемое исследование. Затем сопоставили результаты с проблемами из предыдущих интервью с 32 практиками. И выяснили следующее

1️⃣ В ограниченных задачах AI уже полезен
Модель для выбора одного из трех паттернов по требованиям показала точность 70%; извлечение архитектурных зон ответственности из текста - около 75% полноты (recall) на четырех проектах. На корпусе из 95 ADR GPT-4 давал связные решения, но уступал человеку по полноте. Это не готовый «архитектор», а ускоритель первого прохода с обязательной проверкой.
2️⃣ Убедительнее всего выглядят задачи с измеримым контуром
На небольшом стенде Kubernetes комплексный фреймворк с прогнозированием нагрузки сократил время развертывания контейнеров на величину до 34%; RL-агенты лучше случайного chaos monkey находили критические отказы, правда, пока в симуляции. Промышленное подтверждение есть в автомобильных, аэрокосмических и киберфизических системах - там, где задача узкая, а quality attributes можно посчитать.
3️⃣ Ранний дизайн и стратегические решения остаются в основном академическими прототипами
Модели умеют предложить границы, паттерн или ADR по текущему контексту, но плохо удерживают организационные ограничения, регуляторику, историю компромиссов и последствия изменений.
4️⃣ В отдельном срезе 21 массового инструмента авторы увидели ту же асимметрию
Больше всего AI-функций уже есть в observability, governance, conformance и локальной генерации. Слабее всего - в рассуждении на уровне всей системы, двусторонней связи intent/ADR/code/runtime и накоплении сигналов архитектурной эрозии во времени.

В общем, если обобщить, то на уровне текущего среза AI инструменты уже помогают с архитектурными решениями, но на уровне helicopter view и эволюции архитектуры во времени они пока не тянут.

Если смотреть на подход авторов к анализу, то они выделили (картинки приложил)
- Software Architecture challenges
- AI-specific challenges
- И список тем, в которых есть AI инструменты
И сделали маппинг между ними и дальше из этого получили инсайты выше

Если анализировать актуальность работы в 2026 году, то можно увидеть, что с 2025 года появились ArchBench, R2ABench, CAKE и SAKE - то есть один из пунктов роадмапа авторов этого обзора (архитектурные датасеты и бенчи)уже начали закрывать. Но результаты пока скорее подтверждают диагноз авторов
- В R2ABench модели хорошо строят синтаксически корректные диаграммы и извлекают сущности, но слабо связывают их отношениями, из-за чего архитектура получается фрагментированной; агентные процессы (agentic workflows) добавили нестабильности, а не устойчивого выигрыша
- SAKE отдельно предупреждает: знание архитектурных терминов - необходимый фильтр, но не доказательство способности проектировать конкретную систему с ее trade-offs.

Роадмап развития AI в архитектуре от авторов статьи вообще выглядит примерно так
- Живая архитектурная база знаний: требования, решения, код, телеметрия со сквозной traceability
- Живые арх метрики и проверяемые бенчи
- Поверх этого уже можно строить архитектурный интеллект, который развивается вместе с системой: AI играет роль сильного аналитика, а человек остается стратегом и отвечает за контекст, приоритеты и компромиссы.

Вообще можно использовать такие 2 вопроса как лакмусовую бумажку:
- Если меняется требование, то мы можем понять затронутые ADR, компоненты, код, атрибуты качества и рантайм сигналы?
- Если случился инцидент, то можем ли мы отследить в обратном направлении до архитектурного запашка, а дальше вообще к решению, которое его породило?
Если нет, LLM лишь сделает красивее очередной статический снимок - полезный архитектурный AI со связности инженерных данных и способности проверить рекомендацию на истории системы.

В общем, AI повышает цену архитектурной дисциплины - чем дешевле локальная генерация решений, тем важнее удерживать намерение, границы, trade-offs и последствия во времени.

#Architecture #AI #AI4SDLC #Engineering #Research #Software #SystemDesign

Мысли про архитектуру (Рубрика #Architecture)

Поймал себя на мысли, что в своих пет-проектах я архитектуру улучшаю из идеи, что хочу быстро пилить фичи, но
- Не хочу тратить много денег на обслуживание - нужны эффеrтивные CI/CD пайплайны и оптимальная схема для работы в проде
- Не хочу тратить много времени на поддержание - приложения должны быть self-healing, а эволюция решения простой в нужную мне сторону
- Не хочу тратить много слов на объяснение агентам как пилить новые фичи (на объяснение что пилим тратить время готов) - должны быть заданы понятные архитектурные рамки
- Не хочу тратить много сил на ревью и разбираться с регрессионными багами - нужно много детерминированных проверок

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

P.S.
Мысли появились во время изучения whitepaper про AI для software architecture, ну и в рамках фиксов очередных проблем, где я чуток архитектурно залажал.

#Architecture #Engineering #Software #SystemDesign