Фестиваль фонарей: почему AI-агенты пишут код быстрее, чем команда успевает его проверить

Сегодня у нас мастерская, в которой мы производим фонари. В городе через 12 смен фестиваль, и к нему нужно зажечь город: 12 фонарей к четвёртой смене — это набережная, 32 к восьмой — рыночная улица, 64 к двенадцатой — праздничная площадь. Перед каждой сменой мы принимаем решение, а цель очень простая: за минимум затрат выполнить все обещания перед городом.

Каждый фонарь сначала проходит через станок — пресс, где делается заготовка, — а потом через ручную работу мастера. Станок за смену делает до 12 заготовок — он гораздо производительнее, как и агенты. Мастер за смену доводит только один фонарь, а мастеров у нас четыре. И то, что станок сделал в этой смене, попадает к мастерам только в следующей — как было бы в реальной жизни.

Бюджет — 360 монет, по сути это наши косты. Все траты считаются за смену. Каждый ожидающий заказ — одна монета за каждую смену ожидания: ожидание заказов должно чем-то плохим оборачиваться. Каждый фонарь, который проходит через пресс, — одна монета. Заготовка, которая ждёт в очереди на ручную доработку, — две монеты за смену. Каждый сотрудник — полмонеты за смену. В какой-то момент нужно будет принять новое правило, и стоит оно 12 монет. И последнее: опытные мастера могут учить подмастерьев. Можно отвлекать на это опытных сотрудников, как в обычной продуктовой команде, а можно нанять отдельного наставника — но он стоит в два раза дороже, одну монету за смену.

На старте у нас четыре заготовки с пресса и четыре мастера. Решение каждый раз одно из трёх. Загрузить станок — пусть по максимуму обработает все входящие заказы. Сделать столько, сколько по силам мастерам — четыре мастера превратят четыре заготовки в четыре фонаря. Или дать время поучиться — двое мастеров начинают учить двух подмастерьев, и через три смены у нас будет не четыре мастера, а шесть. Но пока мастер учит, он не делает свою работу и не вносит вклад в готовую продукцию — как, в принципе, в любой компании.

Самым популярным решением оказалось дать время поучиться. Двое подмастерьев начали учиться, две заготовки остались необработанными — двое мастеров были заняты обучением. Появился «бенч», как говорят в некоторых компаниях. Город пока тёмный, но два фонаря мы уже доставили.

В чате сразу появились интересные мысли. Один участник заметил: в игре AI-вывод безошибочен, а в жизни его брак тоже съедает время проверяющих, поэтому вкладываться надо в людей и в процесс проверки, а не в загрузку станка. Другой написал, что обучение расшивает узкое горлышко мастеров, которые точно не сделают 64 фонаря за 11 смен. Третий — что обучение снижает производительность.

Пара вопросов по правилам. Если монеты закончатся, вы просто уйдёте в долг: у нас средневековье, не совсем капиталистическая игра (в следующей версии, с конкуренцией на рынке, это будет банкротство). Штрафа за невыполненное обещание городу тоже нет — город просто расстраивается.

Зачем тогда промежуточные цели? Я спросил зал, и один из участников ответил: если работать только с четырьмя мастерами, получится 12 × 4 = 48, и цель игры не выполнить. Да, за 12 смен невозможно подготовить 64 фонаря, если не начать вкладывать в обучение, — это я и пытался показать. И позже, отвечая на другой вопрос, я призвал: вкладывайтесь в обучение, чем раньше, тем лучше.

Следующие смены зал выбирал «по силам мастерам», и тут событие: в городе починили и открыли старый мост. Другой берег присоединяется к фестивалю, и заказов теперь вдвое больше: не четыре за смену, а восемь. Пресс легко с этим справится. Узкое место — мастера.

Возможно, решение учить с первой смены было правильным ходом, учитывая, что вы не знали, что объём заказов вырастет вдвое. Из обучения вышли первые двое — после трёх смен они становятся такими же производительными, как мастера, — и зал снова отправил двоих учиться. Начали копиться заказы и незавершённая продукция.

