Сегодня поговорим о сложностях изменений. Мы привыкли считать, что автоматизация должна повторить существующий порядок действий - только быстрее. Но при работе с LLM обнаруживается более интересный вызов: новый инструмент предлагает изменить не отдельную операцию, а сам способ организации работы.

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

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

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

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

Но и предложение LLM нельзя принимать автоматически. Модель может не знать исключений, требований безопасности или скрытой функции промежуточного шага. Допустим, она предлагает сразу рассылать отчёт, пропустив просмотр сотрудником. А именно во время просмотра тот замечает редкие, но важные отклонения. В таком случае нужно не просто вернуть старую операцию, а объяснить её назначение и решить, можно ли заменить её другим контролем.

Короткий путь не всегда допустимый. Если порядок установлен законом, он является обязательным условием. Если действие защищает от ошибки, нужно понять, насколько часто ошибка возникает и кто будет её замечать после изменения. Если же шаг существует только потому, что «так принято», его сохранение требует не меньшего объяснения, чем попытка его убрать.

Поэтому при работе с LLM полезно разделять три вещи:

1. Цель - какой результат нужен пользователю, клиенту или организации. 2. Ограничения - что нельзя нарушать из-за закона, безопасности, ответственности или риска. 3. Привычный маршрут - как эту работу выполняют сейчас, но не обязательно должны выполнять всегда.

Хороший запрос к LLM описывает первые два пункта и не превращает третий в закон без необходимости. А хороший человек-постановщик проверяет предложенный вариант: где будет контроль, кто отвечает за последствия и не появится ли новая ручная работа на соседнем этапе.

В этом смысле LLM не волшебник и не новый владелец процесса. Она скорее собеседник, который не испытывает почтения к давно существующим кнопкам, файлам и согласованиям. Иногда это приводит к опасному упрощению. Иногда - позволяет впервые увидеть, что мы защищали не полезный результат, а знакомый порядок действий.

Модель предлагает изменение, но работать с его последствиями будем мы. Поэтому её ответ - не готовое решение и не повод отменять правила. Это приглашение заново спросить: зачем мы делаем именно так и что должно остаться неизменным?

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

Что в вашей работе вы назвали бы настоящим требованием, а что - всего лишь привычным способом его выполнять?