Колеги бачать, що ви використали ШІ – Microsoft перевірила, чи оцінять роботу гірше

Позначка про використання штучного інтелекту в робочому завданні може здаватися ризикованою. Якщо колега знає, що код створювався за допомогою ШІ, чи не вирішить він автоматично, що робота гірша, а її автор менш компетентний?

Microsoft Research перевірила саме цей сценарій на 447 інженерах-програмістах. Кожен учасник оцінював однакові фрагменти коду, але поруч із ними змінювалася додаткова інформація: чи було вказано використання ШІ та який рівень досвіду приписували автору.

Результат виявився несподіваним. У досліджуваній організації, де використання ШІ вже було нормалізоване, Microsoft не виявила штрафу за сам факт розкриття використання AI. Натомість інформація про seniority автора суттєво впливала і на оцінку ефективності коду, і на сприйняття компетентності людини.

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

Що саме з'ясувала Microsoft про використання ШІ на роботі

Microsoft не виявила статистично значущого упередження проти коду лише через повідомлення про використання ШІ в досліджуваному середовищі. Натомість позначка рівня автора суттєво впливала на оцінки. Дослідження представлено в межах IEEE Symposium on Visual Languages and Human-Centric Computing 2026.

Учасниками експерименту стали 447 software engineers. Кожен оцінював ті самі чотири фрагменти коду в умовах, де дослідники змінювали інформацію про використання ШІ та seniority автора.

Ключовий висновок Microsoft сформульований обережно: у цьому конкретному AI-normalized середовищі не було виявлено penalty за disclosed AI use. Це не означає, що упередження проти ШІ зникло в усіх компаніях або професіях.

Натомість інформація про рівень автора продовжувала впливати на оцінювання. Тобто проблема змістилася з питання "це зробила людина чи людина з ШІ?" до іншого маркера – "хто саме це зробив?".

Як проходив експеримент Microsoft із 447 програмістами

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

Це within-subjects experiment – дизайн, за якого один учасник оцінює кілька умов. Кожен із 447 інженерів переглянув чотири однакові за змістом code snippets із різними позначками. Microsoft перевіряла два основні сигнали:

1. Інформацію про використання ШІ, вбудовану в commit message.

2. Інформацію про seniority автора.

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

Що таке позначка про використання ШІ

Позначка про використання ШІ – це інформація для рев'юера про те, що під час підготовки роботи автор застосовував AI-інструмент. У дослідженні Microsoft така інформація була вбудована в commit message.

Це вже не суто теоретична ситуація. Інструменти для code review дедалі частіше можуть показувати, чи використовував автор ШІ під час підготовки pull request.

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

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

Чи справді людей більше не карають за використання ШІ на роботі

Ні, такого загального висновку дослідження Microsoft не дозволяє зробити. Воно показало відсутність виявленого штрафу в конкретній AI-normalized організації та в конкретному сценарії code review.

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

Тому твердження "тепер можна спокійно використовувати ChatGPT на будь-якій роботі, ніхто не оцінить вас гірше" було б неправильним.

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

Це добре вписується у ширшу зміну ролі ШІ на роботі. На Gosta вже розібрано, як ChatGPT впливає на технологічний світ і робочі процеси. Коли AI-інструмент стає звичайною частиною процесу, питання поступово зміщується з самого факту використання технології на якість результату та правила її застосування.

Що таке junior penalty

Junior penalty у контексті дослідження – це упередження, за якого інформація про нижчий рівень seniority автора впливає на сприйняття його роботи та компетентності. Сам код при цьому може залишатися тим самим.

У назві роботи Microsoft прямо протиставляє два результати: AI bias fades, але junior penalty persists. Це не означає, що кожного junior-розробника в кожній компанії обов'язково оцінюють несправедливо. Йдеться про ефект, виявлений у конкретному контрольованому експерименті.

Але сам механізм дуже показовий. Рев'юер бачить не лише код – він також бачить інформацію про людину, яка його написала. Якщо ця інформація змінює оцінку однакового результату, виникає проблема незалежності review.

Робота може бути однаковою, а очікування від неї – різними ще до того, як людина завершила оцінювання.

Що виявилося сильнішим – позначка AI чи статус junior

У цьому експерименті Microsoft не виявила значущого штрафу за disclosure використання ШІ, тоді як seniority label суттєво впливав на обидва оцінювані показники. Саме тому статус автора виявився важливішим сигналом.

Найцікавіше тут не те, що "junior програв AI". Ці фактори не є прямими конкурентами.

Важливіше інше: ярлик, який людина бачить поруч із роботою, може впливати на оцінку навіть тоді, коли сама робота не змінилася.

Чому позначка про використання ШІ могла перестати лякати колег

Microsoft пов'язує результат із AI-normalized organization – середовищем, де використання штучного інтелекту вже прийняте як нормальна частина роботи. Коли інструмент перестає бути незвичним, інформація про його використання може втрачати силу негативного сигналу.

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

