Старшее суждение в командах с интенсивным применением ИИ: что остаётся за людьми

Почему более быстрый результат может снижать качество решений

Скорость даёт удовольствие. Команда может попросить AI предложить пять вариантов дизайна, три схемы базы данных и неделю каркаса кода до обеда. Проблема проста: варианты приходят раньше, чем кто‑то проверит, подходят ли они продукту, пользователям или бюджету.

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

Полированный результат усугубляет проблему. AI часто пишет код, документацию и технические заметки в спокойном, законченно звучащем тоне. Такой тон может скрывать слабые допущения. Разделение сервиса может выглядеть аккуратно на бумаге и всё равно добавить точки отказа. Модель разрешений может читаться хорошо и одновременно игнорировать то, как на самом деле работает саппорт.

Быстрая генерация также может разрушить коллективную память команды, если никто не фиксирует компромиссы. Один инженер принимает самое быстрое решение по схеме, потому что демо близко. Другой оставляет старый API, потому что изменить мобильное приложение займёт два лишних дня. Менеджер утверждает оба решения, так как работа выглядит видимой. Неделей позже у команды оказывается дизайн с перемешанными правилами и без общей причины, стоящей за ним.

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

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

Эти вопросы замедляют команду на час. Они могут сэкономить недели на уборке.

Риск растёт, когда целью становится только скорость. Команды начинают поощрять тех, кто выпускает первым, а не тех, кто заметил слабое допущение рано. Такая привычка выглядит продуктивной один‑два спринта. Позже она проявляется как переработки, тяжёлые инциденты и архитектурные решения, которых никто не хочет защищать.

Быстрый вывод полезен. Быстрое суждение — редкость. Это разные вещи.

Что люди всё ещё должны решать

AI может сгенерировать десять приемлемых опций за то время, за которое человек набросал бы одну. Эта скорость полезна, но она не должна решать правила, по которым команде жить. Люди по‑прежнему должны принимать решения, формирующие риск, стоимость и поведение продукта.

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

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

Краевые случаи тоже требуют человеческого суждения. AI хорош на «счастливом» пути. Он гораздо хуже задаёт неловкие вопросы, например: что если платёж пройдёт дважды, синхронизация опоздает или пользователь загрузит неверный тип файла прямо перед дедлайном? Старшие люди обычно видят эти режимы отказа, потому что уже сталкивались с ними.

Возьмите внутренний инструмент, который суммирует тикеты поддержки. AI может набросать фичу и даже предложить изменения в базе. Человеку всё равно следует решить, может ли инструмент читать приватные заметки клиентов, сохранять ли сводки и что делать, если модель вернёт неверный результат. Эти решения влияют на доверие больше, чем скорость кода.

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

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

Как разделять работу по риску

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

Это особенно важно, когда AI быстро черновые варианты работы. Если никто заранее не выделяет рискованные задачи, команда начинает относиться ко всему выводу одинаково.

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

Затем пометьте каждое решение по влиянию:

• Низкое влияние — легко отменить, небольшой эффект на пользователей, нет рисков по безопасности или данным
• Среднее влияние — затрагивает общий код, влияет на производительность или меняет поведение между командами
• Высокое влияние — затрагивает архитектуру, безопасность, соответствие, биллинг, данные клиентов или риск простоев

Низко‑влияющиеся задачи — там, где AI помогает больше всего. Пусть он готовит тесты, рутинный CRUD, заметки по миграциям, статус‑апдейты или первичную документацию. Если результат неверен, кто‑то быстро исправит и двигаться дальше.

Работа среднего влияния требует ревью с контекстом. Обычно её может вести инженер среднего уровня, но он не должен ревьюить в одиночку. Дайте ему явного ревьюера и короткий чек‑лист.

Решения высокого риска нуждаются в именованном владельце до старта спринта. Это может быть старший инженер, тим‑лид или CTO. Правило должно быть простым: AI может предлагать варианты, но люди утверждают финальное направление.

Быстрая оценка помогает, когда ярлык кажется размытым:

• Можем ли мы отменить это менее чем за час?
• Затрагивает ли это деньги, авторизацию или данные клиентов?
• Распространится ли ошибка по сервисам?
• Закрепляет ли этот выбор дизайн, о котором мы пожалеем?
• Кто должен подписать перед мерджем или релизом?

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

Ревью, которые всё ещё требуют старших глаз

Быстрый вывод делает слабые изменения безопасными на вид. Дифф может выглядеть аккуратно, тесты — проходить, а риск всё равно сидеть в вещах, которые повредят позже: форма данных, правила доступа, денежные потоки и фоновые джобы.

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

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

Это ещё важнее в AI‑интенсивных командах, потому что скорость генерации скрывает архитектурный дрейф. Инструмент может создать аккуратный новый сервис, хелпер или абстракцию за минуты. Сложность в том, нужно ли системе вообще это дополнительное звено.

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

Старший ревьюер должен задавать простые вопросы:

• Что произойдёт, если этот запрос таймаутит после записи, но до ответа?
• Создаст ли повтор дубликат записи, платежа или сообщения?
• Если одна зависимость упала, система закроется или откроется (fail closed или fail open)?
• Добавило ли это изменение скрытое правило, которое пропустит другая команда?

Аккуратно выглядящий код заслуживает дополнительного подозрения, когда он добавляет скрытую сложность. AI хорош в создании кода, который читается красиво на поверхности. Он также может подкинуть ещё один wrapper, ещё один фоновой процесс, ещё один путь конфигурации или ещё одно состояние, которого никто не просил.

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

