Я вже багато років працюю з remote-розробниками. Ця стаття буде корисною для фаундерів, CTO, HR і розробників, які працюють з AI і хочуть краще розуміти ризики, що з’явилися на ринку. Я ділюся реальним досвідом нашої компанії — без звинувачень і з чіткими висновками.
Передісторія: чому ми про це говоримо
Після буму GenAI ринок розробки змінився. Багато задач зараз бере на себе ШІ.
Зараз навіть засновник Linux вайбкодить, і це стало чимось звичайним. Використання ШІ дійсно допомагає у рутинних задачах та трохи розвантажує розробників.
Я це приймаю і загалом позитивно ставлюсь до ШІ як до додаткового інструменту який економить час. Та на жаль, деякі розробники (ну і користувачі ШІ загалом, але наш кейс пов`язаний саме з розробником, тому тут такий акцент) зловживають штучним інтелектом і скидають на нього всі свої задачі. А оскільки зараз багато компаній, в тому числі і наша, працюють на 100% ремоут, якось проконтролювати це на старті стає важко.
Але є ще один важливий момент, про який зараз все частіше говорять.
Існує теорія, що якість генеративних моделей починає деградувати, коли навчаються на згенерованих даних. Спочатку моделі навчалися на живих даних з інтернету (коді, статтях, дискусіях у редіті, тобто на реальному досвіді людей). Але вже наприкінці 2025 року, за оцінками досліджень, більше ніж половина публічного контенту в мережі та 41% всього коду складається з AI-згенерованих матеріалів.
Це означає, що нові моделі дедалі частіше навчаються на контенті, згенерованому попередніми моделями. Як результат, якість їхньої видачі погіршується (відбувається model collapse). Поки ще мало досліджень на цю тему, але це все-таки дає привід задуматися про якість роботи повністю виконаної штучним інтелектом.
То був короткий відступ, щоб підсвітити проблему: так, писати код з ШІ це швидко, але не завжди якісно. Та інколи спеціалісти думають, що якщо код хоч якось працює, то вже не так важливо, як саме він був створений. Головне, що тепер є більше вільного часу, який теж можна монетизувати.
І як результат, один розробник має кілька фул-таймів, а працює насправді максимум 1-2 години на день. Я чув такі історії, але ми у команді стикнулися з таким вперше. І ось я хочу розповісти про наш кейс.
Одразу дисклеймер: це наш досвід, ми не проти розумного використання ШІ в розробці. Моя головна мета тут — пояснити, що для нас головне — вчасно та якісно виконана робота. Ми відповідальні перед клієнтами і не можемо їх підвести, тому що якщо людина з нашої команди нехтує своїми обов`язками, тоді страждає насправді вся компанія, і це несправедливо.
Саме тому я вирішив, що цим важливо поділитися. Для когось це буде цінний досвід, як вчиняти у подібних ситуаціях, а для когось, можливо, знак, що варто переглянути свій підхід до роботи. Для нас же це урок, який не хотілося б повторювати знову.
Наш кейс: як визначити, що розробник зловживає ШІ
Наприкінці листопада, на початку грудня ми терміново шукали розробника під проєкт. Клієнт різко заапрувив скоуп, а всі наші інженери були зайняті.
Ми взяли людину, яка вже проходила інтерв’ю раніше. На той момент вона шукала роботу вже три місяці й досі була в пошуках. Це насторожило, але, чесно кажучи, часу на довгі роздуми не було.
Проблеми почалися уже з перших днів роботи. Спочатку дрібні, на перший погляд, наприклад, було кілька днів простоїв через відсутність Figma Dev Mode, або він відмовлявся робити базову верстку без pixel perfect. І загалом, за робочий день результатів чи прогресу майже не було.
І, зрештою, за перший місяць у нового розробника було кілька розмов зі мною, пару зідзвонів з HR та з техлідом. Ці розмови були не про онбординг, ми відкрито обговорювали що нас не влаштовувало в його роботі. Тобто у людини було п’ять попереджень за чотири тижні.
Ми не розірвали відносини одразу — і це наша помилка.
Оскільки проєкт був критичний, а часу шукати заміну не було, ми сподівалися, що ситуація вирівняється. Але далі стало тільки гірше.
Розробник не повідомляв, що задач немає, чекав, поки клієнт прокинеться (клієнт з Америки), щоб сказати, що його робочий день вже закінчився. Він часто зникав перед колами і здавав last-minute PR, згенеровані AІ.
Поки задачі були прості, типу змінити колір кнопки (на це у нього йшов цілий день, між іншим) це ще якось маскувалося. Але коли з’явилась логіка — все зламалося.
У критично важливий момент, AI-код був залитий в обхід техліда, проєкт упав, а людина не могла його пофіксити, бо не розуміла, що саме там відбувається.
У результаті інші розробники терміново переписували код, а клієнт був під ризиком зірвати демо для інвесторів. Фактично, інші наші розробники терміново мусили відірватися від своїх задач, щоб якось урегулювати ситуацію яку ця людина створила.
Як ми намагалися вирішити ситуацію і що з цього вийшло
Після повного ігнору комунікації та зриву делівері ми прийняли рішення про розрив відносин за порушення умов договору одним днем. Це був перший такий випадок активації певних пунктів договору. Вперше за 13 років. Мені завжди було легше в усіх конфліктах просто заплатити і зекономити нерви.
Важливо уточнити, що спочатку ми намагалися виправити ситуацію кілька разів і різними способами.
По-перше, ми дали час. Попри перші проблеми, людина отримала повну зарплату за перший місяць. Ми очікували, що з часом він втягнеться в процес і вирівняє темп.
По-друге, ми підключили менеджмент і технічну підтримку. Були регулярні розмови: зі мною, з HR та з техлідом. Ми напряму проговорювали проблеми: відсутність прогресу, ігнорування задач, дивну поведінку з комунікацією, використання AI без контролю. Людина отримувала чіткий фідбек і попередження.
По-третє, ми дали можливість виправитися. Навіть після зриву делівері і перших серйозних проблем, ми не закрили питання одразу. Ми очікували хоча б базової відповідальності: вийти на зв’язок, пояснити ситуацію, запропонувати рішення. Ну і можливо якогось людського — вибачте, що так вийшло (в ідеалі, звичайно).
Цього не сталося і тому ми попрощалися з цим розробником. Тут питання вже було не в конфлікті між компанією і людиною, а в відповідальності перед клієнтом і командою.
Висновки: як компаніям захиститися від подібних випадків
Сам факт зловживання AI не був найважчим для нас. Найважчим уроком було те, що толерантність до проблем на старті коштує дорожче, ніж швидке рішення.
Якщо людина з перших тижнів: уникає відповідальності, не комунікує, та не виконує свої обов`язки, а маскує все згенерованим кодом, ситуація не покращиться. Тому потрібно одразу припиняти співпрацю, щоб уникнути проблем (а вони будуть 100%).
Сподіваюся, наша ситуація стане для когось цінною інформацією та допоможе визначити чи ваші працівники зловживають ШІ. Ми, на жаль, на собі відчули скільки шкоди всього за два місяці зможе завдати людина, яка нехтує своїми обов`язками.
Ми не вважаємо цей кейс унікальним. Навпаки — таких історій стає більше. Ось кілька основних пунктів, з нашого досвіду, як вберегтися від подібних ситуацій:
1. Проговорювати правила ще на співбесіді.
На співбесіді має звучати прямо і без двозначностей, що саме ви очікуєте від кандидата. Наприклад, для нас, це — не більше одного фул-тайма (так, це також на жаль треба проговорювати).
Також ми очікуємо реальну залученість і відповіді у чатах протягом 20-30 хвилин у робочий час. Це дозволить одразу відсіяти мультифултаймерів.
2. Не забороняти використання ШІ, але обмежувати правилами.
Розробляйте чіткі політики та інструкції використання ШІ. У ваших політиках має бути чітко прописано:
- що вважається допустимим використанням AI;
- хто несе відповідальність за результат;
- що код має бути зрозумілим автору, а не просто згенерованим.
Ми вже додали цей пункт у наші правила співпраці.
3. Фокусуватися не на годинах, а на делівері.
Повинні бути регулярні проміжні результати, а також короткі і зрозумілі чекпоїнти. Якщо за 8 годин роботи людина встигла лише змінити колір кнопки — це не ОК.
4. Прозора комунікація — обов’язкова.
Мовчання, зникання одразу перед колами, виправдання, мовляв, потім зроблю, або Сиджу без світла. В Польщі (і я, який читаю це з Харкова 🙃) — це вже сигнали непрофесіоналізму та безвідповідальності.
Зараз ми одразу домовляємося про прозорість роботи ще під час співбесіди. Окрім делівері, важливо одразу проговорювати як саме людина працює:
- Що нормально — показувати проміжний прогрес, обговорювати рішення, ставити питання.
- Що не нормально — зникати на 3 дні, з’являтися лише з готовим результатом і не пояснювати, як він був отриманий.
5. Перевіряти розуміння логіки розробки.
На старті важливо дивитися на те, як людина пояснює свої рішення, чи розуміє вона, що саме здала, а також чи зможе швидко відповісти на запитання по своєму PR. AI-код дуже добре видно, коли людина не може пояснити, як він працює.
Якщо у вас є схожий досвід, поділіться, будь ласка, як ви виходили з таких ситуацій і як себе вберігаєте від подібного. Буду вдячний за фідбек.