Безсилля сильних: вплив АІ на дистанції
Мабуть, усі ми помічали за собою небажання робити якусь певну річ або дію після того, як спробували виконати її за допомогою штучного інтелекту (далі — АІ).
Сьогодні АІ — це передовий інструмент для підвищення ефективності роботи, про що свідчать численні дослідження. Зокрема, в Anthropic виявили, що АІ здатен пришвидшувати виконання певних завдань до 80%.
Проте чи існує «зворотна сторона медалі»? Чи справді використання АІ приносить лише позитивні результати?
Особистий досвід
На попередньому місці роботи мені часто доводилося писати офіційні та складні листи. Коли з’явився AI, я зрозумів, що цей інструмент робить аналогічні завдання достатньо якісно і без помилок, з мінімальним рев’ю.
Згодом настала моя професійна ера в OBRIO як Marketing Operations Lead, де спершу всі підходили до впровадження АІ з обережністю. Проте з часом, підігріта ефектом «Fear of missing out» (далі — FOMO), дедалі більша кількість людей почала використовувати АІ майже в усіх сферах роботи: від аналізу ризиків до написання мікросервісів. Це швидко дало результати, і менеджмент отримав чіткий сигнал: «Це воно!».
Розробивши низку AI-рішень для маркетингу (наприклад, МСР на Golang) та здобувши перемогу в конкурсі на найвпливовіше для бізнесу рішення, я замислився: що саме я здобув у цьому процесі та як це вплине на моє становлення як професіонала?
Таким чином народилася ідея для цієї статті: спробувати спрогнозувати, як подальший розвиток тренду у використанні АІ вплине на персональні навички індивіда і як запобігти деградації цих скілів при надмірному використанні АІ.
Варто зазначити, що я намагаюся уникати ресентименту — явища, яке блискавично описав Макс Шелер у своїй роботі «Ressentiment» і яке, на мою думку, є надмірно актуальним щодо АІ. Тобто я розумію та повсякденно використовую бенефіти АІ для бізнесу та ефективності працівника, але водночас прагну, щоб це не сповільнювало мій розвиток як професіонала.
Проблематика
Чи виникає негативний ефект, коли працівник «делегує функцію мислення» — тобто стає менш залученим у процес та докладає менше зусиль для досягнення певного результату?
Так, аналізуючи результати нещодавніх досліджень, можна стверджувати: інженер, який використовує АІ на постійній основі, гірше засвоює нові знання. У довгостроковій перспективі це може призвести до погіршення загальних результатів роботи, незважаючи на допомогу АІ. Якими можуть бути практичні наслідки? Наприклад, ситуація на зображенні нижче.

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