Потом интересная вещь: при шести мастерах обработали только четыре фонаря — от станка не пришло достаточно заготовок, и мастера впервые простаивали. Поэтому на следующей смене зал загрузил станок.

Дальше — системное инвестиционное решение за 12 монет, одно из трёх. Первое: нанять двух опытных сотрудников — сезонная рабочая сила, они поработают две смены. Второе: прокачать станок, чтобы он не задерживался и работал по графику; быстрее он не станет, просто станет устойчивее. Третье: открыть учебную мастерскую с full-time преподавателем, назовём его корпоративным учителем. Он стоит монету за смену, зато опытных сотрудников отвлекать не нужно; обучение всё равно занимает три смены.

Здесь я дал залу договориться самим. Одни предлагали позвать сезонных мастеров, считая, что учебная мастерская в глобальном смысле не поможет. Другой участник возразил: позвать мастеров — значит приоритизировать рыночную улицу, а не праздничную площадь; если ставим главную цель, надо учить, потому что в последних сменах это будет самым узким горлом.

Зал проголосовал за учителя. Забавная деталь: в следующих сменах зал выбирал «по силам мастерам» и никого не отправлял учиться, так что учителю было некого учить. Наставник без учеников новых мастеров не даёт.

Мастеров стало восемь, и дальше каждую смену — восемь заготовок на входе, восемь фонарей в город. К одиннадцатой смене зал доставил 64 фонаря: набережная, рыночная улица и праздничная площадь горят, все три района — в срок, потрачено 198 монет из 360.

Для меня было неожиданно, что в первом же голосовании почти все решили учить, — это решение было очень правильным. Логику объяснил один из участников: с текущим количеством людей задачу не выполнить, нанимать нельзя — значит, учить, и чем раньше начнём, тем больше смен у нас будет с большим количеством людей.

Кстати, саму игру я сделал часа, наверное, за 4–5 во взаимодействии с Codex, причём не сидел эти пять часов у Codex, а кое-что окончательно докрутил в Claude. Условно, за 8 часов можно сделать такие симуляторы, и найм или обучение, я думаю, станут такими.

После вебинара я прогнал движок игры по разным стратегиям — 12 смен, одни и те же заказы, одни и те же стартовые мастера и заготовки. Это детерминированные эксперименты «что если» внутри игры, а не утверждения о реальных агентах, но картинка наглядная:

• «Всегда грузить станок», без подмастерьев: 44 фонаря за 426 монет — минус 66. Меньше всех фонарей, и единственная стратегия, которая уходит в минус. К тому же в девятой и одиннадцатой сменах по одному мастеру выгорает, и к концу их остаётся двое.
• «Только то, что мастера успевают доделать», без подмастерьев: 48 фонарей за 270 монет, плюс 90.
• «Учить с первых смен» — решения зала, но первые смены отданы обучению: по сравнению с залом меняется только вторая смена, где ещё двое подмастерьев идут учиться. За 12 смен — 80 фонарей за 199 монет, плюс 161.

Оба прогона без подмастерьев всё равно платят за выбранное залом правило с учителем. Без подмастерьев праздничная площадь не зажигается. А станок на полной мощности наращивает платную очередь заготовок перед мастерами — каждая стоит денег за каждую смену ожидания, — и в этом прогоне мастера ещё и выгорают.

Теперь самое интересное: при чём тут продуктовые команды. На что сейчас жалуется практически каждая команда, которая ускорила разработку с помощью AI? В чате ответили сразу: на код-ревью.

Станок — это AI-агент, который что-то производит. Мастер — человек, который ревьюит output агента, прежде чем пустить его в готовую продукцию. Очень многие команды столкнулись с тем, что output благодаря агентам вырос, но общий output команды вырос несоизмеримо. Кода могут писать в 5–10 раз больше, а фич релизят не в 5–10 раз больше, а, по разным оценкам, на 30–50%, то есть в 1,3–1,5 раза.

