Коллега делегирует свою работу AI, а разгребать приходится вам: что делать с AI-workslop

Смотреть детальнее

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

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

В этой статье разобрались:

• чем AI-workslop отличается от обычного использования AI-инструментов в работе — определение workslop, и почему не любой сгенерированный контент является проблемой;
• по каким признакам руководители могут за несколько секунд распознать workslop;
• почему эта проблема касается не только слабых или ленивых специалистов, и кто тогда виноват;
• какие скиллы становятся самыми ценными вместо простого «умения пользоваться AI».

Что такое workslop (спойлер: не любой контент, созданный с помощью AI)

Если разработчик сгенерировал каркас фичи с помощью Copilot, а затем проверил логику, подстроил под контекст проекта и взял ответственность за результат — это нормальное использование инструмента. Workslop возникает тогда, когда автор пропускает этот шаг и сдает результат «как есть».

Исследователи Stanford Social Media Lab и BetterUp Labs, которые и ввели этот термин, определяют workslop как контент, который выглядит как качественная работа, но не имеет сути, достаточной для продвижения задачи. Он неполный или вообще не относится к заданию, хотя формально «закрывает» его. Главное отличие не в том, использовался ли AI, а в том, является ли решение финальным.

Типичные проявления AI-workslop в IT:
🎯 резюме кандидата, идеально «заточенное» под ключевые слова вакансии, хотя опыт человека этим словам не соответствует;
🤖 чат-бот, который генерирует уверенные ответы, но не имеет доступа к актуальным данным о продукте или услуге;
📊 дашборд с десятками метрик, который выглядит убедительно, но не дает ответа ни на один бизнес-вопрос;
🗂️ backlog из десятков красиво сформулированных задач, у которых нет приоритетов и которые не приближают команду к ключевой цели;
🔐 security review, который перечисляет стандартные уязвимости, но пропускает риск, специфичный именно для этого продукта.

Тимлидам на заметку
AI-workslop редко появляется из-за лени или нехватки скиллов. Чаще всего это рациональная реакция на систему стимулов, которую выстроила компания. Например, когда в команде требуют использовать AI активнее, но редко объясняют, где нужна проверка человека. Или когда метрики обычно учитывают артефакты — тикеты, страницы, PR, — а не то, что с ними произойдет дальше. Поэтому скорость побеждает надежность, ведь именно она попадает в performance review. 

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

Сколько (на самом деле) стоит AI-workslop

Вернемся к кейсу из интро статьи. Генерация 15-страничного архитектурного анализа заняла 20 минут. Затем тимлиду нужно прочитать документ, проверить, существуют ли источники, на которые он ссылается, сверить рекомендации со стеком компании. Это может занять 2–4 часа — а если в итоге выясняется, что анализ не годится и решение приходится принимать заново, смело умножайте количество часов на два. Если перевести это в деньги при почасовой ставке тимлида $40–60, те 20 минут, которые «сэкономил» автор, оборачиваются $160–480 чужого времени (и это без учета того, что решение откладывается на день или больше).

Еще один пример: 20 аккуратно сформулированных user stories появляются за четверть часа и выглядят вполне рабочими. Но кто-то — продакт или тимлид — все равно садится расставлять приоритеты, которых там не было: это еще полчаса-час. Такая практика часто повторяется каждый спринт.

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

Главные симптомы workslop с использованием ИИ

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

Цифры без источников

Представьте, что в продуктовом отчете написано: «внедрение онбординга повысит активацию новых пользователей на 12%». Число звучит конкретно, стоит рядом с рекомендацией и вроде бы выглядит как результат анализа.

Однако эта цифра может выполнять риторическую функцию, а не информационную — делать предложение убедительным, не будучи ни измеренной, ни рассчитанной. Настоящий расчет всегда включает в себя исходные данные — «мы посмотрели на похожую фичу в прошлом квартале, активация выросла с 40% до 47%. Берем это число за основу, но с поправкой на разницу в аудитории».

Вывод сделан без привязки к ситуации

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

Полезный совет всегда привязан к конкретике и вашему контексту:

❌ Вместо: «Улучшить производительность приложения»
👍 Лучше: «Оптимизировать SQL-запрос на странице заказов: профилирование показало, что он выполняется в среднем 2,8 с и формирует основную часть задержки».

❌ Вместо: «Повысить качество кода»
👍 Лучше: «Вынести логику обработки платежей из контроллера в отдельный сервис: сейчас более 600 строк кода дублируются в трех местах, из-за чего исправление ошибок требует изменений в нескольких файлах».

Эскалация без тщательной диагностики

Сталкивались ли вы с ситуацией, когда в тикете техподдержки написано что-то вроде «проблема выглядит сложной на уровне базы данных, рекомендую подключить сеньора» — и никакого описания того, что уже проверялось? Это классический workslop: вывод («нужен сеньор») есть, а путь к нему отсутствует.

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

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

План представлен без порядка выполнения

Случается, что в брифе для новой фичи задачи перечислены списком: «разработать API», «написать документацию», «провести нагрузочное тестирование», «интегрировать с фронтендом» — все на одном уровне, без пометок о зависимостях между ними.

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

Что с этим делать: 5 шагов для тимлидов и HR-менеджеров

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

#1. Сформулируйте четкие правила

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

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

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

Смотреть детальнее

#2. Избегайте прямых обвинений

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

Несколько рабочих формулировок вместо прямых обвинений:

• «Мог бы ты показать в коде, где ты это проверил?» — вместо абстрактного обсуждения просите конкретное действие.
• «А почему именно этот вариант, а не другой?» — у человека, который сам принял решение, есть готовый ответ и он не станет использовать общие фразы.
• «Расскажи мне, пожалуйста, эту часть своими словами» — убирает костыль в виде слишком пространного текста.

#3. Смените метрики с «сколько сделано» на «что сделано»

Если перформанс-ревью считает закрытые тикеты, написанные страницы документации или количество PR в неделю, люди рационально будут генерировать объем вместо качества. Замените эти метрики на индикаторы качества, которые напрямую указывают на долю workslop в произведенном:

• сколько из сданных пул-реквестов пришлось существенно переделывать уже после мерджа;
• сколько правок вносит ревьюер в среднем на один пул-реквест;
• сколько уточняющих вопросов возникает на ретро или демо по поводу уже «готового» результата;
• сколько раз клиент или смежная команда возвращали документ на доработку.

Такие метрики фиксируют результат взаимодействия, а не объем текста или кода.

#4. Пропишите ответственность за финальный результат

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

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

#5. Проактивно выявляйте workslop

Полезно раз в квартал спрашивать команду «какой результат вам пришлось фактически переделать заново?» или «где вы потратили больше всего времени на проверку или переделывание чужой работы?»

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

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

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