Саме тому результати Microsoft не можна механічно переносити на будь-який офіс. Корпоративна культура навколо ШІ може бути не менш важливою, ніж сам факт використання ChatGPT, Copilot або іншого AI-інструмента.

Чи означає це, що використання ChatGPT більше не потрібно приховувати

Ні. Дослідження Microsoft не встановлює універсального правила щодо того, коли працівник повинен повідомляти про використання ChatGPT, Copilot чи іншого ШІ. Правильна поведінка залежить від політики конкретної компанії, типу роботи, конфіденційності даних і правил щодо використання зовнішніх сервісів.

Якщо роботодавець вимагає disclosure, його потрібно робити незалежно від того, як колеги потенційно оцінять результат. Якщо компанія забороняє передавати певні дані зовнішньому AI-сервісу, відсутність "штрафу за ШІ" в експерименті не скасовує цю заборону. Для працівника корисно розділяти два питання:

1. Чи дозволено використовувати конкретний ШІ-інструмент.

2. Чи потрібно повідомляти про його використання.

Дослідження Microsoft стосується насамперед другого рівня – як disclosure впливає на сприйняття роботи, а не юридичних чи внутрішніх правил використання AI.

Чи варто зазначати, що текст або код створювався з ШІ

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

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

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

ШІ може допомогти створити результат, але відповідальність за те, що потрапляє у фінальну роботу, не повинна автоматично переходити на інструмент.

Чому junior penalty особливо важливий саме зараз

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

Проблема має два рівні.

• Перший – працівник нижчого рівня може використовувати ШІ для підказок, пояснення коду або швидшого виконання рутинної частини роботи.

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

Якщо seniority label сам по собі впливає на review, це може ускладнювати об'єктивний зворотний зв'язок. Молодший працівник ризикує отримувати оцінку не лише за те, що зробив, а й за те, що від нього очікували побачити.

Чи означає junior penalty дискримінацію молодих працівників

Не обов'язково. Junior у software engineering описує професійний рівень, а не вік людини. Молодший за посадою розробник може бути старшим за віком, а senior-інженер – молодшим.

Тому junior penalty не слід автоматично перетворювати на висновок про вікову дискримінацію. Йдеться про author-seniority labels – інформацію про професійний рівень автора. Саме вона впливала на сприйняття коду та компетентності.

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

Чому однаковий код можуть оцінювати по-різному

Люди не оцінюють інформацію у вакуумі. Ім'я автора, посада, досвід, репутація та інші сигнали можуть формувати очікування ще до детального перегляду результату.

Експеримент Microsoft із seniority label показує саме такий ефект у code review.

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

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

Якщо інформація про автора змінює оцінку незмінного коду, review частково оцінює вже не лише код.

Чи допоможе анонімне code review прибрати junior penalty

Дослідження Microsoft показує, що інформація про автора може впливати на оцінювання, але саме по собі не доводить, що повністю анонімне code review є найкращим рішенням для кожної команди. Такий висновок потребував би окремої перевірки.

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

Тому прибрати всі сигнали про автора технічно не завжди можливо й не обов'язково корисно.

Але результати Microsoft дають сильну причину хоча б перевірити власний процес. Якщо команда бачить, що однакові рішення оцінюються по-різному залежно від статусу автора, варто чіткіше формалізувати критерії review.

Що можуть змінити компанії після такого дослідження

Найпрактичніший висновок для роботодавців – правила використання ШІ та критерії оцінювання роботи потрібно розділяти. Сам факт використання інструмента не повинен замінювати перевірку результату, а професійний статус автора – визначати якість наперед.

Команди можуть переглянути кілька речей:

1. Визначити, коли використання ШІ дозволене.

2. Чітко пояснити, коли потрібне disclosure.

3. Оцінювати результат за однаковими технічними критеріями.

4. Відокремлювати code review від оцінювання загальної професійної компетентності.

5. Перевіряти, чи не впливають статусні ярлики на рішення рев'юерів.

6. Залишати людину відповідальною за фінальний код незалежно від використаного інструмента.

7. Окремо визначити правила для конфіденційних даних і зовнішніх AI-сервісів.

Такий підхід не вимагає ні забороняти ШІ, ні ігнорувати ризики його використання. Він переносить увагу з ярлика на те, що справді має значення – якість, безпеку та правильність результату.

Що дослідження означає для junior-спеціалістів

Для junior-спеціаліста результат одночасно позитивний і тривожний. Позитивна частина – у досліджуваному AI-normalized середовищі disclosure використання ШІ не призвів до виявленого падіння оцінки компетентності.

Тривожна частина – сам junior status усе ще впливав на оцінювання.

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

Практично це означає просте правило: не подавати AI-generated рішення, яке неможливо самостійно пояснити.