Первый стейтмент: узкое место — ревью. Даже если агенты работают в fast-режиме, общий output не вырастет, пока мы ничего не сделали с узким местом. Поэтому хорошо, что вы вложились в подмастерьев — в терминах разработки это джуниоры, которые научатся ревьюить output агентов. Пропускная способность системы выросла не до 12 — это всё, что может выдать станок, — но хотя бы до восьми.

Один участник добавил, что некоторые команды уже готовы отдать код-ревью агенту. Но тогда горлышко всё равно уйдёт дальше: появится что-то ещё, что будет тормозить выпуск.

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

Не запуская в какие-то моменты станок на полную мощность, вы на самом деле делали то, что рекомендует Голдратт в пяти шагах теории ограничений.

Сначала найдите узкое место, которое ограничивает выпуск всей системы. У нас это мастера. Потом подчините ему остальные части системы: агенты не должны генерировать код, который никто не ревьюит, если на это нет пропускной способности.

Затем расшейте узкое место и сбалансируйте систему. Когда мы дошли до восьми мастеров, станок в последние смены обрабатывал восемь и мастера делали восемь — система согласована по узкому месту. Станок может 12, мастера — восемь, так что при более грандиозных целях нужно было бы и дальше учить людей.

И наконец: как только мы избавились от ограничения, оно перескочит куда-то ещё, и цикл надо повторять. Автоматизировали код-ревью — возникает вопрос архитектуры. Или не хватает юзеров и надо выходить на новые рынки. Или нет денег платить всем этим мастерам.

Итого: находим узкое место, подчиняем ему систему, расшиваем, балансируем, ищем новое узкое место и повторяем. И один из шагов я сначала забыл назвать: освободить узкое место от всякой ерунды, чтобы оно не отвлекалось на неважное. Мы к нему ещё вернёмся.

Какие есть способы расшить ревью? С одной стороны, добавлять людей — обучать или нанимать. С другой — автоматизировать. Сейчас много работы делается на то, чтобы автоматизировать код-ревью, и по уже известному нам алгоритму это, конечно, сдвинет узкое место.

Кто был на семинаре по AGI Economics, помнит картинку с двумя осями: насколько дёшево производить что-то и насколько дёшево и быстро проверять результат. Один из участников считает, что архитектуру текущие модели пока делают не очень хорошо, и я соглашусь двумя руками. Локально, на уровне класса, они решают задачу очень хорошо, даже сразу пишут тесты и мутанты. Но постепенно теряется согласованность модулей — в том числе потому, что модели не держат контекст достаточно глубоко и их intelligence падает с ростом токенов в контексте.

Тесты — тоже способ, но это та же автоматизация. А что ещё?

Представьте pull request от агента, который затрагивает внутреннюю админку, где ваш саппорт смотрит досье на пользователя перед ответом: платящий он или нет. Один из участников ответил ровно то, к чему я вёл: можно уйти от концепции, что весь output агентов должен проверяться. С ростом интеллекта моделей, гарантирую, вы всё чаще будете приходить к этому решению: не ревьюить pull request-ы, где blast radius и риски достаточно низкие, где мы готовы принять, что саппорт, условно, полдня не поработает.

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

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

А теперь вспомните мобильные приложения. Раньше ты выпускал новую версию iOS-приложения, две недели ждал ревью Apple — а там баг, и сыплются негативные отзывы. Спустя годы появился staged rollout: новая версия раскатывается сначала на 1% пользователей, потом на 5%, на 15% и так далее. По-моему, это комбинация: мы снижаем стоимость последствий — баг, который мог внести агент, не затронет много людей, и rollback сделать легко, — и одновременно передаём часть работы юзеру. Как уточнили в чате, передаём не весь риск, а пониженный.

Я пытаюсь перевести абстрактные стратегии — снижать, принимать, передавать — в тактические штуки, которые нужно закладывать в свои продукты. Тогда вам будет легче справляться с output-ом агентов.

Допустим, мы расшили ревью всеми этими способами. Узкое место точно куда-то сдвинется — это закон систем, в «Цели» Голдратта это описано в красках.

