ИИ ускоряет сотрудника, но замедляет команду: где проходит граница полезной автоматизации

Я Антон Калуцкий, руководитель DEVCOM — экспертного центра аутстаффинга ИТ-специалистов с экспертизой в 1С. Делюсь наблюдениями, как разработчики 1С применяют ИИ в работе, какие задачи ему доверяют и в каких случаях он действительно помогает ускорить разработку.

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

Но что происходит с результатом дальше? По моему опыту ^[1], сотрудник действительно может работать быстрее в два-три раза, а скорость команды остается прежней. Более того, иногда ИИ замедляет общий процесс, потому что экономия времени на одном этапе оборачивается дополнительной работой на следующем.

Аналитик сделал документ за час, архитектор разбирал его три

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

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

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

Личная производительность и результат команды — разные вещи

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

Для приблизительной оценки можно использовать простую формулу:

Эффект от ИИ = сэкономленное время автора − дополнительное время, затраченное остальными участниками.

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

Быстрее подготовить результат — не значит быстрее решить задачу.

Почему ИИ создает дополнительную работу

ИИ умеет быстро производить большие объемы текста. Для человека написать 15 страниц — отдельная задача: нужно сформулировать мысли, выстроить структуру, подобрать аргументы, перечитать и отредактировать написанное. Для языковой модели разница между одной и пятнадцатью страницами гораздо менее существенна.

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

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

На этом этапе возникает соблазн отправить текст дальше: если задача состояла в экономии времени, зачем тратить еще два часа на проверку? Но проверка никуда не исчезает — ее выполняет следующий участник процесса. Так локальная экономия превращается в дополнительную нагрузку на команду.

Чем опасен правдоподобный текст от ИИ

Плохой текст, написанный человеком, часто обнаруживает свои недостатки довольно быстро. ИИ может выдать убедительный документ с корректными терминами, понятной структурой и последовательными рассуждениями, в основе которых лежит неверное предположение.

Если его не заметить, на ошибке ^[2] могут строиться следующие выводы. Поэтому проверка такого результата порой требует больше времени, чем ожидает автор. Очевидную бессмыслицу легко отсеять, а убедительно сформулированную ошибку заметить сложнее.

Чем качественнее выглядит ответ модели, тем важнее не путать форму с содержанием. Хорошая структура и уверенный тон сами по себе не подтверждают достоверность фактов и правильность выводов.

Почему умения писать промпты недостаточно

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

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

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

Как использовать ИИ в аналитике

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

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

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

С разработкой происходит то же самое

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

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

Поэтому экономить время на написании кода имеет смысл, если это не увеличивает затраты на проверку, исправление и сопровождение.

Как понять, что ИИ действительно помогает

Я бы оценивал качество использования ИИ по тому, становится ли следующему участнику процесса проще работать с результатом:

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

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

• Руководитель, получив отчет, должен увидеть выводы, а не тратить время на изучение двадцати страниц сгенерированного текста.

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

Иначе получается, что мы автоматизировали производство результата, но не решение задачи. А иногда просто сделали дешевле создание работы для другого человека.

Как руководителю оценивать производительность

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

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

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

ИИ не отменяет экспертизу

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

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

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

Вывод

Я не считаю, что ИИ нужно ограничивать из-за риска неправильного использования. Он уже ускоряет множество задач, и область его применения будет расширяться. Но опасно считать любую экономию времени отдельного сотрудника доказательством роста производительности.

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

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