Як зловживання AI руйнує довіру в remote-командах. Наш реальний кейс

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Я Максим, CEO SpdLoad, і я вже багато років працюю з remote-розробниками. Ця стаття буде корисною для фаундерів, CTO, HR і розробників, які працюють з AI та хочуть краще розуміти ризики, що з’явилися на ринку. Я поділюся реальним досвідом нашої команди.

Після буму GenAI ринок розробки змінився. Багато задач зараз бере на себе ШІ. Навіть засновник Linux вайбкодить, і це стало чимось звичайним. Використання ШІ дійсно допомагає в рутинних задачах та трохи розвантажує розробників.

Я це приймаю і загалом позитивно ставлюся до ШІ як до додаткового інструменту, який економить час. Та, на жаль, деякі розробники (ну і користувачі ШІ загалом, але наш кейс пов’язаний саме з розробником, тому тут такий акцент) зловживають штучним інтелектом і скидають на нього всі свої задачі. А оскільки зараз багато компаній, у тому числі й наша, працюють на 100% ремоут, якось проконтролювати це на старті стає важко.

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

Існує теорія, що якість генеративних моделей починає деградувати, коли вони навчаються на згенерованих даних. Спочатку моделі навчалися на живих даних з інтернету (коді, статтях, дискусіях на Reddit, тобто на реальному досвіді людей).

Але вже наприкінці 2025 року, за оцінками досліджень, більше половини публічного контенту в мережі та 41% всього коду складається з AI-згенерованих матеріалів.

Це означає, що нові моделі дедалі частіше навчаються на контенті, згенерованому попередніми моделями. Як результат, якість їхньої видачі погіршується (відбувається model collapse). Поки ще мало досліджень на цю тему, але це все-таки дає привід задуматися про якість роботи повністю виконаної штучним інтелектом.

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

І як результат один розробник має кілька фултаймів, а працює насправді максимум 1-2 години на день. Я чув такі історії, але ми у команді стикнулися з таким вперше.

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

Очікувано у вас може з`явитися питання: а де контроль з вашого боку? Хіба ви не помітили одразу, що щось не так? Відповідаю: проблеми ми помітили одразу і від нас були фідбеки, однак часу на радикальні зміни не було. Тому сподівалися, що чесні відгуки про роботу та чітко окреслені обов’язки і очікування допоможуть людині виправитися.

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

Як визначити, що розробник зловживає ШІ

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

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

Проблеми почалися вже з перших днів роботи. Спочатку дрібні, на перший погляд: кілька днів простою через відсутність Figma Dev Mode або відмова робити базову верстку без pixel perfect. Загалом за робочий день результатів чи прогресу майже не було.

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

Ми не розірвали відносини одразу — і це наша помилка.

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

Розробник не повідомляв, що задач немає, і чекав, поки клієнт прокинеться (клієнт з Америки), щоб сказати, що його робочий день уже закінчився. Він часто зникав перед колами та здавав last-minute PR, згенеровані AI.

Поки задачі були прості — типу змінити колір кнопки (на це в нього, між іншим, йшов цілий день) — це ще якось маскувалося. Але коли з’явилася логіка — все зламалося.

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

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

Як ми намагалися вирішити ситуацію і що з цього вийшло

Після повного ігнору комунікації та зриву делівері ми ухвалили рішення про розрив відносин за порушення умов договору одним днем. Це був перший такий випадок активації певних пунктів договору за 13 років. Мені завжди було легше в усіх конфліктах просто заплатити й зекономити нерви.

Важливо уточнити, що спочатку ми намагалися виправити ситуацію кілька разів різними способами.

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

По-друге, ми підключили менеджмент і технічну підтримку. Ми напряму проговорювали проблеми — відсутність прогресу, ігнорування задач, дивну поведінку в комунікації, використання AI без контролю. Людина отримувала чіткий фідбек і попередження.

По-третє, ми дали можливість виправитися. Навіть після зриву делівері та перших серйозних проблем не закрили питання одразу. Ми очікували хоча б базової відповідальності: вийти на зв’язок, пояснити ситуацію, запропонувати рішення. Ну і, можливо, якогось людського — «вибачте, що так вийшло» (в ідеалі, звичайно).

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

Як захиститися від подібних випадків

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

Якщо людина з перших тижнів уникає відповідальності, не комунікує та не виконує свої обов’язки, а маскує все згенерованим кодом — ситуація не покращиться. Тому співпрацю потрібно припиняти одразу, щоб уникнути проблем (а вони будуть 100%).

Сподіваюся, наш випадок стане для когось цінною інформацією та допоможе визначити, чи ваші працівники зловживають ШІ. Ми, на жаль, на собі відчули, скільки шкоди всього за два місяці може завдати людина, яка нехтує своїми обов’язками.

Ми не вважаємо цей кейс унікальним. Навпаки — таких історій стає більше.

Ось кілька основних пунктів з нашого досвіду, як вберегтися від подібних ситуацій:

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

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

2. Не забороняти використання ШІ, але обмежувати правилами. Розробляйте чіткі політики та інструкції щодо використання ШІ. У ваших політиках має бути чітко прописано:

• що вважається допустимим використанням AI;
• хто несе відповідальність за результат;
• що код має бути зрозумілим автору, а не просто згенерованим.

Ми вже додали цей пункт у наші правила співпраці.

3. Фокусуватися не на годинах, а на делівері. Мають бути регулярні проміжні результати, а також короткі й зрозумілі чекпоїнти. Якщо за 8 годин роботи людина встигла лише змінити колір кнопки — це не ОК.

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

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

5. Перевіряти розуміння логіки розробки. На старті важливо дивитися на те, як людина пояснює свої рішення, чи розуміє вона, що саме здала, а також чи може швидко відповісти на запитання по своєму PR. AI-код дуже добре видно, коли людина не може пояснити, як він працює.

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

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.