Якщо під час code review виникає питання, junior має розуміти, чому рішення побудоване саме так, які в нього обмеження та що відбудеться в крайових випадках.

Чи може ШІ допомогти junior-програмісту стати сильнішим

Так, AI може бути інструментом навчання, пояснення та перевірки, але дослідження Microsoft не вимірювало, чи ШІ прискорює професійний розвиток junior-розробників. Тому цей висновок потрібно відокремлювати від результатів експерименту.

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

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

І це стає ще важливішим у світі, де AI переходить від простих підказок до автономної роботи. На Gosta вже розібрано, як OpenAI Dots можуть працювати за користувача 24/7 без постійних промптів. Чим більше роботи система може виконати самостійно, тим важливішою стає здатність людини перевірити результат, а не просто отримати його.

Чи варто роботодавцю знати, що працівник використовував ШІ

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

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

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

Але тут не можна міняти місцями причину й наслідок. Дослідження не доводить, що введення AI-label саме по собі прибере упередження. Можливо, важливим фактором є вже сформована культура прийняття ШІ.

Чи можна перенести результати Microsoft на тексти, дизайн і маркетинг

Напряму – ні. Експеримент проводився з інженерами-програмістами та code review, тому його результати не можна автоматично переносити на копірайтерів, дизайнерів, журналістів, маркетологів, студентів або інші професійні групи.

У різних видах роботи ставлення до AI може відрізнятися.

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

Тому правильне формулювання таке: Microsoft отримала ці результати в конкретному контексті code review в AI-normalized organization.

Це робить дослідження важливим сигналом про те, як можуть змінюватися робочі норми, але не універсальним законом про ставлення людей до ШІ.

Чи впливає ШІ на те, як оцінюють компетентність працівника

У цьому експерименті Microsoft не виявила, щоб disclosure використання ШІ погіршував сприйняття компетентності автора. А ось seniority label мав суттєвий вплив.

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

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

Чому це дослідження важливе саме у 2026 році

ШІ у 2026 році дедалі менше виглядає як окремий експериментальний сервіс і дедалі більше – як частина звичайного робочого середовища. Саме тому питання поступово змінюється з "чи використовував працівник AI?" на "як він його використав і яким є результат?".

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

На цьому тлі простого ярлика "AI used" може бути дедалі менше для оцінки реального внеску людини. Значно важливішими стають відповідальність за результат, перевірка, здатність пояснити рішення та правила конкретної організації.

Що Microsoft не довела цим експериментом

Дослідження не доводить, що упередження проти ШІ повністю зникло, що junior-працівників завжди оцінюють несправедливо або що AI-generated робота має таку саму якість, як робота без AI. Жоден із цих висновків не випливає з описаного експерименту.

Так само робота не відповідає на всі питання про продуктивність. Вона не встановлює, хто написав кращий код – людина без AI чи людина з AI. У центрі експерименту інше питання: як інформація, яку бачить рев'юер, впливає на оцінку однакової роботи.

Це важлива межа. Microsoft досліджує не абсолютну якість AI-generated коду, а людське сприйняття роботи після disclosure та seniority cues.

Що робити працівнику, який використовує ШІ на роботі

Найбезпечніша стратегія – не приховувати використання ШІ там, де правила вимагають disclosure, і не сприймати AI як заміну власній відповідальності. Результат Microsoft дає привід менше боятися самого ярлика, але не скасовує професійних вимог.

Практично варто дотримуватися кількох правил:

1. Перевірити AI-політику роботодавця.

2. Не передавати конфіденційні дані в неавторизовані сервіси.

3. Позначати використання ШІ, якщо цього вимагає процес.

4. Самостійно перевіряти створений результат.

5. Розуміти та вміти пояснити фінальне рішення.

6. Не приписувати ШІ відповідальність за власну помилку.

7. Зберігати людський контроль над критичними рішеннями.

Головна зміна полягає не в тому, що використання ШІ стало "безпечним для репутації". В AI-normalized середовищі сам факт його використання може перестати бути головним критерієм, за яким колеги судять про професіоналізм.

Що результат Microsoft означає для майбутнього роботи з ШІ

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

Але це не означає, що упередження зникають разом із нею. Експеримент Microsoft показав іншу проблему: навіть якщо AI-label перестає впливати на оцінку, інформація про статус автора все ще може змінювати сприйняття тієї самої роботи.

Для компаній це важливий сигнал. Впровадити Copilot, ChatGPT або інший AI-інструмент недостатньо. Потрібно ще вирішити, як оцінювати роботу людей у середовищі, де межа між "зробив сам" і "зробив за допомогою ШІ" стає дедалі менш корисною для визначення реальної компетентності.

А для працівника висновок простіший: професійну цінність дедалі важче вимірювати лише тим, чи користувалася людина ШІ. Значно важливіше, чи може вона відповідати за результат, перевірити його та пояснити власне рішення.