Как перестать быть бутылочным горлышком в работе с ИИ: один разработчик выяснил, что половина решений ему не нужна
Разработчик из пищевой индустрии обнаружил, что при работе с ИИ-ассистентом тратит время не на управление проектом, а на вычитку чужих решений. Его решение — разделить все решения на две стопки и часть из них делегировать машине целиком.
«Человек — бутылочное горлышко» — это диагноз, а не комплимент. Исправление не в том, чтобы читать быстрее, а в том, чтобы разделить решения на те, которые должны пройти через вас, и те, которые могут не проходить.
Забавная история из мира разработки: обычный офисный работник пищевой промышленности, который занимается планированием, а не инженерией, в свободное время собирает ИИ-проект. Три года наблюдал за развитием искусственного интеллекта со стороны, в этом году впервые открыл терминал. А потом обнаружил, что его главный вклад в собственный проект — быть бутылочным горлышком.
Ожидание vs. реальность
Знакомая каждому, кто работал с ИИ-ассистентами, картина: вы ставите задачу, получаете длинный ответ, внимательно его читаете, либо одобряете то, до конца не понимаете, либо задаёте уточняющий вопрос — и получаете ещё один длинный ответ для внимательного чтения.
Автор этого эксперимента честно признаётся: он не управлял процессом. Он вычитывал чужую работу.
Фразу «человек — бутылочное горлышко» он раньше воспринимал как завуалированный комплимент — мол, посмотрите, как многое зависит от моего решения. Но когда пришлось посчитать, куда уходят часы, комплимент рассеялся.
Две стопки
Решение пришло в форме простого деления. Все решения разделились на две категории:
Стопка 1 — только я могу ответить. Какую проблему решаем. Какова цель. Что считается успехом и как это проверить. Кто проверяет. Где граница, за которую нельзя заходить без моего участия. Это заслуживает медленного, плотного разговора — и чем раньше, тем лучше.
Стопка 2 — всё, что выводится из стопки 1. Обычно это область, в которой автор не специалист. Обычно — без существенного влияния на итог. ИИ решает, действует, записывает, что решил.
Само разделение заняло десять минут. Трудная часть в другом: граница между стопками постоянно дрейфует — в сторону первой. Потому что спросить человека модели кажется безопасным, а человеку кажется, что так он лучше контролирует процесс. И этот дрейф нужно было как-то обуздать.
Два стража у границы
Для контроля границы автор ввёл два механизма:
- Шлюз автономности. Исходя из текущего плана — безопасно ли запускать без человека в цепочке? Если да — начинается автономный участок работы.
- Проверка глубины разговора. На этапе диалога — не спрашивает ли ИИ того, что мог бы решить сам или найти в файле? Не эскалирует ли детали, которые не требуют участия человека?
Это превратилось в глобальное правило с двумя осями для каждого решения: риск (необратим ли эффект, если решение окажется ошибочным) и полномочия/информация (нужно ли то, что знаю только я, или то, что могу санкционировать только я).
На выходе — четыре маршрута: ИИ решает сам / сверить с исходниками / спросить человека / безопасная остановка. Четвёртый — самый коварный: низкая уверенность плюс высокое влияние означает «стоп и доложи», а не «угадай и продолжай».
Плюс два фазных этапа — этап согласования и этап автономной работы, с шлюзом между ними. И калибровочная петля, которая двигает границу не по ощущениям, а по двум измеримым показателям: как часто человек отменяет решения, принятые ИИ без спроса (высокий показатель — откатываем зону обратно в диалог), и как часто ИИ задаёт вопросы, на которые мог ответить сам (высокий — отправляем зону в автономию).
Три тетрадки
Отдельная идея — три заметки на проект. Факт-заметка (что является правдой, с источниками). Решение-заметка (почему выбрали это, кто решил — я или ИИ один — и позднейший вердикт: удержано, отменено, отброшено). Промпт-заметка (история разговора).
Потому что «сколько решений принял ИИ» — бесполезная метрика. А «сколько решений ИИ, умноженных на количество позднее отменённых» — конкретный сигнал о том, где нужно пересмотреть или сузить автономию.
Два прогона — и почему они оба нужны
Вот неприятная часть. Всё вышесказанное было сформулировано в той же сессии, которая весь утро наблюдала за всей кашей, породившей эту идею. А это именно та сессия, которой не стоит позволять проверять собственную домашнюю работу.
Поэтому днём тот же промпт отправился в свежую сессию — топового класса, но без какого-либо контекста. Чистая комната. Затем два варианта легли рядом, и автор начал их мержить.
Ожидалось, что один победит. Вместо этого различия расслоились по слоям.
Сессия с контекстом оказалась сильнее в ядре. Точность условий шлюза. Модель данных, включая таксономию того, кто принимает решения. Правила гигиены о том, что куда не копировать. Это читается как текст, написанный человеком, который обжёгся в конкретных местах, — потому что так и есть.
Чистая комната добавила инструментацию, контроль и автоматизацию — четыре вещи, которых в первой версии просто не было. Письменный контракт, делающий каждое решение шлюза аудируемым в виде diff документа. Количественную калибровочную петлю. Экспорт в JSONL, превращающий журнал решений в обучающий материал. Напоминание-хук, срабатывающий прямо перед тем, как ИИ задаст вопрос.
Чистая комната построила механизм измерения того, работает ли правило. Сессия, которая это правило изобрела, не могла увидеть эту брешь — она была этим правилом. Вовлечённость даёт точность, но забирает перспективу.
Итоговая версия: ядро от сессии с контекстом плюс слой инструментации от чистой комнаты.
Стоило ли делать двойную работу?
Затраты: одна и та же работа дважды, два контекста, один день. Отдача: гипотеза о том, какому слою доверять в каких условиях — гипотеза, которую теперь можно проверить на следующем правиле вместо того, чтобы гадать.
Рабочее эмпирическое правило:
- Черновик ядра — в сессии, которая жила внутри проблемы.
- Чертовик измерения и контроля — в сессии, которая никогда о проблеме не слышала.
- Смержить. Не выбирать одну.
Контекст — это линза, а не золото
Ничего из этого не является принципиально новой идеей. Разделение автора и ревьюера — то, что знает любая команда. Но то, что это работает применительно к инструменту, а не только к людям — вот что интересно. Распространённое допущение «больше контекста — всегда лучше» оказывается неверным. Контекст — это линза: резкая в центре, искажённая по краям.
А финальный парадокс пишет сам себя: автор начал с того, чтобы принимать меньше решений, и немедленной ценой стало два лишних решения о том, как принимать меньше решений. Но этот обмен, по его словам, он повторил бы снова.
Материалы проекта, включая оба варианта правила, шаблон контракта и карточку сравнения версий, опубликованы в репозитории BehindTheBuild на GitHub. Документы основного пакета написаны на корейском (автор работает в корейскоязычной среде), README содержит англоязычные суммарии.