Хорошее старшее ревью не медленно из‑за неприязни к AI. Оно медленно потому, что некоторые решения требуют памяти, контекста и чувства отказов, которых генерация кода не имеет. Когда изменение может коснуться доверия, денег, данных или восстановления, финальный звонок всё ещё должен делать человек.

Простой пример спринта

В понедельник команда получает небольшую задачу: добавить фичу импорта клиентов, чтобы пользователи могли загрузить CSV и массово создавать записи. Инструмент AI набрасывает большую часть за один день. Он генерирует endpoint загрузки, парсер, фоновый джоб и несколько тестов.

На первый взгляд результат выглядит хорошо. Демо работает на чистом примере. Команда может загрузить 50 строк в staging, и джоб быстро завершится.

Потом старший ревьюер читает код и проверяет реальную схему, а не образец данных. Там и проявляются проблемы.

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

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

Фикс — не мелкий патч. Команда меняет поток джоба перед релизом:

• Валидировать файл и соответствие колонок первым шагом.
• Создать запись партии импорта (import batch).
• Обрабатывать строки маленькими чанками со статусом по строке.
• Повторять только неудачные чанки.
• Добавить проверки идемпотентности перед записью данных.

Это занимает большую часть следующего дня. Фича уходит в прод на день позже, чем планировалось.

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

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

Быстрый вывод помогает. Старший ревью решает, достаточно ли безопасен результат для релиза.

Ошибки, которые ослабляют суждение

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

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

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

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

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

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

Последняя ловушка проявляется в начале внедрения. Руководители внедряют AI‑инструменты до того, как задают границы, пути утверждения и владение. Люди начинают использовать инструмент для всего — от генерации тестов до миграций базы, даже когда никто не согласовал, где проходит граница.

Обычно это ведёт к предотвращаемым проблемам:

• AI пишет продакшен‑код до того, как команда определила, где нужно ручное ревью.
• Старший человек становится резиновым штампом, потому что запросы скапливаются весь день.
• Люди мержат рискованные изменения без письменного обоснования.
• Никто не владеет правилами по безопасности, архитектуре или откату.

Лучший паттерн — скучный, и поэтому он работает. Решите, какие изменения требуют двух человеческих ревью. Решите, какие решения требуют письменных компромиссов. Решите, кто может сказать «нет», когда вывод AI выглядит нормально, но кажется неправильным.

Это совпадает с подходом, который описывает Oleg Sotnikov в своей консультативной работе на oleg.is: позволить AI заниматься черновиками и ускорением, но оставить архитектуру, операционную работу и решения по риску людям, которые могут принять ответственность за результат.

Быстрая проверка перед релизом

Скорость создаёт ложное чувство безопасности. Команда видит зелёные тесты, чистые диффы и быстрый AI‑выход, затем предполагает, что релиз готов. Чаще всего именно в этот момент суждение ослабевает.

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

Задайте эти вопросы перед выводом в прод:

• Кто принял окончательное архитектурное решение?
• Прочитал ли старший ревьювер рискованные изменения от начала до конца?
• Может ли команда объяснить план отката в двух‑трёх понятных шагах?
• Тестировали ли кто‑то специально путь отказа, а не только счастливый путь?
• Знает ли поддержка в простых словах, что изменилось?

Эта проверка не занимает много времени. Во многих командах она занимает 10–15 минут и экономит часы уборки позже. Она также заставляет полезную паузу: люди перестают спрашивать «AI завершил задачу?» и начинают спрашивать «Доверяем ли мы этому изменению в проде?»

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

Если релиз не проходит эту проверку — отложите его. Это не проблема процесса. Это значит, что команде нужен человеческий вердикт, а не ещё больше сгенерированного кода.

Что делать дальше

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

Запишите, какие решения по‑прежнему принадлежат людям. Держите за людьми архитектурные изменения, правила безопасности, обязательства перед поставщиками, поведение, видимое клиенту, и любые расходы, которые могут расти месяц за месяцем.

Короткое правило работает лучше длинной политики. Поместите его в заметки спринта, шаблон pull request или чек‑лист ревью, чтобы никому не приходилось догадываться:

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

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

Затем измерьте эффект за два спринта. Отслеживайте три числа: переделки, инциденты и сэкономленное время. Переделки покажут, создал ли AI лишнюю уборку. Инциденты покажут случаи, где ревью было слишком лёгким. Сэкономленное время покажет, помогает ли процесс команде двигаться быстрее.

Небольшой тест упрощает задачу. Допустим, команда использует AI для ускорения работы над потоком онбординга клиентов. Пусть AI набросает формы, тесты и рутинные обработчики. Держите модель данных, правила прав доступа и выбор внешних сервисов у старшего инженера или CTO. Через два спринта сравните, сколько тикетов было переоткрыто, сколько дефектов дошли до пользователей и сколько часов команда сэкономила.

Если у команды нет человека с достаточным временем или охватом, внешняя помощь быстро закроет этот пробел. Oleg Sotnikov работает как внештатный CTO для стартапов и небольших бизнесов, и его работа фокусируется как раз на такой проблеме: использовать AI, чтобы двигаться быстрее, не теряя контроля над архитектурой, инфраструктурой и рисками.

Цель не в том, чтобы замедлить AI. Цель — решить, где скорость помогает, а где суждение всё ещё защищает бизнес.