Обезьяна, пулемёт, аимбот: управление AI в командах

Оружейная открыта

Пулемёты уже розданы.

Massimo Chieruzzi, сооснователь AdEspresso и Chief AI Officer в Unkover, описал это идеально: «AI иногда заставляет тебя чувствовать себя обезьяной с пулемётом». Мы согласны. И из этого наблюдения мы выводим собственное: мы и есть обезьяна, оружие уже у нас в руках, и проблема не в том и не в другом. Проблема — в отсутствии прицела.

Cursor, Copilot, Claude Code, v0 — это не технологии будущего, обсуждаемые на architecture review. Они уже работают в вашем стеке, генерируют код рядом с вашими разработчиками, коммитят в ваши репозитории. AI-агент уже имеет API-доступ к вашему codebase. Вопрос «стоит ли разрешать AI-инструменты?» был решён полгода назад самим фактом того, что никто не спросил разрешения.

Ваша команда уже вооружена. Единственный вопрос — установили ли вы аимбот.

Что такое управление AI-кодом?

Управление AI-кодом — это набор структурных правил, определяющих, как разработчики и AI-агенты пишут, изменяют и поставляют код. Это не бюрократия на основе разрешений. Это не очередь из тикетов и не обязательная цепочка согласований. Это соблюдение правил на основе guardrails, работающее на скорости разработчика: жёсткие границы сервисных module, явные интерфейсы dependencies и contract tests, которые падают в CI до того, как плохой код доберётся до production.

Без этого каждый AI-сгенерированный pull request — это патрон, выпущенный в темноту. С этим обезьяна всё ещё стреляет — но каждый патрон попадает туда, куда нужно.

Обезьяна попадает в цель

Вот в чём ужас. Фича выкатывается. Тикет закрывается. Демо работает безупречно.

Обезьяна попала в цель. Но какой ценой? Потому что, чтобы попасть в эту одну цель, она распылила тридцать патронов через сервис аутентификации, database schema и три microservices, которые она разнесла по пути — потому что обезьяна не целится, она распыляет.

Канал в Slack празднует. Production тихо истекает кровью. Регрессия auth не видна в diff pull request. Она проявляется через сорок восемь часов, когда дежурного разработчика поднимают в два часа ночи, потому что токены входа отказывают на всей платформе.

Цель никогда не была проблемой. Проблемой был побочный ущерб.

Почему code review не работает как управление

Code review — это ручное отражение пуль

Стандартный ответ — не обучение. Ни у кого нет шести недель на bootcamp. Настоящий ответ хуже: заставьте старшего разработчика проверять каждый pull request.

Code review превращается в отражение пуль. Старший разработчик читает каждую строку, ловит каждый шальной патрон и перенаправляет его к цели. Он не наставляет. Он не занимается architecture. Он стоит перед обезьяной, вручную корректируя каждый выстрел, чтобы тот попал хоть куда-то приемлемо.

Это не масштабируется. Один старший разработчик. Двенадцать обезьян. Четыреста патронов за sprint. Старший разработчик выгорает. Очередь на review растёт. В конце концов он одобряет то, что не следовало — не потому, что стал ленивым, а потому, что человеческое внимание — конечный ресурс, а у обезьяны бесконечный боезапас.

Даже когда обучение есть, оно проходит в песочнице. Настоящая обезьяна учится, стреляя боевыми патронами в production. К тому времени, когда уроки усваиваются, codebase получает попадания, на восстановление после которых уйдут кварталы.

Невозможно нанять достаточно старших разработчиков, чтобы вручную отражать каждую пулю. Математика не сходится.

Множитель AI: ни гордости, ни страха

Начинающие разработчики хотя бы что-то чувствуют. Они улыбаются в Slack, когда быстро выкатывают фичу. Они со временем ощущают отдачу, когда рикошет прилетает в них в форме postmortem или rollback.

AI-агенты не чувствуют ничего. Ни гордости. Ни страха. Ни вины. Когда auth-слой ломается в три часа ночи, никто не пейджит модель. Пейджят человека, который смержил pull request.

LLM «приберёт codebase» в три часа ночи и отрефакторит ваш auth-слой с абсолютной уверенностью. Он удалит устаревшие поля, от которых всё ещё зависят downstream-потребители. Он внесёт циклические dependencies, которые чисто компилируются, но ломаются во время выполнения. Он сделает всё это вежливо, с отличными именами переменных и подробными комментариями.

Обезьяна со временем понимает, что распыление приводит к рикошету. Она учится сначала целиться, а потом стрелять. К тому времени ущерб уже нанесён.

Autotomy — это аимбот

Здесь метафора переходит от предупреждения к решению.

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

Autotomy — это не бюрократический процесс согласования. Это не очередь из тикетов и не обязательный code review от старшего разработчика, который и так тонет. Это управление на основе guardrails, работающее на скорости разработчика.

Обезьяна всё ещё стреляет. Обезьяна стреляет увереннее, потому что перекрестие прицела фиксируется на допустимых целях. Service boundaries — это жёсткие ограничения, а не рекомендации. Dependencies должны проходить через явные interfaces. Изменения контрактов распространяются по проверенным путям. Фича выкатывается, и больше ничего не умирает.

В этом разница между управлением на основе разрешений и управлением на основе guardrails. Разрешение говорит: остановись и спроси. Guardrails говорят: двигайся на полной скорости и верь, что структура поймает плохие выстрелы до того, как они достигнут цели.

Результат: старшие разработчики снова становятся наводчиками

Сегодня ваши старшие разработчики — это телохранители. Они стоят перед обезьяной и ловят шальные пули. Каждый pull request — это ликвидация ущерба. Каждый review — это сортировка в отделении неотложной помощи. Старший разработчик проводит день, говоря «нет, не трогай этот файл» и «нет, этот module закрыт», пока его собственная продуктивность не падает до нуля.

С установленным аимботом старший разработчик снова становится наводчиком. Он проверяет поправку на ветер. Он подтверждает попадания по сложным целям. Он выискивает краевые случаи, которые автоматизированное управление не видит. Он больше не живой щит. Он — множитель силы.

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

Более глубокий взгляд на то, как жёсткие границы делают AI-сгенерированный код надёжным в production, читайте в статье как AI-разработка работает с фреймворком Autotomy. Если вы хотите понять, где guardrails вписываются в стек, прочитайте про стек безопасности AI.

Что делать дальше на практике

Если вы управляете командой с начинающими разработчиками или AI-агентами, не начинайте с учебной программы. Начните с жёстких границ.

Определите interfaces modules до того, как кто-либо начнёт писать реализацию. Проведите каждую dependency через composition root. Добавьте по одному contract test на каждую границу. Обеспечьте соблюдение import restrictions в CI так, чтобы pull request буквально не мог быть смержен, если он нарушает architecture.

Эти шаги занимают день. Они меняют то, доверяет ли ваша команда своим разработчикам к четвёртой неделе. Для команд, работающих с AI-сгенерированным кодом, добавление contract tests на каждой границе API — это первый шаг с наибольшей отдачей.

Обезьяна уже в здании. Оружие уже заряжено. Установите аимбот или готовьтесь продолжать ловить пули.