Но сначала — момент, которого в этой версии игры не было. Если вы используете агентов, да даже и без них, если в команде хотя бы четыре человека, я думаю, вы это испытывали. Представьте: от отправки pull request-а на ревью до начала ревью в среднем проходит, допустим, две недели. С агентами люди стали делать pull request-ов в пять раз больше, и две недели превратились, допустим, в два месяца. Что происходит с незавершённой продукцией? Она начинает протухать: pull request-ы оказываются от старых веток, код за это время так изменился, что это, по сути, pull request к другому продукту, и нужен rebase.

В игре я дал это как стоимость в монетах: на производстве незавершёнка — это оборотный капитал, который стоит мёртвым грузом, закопанные деньги, которые не крутятся в бизнесе.

Теперь — куда сдвинется узкое место. Мы ускорили написание кода, ускорили верификацию, снизили риски через staged rollout, какие-то pull request-ы вообще не проверяем людьми, дали саппорту самому с помощью агентов катить внутренние админки. Думаю, сначала узкое место сдвинется в проектирование и дизайн, а потом — ещё абстрактнее, в придумывание и выбор того, что делать.

Как мы выбираем, что делать? По обратной связи от пользователей и по vision продукта. Но если мы можем разработать любую идею, где будет constraint?

В чате назвали косты и обратную связь. С костами нужен cost-benefit анализ: грубо говоря, если мы потратим токенов на 10 тысяч долларов, а фичей будет пользоваться один неплатящий пользователь, это, очевидно, плохая идея. А если мы деливерим всё, что приходит в голову или в саппорт, — что происходит с обратной связью?

Оговорюсь: это не серебряная пуля, это мои размышления, мы в дискуссии. Но моя мысль такая: скорость отрезания фич должна быть равна скорости добавления фич. И, по моим наблюдениям, пока все агенты очень плохи в урезании. Они очень хороши в том, чтобы максимизировать output, но не минимизировать. Один участник предположил, что отрезать нужно даже быстрее, — возможно, но в пределе скорости должны быть равны: если отрезать быстрее, продукта в итоге не станет.

Другой участник поднял вопрос личного интереса. Если это вендор, минимизация, наверное, будто противоречит бизнесу; если продуктовый бизнес, меняется сама единица измерения output-а. Про производителей моделей у меня был полушуточный пост: токенов на задачу генерируется всё больше, потому что это выгодно лабораториям. Если в обучение попадает внутренняя работа компании, где постоянно звучит мысль о выручке, я не исключаю, что модель выучивает паттерн «чем больше токенов, тем лучше».

Нам нужна система, которая быстро тестирует обратную связь: мне кажется, в итоге узкое место сдвинется вовне компании — в её конкурентную и клиентскую среду. И нужна система автоматизации урезания — шире, экспериментирования.

Себя я поймал вот на чём: я начинаю забывать оптимизации, которые задеплоил, — потому что это так легко. Поэтому мне пришлось написать мини-утилиту на пару с другом: когда pull request уходит в прод, она ставит напоминание — через столько-то дней поднять ту сессию, оценить эффект заданными командами и решить, откатываем или оставляем. В классическом виде это журнал экспериментов в growth-командах: ожидания и условия отката фиксируются до начала эксперимента.

Мой другой пойнт: в какой-то момент нужен полный реорг всего продуктового SDLC, и я уверен в этом на 99%. Один из участников привёл кейс: DHH про это говорит. Кажется, пришло время нового манифеста а-ля Agile, потому что SDLC надо переделывать. То, как сейчас сделан SDLC, — совершенно не то, как мы работаем с агентами.

Помните идею дать саппорту вместе с агентами править баги? Не надо загонять саппорт в SDLC-процесс: это будет nightmare. Я вижу, как некоторые CIO и CTO требуют, чтобы любой POC из бизнес-подразделения, который решили использовать, прошёл через стандартный SDLC. Я понимаю почему, но это сова на глобус: новую среду пытаются засунуть в старый процесс, и это ошибка.

