Спикер говорит и советует сгрузить рутину на нейросети. Часть инженеров возражает: вздохи, саркастичные комментарии, длинные треды о том, как спикеры оторваны от реальности. «ИИ не умеет думать», «он галлюцинирует», «кто потом будет переписывать этот код?»
Претензии выглядят странно по одной причине. «Отдай это AI» — метафора, ужатая до размера короткого ролика. Никто из выступающих не имеет в виду «нажми кнопку, уйди пить кофе, а алгоритм сам построит тебе космодром». Буквальное прочтение целиком принадлежит слушателю: он его додумал и критикует буквальную интерпретацию фразы.
Что теряется в споре о буквальном смысле
Пока в треде опровергают выдуманный тезис, процессы делегирования всё равно приходится проектировать.
Спорящий не строит постановку задачи. Не размечает границы того, что агенту вообще позволено трогать. Не выстраивает приёмку. Через полгода у него по-прежнему нет ни одного процесса, где агент несёт часть нагрузки под контролем, зато есть коллекция аргументов, почему это невозможно. Из-за этого внедрение может откладываться на месяцы.
Отдельная плата — страх. Для CTO «агент сделал что-то не то» страшнее, чем «агент медленнее человека». Риск снижается через наблюдаемость, ограничения прав и этапы приёмки. Отказ этот страх консервирует.
Что фраза значит в профессиональном разговоре
В профессиональном контексте «отдай это AI» означает ровно одно:
— Перестрой организационные и технологические процессы так, чтобы делегировать эту работу агенту, осуществляя постановку задачи, контроль и приёмку результатов.
Три слова несут всю нагрузку: постановка, контроль, приёмка. Не одно из трёх, а все сразу. Убери любое — и получится ровно та карикатура, с которой скептики так убедительно спорят.
Подрядчику вы почему-то пароли не отдаёте
У этой фразы есть точный управленческий двойник, которым все пользуются не задумываясь.
Когда руководитель говорит «делегируй это подрядчику», никто не подразумевает, что нужно скинуть рутовые пароли к инфраструктуре и уехать в отпуск. Все понимают, что дальше: составить понятное ТЗ, разметить границы ответственности, настроить пайплайн проверки, валидировать конечный результат. Никого не смущает, что подрядчик может сделать не то. Для этого и существуют ТЗ и приёмка.
При делегировании агенту полезна похожая логика контроля. Это автоматизация с недетерминированным исполнителем, которая требует явных критериев, ограничений доступа, логирования и ответственного approve.
Как это выглядит, когда собрано руками
Ниже пример минимального процесса.
1. Постановка. Задача не уходит в работу, пока у неё нет цели, обозначенного scope и проверяемых критериев приёмки. Я собрал под это отдельный gate в джире: тикет не проходит дальше, пока формулировка остаётся неявной. В таких кейсах ошибка часто возникает из-за неполной постановки, где половина требований жила в голове автора тикета. Открытый код: github.com/dobryakov/jira-clarify-bot.
2. Approve. Гейт не автоматический штамп: решение принимает человек. И тут же вылезает главная типовая ошибка этой схемы — approve без фальсифицируемых критериев. Нажал «согласовано», критерии остались непроверяемыми вроде «должно работать корректно». Гейт формально пройден, постановка по-прежнему неявная, а виноватым назначат агента.
3. Разделение ролей. Постановщик пишет файл в inputs/. Исполнитель видит один файл и делает одну операцию. Он не знает контекста сверх задачи, не ходит по смежным системам, не додумывает.
4. Разбор результата. Именно ради этого разделение и существует. Нет файла в inputs/ — сломался постановщик. Нет результата в outputs/ — сломался исполнитель. Есть оба — открываем и сравниваем «что просили» с «что получили». Аудит идёт через git log: кто, когда, что положил и что забрал.
В таком виде фраза «отдай это AI» означает управляемое делегирование, которое влезает в короткий ролик одной фразой, а в реальности занимает четыре шага и несколько недель перестройки.
Нюансы, о которых на сцене не говорят
У схемы есть операционные издержки, и издержки лучше зафиксировать заранее.
Задержка растёт. Гейт на постановке и человек на approve добавляют время к каждому циклу — там, где раньше тикет летел в разработку за минуту.
Есть социальный риск. Постоянно хочется дать исполнителю чуть больше контекста, «чтобы он лучше понял». Расширение контекста усложняет последующий разбор причины ошибки: как только исполнитель видит лишнее, вопрос «кто сломался» перестаёт иметь однозначный ответ.
И это не замена PAM. Разделение постановки и исполнения даёт наблюдаемость и границу ответственности, а не управление привилегированным доступом. Кто путает одно с другим, получит ошибочную оценку уровня защиты.
Отдельно: гейт на постановке не делает требования хорошими. Он делает неявные требования видимыми. Дальше всё решает человек, который жмёт approve.
Почему у большинства ничего не выходит
Основная причина провалов в описанной схеме: в описанных случаях проблема часто связана не с моделью, а с процессом.
Инженеры умеют строить пайплайны, но не умеют ставить задачу так, чтобы результат можно было принять по критериям. Менеджеры умеют ставить задачи и принимать работу, но не умеют строить контур, в котором это исполняется машиной. Делегирование агенту требует обеих компетенций одновременно — явных критериев, ограничений доступа, логирования и ответственного approve.
Часто одна из этих компетенций отсутствует. Из-за этого критика может смещаться на модель: с AI ничего не выходит, значит проблема в AI. Буквальная критика фразы позволяет не обсуждать качество процессов — она позволяет не признавать, что не хватает управленческого навыка, а не технологии.
Что с этим делать тому, кто дочитал
Начать можно с одного ограниченного процесса.
Выберите один повторяемый процесс с понятным входом и выходом. Поставьте перед ним гейт: цель, scope, фальсифицируемые критерии приёмки. Разведите постановку и исполнение по разным ролям и разным каталогам. Оставьте человека на approve и следите не за тем, сколько тикетов прошло, а за тем, сколько прошло с критериями, которые действительно можно провалить. Разбирайте инциденты по трём состояниям — нет входа, нет выхода, есть оба.
Наблюдаемость при этом получается из файловой системы и git, без отдельной платформы под управление агентами. Дальнейшие решения зависят от вашей схемы доступов, аудита и интеграций с тем, что у вас уже стоит.
Буквальная критика не заменяет проектирование процесса
«Отдай это AI» — не инструкция нажать кнопку. Это требование перестроить процессы под делегирование: постановка, контроль, приёмка. Логика похожа на работу с подрядчиком, но требует дополнительных ограничений и проверки.
Кто считывает призыв буквально и предпочитает закатывать глаза вместо того, чтобы учиться ставить задачи и строить агентские конвейеры, откладывает освоение управляемого делегирования. И евангелистам это, если по-чесноку, только на пользу: пока часть команд обсуждает формулировку, другие тестируют процессы с постановкой, контролем и приёмкой.
Пока вы спорите с фразой, которой никто не говорил, другая команда может раньше внедрить управляемый контур делегирования — и после этого тикеты без явных критериев не должны уходить в исполнение.