Джерело: Anthropic
Методологія експерименту
Дослідження проводилося у форматі рандомізованого контрольованого експерименту, в якому взяли участь 52 Python-інженери.
Учасникам поставили завдання: вивчити та застосувати на практиці нову для них бібліотеку асинхронного програмування (Trio). Їх поділили на дві групи:
- Перша група виконувала завдання з використанням AI-асистента.
- Друга (контрольна) — самостійно, без допомоги AI.
Ключові результати
- Деградація навичок. Використання AI негативно вплинуло на концептуальне розуміння матеріалу, здатність читати чужий код та навички дебагінгу.
- Провал на тестах. Під час фінального тестування розробники з першої групи набрали на 17% менше балів, ніж контрольна група (50% проти 67%). Найважче їм давався пошук помилок у коді.
- Ілюзія продуктивності. AI-асистент не дав суттєвого виграшу в часі. У середньому група з AI витратила на завдання стільки ж часу, скільки й інженери без нього.
- Делегування vs Навчання. Ті, хто повністю переклав написання коду на AI, виконали завдання трохи швидше, але ціною «навчального ефекту» — вони фактично не засвоїли роботу з бібліотекою.
- Важливість патернів взаємодії. Дослідники виділили 6 моделей співпраці з AI. Лише три з них, що вимагали високого когнітивного залучення інженера, не шкодили процесу навчання.
Що ми можемо винести з цього дослідження?
Найголовнішим є той факт, що глибоке засвоєння навичок та надмірне покладання на АІ — це діаметрально протилежні речі, які не компенсують одна одну.
Більше того, надмірна залежність від використання АІ-асистентів та «делегування мислення» під час вивчення нового суттєво гальмують професійний розвиток. Саме тому, високі бали у фінальному тесті здобули лише ті інженери, чиї патерни співпраці з АІ вимагали активного та глибокого «мислення». Тобто, якщо учасник просив пояснити концепції або не рухався далі, допоки не прочитав та не осмислив написане, він дійсно навчався та здобував необхідні навички. Саме це забезпечило високі бали на фінальному тесті.
Яке практичне застосування цих знань?
У світі, де все частіше лунають монологи СЕО Nvidia та гучні заяви на кшталт «The Death of Software Development», варто бути насторожі щодо можливих викликів та небезпек, котрі несуть ці зміни.
Якщо сліпо слідувати трендам і вважати, що не потрібно розвиватися або докладати зусиль для вивчення нового, адже АІ «і так все нормально сам зробить», можна опинитися у глухому куті. Коли комплексність певних рішень зростатиме, відсутність фундаментального розуміння причин та наслідків призведе до неможливості вирішувати складні задачі та, як наслідок, вміння «мислити».
Таким чином, якщо наразі використання АІ-рішень підвищує ефективність фахівців різною мірою, то незабаром може настати момент, коли почнуть виконувати задачі або вирішувати певні виклики «стандартизовано погано». Тобто, небажання навчатися та покращуватися призведе до того, що більшість буде генерувати приблизно однакові, посередні результати. Як наслідок, зникне той самий фактор, що відрізняв геніального інженера від пересічного.
Тобто, якщо не намагатися мислити та аналізувати написане, можна потрапити у замкнене коло, коли попри покращення АІ, він фактично почне вчитися на власному посередньому коді. У результаті відбудеться модельний колапс, що призведе до нескінченної деградації якості.
Чи є вихід з цієї ситуації?
Human in the loop
Шукаючи вихід із подібної ситуації, потрібно спершу визначити власну позицію щодо цього питання. Одним із варіантів визначення може бути саморефлексія, наприклад, використання принципу «категоричного імперативу» Канта.
Отже, варто себе запитати: «Чи хочу я, щоб кожна людина у світі використовувала АІ без додаткового аналізу або без залучення власного критичного мислення?»
Кожен може дати відповідь на це питання самостійно. Проте ми також можемо спробувати спрогнозувати, наприклад, якою б була відповідь на це питання CEO Nvidia. Швидше за все, він би теж не погодився з таким твердженням.
Тепер, розуміючи позицію, можна спробувати знайти вирішення цієї проблеми. Так, одним із дієвих методів тут виступає фреймворк «Human in the loop». Що саме він собою являє та якими є його практичні застосування?
Головний принцип «Human in the loop» — це відповідальність. Відповідальність за кожен рядок, результат, баг чи ефект. Деякі ентузіасти АІ вважають, що присутність людини в циклі АІ — це лише тимчасове обмеження, ботлнек, який незабаром усунеться. Насправді ж, це не обмеження, це — суть процесу.
Розглянемо два приклади застосування цього принципу у User Acquisition Manager’і (далі — UAM) та в розробці.
AI в розробці
У вищезгаданій статті «The Death of Software Development». Майкі Арналді наводить аргумент про «термінал Bloomberg» (програмне забезпечення для перегляду актуальних фінансових даних): «If an idiot like me can clone a product that costs $30k per month in two hours, what even is software development?»
Відповідаючи на це запитання, можна звернутися до статті Матео Коліна (ключового меінтейнера Node.js), де він дещо екстраполює це питання далі: А хто є відповідальним за неочікуваний баг у програмному забезпеченні Майка, через який користувач укладе програшну угоду щодо купівлі/продажу цінних паперів? Хто розуміє едж-кейси цього інструмента? Хто зможе задебажити цей баг, якщо він покладе прод о 3 ранку?
Матео намагається донести думку, що «термінал Bloomberg» цінний не тому, що його важко написати. Він цінний тому, що за ним стоять професіонали, які володіють контекстами фінансових ринків, розуміють регуляторні обмеження, цілісність даних та системну архітектуру. Це люди, що завжди можуть підтримати рішення та виправити будь-яку проблему.
Здається, тут починає звучати основний мотив роздумів минулих років: код — це не актив, а зобов’язання. І з цим важко не погодитися, маючи певний досвід розробки софту.
Отже, наразі ботлнек полягає не у швидкості написання коду (що блискуче робить АІ), а у можливості його якісно оцінити та провалідувати. І, на думку Матео, це так яу має бути завжди.
АІ в маркетингу
Тепер спробуємо розглянути сферу, яка є ключовою та фундаментальною в межах екосистеми Genesis — перформанс-маркетинг. Як тут відбувається перехід та адаптація до АІ?
Якщо аналізувати сферу UAM та тренди останніх місяців, часто лунає думка, що UAM — це напрям, який цілком можливо повністю автоматизувати, адже загалом це повністю рутинні дії.
Чи є сенс у цьому твердженні та чи можна його зрозуміти? Однозначно так. Якщо спостерігати за діями типового UAM’а, видається, що це просто набір автоматизовано-рутинних дій, котрі виконуються за умови досягнення певними показниками визначених порогів.
Проте мало хто замислюється, що насправді глибинна задача UАМ’а — це знаходити патерни та логічні принципи у динамічному та постійно змінному середовищі аукціону. Відповідно, впровадження АІ — це гіперболізація цього процесу. Це може призвести до таких неочікуваних наслідків, як нераціональне витрачання бюджету, неспроможність адаптуватися до нових ринкових умов або змінити методологію прийняття рішень.
Саме тому, якщо провести паралель зі статтею Матео, виникають питання: А хто є відповідальним за неочікуваний збій у роботі такого агента, в результаті якого витрачаються мільйони доларів у від’ємну окупність? Хто розуміє обмеження цього інструмента та може вберегти його від ризикованих кроків, як-от раптового видалення Х кампаній? Хто зможе змінити алгоритм його роботи у разі неочікуваних змін аукціону (як наприклад нещодавно сталося з приходом Андромеди)?
З огляду на це, ми знову доходимо висновку: ботлнек криється не у швидкості прийняття рішень (яку реактивно забезпечує АІ), а у якості цих рішень, спроможності їх правильно оцінити та провалідувати принцип дій. Тобто справжньою цінністю є володіння контекстом та здатність гнучко адаптуватися до нових ринкових умов — особливо враховуючи, що здебільшого UAM працює саме з невизначеністю алгоритмів. Отже, в цьому випадку присутність наглядача (чи то UAM, чи менеджера агентів) є критичною задля досягнення довгострокового бізнес-результату. Принцип «Human in the loop» тут — не вибір, а необхідність.
Якщо дотримуватися такої логіки і надалі, постає нове питання: якщо присутність людини необхідна, то як це відобразиться на ринкових трендах та чи змінить їх?
Нові ринкові тенденції
Відповідь на це питання є доволі простою — змінилося все. В осяжному майбутньому інженери проєктують та оркеструють високорівневі системи та технології, а UAM є оркестратором маркетингових агентів, які виконують типові задачі з управління рекламою.
Що зникає, так це роль фахівця, який просто брав задачу з Jira, виконував її та на цьому завершував робочий день. АІ зможе виконувати цю саму роботу швидше, ефективніше та дешевше. Саме тому на даному етапі навички «мислення та залученості» є критично важливими в подальшому майбутньому кожного професіонала.
Однак впровадження АІ у робочі процеси має бути дуже обережним, щоб не втратити довгострокову експертизу співробітників, особливо у сферах, де ціна помилки є високою.
10 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівДействительно, статья глубока! Видно что автор много размышлял над темой, респект.
Но я хотел бы разделить несколько проблем упомянутых в тексте, потому как решать их по отдельности легче.
1. Использование AI инжинерами. Здесь, я для себя четко отделяю потребности компании и мои личные. Работа должна быть сделана в срок с приемлимым уровнем качества. Это закон, который нельзя нарушать, потому как — бабки правят этим миром (социумом). И в общем случае, компании плевать на твою экспертизу и как ты это сделал. Пока этот закон выполняется все будут доволны. Но не плевать мне — как исполнителю, и действительно можно слишком сильно положится на AI, так что это закончится в итоге плачевно. И менно поэтому в моих интересах использовать IA не только в целях компании, но идля самоубочения и развития. Степень этого каждый решает длясебя сам.
2. Проблема Accountability, которую никто пока не нрешил. Ну, тут добавить нечего — вопрос открыт. Кто будет отвечать за ошибки в нагенерированном IA коде.
3. Human in the loop. На данный момент, я согласен с автором мы действительно должны быть в цикле, со всеми нашими экспертными знаниями, однако долго ли ?! — это зависит от токак как быстро AI станет достаточно умным что бы перенять и эту функцию. Я лично думаю что скоро, что идущая сейчас гонка AI, только в начале, и через 3 самое больше 5 лет нам нужно будет переотвечать на все заданные в статье вопросы по новой.
Крута стаття, дуже дякую за працю!
Класна та актуальна тема! Дякую, є над чим замислитися :)
На мою думку, там трохи інший ефеткт.
Це ефект низкього засвоєння знань рівня «як викопати 1 куб землі палкою нової форми», коли поруч стоїть автоматичний ескаватор.
Знання нових фреймворків і ліб принципово вже не потрібні.
А під кубом землі прокладено електричний кабель.
А потім те, що нагенерила аішка — не запускається взагалі ніяк, бо unknown method RunApp()
ідеш дивитися доку — не існує такого методу
кажеш про це АІшці — «так, ти абсолютно правий! ось виправлений код»...
... і в ньому знову вигадані методи! Гарного дебагу 🙂
Це було у2023-му.
Ви здивуєтеся, мабудь, наскільки уперед зрушився ШІ з того часу.
я сьогодні тестував 4 тули для генерації прототипів (версел, ловабл, аістудію, та клод дезайн)
і там далі вилазять тонни лайна на кожному другому кроці
я б навіть сказав, лайна десь так само як раніше але всі прототипи створються в рази швидше і можна це скоріше вирішити)
У меня буквально сегодня claude code 4.7 выпилил пару конфигов с кафка коннекторов при миграции с терраформа на стримзи. При том что всё в гите, в соседней папке, и большинство конфигов он правильно стащил. Он просто решил что они не нужны, хотя я прямо сказал просто возьми конфиги как есть. Вперёд-то он шагнул, но галюны это фундаментальная проблема и она никуда не уйдёт.
ага, а ви спробуйте запитати не щось банальне, а щось про бібліотеку у якої 100 зірочок на гітхабі. замість чесно признатись «та я хз», в 100% випадків аішка просто вигадає методи/функції/конфіги/класи