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

Давайте подивимося, який стан зараз. Для цього мені потрібно познайомити вас з концепцією, яка викликає роздратування у більшості менеджерів, продактів та інших бізнес персон - production ready code(PRC). PRC це код, який готовий для роботи в застосунку, який взаємодіє в реальному середовищі з реальними користувачами. Це код, який не просто робить основні очікувані дії(як прототип), а коректно працює на будь-яких вхідних даних, витримує заплановане навантаження, відповідає хоч якимось стандартам кібербезпеки, а також є підтримуваним, тобто написаний таким чином, щоб доповнювати його новим функціоналом та шукати в ньому баги було відносно нескладно. В деяких доменах ще можуть бути якісь стандарти та регуляції, яким застосунок повинен відповідати. Написати код, який одночасно відповідає всім цим вимогам не так просто, тому нормальна ситуація, коли продакшн реді рішення розробляється в десять разів довше за прототип. Так от, сучасні LLM-помічники зовсім не вміють писати PRC. Прототипи - так. Скрипти, які виконаються один раз на чітко визначеному наборі даних - можливо. Щось продакшн-реді - хєр. Що ще гірше, вони не підтримують код. Copilot та Claude, наприклад, не можуть нормально шукати по файлам проекту. Тобі треба руками вказати конкретний файл з кодом, щоб вони його проаналізували. Cursor вміє, але дуже обмежено. Коли проект невеликий, то ще якось шукає, але навіть на small-to-middle розмірах вже починає страшенно галюцинувати. І це притому, що Cursor використовує tree sitter - бібліотеку для детерміністичного парсингу коду та будування синтаксичних дерев(для не технарів - Cursor розглядає код не просто як текст, а й додає смисловий контекст), але все одно не робе. Це схоже на те, як періодично LLM-чати з розумним видом несуть повну маячню, але різниця в тому, що код вимагає бути коректним. Короче, прототипи - так, продакшн реді - ні.

Окей, скажете ви, LLM не можуть генерувати коректний код зараз, але зможуть генерувати продакшн реді код пізніше. Он як вони швидко розвиваються. А тепер підіть і подивіться на графік в першому коментарі. Це статистика публікації нових питань на Стековерфлоу. Ви вже знаєте, що таке СО і бачите, що справи ідуть не дуже. І це логічно, бо навіщо питати на СО і чекати годину чи добу на відповідь, якщо можна спитати ChatGPT і отримати відповідь миттєво, або взагалі попросити Copilot зробити роботу за тебе. Я не бачив всеосяжної статистики по юзергрупам та іншим комьюніті розробників, але в тих, де я знаходжусь, ситуація подібна. До чого тут статистика СО? Та до того, що Стековерфлоу був основним джерелом даних на яких LLM тренувались в кодінгу. Це вже розмічені дані, де питання людською мовою окремо, відповідь окремо, код теж окремо. А раз люди перестають питати на СО та юзергрупах, то на основі яких даних будуть вчитися ЛЛМ? Особливо, коли це стосується нових технологій. Однієї офіційної документації явно не вистачить, ШІ тренується на великих об”ємах даних, плюс йому потрібна людська кмітливість для перетворення бізнес-кейсів та специфічних ситуацій на код. Охуєнно виходить, Стековерфлоу задізраптили, коммьюніті задізраптили, а далі що? Типова ситуація саранчі, або, як зараз прийнято казати - бліцскейлінгу. Тому, сорян, але для того, щоб ШІ-Бог ріс і розвивався, йому потрібні постійні масові гекатомби зі знань шкіряних мішків, і я не бачу опцій одночасно мати доступні LLM і підтримувати QnA юзергрупи.