Я думав півроку, тестував різні LLM, спілкувався з різними людьми на різних посадах, і тепер я впевнений, що ШІ справді замінить програмістів в компаніях. Але вам це не сподобається.
Перед тим, як перейти до конкретно айтішних тем, я хочу згадати книгу “Зосереджена робота” Кела Ньюпорта, яку я прочитав нещодавно. Автор пише про майже втрачену нині навичку працювати зосереджено. Він спирається на дослідження про те, що соцмережі, хто б міг подумати, руйнівно впливають на нашу здатність зосереджуватись. А, найголовніше, він згадує про те, що у нульові під час первинного буму соцмереж менеджмент вимагав від людей різних професій, наприклад, журналістів, вести соцмережі замість того, щоб зосереджено та продуктивно писати статті. Отже токсичні робочі практики посприяли руйнації фокусування навіть у тих, хто не хотів сидіти в соцмережах.
Тепер щодо програмування. Програмування складається з двох частин - прийняття рішень та написання коду. Уявимо, що перед програмістом стоїть задача - записати данні з csv файлу в таблицю в базі даних. На перший погляд все виглядає просто:
1. Читаємо з файлу
2. Формуємо sql-запит
3. Відкриваємо з’єднання з БД, пишемо в неї
4. Оброблюємо помилки типу обриву з’єднання, неспівпадіння формату даних і т.п.
Хороший джун впорається з таким без проблем. Але є нюанс. Пункт один працює лише тоді, коли вміст файлу влізає в оперативну пам’ять. А якщо файл не влізе в оперативку? Можна читати порядково і записувати кожен рядок. Можна читати батчами по 10-100-1000 рядків. Код стане складніше, додадуться нові типи помилок, що треба обробити, більше коду - більше багів і складніша підтримка. Тому розробнику бажано не тупо закладуватись на те, що файл не влізе, а зрозуміти - чи може виникнути така ситуація і не ускладнювати код, якщо ні. А це залежить від того, що саме в файлі - якщо там дані по користувачам які заходили на сайт за місяць, то може і не влізти. Якщо ж там якісь статуси агреговані, наприклад, по країнам, то їх ніколи не буде багато. Відповіді на подібні питання і є прийняттям рішень. Важливо розуміти, що зазвичай питання розглядаються не на наочному абстрактному рівні файл-БД, а більш специфічному, типу в тебе є модуль такий і модуль сякий, і треба розробити третій модуль, який використовує перші два і робить шось ще. Прийняття рішень це і є основна інтелектуальна робота програміста, яка поїдає ресурси мозку. Писати ж код, коли ти прийняв всі рішення доволі просто і ненапряжно. Хоча, звісно, займає час.
Так от, ШІ-ентузіасти уявляли собі, що розробник буде приймати ці рішення, писати їх в чат, а LLM швидко напише код, економлячи час розробника. Але я(як і всі мої знайомі) цього не бачу. А бачу я, що навіть сіньйорні програмісти просто хуярять в ChatGPT/Claude/Copilot/Cursor запити типу “запиши мені файл в базу”, а потім підчищають згенероване. Тобто все відбувається рівно навпаки - машина займається інтелектуальною діяльністю, приймає рішення, а шкіряний мішок виконує некваліфіковану роботу дрібного кодфіксінгу! А що відбувається з мозком людини, яка перестає приймати рішення в своїй експертний сфері? Мозок відвикає і людина губить навички. Тому я вважаю дуже вірогідним, що ШІ таки зрівняється з більшістю програмістів. Не тому що LLM розвинуться до рівня сучасного сіньора, а тому що сіньори заредьюсять самі себе до рівня сучасних LLM.
Чому навіть досвідчені розробники займаються подібною самодеградацією? Тому що наш мозок воліє зберігати енергію. Тому що вони втомлені. Тому що в них і так хуйово з фокусуванням через соцмережі. Тому що в айті є культура “не ледацюга, а оптимізатор” і вона крута сама по собі, але ШІ по суті її хакає. А, найголовніше, тому що від них цього вимагають або дуже скоро будуть вимагати. Зараз менеджери та компанії змагаються між собою, хто швидше та глибше інтегрував ЛЛМ у процеси розробки. На першому етапі це були лише публікації репортів, які всі дофіга прогресивні, але зараз йде вже масове впровадження різних ЛЛМ-помічників, ліцензії на які зовсім не безкоштовні. А якщо компанія витрачається на ліцензію, то керівництво починає вимагати віддачі від витрат, а конкретніше - помітного збільшення швидкості розробки. Тому йде тиск на менеджерів нижніх ланок і відповідний тиск на розробників. Не бачиш користі від ШІ-помічника і не хочеш ним користуватися? Нікого не їбе, користуйся. Користуєшся і не демонструєш прискорення розробки на третину? Нікого не їбе, ріж кути. В результаті все більше і більше розробників буде різати кути за допомогою ШІ-помічника, перекладувати все на нього і деградувати. В цьому я бачу схожість з інвазією соцмереж, де саме робочі практики посприяли руйнації здатності зосереджуватись.
Буквально вчора я прочитав пейпер “AI Meets the Classroom: When Do Large Language Models Harm Learning?”[1] Його автори літом 2024 проводили серію досліджень про вплив використання ЛЛМ на розвиток навичок програмування. В першому дослідженні вони виявили, що у студентів, які використовували ChatGPT для відповідей на деякі питання, загальна оцінка по іншим питанням нижча. В другому і третьому дослідженні вони проводили контрольований лабораторний експеримент з вивчення пайтону. Вчені визначили, що, якщо студенти звертались до ЛЛМ за поясненнями, то це трішки покращувало їх розуміння теми. Якщо ж студенти просили ЛЛМ дати їм готові рішення, то вони опрацьовували більше тем, але мали поверхневі знання. Важливою відмінністю було те, що у другому дослідженні було системно заблоковано використання copy-paste команд, а в третьому - дозволено. Відповідно кількість студентів, що зверталися за рішенням, а не роз'ясненням зросла з 40% до 60%. Це повноцінне неупереджене наукове дослідження зроблене вченими з урахуванням додаткових факторів, статистичних погрішностей і тому подібних речей. Воно збігається з тим, що бачу я, з загальними теоріями про навчання, роботу мозку та інтелектуальну дисципліну. З чим воно не збігається? З бравурними репортами корпорацій та менеджерів, які є зацікавленими сторонами.
Один з аргументів проти деградації, який я чув від інших розробників, це Стековерфлоу. Якщо хто не курсі, це велика спільнота, де ти можеш задати питання на айтішну тему, включаючи доволі специфічні речі, типу “чому ця бібліотека версії трьорічної давнини не працює так, як мені хотілося б?” і отримати відповідь. Є навіть такий мем як stackoverflow-driven-development, типу ця спільнота основний генератор коду. І контраргумент полягає в тому, що девелопери не деградували після появи СО. По-перше, у нас немає даних стверджувати, чи деградували, чи ні. А по-друге, СО має доволі жорстку політику модерації, згідно якої ти не маєш писати запити типу “зробіть роботу за мене” і твоє питання повинно бути корисне іншим, тобто більш менш абстрактне. Інтегрувати код, який тобі порадили в СО зазвичай потребує деякого розумового процесу. Користувачів СО можна порівняти з тими студентами з дослідження, які використовували ШІ виключно для роз'яснень. В той же час найпоширеніше використанням ЛЛМ в розробці - це як раз типове “зроби роботу за мене”, тому їх масове впровадження приведе до принципово іншого ефекту.
Інший аргумент, який я чув в основному від менеджерів, полягає в тому, що нехай деградують, все одно скоро ми їх всіх звільнимо і замінимо на ШІ. Типу є дві умовні криві - одна на деградування девелоперів, інша на розвиток ШІ і ризик лише в тому, що можливо ці криві перетнуться занадто низько чи пізно. А так як віримо в ШІ, то ризик хоч і є, проте мінімальний. Та чи розвинеться ШІ настільки, щоб замінити сучасних сіньорів?
Давайте подивимося, який стан зараз. Для цього мені потрібно познайомити вас з концепцією, яка викликає роздратування у більшості менеджерів, продактів та інших бізнес персон - production ready code(PRC). PRC це код, який готовий для роботи в застосунку, який взаємодіє в реальному середовищі з реальними користувачами. Це код, який не просто робить основні очікувані дії(як прототип), а коректно працює на будь-яких вхідних даних, витримує заплановане навантаження, відповідає хоч якимось стандартам кібербезпеки, а також є підтримуваним, тобто написаний таким чином, щоб доповнювати його новим функціоналом та шукати в ньому баги було відносно нескладно. В деяких доменах ще можуть бути якісь стандарти та регуляції, яким застосунок повинен відповідати. Написати код, який одночасно відповідає всім цим вимогам не так просто, тому нормальна ситуація, коли продакшн реді рішення розробляється в десять разів довше за прототип. Так от, сучасні LLM-помічники зовсім не вміють писати PRC. Прототипи - так. Скрипти, які виконаються один раз на чітко визначеному наборі даних - можливо. Щось продакшн-реді - хєр. Що ще гірше, вони не підтримують код. Copilot та Claude, наприклад, не можуть нормально шукати по файлам проекту. Тобі треба руками вказати конкретний файл з кодом, щоб вони його проаналізували. Cursor вміє, але дуже обмежено. Коли проект невеликий, то ще якось шукає, але навіть на small-to-middle розмірах вже починає страшенно галюцинувати. І це притому, що Cursor використовує tree sitter - бібліотеку для детерміністичного парсингу коду та будування синтаксичних дерев(для не технарів - Cursor розглядає код не просто як текст, а й додає смисловий контекст), але все одно не робе. Це схоже на те, як періодично LLM-чати з розумним видом несуть повну маячню, але різниця в тому, що код вимагає бути коректним. Короче, прототипи - так, продакшн реді - ні.
Окей, скажете ви, LLM не можуть генерувати коректний код зараз, але зможуть генерувати продакшн реді код пізніше. Он як вони швидко розвиваються. А тепер підіть і подивіться на графік в першому коментарі. Це статистика публікації нових питань на Стековерфлоу. Ви вже знаєте, що таке СО і бачите, що справи ідуть не дуже. І це логічно, бо навіщо питати на СО і чекати годину чи добу на відповідь, якщо можна спитати ChatGPT і отримати відповідь миттєво, або взагалі попросити Copilot зробити роботу за тебе. Я не бачив всеосяжної статистики по юзергрупам та іншим комьюніті розробників, але в тих, де я знаходжусь, ситуація подібна. До чого тут статистика СО? Та до того, що Стековерфлоу був основним джерелом даних на яких LLM тренувались в кодінгу. Це вже розмічені дані, де питання людською мовою окремо, відповідь окремо, код теж окремо. А раз люди перестають питати на СО та юзергрупах, то на основі яких даних будуть вчитися ЛЛМ? Особливо, коли це стосується нових технологій. Однієї офіційної документації явно не вистачить, ШІ тренується на великих об”ємах даних, плюс йому потрібна людська кмітливість для перетворення бізнес-кейсів та специфічних ситуацій на код. Охуєнно виходить, Стековерфлоу задізраптили, коммьюніті задізраптили, а далі що? Типова ситуація саранчі, або, як зараз прийнято казати - бліцскейлінгу. Тому, сорян, але для того, щоб ШІ-Бог ріс і розвивався, йому потрібні постійні масові гекатомби зі знань шкіряних мішків, і я не бачу опцій одночасно мати доступні LLM і підтримувати QnA юзергрупи.
Давайте зведемо все разом.
1. Розробники деградують перекладаючи все на ШІ.
2. Робочі практики будуть приводити до агресивнішого застосування ШІ повсюди, отже п.1 буде пришвидшуватись.
3. Якщо не буде якісно нового прориву, ШІ не зможе писати коректний код.
4. Руйнування девелоперських комьюніті призведе до подальшої деградації як розробників так і ШІ.
Зверніть увагу, на відміну від інших апокаліптичних прогнозів, які моделюють, що буде, якщо ШІ розвинеться до іншого якісного рівня, я вказую на ризики, які виникнуть, якщо штучний інтелект НЕ перестрибне якимось дивом проблеми галюцинацій, а буде продовжувати розвиватися кількісно, як зараз. Також зверніть увагу на загальну дискусію щодо ШІ. Всі люблять писати про загрози AGI, вискорозвинений інтелект, восстаніє машин і тому подібний кіберпунк. А про загрози типу токсичних робочих практик не пише ніхто, навіть серйозні репорти ЄС, це нудно і нецікаво. Так працює інфономіка.
Як запобігти деградації і які будуть наслідки? Відповідь на перше питання - ніяк. Ну серйозно, подивіться на обличчя всіх цих СЕО, менеджерів та інших технобро, коли вони говорять про заміну девелоперів на ШІ. У них очі горять і хіба що слина з рота не капає(у Маска капає). Вони сплять і мріють, як нарешті позвільняють всіх цих задротів з роздутою зарплатнею і повиписують собі гігантські бонуси за оптимізацію і cost cutting. Немає адекватних способів перемогти корпоративну жадібність. Я вже не кажу про те, що для багатьох це ще й вендетта за роки приниження, коли джоб маркет в айтішці був ринком пошукачів, а не роботодавців. Плюс багато тих самих менеджерів і бізнес людей не вірять в складність розробки production ready коду і щиро вважають цей концепт наїбаловом від технарів. Рішення про масові лейофи вже прийнято. Прийнято не як конспірація, а як відверте бажання десіжн мейкерів. Це золота мрія і ніщо не зупинить цих людей. Неважливо, наскільки заміна буде адекватною - дані будуть підганятися під бажаний результат. Та що там будуть - це вже робиться.
Щодо наслідків, то, звичайно, це буде доволі серйозний удар по розвитку айті-спільнот і айтішки як такової. Роботи буде менше, комьюніті будуть теж менші, джунів вже зараз майже не наймають, тому отримаємо ще й генераційну демографічну кризу. Чи відновиться все в далекому майбутньому? Фіг знає, напевно так, але плюс-мінус десятиріччя потенційного прогресу ми втратимо.
Щодо продуктів та застосунків, то треба розуміти, що загальна акумульована деградація розробників та ШІ скоріш за все буде відносно повільною. Повільною достатньо, щоб менеджери продовжували робити вигляд, що все йде по плану. Так, якість застосунків буде потрохи зменшуватись, але це не перша ситуація, коли автоматизація призводила до загального падіння якості, а користувачів переконували, що все зашибісь. Колись давно індивідуально пошите взуття було доступно куди більшому прошарку суспільства, ніж зараз. Колись не так давно, на сапорті були живі люди, а не примітивні чат-боти(привіт, Дія). Ну буде один раз з двадцяти банкомат списувати гроші з рахунку, а кеш не видавати. Ну буде іноді приходити вам товар що замовили не ви, а людина зі схожим ім”ям, а ШІ переплутав. Нічого страшного, звикнете, воно ж так буде всюди і альтернативи у вас не буде. Точніше буде, якщо ви 1% і користуєтесь хендмейд софтом, написаним бутік-компанією за єбєйші гроші(колись я таку відкрию, знижка по промокоду #apostlecorpwasright).
А от що страшно, це накопичування помилок і некоректностей, поки не йобне. Я маю на увазі каскадну відмову великої частини світової IT-інфраструктури. Сподіваюсь, що це буде просто гугол чи мастеркард, а не АЕС, але я б очікував усього. Я хотів би написати, що після першої катастрофи уряди очухаються, введуть регуляції та дотримування певних стандартів, але дивлячись на те, як розрулюють економічні кризи, я щось не дуже впевнений. Але це вже дуже далекі хащі майбутнього, де може трапитися все, що завгодно.
В мене стійке враження, що подібне нас очікує в багатьох сферах. Всюди буде одне й теж: дізрапшн та/або деградація професіоналів-людей → менше відкритого контенту зробленого цими людьми → деградація ШІ. Але я не розуміюсь на інших сферах, тому пишу про розробку.
І на останок. Дивіться, я не блогер, не ЛОМ, я не публікую прогнози, чи, як кажуть дуже розумні люди, інерційні сценарії. Важлива частина моєї роботи як смузі-архітекта це бачити ризики. Ризики які я бачу - це чотири пункти вище, про них і пишу. Чи наїбнеться все - питання відкрите. Мені здається, що так, але можливо є ще якісь фактори, яких я не помічаю. Я над цим думаю останні півроку, дискутую на цю тему з купою людей і щось поки не помітив нічого, що б наштовхувало на позитив. Можливо ви каментах напишете щось, я б радий був заспокоїтись. Але йобне чи нє, а глобально якість розробки і відповідно застосунків точно просяде, тут прям без варіантів, до чого й готуйтесь. Чи не готуйтесь, є і більш актуальні проблеми.
з.і. Картина намальована людиною-художником на ім’я Lius Lasahido.
Комментариев нет:
Отправить комментарий