Колега делегує свою роботу 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, створювати документацію та планувати роботу команди. Без чітких вимог до перевірки їхніх результатів ризик появи workslop лише зростає.

Дивитись детальніше

#2. Уникайте прямих звинувачень

«Ти сам це писав?» чи «Це AI згенерував?» — природна перша реакція, але вона програшна. Пряме звинувачення найчастіше переводить розмову в режим захисту. А ще, якщо будь-яке використання AI автоматично стає приводом для докорів, це швидко створює токсичність на роботі. У такому середовищі співробітники починають приховувати використання інструментів замість того, щоб відкрито обговорювати ризики й відповідальність за кінцевий результат.

Кілька робочих формулювань замість прямих звинувачень:

• «Чи міг би ти показати в коді, де ти це перевірив?» — замість абстрактного обговорення просите конкретну дію.
• «А чому саме цей варіант, а не інший?» — людина, яка сама ухвалила рішення, має готову відповідь і не використовує загальні фрази.
• «Розкажи мені, будь ласка, цю частину своїми словами» — прибирає милицю у вигляді надто розлогого тексту.

#3. Змініть метрики зі «скільки зроблено» на «що зроблено»

Якщо перформанс-ревʼю рахує закриті тікети, написані сторінки документації чи кількість PR на тиждень, люди раціонально генеруватимуть обсяг замість якості. Замініть ці метрики на індикатори якості, що прямо вказують на частку workslop у виробленому:

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

Такі метрики фіксують результат взаємодії, а не обсяг тексту чи коду.

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

Незалежно від того, чи використовувався AI, автор документа чи коду залишається відповідальним за його якість так само, як і раніше. Варто проговорити, що саме людина вирішує, що відправити на ревʼю, що змерджити в основну гілку, який документ розіслати команді чи який звіт показати керівництву. AI не бере участі в цих рішеннях.

Тож в командах варто оцінювати не те, чи використовував співробітник AI в принципі, а те, чи відповідає фінальний результат стандартам якості. Це зберігає незмінними очікування до роботи й не створює подвійних стандартів для контенту, написаного людиною або моделлю.

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

Корисно раз на квартал запитувати команду «який результат вам довелося фактично зробити заново?» або «де ви витратили найбільше часу на перевірку чи переробку чужої роботи?»

Такі запитання швидко виявляють місця, де AI створює лише видимість виконаної роботи. Якщо кілька людей незалежно згадують однаковий тип задач — наприклад, PR, які доводиться майже повністю переписувати, або документи, які простіше написати з нуля, ніж виправляти, — це системний сигнал.

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

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