Не можеш щось зупинити — очолуй це.

Ще кілька місяців тому, попри весь гайп навколо LLM, я свідомо уникав їх впровадження в розробку. Судячи з відгуків, я сприймав цю технологію як сирий інструмент, що не піддається контролю, з усіма відповідними проблемами. І оцінював це як справу майбутнього, хоч і недалекого. Впроваджувати таке в робочий процес моєї .NET-команди здавалося несвоєчасним.

Перший дзвіночок: блукаючі шаблонні рішення

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

Я не бачу в цьому нічого страшного, адже завжди можна під час живого спілкування з'ясувати хід думок і мотивацію людини. Проблема в іншому: кандидати, що покладалися на ШІ, практично ніколи не могли пояснити причину того чи іншого рішення. Гірше те, що в них не вистачило кмітливості попросити той самий ШІ перевірити завдання. Тобто, гіпотеза підтверджується: це був «чіт», а не інструмент.

Новий «колега» в команді

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

На риторичне запитання: «Ну і навіщо ти це написав?» — я отримав досить самоіронічну відповідь: — От не знаю, ChatGPT поплутав...

Стало зрозуміло, що в команді з'явився новий «розробник» із високим рівнем авторитету, який не підпорядковується загальним вимогам. Такий собі містер всезнайко. Ігнорувати його появу було щонайменше нерозумно.

Зіткнення з «вайб-кодингом»

Поки ми примірялися: використовувати чи не використовувати, а якщо так — то як, наші колеги вже діяли. Аналітики, DevOps-інженери тощо вже почали вирішувати свої нагальні завдання за допомогою ChatGPT.

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

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

Висновок

У якийсь момент прийшло розуміння: скриньку Пандори відкрито, і цей процес вже не зупинити. Найкращим способом адаптації завжди був принцип: не можеш щось зупинити — очоль це.

Наостанок — кілька слів про мене, щоб ви вирішили, чи варто витрачати час на мої дописи.

Я не можу похвалитися роботою у FAANG, проте більшу частину свого життя я працював на невеликі компанії або створював щось для себе. Кілька років тому я почав розвивати напрям навчання нейромереж, коли це ще не було мейнстримом. Це починалося як невеликий R&D-відділ, і своїм головним досягненням я вважаю те, що цей відділ перетворився на повноцінну компанію.

Мені вдалося не просто передати свій код та інфраструктуру новим співробітникам, а й організувати їхню роботу в рамках нової структури. Гадаю, багатьом відомий страх перед ключовим розробником, без якого все зупиниться. Я радий, що позбувся цього тягаря, і зараз починаю новий етап.

У планах — публікувати суміш ретроспективних дописів (щоб можна було поностальгувати) та матеріалів про актуальні експерименти..