AI в рутине: где он экономит часы, а где крадёт их

Прошло примерно полгода с того момента, как агентные инструменты и reasoning-модели перестали быть для меня предметом скепсиса и стали обычной частью рабочего дня. За это время накопилось достаточно эмпирики, чтобы перестать спорить о том, «работает AI или нет», и заняться куда более скучным, но полезным делом — инвентаризацией. Не «изменил ли он мою жизнь», а буквально: на каких задачах он стабильно экономит мне часы, а на каких так же стабильно их крадёт, делая вид, что экономит.

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

Сразу зафиксирую главную мысль, чтобы дальше было понятно, к чему я веду. Ценность AI в рутине — это не то, что он «всё умеет». Реальная ценность в другом: он снимает с инженера механический слой работы и тем самым освобождает голову под то, что умеет только инженер. Это и есть фигура «не A, а B». Не универсальный исполнитель, который делает за тебя инженерную работу, а разгрузчик рутины, который возвращает тебе внимание. Всё, что описано ниже, — попытка аккуратно провести границу между этими двумя ролями, потому что путаница между ними и есть главный источник потерянного времени.

Когда форма результата известна заранее, ассистент почти не ошибается

Общий признак задач, на которых AI даёт настоящий прирост, формулируется довольно точно: это работа, где форма результата известна заранее, а трудоёмкость лежит в объёме, а не в принятии решений. Там, где инженер и сам знает, что должно получиться, и единственная проблема — это набить руками много предсказуемого кода, ассистент работает почти безупречно. Он не придумывает архитектуру, он тиражирует уже принятое решение. И именно поэтому он надёжен.

За полгода у меня сложился вполне устойчивый список таких сценариев. Перечислю прямо, потому что конкретика тут важнее рассуждений:

Тесты на уже написанный код. Когда поведение функции зафиксировано, генерация табличных и граничных кейсов — почти идеальная задача. AI быстро покрывает очевидное, я добавляю неочевидное. Час работы превращается в двадцать минут.
Механические миграции. Переименование API по кодовой базе, перевод компонентов на новый паттерн, обновление вызовов под изменившуюся сигнатуру. Особенно с агентным режимом, который видит несколько файлов сразу и держит контекст изменения.
Бойлерплейт. DTO, типовые контроллеры, схемы валидации, обвязка вокруг известного интерфейса, конфиги. Всё, что ты сто раз писал и где каждый новый экземпляр отличается от прошлого деталями, а не сутью.
Одноразовые скрипты. Распарсить выгрузку, переложить данные из одного формата в другой, собрать утилиту для разовой починки. Код, который не будет жить долго и которому не нужна архитектура — нужен результат сейчас.
Разбор логов и стектрейсов. Скормить простыню и получить структурированную гипотезу «вот здесь падает, вот почему» — это огромная экономия внимания на этапе, где ты ещё ничего не знаешь и просто хочешь сузить область поиска.
Документация и пояснения. Черновик README, описание модуля, комментарий к нетривиальному куску, changelog по диффу. AI даёт болванку, которую правишь, а не пустой файл, перед которым прокрастинируешь.

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

Почему именно на рутине прирост настоящий, а не выдуманный

Тут стоит остановиться, потому что есть соблазн обесценить эту экономию: «ну подумаешь, бойлерплейт, это же не настоящая работа». Это ошибка. Механическая работа отъедает не только время — она отъедает внимание, а внимание у инженера ресурс куда более дефицитный, чем часы. Когда я полдня переименовываю поля и пишу однотипные тесты, к вечеру у меня не остаётся свежести на единственную действительно сложную задачу дня. И вот её-то я делаю плохо.

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

А вот где минута на запрос превращается в полдня на последствия

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

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

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

Главный механизм кражи времени — правдоподобие, которое отключает подозрительность

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

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

Чем приходится платить за разгрузку рутины

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

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

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

Третья цена — ответственность не делегируется вместе с задачей. Сгенерированный код, попавший в продакшен, — это мой код. Не «AI ошибся», а «я не проверил». Инструмент не несёт последствий за то, что написал, последствия несу я и моя команда. И это, пожалуй, та граница, которую важнее всего не перепутать: можно отдать исполнение, но нельзя отдать ownership. Кто нажал merge, тот и автор.

Практическое правило, по которому я теперь решаю, звать ли AI

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

Этот критерий хорош тем, что не опирается на расплывчатое «сложно или просто». Тесты на готовый код — проверить тривиально, значит, AI. Доменная логика — чтобы проверить, надо продумать всё самому, значит, я сам. Разбор лога — гипотезу проверяю быстро, значит, AI как ассистент следователя. Архитектурная развилка — цена решения видна только во времени, проверить «сейчас» невозможно, значит, ассистент в лучшем случае собеседник, но не автор. Один и тот же вопрос аккуратно разрезает все мои задачи по правильной границе.

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

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

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

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