Что я пока не готов делегировать AI

Чем дольше я работаю с coding agents, тем больше задач им отдаю. Сначала отдельные функции. Потом рефакторинг. Потом полноценные feature. Потом исследование. Потом review. Потом часть тестирования. Потом почти весь workflow.

И в какой-то момент естественно возникает вопрос: а что вообще останется мне?

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

Поэтому я хочу зафиксировать не универсальный список запретов. А свою текущую границу.

Июль 2026 года. Вот что я пока не готов полностью делегировать AI.

Окончательное архитектурное решение

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

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

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

AI
    ↓
варианты
    ↓
аргументы
    ↓
риски
    ↓
я
    ↓
решение

А не:

AI
    ↓
решение

Security-critical изменения без независимой проверки

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

В таких местах ошибка слишком дорога. Особенно потому, что security-баг часто не выглядит как «сломанный код». Всё может работать идеально. Просто доступ получил не тот пользователь. Или проверка происходит не на том уровне. Или новый endpoint обходит старое ограничение.

AI может написать такую ошибку очень аккуратно. С хорошей типизацией. С тестами. С красивым объяснением. Поэтому здесь я хочу видеть независимый review и собственную проверку. Про то, почему self-review здесь недостаточен, я уже писал отдельно.

Бизнес-компромиссы

Это одна из самых сложных границ. Допустим, есть два решения. Первое архитектурно чище. Второе можно выпустить за три дня. Первое потребует миграции данных. Второе создаст небольшой технический долг. Через полгода модуль, возможно, вообще перепишут. Что выбрать?

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

Это не вопрос «какое решение технически лучше?» Это вопрос: какое решение сейчас правильнее для этого бизнеса? И здесь я пока не хочу отдавать последнее слово модели.

Production migration

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

AI может написать migration. Может проверить SQL. Может предложить rollback. Может оценить риски. Может даже составить план выполнения. Но нажать условную кнопку «выполняем на production» я пока хочу сам.

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

Разрушительные операции

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

В таких операциях меня меньше интересует способность AI выполнить команду. Меня больше интересует необратимость последствий. Поэтому здесь мне нравится простое правило:

AI может подготовить действие
    ↓
AI может объяснить последствия
    ↓
AI может проверить условия
    ↓
человек подтверждает разрушительный шаг

Возможно, со временем эта граница тоже сдвинется. Но пока мне комфортно именно так.

Решение «что вообще нужно сделать»

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

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

Может быть, проблема не в state machine. Может быть, интерфейс плохо объясняет существующее состояние. Или бизнес пытается через техническое изменение компенсировать неудобный процесс. Или feature нужна одному клиенту и ухудшит продукт для всех остальных.

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

Я не хочу делегировать ответственность вместе с задачей

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

Если агент написал feature, а она сломала production, странно говорить: это AI решил так сделать. Нет. Это мы приняли изменение. AI был исполнителем.

Поэтому чем выше цена ошибки, тем меньше меня устраивает схема:

agent finished
    ↓
merge

И тем больше хочется:

agent finished
    ↓
evidence
    ↓
review
    ↓
human checkpoint
    ↓
decision

Не все задачи требуют одинакового контроля

При этом я не хочу превращать всё в бюрократию. Исправить опечатку в сообщении? Пусть агент сделает и проверит. Переименовать внутренний метод? Скорее всего тоже. Добавить простой тест? Без проблем.

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

Для меня размер контроля должен зависеть не от количества строк, а от стоимости ошибки.

Интересно, что некоторые вещи я уже делегирую, хотя раньше не делегировал бы

Например, исследование архитектуры. Ещё недавно мне было трудно представить, что я начну задачу словами: сам найди, как здесь всё устроено. Теперь это обычный сценарий.

То же самое с review. И с написанием значительной части тестов. То есть граница действительно движется. И именно поэтому мне кажется важным её фиксировать.

Моя текущая схема примерно такая

AI может самостоятельно:
    ↓
исследовать
    ↓
предлагать варианты
    ↓
писать код
    ↓
писать тесты
    ↓
запускать проверки
    ↓
делать self-review
    ↓
делать independent review


но human checkpoint остаётся перед:
    ↓
важным архитектурным решением
    ↓
security-critical изменением
    ↓
production migration
    ↓
destructive action
    ↓
значимым бизнес-компромиссом
    ↓
решением «что вообще строим»

Это не закон. Просто моя текущая граница доверия.

Я стараюсь не путать автономность и бесконтрольность

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

Например: для выполнения задачи нужно изменить публичный API. Нужен human approval.

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

Иногда AI сам должен уметь остановиться

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

если migration destructive
    ↓
stop

если меняется public API
    ↓
stop

если нужно добавить dependency
    ↓
ask

если затрагивается auth
    ↓
require review

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

Самое сложное — не передержать контроль

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

Поэтому сейчас я скорее пытаюсь найти не максимальный контроль, а разумный уровень доверия. Где можно принимать результат по тестам и review. Где нужно посмотреть diff самому. А где я вообще должен участвовать ещё до реализации. Это пока постоянно меняется.

Возможно, через год этот список покажется смешным

Именно поэтому мне хочется сохранить дату. Июль 2026 года.

Сегодня я пока не готов полностью отдать AI финальную архитектуру, security-critical изменения без review, крупные production migrations, destructive operations, важные бизнес-компромиссы, решение о том, что вообще нужно строить.

Через год часть этого списка может исчезнуть. Появятся более надёжные agents. Лучшие verification systems. Более строгие policies. Sandbox environments. Автоматические review pipelines. Возможно, production migration будет проходить через настолько хороший набор проверок, что человеческое подтверждение станет формальностью.

А возможно, наоборот, я обнаружу новые границы, о которых сегодня вообще не думаю. И это как раз интересно.

Потому что вопрос уже не «можно ли доверять AI»

Он слишком широкий. Мне гораздо полезнее спрашивать: какую именно ответственность я готов ему передать в этой конкретной задаче?

Исследовать? Да. Предложить архитектуру? Да. Принять архитектурное решение? Пока нет. Написать migration? Да. Запустить её на production? Пока нет. Найти бизнес-компромиссы? Да. Выбрать компромисс за продукт? Пока нет.

И такая формулировка мне нравится намного больше. Она не требует верить или не верить AI целиком. Она позволяет постепенно расширять границы.

Поэтому моя текущая роль всё ещё довольно понятна

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

И, возможно, моя роль постепенно именно туда и сдвигается. От «кто будет писать этот код?» к «кто должен принять решение, последствия которого останутся после этого кода?»

На июль 2026 года мой ответ пока такой: в некоторых местах — всё ещё я.