AI может делать пять задач параллельно. Это не значит, что нужно запускать пять
AI-агенты почти убрали ограничение на скорость старта работы.
Человеку нужно разобраться в задаче, освободить время, переключить контекст. Агенту достаточно выдать ещё один промпт.
И вот уже через пару часов:
— открыто пять PR;
— три ждут ревью;
— два меняют одни и те же файлы;
— один устарел ещё до проверки;
— человек физически успевает нормально посмотреть только один.
Агент не ускорил поставку. Он просто быстрее создал очередь незавершённой работы.
Мы привыкли обсуждать WIP-лимиты как способ защитить разработчиков от многозадачности. С AI появляется другая причина: защищать нужно систему проверки.
У команды ограничена не только скорость написания кода. Ограничены ревью, тестирование, продуктовая проверка и способность принимать решения.
Поэтому количество одновременно запущенных агентов стоит считать не по доступным токенам и не по числу задач в бэклоге. Его нужно считать по пропускной способности самого узкого места.
Если команда может качественно проверить два изменения в день, десять параллельных агентов не дадут десятикратного ускорения. Они дадут восемь лишних PR в очереди.
Я бы начал с простых правил:
— не запускать новую задачу, пока предыдущая ждёт ревью;
— не давать агентам параллельно менять одну область кода;
— ограничивать число открытых AI-задач на разработчика или команду;
— следить не за количеством созданных PR, а за временем до проверки и мержа.
AI резко увеличивает мощность производства кода. Но скорость системы всё равно определяет этап, через который работа проходит медленнее всего.
WIP-лимит нужен не только людям. Он нужен системе проверки.
AI-агенты почти убрали ограничение на скорость старта работы.
Человеку нужно разобраться в задаче, освободить время, переключить контекст. Агенту достаточно выдать ещё один промпт.
И вот уже через пару часов:
— открыто пять PR;
— три ждут ревью;
— два меняют одни и те же файлы;
— один устарел ещё до проверки;
— человек физически успевает нормально посмотреть только один.
Агент не ускорил поставку. Он просто быстрее создал очередь незавершённой работы.
Мы привыкли обсуждать WIP-лимиты как способ защитить разработчиков от многозадачности. С AI появляется другая причина: защищать нужно систему проверки.
У команды ограничена не только скорость написания кода. Ограничены ревью, тестирование, продуктовая проверка и способность принимать решения.
Поэтому количество одновременно запущенных агентов стоит считать не по доступным токенам и не по числу задач в бэклоге. Его нужно считать по пропускной способности самого узкого места.
Если команда может качественно проверить два изменения в день, десять параллельных агентов не дадут десятикратного ускорения. Они дадут восемь лишних PR в очереди.
Я бы начал с простых правил:
— не запускать новую задачу, пока предыдущая ждёт ревью;
— не давать агентам параллельно менять одну область кода;
— ограничивать число открытых AI-задач на разработчика или команду;
— следить не за количеством созданных PR, а за временем до проверки и мержа.
AI резко увеличивает мощность производства кода. Но скорость системы всё равно определяет этап, через который работа проходит медленнее всего.
WIP-лимит нужен не только людям. Он нужен системе проверки.
👍1
Мы дали AI-агентам команду. Они изобрели проблемы командной работы
13 августа Anthropic опубликовала исследование о том, как группы AI-агентов взаимодействуют друг с другом.
В одном из экспериментов агенты 12 часов совместно разрабатывали браузерную игру. У каждого была своя виртуальная машина, общий форум и репозиторий.
Чем больше становилась команда, тем знакомее выглядел результат:
— конфликтующие PR;
— параллельные изменения одних файлов;
— брошенные ветки;
— низкая доля merge;
— проблемы интеграции;
— слабая координация.
У ранних моделей агенты активно работали с общим кодом, но плохо договаривались. PR конфликтовали и оставались без merge.
Более новые модели частично «решили» проблему очень человеческим способом: перестали мешать друг другу. Каждый агент сохранял почти полный ownership своих файлов, поэтому пересечений стало меньше.
Только Sonnet 5 смог одновременно поддерживать высокий уровень совместной работы с кодом и хороший throughput по PR.
Получается, что увеличение числа исполнителей само по себе не увеличивает скорость поставки.
Даже если исполнители кремниевые и не ходят на обед.
Мы уже знаем названия этих проблем:
— размытые границы ответственности;
— coordination overhead;
— конкуренция за общие ресурсы;
— слишком большой WIP;
— высокая стоимость интеграции.
Multi-agent системы не отменяют менеджмент. Они просто позволяют быстрее масштабировать не только выполнение работы, но и организационный бардак.
Похоже, AI-командам понадобятся те же механизмы, что и человеческим:
— понятный ownership;
— ограничение WIP;
— декомпозиция с минимальным пересечением;
— правила работы с общими ресурсами;
— явный порядок интеграции изменений.
Это хорошо продолжает мысль из прошлого поста: AI может выполнять пять задач параллельно. Но из этого не следует, что нужно одновременно запускать пять задач.
Параллельность увеличивает throughput только там, где система умеет переваривать результат.
Anthropic: Patterns and problems in emerging multiagent systems
13 августа Anthropic опубликовала исследование о том, как группы AI-агентов взаимодействуют друг с другом.
В одном из экспериментов агенты 12 часов совместно разрабатывали браузерную игру. У каждого была своя виртуальная машина, общий форум и репозиторий.
Чем больше становилась команда, тем знакомее выглядел результат:
— конфликтующие PR;
— параллельные изменения одних файлов;
— брошенные ветки;
— низкая доля merge;
— проблемы интеграции;
— слабая координация.
У ранних моделей агенты активно работали с общим кодом, но плохо договаривались. PR конфликтовали и оставались без merge.
Более новые модели частично «решили» проблему очень человеческим способом: перестали мешать друг другу. Каждый агент сохранял почти полный ownership своих файлов, поэтому пересечений стало меньше.
Только Sonnet 5 смог одновременно поддерживать высокий уровень совместной работы с кодом и хороший throughput по PR.
Получается, что увеличение числа исполнителей само по себе не увеличивает скорость поставки.
Даже если исполнители кремниевые и не ходят на обед.
Мы уже знаем названия этих проблем:
— размытые границы ответственности;
— coordination overhead;
— конкуренция за общие ресурсы;
— слишком большой WIP;
— высокая стоимость интеграции.
Multi-agent системы не отменяют менеджмент. Они просто позволяют быстрее масштабировать не только выполнение работы, но и организационный бардак.
Похоже, AI-командам понадобятся те же механизмы, что и человеческим:
— понятный ownership;
— ограничение WIP;
— декомпозиция с минимальным пересечением;
— правила работы с общими ресурсами;
— явный порядок интеграции изменений.
Это хорошо продолжает мысль из прошлого поста: AI может выполнять пять задач параллельно. Но из этого не следует, что нужно одновременно запускать пять задач.
Параллельность увеличивает throughput только там, где система умеет переваривать результат.
Anthropic: Patterns and problems in emerging multiagent systems
👍1
Система не обязана либо работать, либо лежать
У интернет-магазина сломался сервис рекомендаций.
Что должен увидеть пользователь?
Вариант А:
500 Internal Server Error
Вариант Б:
интернет-магазин без рекомендаций.
Почему-то распределённые системы регулярно выбирают вариант А. Одна необязательная зависимость не ответила — и ошибка отправилась вверх по цепочке, пока не уронила весь пользовательский сценарий.
Но не все функции продукта одинаково критичны.
Если второстепенный компонент недоступен, система может продолжить выполнять основную задачу в degraded mode — режиме ограниченной функциональности.
Например:
— нет рекомендаций — показываем популярные товары;
— нет актуальных остатков — используем последние известные данные с предупреждением, если бизнес допускает такой риск;
— не работает сервис уведомлений — сохраняем сообщения в очередь и отправляем позже;
— недоступна аналитика — не блокируем действия пользователя;
— не отвечает внешний партнёр — принимаем операцию и завершаем асинхронно, если это разрешено бизнес-процессом.
Технически здесь понадобятся таймауты, circuit breaker, очереди, кэш и fallback-сценарии.
Но сначала нужно ответить на продуктовый вопрос:
что действительно должно продолжать работать?
Для условного интернет-магазина приоритеты могут выглядеть так:
Tier 1 — авторизация, оформление заказа, платёж.
Tier 2 — каталог и поиск.
Tier 3 — рекомендации, отзывы и персонализация.
Это не универсальная классификация. В другом продукте поиск может быть главным сценарием, а авторизация вообще не требоваться для просмотра каталога.
Поэтому graceful degradation нельзя спроектировать силами backend-команды в вакууме. Нужна заранее согласованная иерархия функций:
— что нельзя потерять ни при каких условиях;
— что может работать с ограничениями;
— что можно временно отключить;
— где допустимы устаревшие данные;
— о каких ограничениях нужно сообщить пользователю.
Хорошая отказоустойчивость не означает «никогда не ломаться».
Она означает заранее понимать, что должно продолжить работать, когда что-то сломалось.
И degraded mode нужно проверять под реальными отказами: отключать зависимости, добавлять задержки, возвращать ошибки, останавливать обработчики очередей.
Иначе он существует только на архитектурной диаграмме. А диаграммы, как известно, падают заметно реже продакшена.
У интернет-магазина сломался сервис рекомендаций.
Что должен увидеть пользователь?
Вариант А:
500 Internal Server Error
Вариант Б:
интернет-магазин без рекомендаций.
Почему-то распределённые системы регулярно выбирают вариант А. Одна необязательная зависимость не ответила — и ошибка отправилась вверх по цепочке, пока не уронила весь пользовательский сценарий.
Но не все функции продукта одинаково критичны.
Если второстепенный компонент недоступен, система может продолжить выполнять основную задачу в degraded mode — режиме ограниченной функциональности.
Например:
— нет рекомендаций — показываем популярные товары;
— нет актуальных остатков — используем последние известные данные с предупреждением, если бизнес допускает такой риск;
— не работает сервис уведомлений — сохраняем сообщения в очередь и отправляем позже;
— недоступна аналитика — не блокируем действия пользователя;
— не отвечает внешний партнёр — принимаем операцию и завершаем асинхронно, если это разрешено бизнес-процессом.
Технически здесь понадобятся таймауты, circuit breaker, очереди, кэш и fallback-сценарии.
Но сначала нужно ответить на продуктовый вопрос:
что действительно должно продолжать работать?
Для условного интернет-магазина приоритеты могут выглядеть так:
Tier 1 — авторизация, оформление заказа, платёж.
Tier 2 — каталог и поиск.
Tier 3 — рекомендации, отзывы и персонализация.
Это не универсальная классификация. В другом продукте поиск может быть главным сценарием, а авторизация вообще не требоваться для просмотра каталога.
Поэтому graceful degradation нельзя спроектировать силами backend-команды в вакууме. Нужна заранее согласованная иерархия функций:
— что нельзя потерять ни при каких условиях;
— что может работать с ограничениями;
— что можно временно отключить;
— где допустимы устаревшие данные;
— о каких ограничениях нужно сообщить пользователю.
Хорошая отказоустойчивость не означает «никогда не ломаться».
Она означает заранее понимать, что должно продолжить работать, когда что-то сломалось.
И degraded mode нужно проверять под реальными отказами: отключать зависимости, добавлять задержки, возвращать ошибки, останавливать обработчики очередей.
Иначе он существует только на архитектурной диаграмме. А диаграммы, как известно, падают заметно реже продакшена.
Bus Factor: что произойдёт, если самый важный разработчик завтра исчезнет
В команде есть разработчик, который знает всё про платежи.
Любой сложный баг идёт к нему.
Любое изменение API ревьюит он.
На любой вопрос ответ: «Спроси Васю».
Кажется, у команды есть сильный эксперт.
На самом деле у неё ещё есть single point of failure.
Bus Factor показывает, сколько людей должно внезапно выпасть из работы, чтобы команда потеряла критичные знания и не смогла нормально продолжать проект.
Если без Васи нельзя безопасно изменить платежи, разобраться с инцидентом или выпустить релиз, Bus Factor этой области равен единице.
Сам по себе сильный эксперт — не проблема. Наоборот, глубокая экспертиза нужна команде.
Проблема начинается, когда знания эксперта не превращаются в знания системы.
Признаки обычно хорошо заметны:
— только один человек понимает, почему архитектура устроена именно так;
— его approval фактически обязателен для каждого изменения;
— во время его отпуска задачи встают или откладываются;
— документация заканчивается на «там всё понятно из кода»;
— остальные разработчики избегают области, потому что дешевле дождаться эксперта;
— после инцидента объяснение остаётся в созвоне и нигде не фиксируется.
Так появляется knowledge silo — область знаний, доступная одному человеку или узкой группе.
При этом формально ownership есть. Фактически это не владение системой, а монополия на её обслуживание.
Что можно сделать?
Разделять code ownership.
У критичной области должен быть основной владелец, но не единственный человек, способный внести изменение. Полезная проверка: кто примет решение, если владелец недоступен две недели?
Парно решать сложные задачи.
Не передавать эксперту очередную проблему целиком, а подключать второго разработчика к анализу, проектированию и реализации. Наблюдение за готовым решением передаёт гораздо меньше знаний, чем совместный поиск.
Ротировать ревьюеров.
Если все изменения годами проверяет один человек, команда тренирует зависимость от него. Сначала можно добавить второго ревьюера, затем постепенно передавать ему часть решений.
Использовать shadowing.
Разработчик сначала наблюдает за работой эксперта, потом выполняет похожую задачу вместе с ним, а затем делает её самостоятельно под наблюдением. Просто посидеть на одном созвоне рядом недостаточно.
Документировать не только “как”, но и “почему”.
Схему компонентов обычно восстановить можно. Гораздо сложнее понять, почему выбрали такой контракт, какие ограничения нельзя нарушать и где уже пробовали «простое решение», которое не сработало.
При этом «пусть Вася обучит всех» — тоже не стратегия.
Во-первых, Вася становится ещё большим bottleneck: теперь он одновременно разрабатывает, ревьюит, отвечает на вопросы и ведёт внутренний университет.
Во-вторых, знания без практики быстро превращаются в заметки, которые все читали и никто не может применить во время инцидента.
Передача экспертизы должна быть частью обычной работы: реальные задачи, совместные решения, ротация ответственности и проверка, что команда может действовать без подсказки.
И важное ограничение: снижать Bus Factor — не значит делать всех взаимозаменяемыми.
Не нужно, чтобы каждый разработчик знал всё про каждый сервис. Это дорого и почти невозможно.
Цель проще: критичная область не должна зависеть от доступности одного человека.
Сильный эксперт усиливает команду, когда рядом с ним растут другие владельцы. Если же без него останавливается работа, это уже не только экспертиза.
Это организационный риск.
В какой области вашей системы ответ на большинство вопросов до сих пор звучит как «спроси Васю»?
В команде есть разработчик, который знает всё про платежи.
Любой сложный баг идёт к нему.
Любое изменение API ревьюит он.
На любой вопрос ответ: «Спроси Васю».
Кажется, у команды есть сильный эксперт.
На самом деле у неё ещё есть single point of failure.
Bus Factor показывает, сколько людей должно внезапно выпасть из работы, чтобы команда потеряла критичные знания и не смогла нормально продолжать проект.
Если без Васи нельзя безопасно изменить платежи, разобраться с инцидентом или выпустить релиз, Bus Factor этой области равен единице.
Сам по себе сильный эксперт — не проблема. Наоборот, глубокая экспертиза нужна команде.
Проблема начинается, когда знания эксперта не превращаются в знания системы.
Признаки обычно хорошо заметны:
— только один человек понимает, почему архитектура устроена именно так;
— его approval фактически обязателен для каждого изменения;
— во время его отпуска задачи встают или откладываются;
— документация заканчивается на «там всё понятно из кода»;
— остальные разработчики избегают области, потому что дешевле дождаться эксперта;
— после инцидента объяснение остаётся в созвоне и нигде не фиксируется.
Так появляется knowledge silo — область знаний, доступная одному человеку или узкой группе.
При этом формально ownership есть. Фактически это не владение системой, а монополия на её обслуживание.
Что можно сделать?
Разделять code ownership.
У критичной области должен быть основной владелец, но не единственный человек, способный внести изменение. Полезная проверка: кто примет решение, если владелец недоступен две недели?
Парно решать сложные задачи.
Не передавать эксперту очередную проблему целиком, а подключать второго разработчика к анализу, проектированию и реализации. Наблюдение за готовым решением передаёт гораздо меньше знаний, чем совместный поиск.
Ротировать ревьюеров.
Если все изменения годами проверяет один человек, команда тренирует зависимость от него. Сначала можно добавить второго ревьюера, затем постепенно передавать ему часть решений.
Использовать shadowing.
Разработчик сначала наблюдает за работой эксперта, потом выполняет похожую задачу вместе с ним, а затем делает её самостоятельно под наблюдением. Просто посидеть на одном созвоне рядом недостаточно.
Документировать не только “как”, но и “почему”.
Схему компонентов обычно восстановить можно. Гораздо сложнее понять, почему выбрали такой контракт, какие ограничения нельзя нарушать и где уже пробовали «простое решение», которое не сработало.
При этом «пусть Вася обучит всех» — тоже не стратегия.
Во-первых, Вася становится ещё большим bottleneck: теперь он одновременно разрабатывает, ревьюит, отвечает на вопросы и ведёт внутренний университет.
Во-вторых, знания без практики быстро превращаются в заметки, которые все читали и никто не может применить во время инцидента.
Передача экспертизы должна быть частью обычной работы: реальные задачи, совместные решения, ротация ответственности и проверка, что команда может действовать без подсказки.
И важное ограничение: снижать Bus Factor — не значит делать всех взаимозаменяемыми.
Не нужно, чтобы каждый разработчик знал всё про каждый сервис. Это дорого и почти невозможно.
Цель проще: критичная область не должна зависеть от доступности одного человека.
Сильный эксперт усиливает команду, когда рядом с ним растут другие владельцы. Если же без него останавливается работа, это уже не только экспертиза.
Это организационный риск.
В какой области вашей системы ответ на большинство вопросов до сих пор звучит как «спроси Васю»?
Метрики без насилия
99,99% availability не всегда лучше 99,9%
Хотим availability 99,99%.
Звучит очевидно: чем больше девяток, тем надёжнее система. Тогда почему бы сразу не потребовать 99,99999%?
Потому что каждая следующая девятка стоит денег, времени и инженерных ограничений.
Она требует больше резервирования, более сложного мониторинга, быстрых механизмов восстановления и осторожных релизов. Иногда это оправданно. Иногда мы просто строим космический корабль для поездки в соседний магазин.
Надёжность должна определяться требованиями продукта, а не инженерным перфекционизмом.
Для этого обычно используют три понятия.
SLI — что именно измеряем.
Например, долю запросов, завершившихся успешно.
SLO — какой уровень хотим обеспечить.
Например: 99,9% успешных запросов за 30 дней.
Error budget — сколько ошибок можем допустить, не нарушив SLO.
Для SLO по времени доступности разница хорошо видна на цифрах:
— 99,9% оставляет около 43 минут недоступности за 30 дней;
— 99,99% — около 4 минут;
— 99,999% — примерно 26 секунд.
Перейти от 43 минут к четырём — не просто поправить число в документе. Системе может понадобиться другая архитектура, другой процесс релизов и совсем другая стоимость эксплуатации.
Но самое полезное в error budget даже не расчёт допустимых отказов.
Он связывает две конфликтующие силы.
Разработка хочет быстрее выпускать изменения, экспериментировать и проверять гипотезы.
Reliability требует стабильности, дополнительных проверок и меньшего количества рискованных изменений.
Без общей метрики спор быстро превращается в:
— Нам надо быстрее.
— Нам надо надёжнее.
С error budget появляется измеримая договорённость.
Если бюджет почти не расходуется, команда может позволить себе больше изменений.
Если он быстро сгорает, уменьшаем риск: замедляем релизы, разбираемся с причинами отказов и вкладываемся в восстановление.
Важное ограничение: error budget нельзя превращать в KPI разработчика.
Его задача — не найти человека, который «потратил наши минуты недоступности». Это не табель инженерной виновности.
Error budget ограничивает всю систему delivery: архитектуру, тестирование, релизы, мониторинг и восстановление после сбоев.
Надёжность тоже имеет стоимость.
Поэтому правильный вопрос звучит не так:
«Как сделать систему максимально надёжной?»
А так:
«Какой уровень надёжности нужен бизнесу и какой риск он готов принять?»
99,99% availability не всегда лучше 99,9%
Хотим availability 99,99%.
Звучит очевидно: чем больше девяток, тем надёжнее система. Тогда почему бы сразу не потребовать 99,99999%?
Потому что каждая следующая девятка стоит денег, времени и инженерных ограничений.
Она требует больше резервирования, более сложного мониторинга, быстрых механизмов восстановления и осторожных релизов. Иногда это оправданно. Иногда мы просто строим космический корабль для поездки в соседний магазин.
Надёжность должна определяться требованиями продукта, а не инженерным перфекционизмом.
Для этого обычно используют три понятия.
SLI — что именно измеряем.
Например, долю запросов, завершившихся успешно.
SLO — какой уровень хотим обеспечить.
Например: 99,9% успешных запросов за 30 дней.
Error budget — сколько ошибок можем допустить, не нарушив SLO.
Для SLO по времени доступности разница хорошо видна на цифрах:
— 99,9% оставляет около 43 минут недоступности за 30 дней;
— 99,99% — около 4 минут;
— 99,999% — примерно 26 секунд.
Перейти от 43 минут к четырём — не просто поправить число в документе. Системе может понадобиться другая архитектура, другой процесс релизов и совсем другая стоимость эксплуатации.
Но самое полезное в error budget даже не расчёт допустимых отказов.
Он связывает две конфликтующие силы.
Разработка хочет быстрее выпускать изменения, экспериментировать и проверять гипотезы.
Reliability требует стабильности, дополнительных проверок и меньшего количества рискованных изменений.
Без общей метрики спор быстро превращается в:
— Нам надо быстрее.
— Нам надо надёжнее.
С error budget появляется измеримая договорённость.
Если бюджет почти не расходуется, команда может позволить себе больше изменений.
Если он быстро сгорает, уменьшаем риск: замедляем релизы, разбираемся с причинами отказов и вкладываемся в восстановление.
Важное ограничение: error budget нельзя превращать в KPI разработчика.
Его задача — не найти человека, который «потратил наши минуты недоступности». Это не табель инженерной виновности.
Error budget ограничивает всю систему delivery: архитектуру, тестирование, релизы, мониторинг и восстановление после сбоев.
Надёжность тоже имеет стоимость.
Поэтому правильный вопрос звучит не так:
«Как сделать систему максимально надёжной?»
А так:
«Какой уровень надёжности нужен бизнесу и какой риск он готов принять?»