Вопрос из зала: если задачи решаются так быстро, мы не проживаем опыт решения — не страдает ли наш опыт? Вспомните подмастерьев, которых мы три смены учим. Рыночные условия ведут к двум вещам. Во-первых, бизнесам невыгодно инвестировать в таких подмастерьев — нужны другие подмастерья: учить надо не писать код, а дизайнить и проверять output агента.

Во-вторых, чем выше по абстракции мы поднимаемся, тем меньше понимаем, что происходит под капотом, и в определённых ситуациях это повышает риски. Будет специализация: тех, кто знает, как всё работает под капотом, станет меньше, но им будут больше платить как экспертам. В чате добавили, что это ещё и про ответственность, — совершенно верно.

Один из участников, который много ресёрчит перестройку оргструктуры под AI, поделился лучшим, что он нашёл: моделью Valve — по его словам, у них больше выручки на сотрудника, чем у кого-либо. У каждого сотрудника есть набор пермишенов: что он может делать и что не может. А какая у тебя роль, руководитель ты или нет, никого не волнует — ролей там просто не существует. Такая модель одинаково ложится и на сотрудников, и на агентов. Вторая его мысль была скептической: не каждого можно научить любой задаче, поэтому агентов будут менеджировать не все, а только те, кто реально сможет, а остальные останутся без работы.

Моих комментариев три. Первый: с permissions полностью согласен и думаю, что это будет динамически. Модель, которую я предлагаю, упрощу до код-ревью: я должен научиться атрибутировать, насколько хорошо человек или агент проверил output, и перераспределять пермишены по этой метрике. Если агент или человек очень хорошо ревьюит output других агентов и дефектов на проде практически нет при сравнимом количестве юзеров — то есть считаем дефекты на количество юзеров, которые попробовали функционал, — на следующем цикле он получает больше пермишенов.

Второй: если я во что-то и верю, то в человека и в силу обучения. Возможно, верификация и оркестрация агентов одним даётся легче, чем другим, но, возможно, это задача инструмента — однозначно пока сказать не могу.

Третий: идея динамических пермишенов пришла ко мне, когда я наблюдал за своим follow-through: в каких-то сессиях всё правильно, а в каких-то blast radius был большой или я сам отвлёкся. Поэтому я завёл базу данных и собираю статистику успешных и неуспешных сессий — думаю, в команде её нужно собирать в разрезе человека, который оркестрирует, и по ней перераспределять пермишены и ресурсы. Это похоже на главную страницу Яндекса. Оговорюсь: я в Яндексе не работал, так что, если кто-то работал, может быть, меня поправит. Место на главной ограничено, и вопрос, как им эффективно управлять, с точки зрения системного мышления — трагедия общих ресурсов. Подход к ней — квотирование. Я думаю, в Яндексе, скорее всего, какая-то система квот, и она, скорее всего, учитывает, с одной стороны, стратегические продуктово-бизнесовые цели, а с другой — performance: какой виджет, условно гороскоп или погода, даёт больше в рекламе или engagement.

Так каким должен быть идеальный SDLC? Я не знаю. Мыслей много, но они пока не собраны; как соберу, сделаю пост или встречу. Одна из них: ответственность нужно перевести в измеримую и сравнимую единицу, и пока, если честно, это только деньги — для бесплатных продуктов, может быть, engagement. То есть верификация output-а должна происходить по итоговому эффекту на пользователей, а промежуточные стадии, думаю, с ростом способностей моделей автоматизируют. И, как я говорил на AGI Economics, чем длиннее петля, тем сложнее верификация.

Ответа на этот вопрос у меня пока нет. Надеюсь, игра хотя бы натолкнула вас на мысли. Это моя первая игра, где я пошёл в визуал, — я ни в коем случае не геймдизайнер, — так что буду благодарен за фидбэк.

Если вам понравились такие игры и концепты, приходите на курс по системному мышлению, который стартует. Там моя цель — чтобы все блоки подавались через игру, а половина встреч — это вот такие дебрифы, плюс то, как AI может помочь думать про это: искать узкие места и расшивать их.